[mkgmap-dev] Splitter Error

Thu Mar 14 10:02:47 GMT 2013

Hi,

I think I have enough info now to continue the work.
I use a variant of the default style for testing, the last for lines look
like this:
#include 'inc/water_polygons';
include 'inc/landuse_polygons';
seamark:type=fairway [0x10302 resolution 20]
waterway=riverbank [0x10303 resolution 20] 

My test file contains the bbox
<bounds minlat="49.7021484" minlon="7.8222656" maxlat="50.1855468"
maxlon="8.4375"/>

My results are a bit different, but I also see better results with the
option switched off.
The use of the prepro changes something in the output file, but that seems
not to change 
the draw order. Reversing the order of the lines in wayorder also changes
something in the img file,
but not the draw order.

The reason seems to be this:
1) Option switched off
Some sub divisions contain only polygons with type 0x10302, some only
contain 0x10303,
some contain both. 
2) Option switched off
All subdivisions that contain a fairway (0x10302 ) do also contain the
riverbank polygon (0x10303)
I tried also with swapped types to make sure that it's not the higher type
value that matters, but that just changed the color to a different blue.
It seems that the Garmin algo choses the larger polygon if it finds two
overlapping polygons in one
sub division.

Conclusion:
Either you need 
a) an algo that makes sure that overlapping polygons are not placed within
the same sub division or b) which cuts the smaller polygon out of the larger
one. I don't know yet where to implement that. 

I have to think about this again...

Gerd

RheinSkipper wrote
>> 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.
> 
> 
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/Splitter-Error-tp5752745p5753107.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.