logo separator

[mkgmap-dev] [PATCH] reduce highway=service resolution

From Greg Troxel gdt at ir.bbn.com on Fri Aug 7 12:58:32 BST 2009

Marko Mäkelä <marko.makela at iki.fi> writes:

> When the resolution of highway=residential was reduced, highway=service
> should have been reduced as well.  It looks odd to see highway=service
> but not the highway=residential that they are connected to.
>
>  highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23]

> -highway=service [0x07 road_class=0 road_speed=1 resolution 22]
> +highway=service [0x07 road_class=0 road_speed=1 resolution 23]

+1

> Please apply this patch.  The resolution of highway=track looks a bit high
> too, but displaying highway=track at low zoom levels could be useful in
> sparsely built areas.

This is really a problem with the tagging scheme; physical properties of
a road do not correlate all that well with the appropriate zoom levels.
The problem is even more acute with footway and path.  I can see two
approaches:

  change tagging to have an importance level separate from physical, to
  be able to mark tracks etc. that should show up more prominently.
  This is likely to be so contentious that I'm going to ignore it

  Somehow have mkgmap (and other renderers) figure out importance from
  topology and context, either

    if there wouldn't be much else on the map in the neighborhood, bump
    up the zoom level at which the track is shown.  (sensible, probably
    hard, and computationally scary)

    have rules that look at the length of the way/relation and use that
    to determine zoom.  A track that is 3 miles long is interesting at
    higher zoom levels than one only 100m long.  This is also true for
    footpaths, which is my main motivation (short city paths vs long
    trails in forests)


So if mkgmap calculated the length of the object and one could use that
in style rules, I bet that would go a long way to getting the
appropriate zoom level.  Perhaps 'wlength' and 'rlength', with the
caveat that it's only the part within this tile and associated overlap
areas that is counted.



    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090807/8beb0a65/attachment.bin 


More information about the mkgmap-dev mailing list