[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.
- Previous message: [mkgmap-dev] Splitter Error
- Next message: [mkgmap-dev] Splitter Error
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list