splitter r273 with --precomp-sea parameter
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 -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r273-with-precomp-sea-parameter-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
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
Am 27.12.2012 18:14, schrieb WanMil:
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... Maybe it would be a good thig, if density-map is created by sea-builder
Henning
Henning Scholland wrote
Am 27.12.2012 18:14, schrieb WanMil:
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... Maybe it would be a good thig, if density-map is created by sea-builder
Yes, that would be faster, but requires a lot more changes. I will have a look at the generator when it is clear that the function works as expected. When used with a normal sized file like norway.osm.pbf, this new option adds only a few percent of run time. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r273-with-precomp-sea-parameter-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil,
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. Trimming occurs after the calculation of the tiles, so it would be difficult to use the data at this stage. I did not fully understand why coastline data is added to an otherwise empty area, so I thought it is better to start with something and ask for comments.
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...
Well, good point. I didn't notice that we are talking about more or less constant data. Anyway, this optimization can be done when the usage of the data is correct. Gerd
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. Trimming occurs after the calculation of the tiles, so it would be difficult to use the data at this stage. I did not fully understand why coastline data is added to an otherwise empty area, so I thought it is better to start with something and ask for comments.
Please have a look at the attached image. The green area is the land data contained in the OSM data to be split. The blue area is sea but the left coastline (grey) is not contained in the OSM data. If you trim before merging the sea density the left border of the tile will be the green line. If you trim after merging the sea density data the left border will be the red line because all parts of the grey left coastline is not yet loaded. WanMil
WanMil wrote
Please have a look at the attached image.
The green area is the land data contained in the OSM data to be split. The blue area is sea but the left coastline (grey) is not contained in the OSM data.
If you trim before merging the sea density the left border of the tile will be the green line. If you trim after merging the sea density data the left border will be the red line because all parts of the grey left coastline is not yet loaded.
I think this is very theoretical, but I think I got the point: Try to trim the bbox before adding sea data. Correct? I'll sea if that can be done easily. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r273-with-precomp-sea-parameter-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
Please have a look at the attached image.
The green area is the land data contained in the OSM data to be split. The blue area is sea but the left coastline (grey) is not contained in the OSM data.
If you trim before merging the sea density the left border of the tile will be the green line. If you trim after merging the sea density data the left border will be the red line because all parts of the grey left coastline is not yet loaded.
I've implemented the trimming of the bbox in r275. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r273-with-precomp-sea-parameter-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (4)
-
Gerd Petermann -
GerdP
-
Henning Scholland -
WanMil