unify=path/footway styling, show surface for highway=path/footway/cycleway #1713
Conversation
matkoniecz
changed the title
| @@ -742,6 +745,7 @@ Layer: | |||
| foot, | |||
| bicycle, | |||
| tracktype, | |||
| CASE WHEN surface IN ('unpaved', 'compacted', 'dirt', 'earth', 'fine_gravel', 'grass', 'grass_paver', 'gravel', 'ground', 'mud', 'pebblestone', 'salt', 'sand', 'woodchips', 'clay') THEN 'unpaved' ELSE 'paved' END AS surface, | |||
There was a problem hiding this comment.
It would be better to use a name other than surface for this, as it's a normalized surface, and we may want to consider tracktype in the future.
There was a problem hiding this comment.
I am not sure what would be better name. quality? normalized_surface?
There was a problem hiding this comment.
int_surface, for consistency - it goes with other int_ prefixes e.g. int_tunnel, int_tc_type
There was a problem hiding this comment.
Done in matkoniecz@898339d
See also cc17b03 that split overly long lines.
|
I support unifying them, but long term we may want to look at if the dashed red is the clear cartography for a footpath. I need take a good look at some local paths to see how it looks |
|
So a path without surface tag is considered paved? |
Yes, that's the logic implemented. A more sophisticated logic would be to consider rural vs urban, but we don't have that data, and it's probably an undesired transformation, even if it does produce a better result. |
|
I'm a bit surprised to see more red dots instead of less. I hoped we could keep current path style for unsurfaced - but this won't fix #547. Over there it was proposed to make track wider. |
In the UK, this would lead to less red dots. |
From my looking at alternatives (I really dislike this red dot style and I wanted to replace it by something else) it works quite well. highway=path is also well recognisable but it is closer to already used style for highway=tracks.
Yes, feedback from others would be really useful. |
|
More about alternatives - there are styles that look better and/or are better at recognisability as footways but problems start once it turns out that rendering is too close to some other features (landuse=industrial, highway=service, boundaries, highway=track, landuse=retail etc). |
And in case that somebody want to review some area and is not interested in setting up environment for rendering ( #657 (comment) ) I may generated some requested area. |
|
As most of us dislike the red dots, I'd see it more productive to unify towards the other end, the current path style, with slight differentiation depending on paving. In the future we might then migrate the built-up urban footway towards the narrow white cased style that has already been proposed. Finally I wonder why we need to emphasize different traffic permissions on the general map so significantly, i.e. the blue for cycleways. This could be left to the Cycle map, while the general map focuses on the physical features. |
|
The problem with path is that this style is close to highway=track. It is not as bad as #547 claims, but it makes harder to find way to distinguish between paved/unpaved.
I thought about unifying highway=bridleway to either highway=track or to highway=path/footway. |
Probably towards path/footway. In my area, I have never seen a dedicated bridleway as in wiki in my area, they are all forestry paths or tracks that have a little horse=yes permission. As highway=bridleway gives us no clue if it is suitable for two-track forestry vehicles, chosing the path/footway is safer. |
|
+1 |
|
Bridleway defaults to motorcar=no and should not be suited for motorcars in width and smoothness. Track seems to be the wrong choice. To me bridleway is just some path which is designated for horses. |
|
@math1985 @gravitystorm @everybody Can you try how it works in your region? |
|
Looks good here. Long term I'd like to look at a different styling, but that should wait till after unification as we shouldn't hold up the former for the latter. |
(highway=path; bicycle=designated; foot=designated should match cycleway definition alone)
ice and snow are unhandled because are both really rare and are likely to be misued
|
I changed rendering that improves display of unpaved, especiall on dark surfaces and is not making harder to distinguish paved from unpaved. Also, rebased.
https://cloud.githubusercontent.com/assets/899988/9157193/6cc8d18e-3ef4-11e5-9984-8afa65c4fe6a.png |
|
I think the rendering difference between footway and path is still too subtle to be useful, unfortunately. |
|
Maybe the distance between the dots could be higher to make paths more different? |
|
Just to be clear, following replies from @math1985 and @kocio-pl, the change currently planned is for footway/path to render the same, and the 'dot' difference visible in the images shown by @matkoniecz above are for paved/unpaved, right? |
|
Again, path and footway are totally different entities according to the OSM-wiki. |
|
Unfortunately, mappers use different definitions to distinguish between footway and path, so we cannot draw any general conclusions about the difference between footway and path
This is not clear to me, what needs to be remapped?
I'm not sure what you mean with that. Paths can be paved, and footways can be unpaved, so surface does not distinguish between footway and path. |
To be usable by data consumers, yes, you should never use highway=path without surface and bike/foot access tags. @systemed's what does the path say is one introduction to the problem, but certainly not the only one. |
|
As i have pointed out in #1748 the primary problem here is that the current rendering assumes highway=path without surface tag to be paved. Is there any indication most of the ways tagged this way are actually paved? If not assuming the opposite (unpaved by default) would be more sensible probably. Some basic numbers: there are 3.9 million ways with highway=path of which 800k have a surface tag, about 200k have surface=paved/asphalt or other paving, the rest is unpaved of some sort. My guess is that among the other ~3 million ways the unpaved:paved ratio is at least the same, i.e. 3:1. Alternatively it would be possible to use a specialized rendering for highway=path without a surface tag indicating the missing information somehow. |
|
I agree with @imagico that surface=unpaved should be assumed by default for highway=path. I refer to the OSM-wiki again. This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails as well as combinations of the above. Just think logically. If highway=footway is for urban paths, then highway=path is for outdoor paths which are most likely unpaved. That's how I understand the article highway=path and how I have been used highway=path since 2008 when I joined OSM. I believe the same is true for the other mappers and that's confirmed by @imagico's statistics |
|
sent from a phone
it is generally advisable to add surface tags to all highways, in particular the minor ones, because you hardly can find any global default because people assume different values to be "standard " |
|
The josm preset for combined foot and bicycle ways has a German urban sign as an icon. It generates a path with some access tags but no default surface tag. |
As already said: The default for path (typically encountered outdoor) is basically unpaved and the default for footway (typically encountered in urban areas) is basically paved. Please regard this. |
The terminology is confusing here. Urban is outdoor well. The opposite of outdoor is indoor. |
|
I would be against rendering highway=path and highway=footway different based on the assumption that most paths are unpaved and most footways are paved. Rendering them differently propagates the assumption that data users can assume something about the surface of roads based on footway versus path. |
|
Numbers for highway=footway: 5.3 million total
That is a >3:1 ratio for paved:unpaved, fairly symmetrical to highway=path. I think it is a fairly reasonable idea to suggest based on these numbers that assuming a default of paved for highway=footway and unpaved for highway=path would be much better than any other default assumption in a two class system. As already said the alternative would be to render all without surface tag in a different neutral styling that encourages the mappers to add missing information (a bit like highway=road). |
I'm afraid it's not that simple. Most rural footpaths in the UK are unpaved and tagged as highway=footway. To make the urban/rural distinction you need a set of urban area polygons, which is what I do at cycle.travel/map but couldn't sensibly be applied to the osm-carto toolchain.
Good idea. |
It seems to me by the way it is more that the boundary between use of highway=footway and highway=path is moved more to the rural domain than in other countries. Mountain hiking trails seem equally mostly tagged as highway=path in the UK as they are elsewhere: http://mc.bbbike.org/mc/?lon=-3.206108&lat=54.486092&zoom=13&num=2&mt0=osmfr&mt1=mapnik&marker= It is also natural that relative to highway=footway the number of these is much lower in the UK than in a country like Russia. How meaningful this distinction is even when only considered locally is a different matter of course. |
|
The statistics supplied by @imagico is against this commit. The description of highway=path in the OSM-wiki is also against this commit. So I'd suggest to revert the commit and continue the discussion to find a nice solution. |
|
I don't think there is need to rush things this way - the basic idea of rendering the 200k highway=path paved and the 600k+ highway=footway paved in the same styling and equally for the 200k highway=footway unpaved and the 600k highway=path unpaved is very good. The question is what to do with the rest, this should be changed IMO but there is no need to make a snap decision here. I suggest to open a new issue for that (since #1748 is primarily about a different matter). If no solution is found in time for the next release it could be considered to render highway=path/footway without surface tag in the old path styling as a provisional measure - this would avoid the problems introduced by this change and keep the undeniable improvements it brought. |
|
@vvoovv You can't trust the OSM wiki on this. It's been edited by people with a personal point of view about "what the difference between a footway and a path is", and in a number of cases the current state of it only reflects the POV of the last editor, not the (lack of) concensus. |
The comparatively small number of mountains in the UK are not really the issue, because these are often 'access land' (= public allowed to walk across any area). In these places, it's fairly common that the paths worn by usage - rather than defined by statute - are indeed tagged as highway=path. 95% of the England & Wales landmass is not mountainous, yet has defined Rights of Way - paths, usually unmade, where there is a statutory right for people to walk. Many more of these are tagged as highway=footway than highway=path. |
This was my initial idea - unfortunately finding two different styles for paved/unpaved was already quite problematic and failed to find a third style that would be also recognisable as footway and convey that data necessary to display it properly is missing.
This was one of my main reasons for proposing and implementing this change.
In that case - please, edit wiki. It is main tool to check both intended meaning of tags and real usage. Other methods are burdened with even worse distortions.
Neither current or initial definition recommends assuming that surface is unpaved. |
|
What about making such paths even weaker than unpaved somehow (paler color or bigger distance between the dots - much like what you were testing lately)? This could be a huge encouragement for adding surface tag! 😜 |
This may be a solution, but it would make large amount of paths/footways poorly visible (in many places it would affect all of them). Or maybe for missing data use paved/unpaved style randomly (for example - based on way id). |
|
I fully oppose the unification of the styling: path and footway are different in many aspects and should be distinguishable in Mapnik. Rendering of surface is a major improvement. But there are minor issues due to low contrast on certain background textures (i.e. scree, bare_rock) and the very small perceivable difference of paved vs unpaved should be strengthened, see example from http://osm.org/go/0IXkNEAbg-
Also assuming a default of surface=paved if a suface tag is missing might be reevaluated. IMHO paved for highway=footway and unpaved for highway=path would be more reasonable as imagico mentioned before. We might consider a revert, until a more considerate solution is found, based on a broader participation of the OSM community. Some more thoughts: highway=footway is undoubtly mainly a single-use way for pedestrians, whereas highway=path is a universal key for multi-use or non specific use ways, from rural, wilderness and mountain trails to all kinds of transport infrastrucure in the so called developing countries and may be used by all kinds of non 4-wheel traffic, including stock, mule, yaks and - yes - in some countries even by motorcycles/mopeds etc. We have 9 million paths and footways in OSM, the ratio of path:footway varies significantly according to country. These differences should be reflected in rendering. Globally 1:1.4, This is partly because of national access restrictions, partly because of the "duck tagging" mapping tradition, which is understandable and historically determined. In the UK (especially England and Wales) a highway with designation=public_footpath is mainly attributed as footway (partly even if it's physically a track). |
As has been said many times already, there are so many different interpretations of the difference between footway and path that none of them are useful. It is good, however, to see this reinforced, in that everyone who comes here to complain about this change and explain that they are different comes here with yet another (different) explanation than everyone else who complained before. If anyone has any suggestions for smaller path/footway changes (either to the styling, or to the default surface assumptions, etc) then I would suggest more focussed new issues would be better. |
+ 1 This actually just leaves two options:
Option 2 doesn't exclude future changes, there have been continuous changes over the years after all. If anyone can come up with something good, preferably not just in words but in true visual proposals as @matkoniecz did, I guess we will see re-evaluation as in any normal situation in the past. Any other discussions about the exact meaning of the two tags seems hopeless and senseless at best, as there will not be agreement on that topic any time soon... |
Here a basic test for how this could be done in a similar way as for tracks with solid line for paved and a mixed dash pattern for missing surface tag:
In addition this also uses stronger colors and thinner lines - this might require testing and tuning of course - it is probably a bit too strong as is but it would need more testing to see how much it can be tuned down without being difficult to read over bare_rock and other structured backgrounds. I also tried using uniformly non-dashed thin lines at the lower zooms which would reduce clutter and address #1748: I don't have the time to further develop this, code is here (incomplete, only for footway so far): https://github.com/imagico/openstreetmap-carto/tree/path-nosurface |
@imagico: Would it be possible to provide a kind of small mock-up quick and dirty legend of all the line types in the images, so that people joining the discussion from outside can understand the differences? The second image seems a good basis, as it contains a lot of line types, maybe just label this image as a quick solution? |
|
Thought this is self explaining: solid line: paved |
|
I like this idea: mixed are better visible than not paved, but the pattern "noise" is unpleasant and I think it may encourage people to tag the surface. The only possible problem I see is that it looks like typical boundaries representation, however this is not a deal breaker for me. |
Thanks, I made my own mock-up. Please correct if I mis-interpreted something...
|
Given this is being ignored, I'm going to lock this issue. Please create a new issue to discuss a rendering for unknown surface like there is for unknown tracktype. |
fixes #1698, fixes #547, implements beginnings and tiny part of #110
unification
proposed in this PR/current rendering
paved/unpaved rendering
Reasons for unification of highway=footway and highway=path are discussed in #1698 (massive difference between highway=path and highway=footway is confusing and is not useful).
Goal was to make difference between paved and unpaved noticeable but not overwhelming. Especially as paved footway/path may not be too prominent (problem in cities) and unpaved should be visible without problems (problem in remote areas).
surface is assumed to be paved unless explicitly described as unpaved ('unpaved', 'compacted', 'dirt', 'earth', 'fine_gravel', 'grass', 'grass_paver', 'gravel', 'ground', 'mud', 'pebblestone', 'salt', 'sand', 'woodchips', 'clay').
Fixes minor bug without effects for the current rendering.
https://cloud.githubusercontent.com/assets/899988/9023918/8ba15642-38b1-11e5-8ebb-623796c4f690.png
https://cloud.githubusercontent.com/assets/899988/9023919/8bb7ef24-38b1-11e5-8d1b-9f55a7849dbd.png
https://cloud.githubusercontent.com/assets/899988/9023921/8be01b34-38b1-11e5-99ef-c72743ded263.png
https://cloud.githubusercontent.com/assets/899988/9023920/8bd05b0e-38b1-11e5-8ac7-f3a387217bef.png
https://cloud.githubusercontent.com/assets/899988/9023922/8bf41fc6-38b1-11e5-86c8-282cffa0667f.png
https://cloud.githubusercontent.com/assets/899988/9023923/8bf452fc-38b1-11e5-9fcc-8fa14c64cef9.png
https://cloud.githubusercontent.com/assets/899988/9023942/c3f67990-38b2-11e5-9505-1ba6d79f8e03.png
https://cloud.githubusercontent.com/assets/899988/9023943/c3facf04-38b2-11e5-8202-592798d5571d.png
https://cloud.githubusercontent.com/assets/899988/9023945/ca79553a-38b2-11e5-9489-479dc4b0ac27.png
https://cloud.githubusercontent.com/assets/899988/9023944/ca74faee-38b2-11e5-8fdb-c4931a4e6c4f.png
https://cloud.githubusercontent.com/assets/899988/9023946/cda8f9f4-38b2-11e5-80b8-ab0c33df8c42.png
https://cloud.githubusercontent.com/assets/899988/9023947/cdaba154-38b2-11e5-89a3-79ed82c17915.png