logo separator

[mkgmap-dev] mkgmap creates polygons that break Mapsource panning and also routing in some zoomlevels as well as crashing the GPS

From Felix Hartmann extremecarver at googlemail.com on Sun Sep 6 08:50:19 BST 2009

Mark Burton wrote:
> Hi Felix,
>> thanks for your work,
> You're welcome.
>> by now I am sure (100%) which polygon was fucking up (as so far as being 
>> the main cause). It's the forest here: 
>> http://www.openstreetmap.org/?lat=47.70079&lon=16.18152&zoom=16&layers=B000FTF. 
>> I have attached a screenshot of it' rendering in Mapsource.
>> If you set detail level to lowest, decrease the mapsource window size 
>> (e.g. to 240x240 pixels only), and then pan to it, you will notice that 
>> you can still display it partly, but near to the center will crash.
>> It was (I corrected it) connected at around 30 places to streets. On top 
>> of it sometimes lines were parallel in order to draw holes into the 
>> forest, so the intent here must have been to not show it at certain places.
>> Even though this is bad tagging practice, mkgmap should not create maps 
>> that send gps into rebot/crash, and also send mapsource 6.13.7 and 
>> before into big problems.
>> I am sure it was not the POI index overflowing, but has to do with nodes 
>> shared between streets and polygon.
> Lots of maps share nodes between roads and polygons and don't have
> problems so there's more to this than just that.
>> I have no clue why Mapsource suffocates on that forest if streets are 
>> attached to it in osm database. Excluding rendering of the streets that 
>> shared nodes with the forest would have the same effect as not rendering 
>> the forest at all or skipping rendering another forest that was partly 
>> overlaying at the same place.
> Not sure what you're saying here. Did you mean that you could generate
> a map that had either the forest or the streets but not both together?
Yes. On top of it without a typfile showing either, it will work too. ( 
I think this is related to the extended types, that (at least the types 
I have chosen) will not display at all if not defined in the .TYPfile.)
>> Well maybe you can still find out, Find in the new download:
>> 1. Again the osm tile (I do hope my edits mean that tomorrow it will 
>> render without problems (disconnected all streets and administrative 
>> boarders, and corrected some of the nearly parallel lines).
>> 2. not working with areas-pois
>> 3. not working without without areas-pois
>> 4. working excluding any rendering of wood=mixed & fixme=* and excluding 
>> landuse=forest & fixme=*, with areas-pois
>> 2-4 consisting of tile plus log.
>> Get files for analysis (35MB) here: 
>> http://openmtbmap.org/downloads/polygon_problem.zip
> Thanks for putting that together. I am studying it but have nothing to
> report at this time.
> Is it easy to produce for me the osm file for just that forest region
> (before your recent edits)? If so, please do that because I would like
> to look at the osm data but the tile you sent me is too big for me to
> load into josm. I guess I could use the splitter on that file to
> extract the forest region.
I will try to split it with very small max-nodes to get the size down, 
and also have a look if todays austria extract compiles clean.
More later
> Cheers,
> Mark
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090906/305b0fb2/attachment.html 

More information about the mkgmap-dev mailing list