[mkgmap-dev] Sensible resolutions - (or patch 5)

Fri Mar 25 15:45:39 GMT 2011

On Fri, Mar 25, 2011 at 09:16:27AM +0100, Felix Hartmann wrote:
>>Is the "resolution" a mkgmap-only entity, which is mapped to zoom 
>>layers known as "levels" in the IMG file? If that is the case,  
>>wouldn't this change introduce two more zoom layers to the map,  
>>potentially growing the file size?
>Yes, but there is not a lot of information in those zoom levels anyhow.  
>Overall I would say with the patch applied (on my tests) the 
>gmapsupp.img filesize stays the same. But the GPS renders it much
>faster. The additional levels of 19 and 21 really help to make the 
>zooming in much much smoother and the GPS can render the map faster.

I have tweaked your patch a little and will try to experiment futher. I 
already noticed that the Edge 705 draws the polygons much quicker with 
the highest detail. I did not test adding the levels 19 and 21 yet.

I don't like having primary,secondary,tertiary at the same resolution 
(20). I'll see what happens if I lower tertiary and secondary_link to 
resolution 21.

>Yes - that's a typo. But as long as we inside OSM have no real mean of 
>identifying the main railway lines the railways should not be shown as 
>early anyhow.

As we know, the Garmin firmware wants to hide railways when zooming out 
(on the Edge 705, further than 80m at the lowest detail level, further 
than 500m at the highest level). Because of this, this kind of 
translation of major/minor railways would would require a custom 
polyline code and a TYP file. Maybe that code should even be routable, 
so that one can get a nice map display when travelling by train. I have 
sometimes amused myself by using straight-line routing and watching the 
progress of the estimated time of arrival.

Actually, we do have a mean: if there are multiple parallel tracks (each 
drawn as a separate way with railway=*), it is a major railway. It 
should be doable to merge adjacent ways at lower resolutions and sum the 
"weights" of the ways, to decide what to draw. A style file extension 
could be useful, to specify e.g., the following:

* draw individual railways at resolution 24
* merge parallel tracks to one and draw them at resolution 22..23
* merge parallel tracks to one and draw if count>1 at resolution 21
* merge parallel tracks to one and draw if count>3 at resolution 20

For polygons, it could be useful to specify the minimum size that 
qualifies for inclusion in a given resolution. Of course, small adjacent 
polygons would have to be merged together first.

I am beginning to think that it could be useful to have low-resolution 
versions of the OpenStreetMap data, generated by an experimental 
algorithm that attempts to merge polygons and lines as suggested above.  
If it is not too CPU intensive to merge adjacent areas and lines, 
perhaps it could be implemented inside mkgmap after all.

Best regards,

	Marko