Hi Gerd, I haven't tried yet but it seems to be a good idea. Why is the sea density map and the usual density map merged before trimming occurs? My uneducated guess is that it is better to merge after trimming because the areas that could be trimmed should not be left in the tiles only by having some coastline parts. Wouldn't it be better if the sea density map is delivered with splitter? It won't change very much over time and I guess a 90% correct density map would be sufficient. This makes it easier and probably quicker because you don't have to give a path to the precompiled sea files... WanMil
Hi all,
I've committed r273 in the problem-list branch. Besides some cosmetic changes I've implemented a first try to estimate the nodes that mkgmap adds because of the --precomp-sea parameter. If you specify the same parameter in splitter, it will read the precompiled sea files after reading the normal input files. The data is used like this: The density map that is created while reading the normal input covers a bounding box, splitter then reads all sea data that falls into this bounding box and counts the nodes in a 2nd density map. In a final step, it merges the two density maps so that only those areas with 0 nodes in the normal file are changed. Note that this happens before any kind of trimming occurs.
The --precomp-sea parameter is ignored when --split-file is given.
This should fix remaining problems reported eg. by toc-rox: http://gis.19327.n5.nabble.com/Norway-not-buildable-with-the-no-trim-option-...
Please let me know if it works as expected.
Gerd