[PATCH] reduce highway=service resolution
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. 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. Marko Index: resources/styles/default/lines =================================================================== --- resources/styles/default/lines (revision 1122) +++ resources/styles/default/lines (working copy) @@ -46,7 +46,7 @@ highway=primary_link [0x08 road_class=3 highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23] highway=secondary [0x04 road_class=2 road_speed=3 resolution 20] highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] -highway=service [0x07 road_class=0 road_speed=1 resolution 22] +highway=service [0x07 road_class=0 road_speed=1 resolution 23] highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 20] highway=track [0x0a road_class=0 road_speed=1 resolution 21]
Marko Mäkelä <marko.makela@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.
Hi, 2009/8/7 Marko Mäkelä <marko.makela@iki.fi>
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.
steve commited this change: -highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21] +highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23] (rev 1118) and say it's my patch - which isn't true. It think we should set resolution for residential streets back to 21, now is map just 'empty'. If we want to have this set to resolution 23 we need to update more than just service, but parking and track for example too. So i'm voting to set residential back to 21 :]. -- S pozdravem/Best regards Bc. Ondrej Novy Email: novy@ondrej.org Jabber: onovy@njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207
On Mon, Aug 10, 2009 at 09:14:59PM +0200, Ondrej Novy wrote: [...]
It think we should set resolution for residential streets back to 21, now is map just 'empty'.
If we want to have this set to resolution 23 we need to update more than just service, but parking and track for example too.
So i'm voting to set residential back to 21 :].
+1 I maybe started this whole thing by raising building in commit 1109. Despite nobody complaining about this particular one, I now learn, that we should be more careful about just "randomly" changing resolutions. I think residential at 21 is a good "reference point" and we should layout things around this reference point. Like "We only need to see a restaurant after already seeing the residential streets and zooming more in" (random example. I assume restaurants have the right resolution). I don't know, if we really want to go ahead and create more styles directly shipped with mkgmap. Just some random thoughts: Pro: - There are maybe some people who will love some choices for styles to choose from. Like a "car", "bicycle", "foot", "topo", "hiking" ones... - We would probably need to improve our styling to allow more tricky things like "Just change the resolution for this item, but keep everything else". I tried this by adding an appropiate normal rule to the "elrond" style. Guess what? I forgot about the ordering and a higher priority normal rule didn't kick in and routing was b0rked. Con: - We would end up trying to support >6 styles and trying to keep them useful. I wouldn't know at which levels to add a man_made=wastewater_plant (we don't have that one yet) for all those styles above. One could add it in the "common" style first and anyone more familiar with the "bar" style can override it for that style. Elrond
Elrond <elrond+openstreetmap.org@samba-tng.org> writes:
I don't know, if we really want to go ahead and create more styles directly shipped with mkgmap. Just some random thoughts:
A few more: Maps for rural and urban areas should probably have different resolutions. Eventually this should be dynamic. I basically agree with your points, but looking at some sort of social optimum, having a style in the base distribution is good if enough people use it to make the work of having it in the base is less than everyone having to maintain it. Plus the cost of people who don't know it exists. So I'm not sure how many, but I think having a few more would be good. At some point we may want to have a base style that isn't used directly and then modified styles. The really hard question is the purpose of those styles. I can certainly see the normal style being much as 'default' is, trying to be useful for car routing and also show POIs, with some blend of aproppriateness in all areas. This is essentially what the proprietary maps are trying to do. I can see a bicycle or pedestrian style that computes routes in car mode for bicycle or pedestrians. Beyond that, I'm not sure.
On Mon, Aug 10, 2009 at 09:14:59PM +0200, Ondrej Novy wrote:
It think we should set resolution for residential streets back to 21, now is map just 'empty'.
I don't know. I don't have a car and am using a bicycle for most of my transportation needs (routinely up to 20 km one way, sometimes even 100 km per day). I sometimes prefer to ride through residential streets, if the cycleways along major roads are badly constructed. But I would assume that motorists don't want to see residential streets when navigating longer journeys. If I use routing, which generally works nicely on the Edge 705, I will see the pink line also on low zoom levels where the streets themselves would be invisible. The map on low zoom levels would update quicker if it didn't show residential streets. If I need to see the residential streets, I will switch to 50 or even 20 meter zoom level, no problem. I think that the resolution should depend on the context. For example, I think that cycleways, paths or tracks running aside a bigger road should be suppressed on low zoom levels. But if they are the only road in the area, then they should be displayed. The same applies to residential roads, of course. In some places, the only route through an area is a residential road that goes through a village. How to reliably detect this, I don't know. If there is a highway=cycleway running next to a car highway, then there should be several crossings, bridges or tunnels between the ways. Maybe it would be enough to calculate the average distance between the ways, and omit the lesser way on lower zoom levels if it is "parallel" to the more important road. Or maybe just omit the "parallel" section of the lesser road, e.g., if the cycleway includes a "ramp" to another road, like this: | ==*======== highway={unclassified,residential,tertiary,secondary,primary} | ------ cycleway or footway | / |/ || In this case, the vertical and horizontal sections of the cycleway could be omitted at low zoom levels.
If we want to have this set to resolution 23 we need to update more than just service, but parking and track for example too.
Could we perhaps define a partial order of elements that a test case could check, to prevent similar inconsistencies in the future? E.g., check that the following holds in the style file: resolution(highway=secondary) <= resolution(highway=primary) resolution(highway=tertiary) <= resolution(highway=secondary) ...
So i'm voting to set residential back to 21 :].
I'm fine either way. Marko
On 10/08/09 20:14, Ondrej Novy wrote:
steve commited this change: -highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21] +highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23]
(rev 1118) and say it's my patch - which isn't true.
Apologies about that, that part of the commit was indeed not yours and was included accidentally. I'll change them back. ..Steve
participants (5)
-
Elrond -
Greg Troxel -
Marko Mäkelä -
Ondrej Novy -
Steve Ratcliffe