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

Fri Mar 25 16:09:19 GMT 2011


On 25.03.2011 16:45, Marko Mäkelä wrote:
> 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.
you may lower secondary_link and tertiary_link to resolution 21, but I 
would not lower tertiary to 21. It is best at 20 as otherwise incomplete 
"networks" happen. In my own styles I draw all primaries or secondaries 
with and int_ref even one resolution earlier, problem is that loads of 
int_ref are missing for primaries. If they were complete than this would 
be a good mean to separate important primaries from less important ones. 
Anyhow primary is resolution 19, primary link to tertiary link 20.

The main part of the patch for me is anyhow the polygons part. The 
highways file apart from the railways that are plain stupid at the 
resolution given, are no really big changes. (well things like highway=* 
& motorroad=yes should obviously not be at resolution 16 if it is 
neither trunk/motorway, often such roads are inside cities or not so 
important at all, so 18 is already early - one could even move it to 19)
>
>> 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.
We already have that currently set to 8. But 8 is still tiny and patchy. 
The only real solution is joining of polygons and then one could show 
some polygons earlier again. Merging parallel lines would be another 
major thing. Take all motorroads - before resolution 20 one rarely 
notices the different directions. They should be joined by relations in 
OSM data already except for cases where one would like to sea both 
directions early (huge differences on where they are).
>
> 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