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

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