OpenStreetMap
New road style for the Default map style - highway=path is evil
Posted by Mateusz Konieczny on 14 July 2015 in English. Last updated on 29 October 2018.changes based on feedback (comments on diary and GitHub):
Reverted highway=footway, highway=path changes and restored currently used version. highway=motorway, highway=trunk rendering will be distinguishable. For oneway arrows old blue version also will be considered.
In addition feedback confirmed that it would be a good idea to: render motorway junction labels in red and rework widths of roads.
Example of the current rendering of pedestrian area (left - current rendering, right - proposed new rendering). highway=footway styling was rolled back, but highway=pedestrian/living_street is changed.
Request for a testing place
I am looking for a well mapped place where displaying highway=residential on z10/z11/z12 makes sense and is desirable. I am also looking for a place where rendering highway=unclassified at z10 is a good idea. According to my tests rendering these roads later improves situation, except places with badly mapped road types (highway=residential linking towns etc).
highway=residential rendering starting at z13, instead of z10 (on the right - rendering of minor roads starts later)
z10 without both highway=residential and highway=unclassified (on the right - rendering of minor roads starts later)
After such change it would probably be a good idea to make landuse=residential darker on z10/z11/z12 to make area covered by settlements clear.
Testing road width
I am experimenting with resizing roads and I would welcome feedback on these presented versions - what is a better version for highway=residential/living_street/pedestrian? Left or right side? Or maybe both are too narrow/wide?
Note - I would welcome examples of a well mapped rural areas for testing locations.
highway=path, highway=footway problems
according to http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
highway=path is a generic path, either multi-use or unspecified usage, open to all non-motorized vehicles. The path may have any type of surface.
This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails, ski[disputed] and snowmobile trails[disputed] as well as combinations of the above
It is a big problem for designing rendering. Given that definition from wiki highway=path may be anything from paved cycleway, though paved footway or horse trail to mountain bike trail. Some even include snowmobile trails existing only during winter as an acceptable feature to be mapped as highway=path.
For general rendering it would be preferable to have two tags - one for footways/path/sidewalks open for pedestrians and second for weird variations like mountain bike trails and snowmobile trails existing only during winter rather than current situation.
But in reality overwhelming majority of highway=path is used to map paths that are not more open to non-motorized vehicles than highway=footway. It also seems that as result of a difference in Default map style it is very common to consider highway=footway as paved and highway=path as unpaved. Confirmations/refutations are welcomed as my personal experience is mostly limited to Poland - elsewhere it is mostly guessing based on limited research.
So there are following possibilities that may work:
path/footway difference
- consider highway=path to be unpaved and highway=footway to be paved (current situation)
- stop differentiating between highway=path and highway=footway (render both using current styling of highway=footway or highway=path)
- stop differentiating between highway=path and highway=footway, render them differently based on surface tag
- invent a new tagging style (highly unlikely that something replacing highway=path/footway would be accepted, but the current one may be improved - see for example http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dpath#skiDisputed_and_snowmobile_trailsDisputed )
special access on highway=path (cycleways, bike trails, snowmobile routes)
- consider popular combinations equivalent to already rendered road types (current situation, for example [highway=path; bicycle=designated] is considered to be equivalent of [bighway=cycleway]), ignore other)
- detect popular combinations, in addition attempt to detect other special cases and do not display highway=path in such cases (foot=no would cause highway=path to not be rendered, except cases where it would be rendered thanks to fitting one of popular combinations)
I would welcome opinions on these possibilities and other ideas that would work. There possibilities that are not listed here because it would lead to poor results. For example differentiate rendering based on both highway=path/footway and surface value with four different stylings is not something that would work. Special rendering for every special case of highway=path is also impossible with a style that is supposed to be usable. Ceasing to detect [highway=path; bicycle=designated] makes no sense.
In addition it may be considered to treat highway=bridleway as a synonym of highway=path given relatively low importance of that way type and high similarity.
rendering highway=proposed
Related to current road restyling - see https://github.com/gravitystorm/openstreetmap-carto/issues/1654 that contains a proposal to stop rendering highway=proposed (in that case comments should be posted on GitHub issue).
rendering highway=road
I am not sure how to display this road type. In some way that it would make clear that it should be changed to proper highway type? But it would make the map ugly. But maybe in a situation like that it is acceptable?
Attempt to guess what is the most common proper type and render it in this style or close to it as it done currently? But it breaks The Mapper Feedback Loop, also it results in a confusing map where something that resembles highway=unclassified/residential may be anything.
Stop rendering of highway=road? Provided feedback is “you should not use this tag”. It also would be highly confusing, this time for people contributing to OSM.
accepted changes
Next pull requests related to clutter on clutter around z10 were merged: start displaying minor rail from z13, fixes #1645 #1647. As result railway=rail ways with service=yard/siding/spur are no longer rendered on z11 and z12.
Stop displaying really small zoos and theme parks After that change smaller ones will appear later and bigger on earlier zoom levels (before/after with current road styling).
Discussion
Comment from Warin61 on 14 July 2015 at 22:43
Hi,
Path and footway … I too view this as stupid. I view both as the same thing. I belive it is a British thing .. where there is a legal difference between the two.. and that should have been handled with a tag like access rather than make a new tag.
Road … not a legal tag .. I’d not render it. Consider it a kind of ‘fixme’ tag?
Planned … again I’d not render it. Not ‘on the ground’ = not verifiable, not confirmed, financed … may not happen. Under construction is much more usefull as there may be interference with other traffic.
Just my ideas.
Comment from jremillard on 14 July 2015 at 23:42
The situation with highway=path, highway=footway is very annoying. Regardless of what the wiki says, in practice there is no difference between them. I would support recognizing reality and rendering them the same and render based on common sub tags like surface, access, etc.
Comment from redsteakraw on 14 July 2015 at 23:56
I think the color changes are too drastic, I have thought about the problems and have a solution to them that is closer to the current color scheme.
1.Landuses should be lighter in color than highways, lighten the forest and wood area and darken the green motorways. The dark blue highways should stay as they are quite visible over waterways.
2.Keep the red footways, render paths as red dashes and pedestrian as smaller red ways with red polka-dot filling as with pedestrian areas. That way all foot based travel will have a more unified feel but mostly stay familiar. Footways can have a white background with the red dots to provide the proper contrast needed as with the other pedestrian ways and paths.
Try these suggestions and compare them to the current proposals, I think this is the best way to keep the current look and feel of the carto style while fixing existing issues. There is a certain charm to the style with all the colors used and specifically the blue highways which ties it to older paper road atlases. It also looks so distinct that it is easily recognizable. I appreciate the work you have done so far and your effort to engage the community and reference and compare changes.
Comment from RobJN on 15 July 2015 at 00:05
You can’t make any assumptions about footway and path, so a render based on surface and access tags may be worth exploring.
I would also like to see a difference in rendering between high usage paths/footways and low usage paths/footways. We have all the classifications for roads (motorway, trunk, …) but none for paths/footways but as I walk in rural areas some paths/footways are more important than others. Lesser used ones may be hard to follow as “desire lines” (e.g. trampled grass) may not be so visible.
I have been using footway for the high usage ones, path for the low usage ones (as good a reason as any for the difference between these tags).
Rob
Comment from redsteakraw on 15 July 2015 at 03:12
@ jremillard There is a difference between a hiking trail and a paved footway. Paths are hiking trails places where people travel by foot / bike and prevent extra vegetation thus cutting a path. Footways are ways meant for foot travel, paved or crushed stone or compressed earth. It assumes some extra construction beyond a hiking trail path. You can assume footway to be surface=paved or paths to be surface=dirt or earth and render surfaces differently.
Comment from Aury88 on 15 July 2015 at 06:33
I use path as suggested in the wiki. For the surface I use the surface tag so a footway and a path can be both paved and unpaved. I use path when a way can be described by many highway values but I agree that the distinction between them, ihmo, can be accomplish using the foot/bicycle/motor_vehicle/horse/…tags and some others (sub)tags
the changes seem good ;-)
PS:from zoom level 13 to 16 highway=residential rendering can give some problem in some old, densely urbanised, european town/city: Gela Z13 Gela Z14 Gela Z15 Gela Z16
(oneway=yes should be narrowed but I think this is difficult to obtain without introduce other rendering issues)
However the Humanitarian style work great in this situation. Gela H Z13 Gela H Z14 Gela H Z15 Gela H Z16
I hope you can solve this problem :-)
@ RobJN: About paths/footways “importance” distinction I agree but I think it can be obtained using surface, tracktype, “access” and width tags. so do we really need so many highway (foot, pedestrian, bridleway, path,cycleway)? the main (important for an user ) distinctions between them can be described by already existing tags in my opinion…the only problem can be the legal classification.
Comment from Mateusz Konieczny on 15 July 2015 at 06:43
That would be great - as sometimes adding more data to OSM reduces quality of maps. On z14 displaying only important footways would be result in a better map.
Unfortunately there is no tagging scheme for that what makes such rendering impossible. I was experimenting with one and my conclusion was that it is too subjective.
Unfortunately it seems that different people use path/footway based on different criteria making the distinction unusable (the same as with landuse=forest/natural=wood).
It is not so easy - this would start problems with forest too close to other green landuses. It also would not solve problem with motorways looking like rivers.
I am pretty sure that polka-dot filling would be too busy, but I experimented with footways closer to highway=pedestrian in style. It would be a good idea to at least try highway=pedestrian closer to footways.
Note that according to current definition on OSM wiki highway=path/footway is not indicating surface quality and whatever it is paved. Recommended tagging for combined footway and cycleway is [highway=path; bicycle=designated; foot=designated; segregated=yes/no]
Comment from imagico on 15 July 2015 at 08:44
My understanding of the difference between highway=path and highway=footway without further tags is that footway is meant for ways contructed for use by pedestrians along its whole length (but not necessarily paved) while path is used for ways where rudimentary construction work might have been done to enable safe use but that are largely ways just established by use, for example a way across a meadow that exists simply because a lot of people frequently walk there. Many uses of these tags match this distinction quite well although i am sure there are also many examples contradicting it.
Removal of the minor roads at the lower zooms seems like a good idea, this will also encourage mapping urban land uses (which is missing in a lot of cities at the moment). Likewise for thinning the roads a bit at intermediate zooms. These two things are however strongly a matter of map scale - both lead probably to a huge improvement at low latitudes but probably less so at high latitudes (try Murmansk as an example for that). Hiding residential but showing unclassified might also improve consistency in use of these tags although due to the above it might also lead to a systematic difference in use of these tags depending on latitude (high latitude mappers might use unclassified in residential areas for example to make them show up).
Comment from Rovastar on 15 July 2015 at 08:56
“It is not so easy - this would start problems with forest too close to other green landuses. It also would not solve problem with motorways looking like rivers”
I disagree this was discussed before you joined the carto project. We have too many greens and the current green for trunks is too dull. We still need to sort the greens out….
Comment from geri-oc on 15 July 2015 at 09:50
Ich würde die highway=pedestrian/living_street schon dunkelgrau lassen und die Breite ändern - ähnlich service oder etwas breiter. Dann hebt sie sich auch besser ab als besondere “Straße”.
Comment from flohoff on 15 July 2015 at 11:11
I love the z10 z11 residential road change. I’d like to keep them in z12 for the moment. Residentials often make one get an impression on residential areas and population density. That would get lost. In z10/z11 you cant distinguish between roads so thats a plus to remove them.
Comment from Barthwo on 15 July 2015 at 12:10
Maybe you can make highway=residential a little bit thinner and make them distiguishible from the highway=unclassified, which is part of the “grid” and should be rendered a little bit thicker, especially in z14.
I would like to see residential from z12 on.
Comment from Richard on 15 July 2015 at 13:18
highway=path is most certainly not “a British thing”. It was invented by a mapper from Germany (Cbm) and one from America (Hawke) in 2007. Most active British mappers have had the sense to steer well clear of this disaster of a tag, and continue to use highway=footway, =cycleway and =bridleway. (Taginfo reports that, in Britain, highway=footway is used 400% more often than highway=path; elsewhere, highway=footway is used only 25% more frequently. In other words, don’t blame the British.)
There is one sensible way of dealing with highway=path, and that’s to use Lua processing (available in osm2pgsql as well as other tools such as OSRM and tilemaker) to rationalise it into other, more meaningful values. For example, if you have highway=path, foot=yes, bicycle=no, horse=no, then you can recast it as highway=footway - and so on. This is what cycle.travel does for both rendering and routing.
This would require a database reload, of course, but I believe that’ll be needed sooner rather than later anyway.
Of the other changes, there’s some good stuff here but there’s too much ‘zing’ to the new highway colours at z10/z11. Looking bright may be a worthwhile aim; looking luminous probably isn’t. But given that changes to the current osm-carto style are a bit “deckchairs on the Titanic”, and we should really be thinking about moving to in-browser rendering of vector tiles - which opens up all sorts of stylesheet and interactivity possibilities - I won’t press the point.
Comment from redsteakraw on 15 July 2015 at 20:43
@ Mateusz Konieczny
On the other landuses such as grass parks and forests, they can have textures added like the forest currently has, hatched patters (grass like hatches) This can be done with minimal visual impact.
On the polkadot filling being visually busy, yest it will be but it will be visually distinct and blend in with the current footway rendering and stand out. Part of the point of the theme is to allow mappers to see features, the map is all ready busy because of that. I don’t see that as a problem but a core design feature.
On the “Problem” of blue motorways and rivers, I don’t see that anyone would get confused, the motorway is much darker than any water way, Are there any places or pictures that demonstrate this is indeed a problem?
At the very least I think this is worth some experimentations to see how these suggestions pan out and how they are received by mappers. I understand this is a hard problem and that any change may introduce new bugs / regressions. This is a hard task to take and again appreciate the work put into this so far.
Comment from Alan Trick on 16 July 2015 at 03:13
While this may work for the forest “landuse” (I’m not even sure what that means), natural=wood would have to be changed too.
The further problem with green roads, apart from their shear distinguish ability, is that they fail at being iconic (in a semiotic sense). In other words, the other green things on the map are all generally indicators of some level of plant life, or protection of such life, and highway=trunk has nothing to do with plant life. A green highway=trunk works fine in places that have largely been deforested (i.e. Western Europe, big cities), but not well in many other places.
Comment from 4rch on 16 July 2015 at 08:02
I like the idea to drop the blue and green rendering for motorways/trunks. In some places such roads are nearly invisible, especially the green trunk roads.
Comment from JIBEC on 16 July 2015 at 08:49
what is the impact of narrowing streets on street names ? regarding removing residential street from high zoom level, i found it looks like more gmaps, but don’t find it really better. Can you try to make the residential color lighter on higher zoom level ?
Comment from ika-chan! UK-USA on 17 July 2015 at 07:02
I think the colour changes are so drastic that a version with the existing colours should continued to be maintained as a “heritage” layer and have it run side by side.
Comment from Tractor on 17 July 2015 at 09:35
Overall I like the changes. The old green trunk roads are very difficult to see against natural=wood when zoomed out, so I’m glad to see them go. I don’t find the blue motorways problematic since it’s a very different blue from that of the waterways. It’s just a matter of getting used to blue roads on a map.
It would be nice if we could have more styles to choose from on the main map, but I understand if it will be to much work to maintain different styles.
Would it be possible to make an example where we can compare the new highway=motorway, highway=trunk and highway=* + motorroad=yes?
Comment from pnorman on 18 July 2015 at 01:06
I wouldn’t rule out dealing with it in SQL. It might even be sane, compared to doing z_order in SQL and some of the other constructs.
Comment from Mateusz Konieczny on 18 July 2015 at 15:02
added to list of test locations
I tested this idea, more about it in the next diary entry.
Interesting idea, I will test it.
Or directly in rendering rules as it is currently done for bridleway and cycleway. The more complicated part is deciding what highway=path really represents.
This tag is not used in rendering and without database re-import it is impossible to use it.
It is not blocking rendering names, names are more likely to not fit inside roads.
“residential color” - is it about residential roads or is it about residential landuse?
Comment from Jojo4u on 19 July 2015 at 15:59
highway=pedestrian/living_street: looks good.
Later rendering: This change looks surpringly obvious. We have landuse and not highway=residential for marking of built-up area. I have not looked into excluding unclassified as well.
Width: As long as they are not narrower on a map than an average street in real life (which i doubt) am supporting the right version. It leaves more space for other features - we are not OpentSTREETMap anymore.
footway/path: Well in Germany we have ways which are equally shared by bicycle+foot (STVO signs 240/241) and neither footway nor cycleway fits. So a highway=path, surface=[paved value], foot=designated, bicycle=designated is recommended tagging. If there is only one “designated” we use footway/cycleway. Many small paved “footways” have no traffic signs and are equally allowed (foot/bicycle=yes). Footway implies foot=designated, foot=yes looks wrong on those ways. I want to promote path more, so i support: “stop differentiating between highway=path and highway=footway, render them differently based on surface tag” with detection of bicycle=designated.