Marko Mäkelä <[email protected]> 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.
pgpSma8WosU3Y.pgp
Description: PGP signature
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
