logo separator

[mkgmap-dev] Splitter Error

From RheinSkipper rheinskipper1000 at gmx.de on Wed Mar 13 18:24:13 GMT 2013

> I don't have Mapsource, only Basecamp. I assume that works as well?

Yes, same results. I tried it.


> Where should I find an overlapping polygon which is not correctly
displayed?
> Do you have an OSM id?

162118093 and 174328025 have tob e on top of
143749272 and 4499851 and 30759835

Be sure to use garmin types of equal draw priority! 0x10302 to 0x10306 are
good examples.
Some types (like 0x10105) have higher draw priority (defined in the device´s
firmware/mapsource/basecamp) and are ALWAYS drawn on top.


> I wonder what it means when you say that you cannot control the order with
> the patch.
> At least it seams to have an effect, and "always wrong" seems to mean that
> you have to reverse the order in the input to get a correct result?

I also tried preprocessing in the opposite order. Preprocessing had no
effect at all with the option enabled. But only with big data. With 3 small
polygons it worked.


You can find the preprocessor for sorting xml here:

http://openseamap.svn.sourceforge.net/viewvc/openseamap/garmin/wayorder
http://openseamap.svn.sourceforge.net/viewvc/openseamap/garmin/gsort/gsort.j
ar


Here is a map with option off and random behavior:
http://files.mkgmap.org.uk/download/88/random.JPG
In the upper right rectangle the light blue polygon is covered by the dark
blue polygon, which is incorrect.
The other parts of the map are correct (light blue on top of dark blue).
There is no tile boarder there, so this rectangle must be one of those sub
divisions.

And this is the same map with option on:
http://files.mkgmap.org.uk/download/89/option_on.JPG
Here all light blue polygons are hidden below the darker ones. Preprocessing
has no influence.




More information about the mkgmap-dev mailing list