highway=path/footway should not be assumed to be paved by default #1766
Comments
vvoovv
changed the title
|
It has been suggested by others (@math1985 and @matkoniecz) that different defaults for path and footway are not desirable so the less controversial statement would be that highway=path should not be assumed to be paved by default. It seems everybody can agree on that visually distinguishing paths without surface tag from those with a surface tag would be good. |
Definitely, to lay out a better chance of getting adequate |
gravitystorm
changed the title
|
I've changed the title to reflect a specific topic that I'd be happy to see discussed, but that doesn't mean that I agree with the statement :-) There's a feeling that a 3-level rendering (paved, unpaved, unknown surface) might be workable, but in #1713 (comment) @matkoniecz says:
... and given the amount of work he has done on this, his comment should be considered carefully. @imagico made some suggestions about solid/dots/mixed-dashes at #1713 (comment) but perhaps there are other options too. One issue that I'd like to see considered is whether the hierarchy should be |
That simple question may be the cause of another trench war ;), but it is a valid one. Arguments aside though, any considerate rendering like @matkoniecz and @imagico showed in true viable proposals could work if an appropriate legend is available. |
|
I think the relation to track is to be considered here - track line signature have a gradient from solid line (grade1) to sparse dashing (grade6) and the unknown grade is somewhere in the middle. While tracktype is not the same as surface of course there will be an expectation from map users for both systems to work in a similar manner. And while the fraction of tracks with a tracktype is higher than in case of footway/path (after all it is already routinely rendered) in all cases the fraction of ways without detailed specification is high making the unknown display very important for the overall impact. Both #1748 and #1765 should be considered as well since they would be directly affected by any change in footway/path rendering. |
I would definitely opt for paved > unpaved > unknown to promote proper surface tagging. |
|
Maybe use two styles (paved/unpaved) and in situation where surface data is missing select style randomly (to keep it cache friendly - maybe base in on the legth of element)? |
|
I would slightly prefer "unknown" to be in the middle, because most of the existing ways will not have a surface tag, and should still be well visible, because many of them are important. |
That sounds like a recipe for a lot of new bug-report issues here ;) |
Note that my significant effort to find suitable rendering with solid lines went nowhere ( https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35351 ). It is probably possible, but I am not going to try it again in the near future. |
|
I also think unknown should be in the middle. The surface of a path is not extremely important for most purposes, so I don't think we should force mappers to add the surface tag in order for footways to show up properly (by rendering paths without surface tag only faintly). I don't think we should introduce randomness into the style. |
|
I agree with @math1985. Although it would be nice to, I feel we shouldn't force people to tag the surface. |
Yes, I remember this, a whole lot of good work. In hindsight, maybe all it needs is the colour red?
I could imagine even a solid line might look ok there. But of course, there are so many combinations to check... |
|
I think paved --> unpaved --> unknown to encourage better tagging. I would also like to involved the other main movers and shakers in the tagging of these the main editors (JOSM, iD) to get there take on this and to have their presets default to include surface type. I'll try and reach out later. Hopefully making osm feel more like a community and not individual chaos and opinion that often arises. |
|
Also no idea why track is mentioned here in the chat/pics. Let's not go there. The track type is enough if we mix up surface for that we are in a world of pain. Leave track to the type only, this seems to work ok |
It has big problem on retail and commercial and problems on industrial. Also, generally on map it was harder to recognize as footway for many people. |
|
One new idea to check - alternating big and small dots (big from paved style, small from unpaved one) for unknown surface. |
|
I'm deleting any comments from this thread that suggest highway=path and highway=footway should have different default surface assumptions - please, lets stick to the topic. |
|
Regarding line width variation of various sorts - this is likely not going to work for at least z<16 since it would require quite large line widths to be clearly visible and that would take too much room on the map at these scales. Regarding solid reddish lines not working - this was not my impression when doing tests - would be good to see some examples where this causes problems - for example using https://github.com/imagico/openstreetmap-carto/tree/path-nosurface. In general dashed/dotted lines work very poorly on lower zoom levels. In general styling according to surface is of course a bit one-sided since it only covers the 'material' dimension and not the 'condition' aspect. Taking into account tags like smoothness/sac_scale as well would be worth considering but is technically not possible at this point (it would for example make sense to render paved and all smoothness=intermediate or better - i.e. 'wheelchair compatible' in a common styling). @matkoniecz - select styling randomly - you have got to be kidding - randomly styling 3/4 of the paths/footways is not really compatible to the idea of styling according to tags. @gravitystorm - i suggest you be a bit more tolerant here, i know a lot of comments recently in this repository have not been very productive but it is frankly somewhat insulting to people who try to help improving this style to tell them in what direction they are allowed to think and in what not. As i said repeatedly i respect the decision not to treat path and footway any different but considering the countless maps out there that show this difference it can hardly be considered a completely pointless consideration. You are of course free to impose any rules and constraints here but you would send a very bad message and likely loose a lot of valuable contributions if you routinely tell people what ideas they are allowed to consider and suggest in terms of styling. |
I have zero intention to routinely tell people what ideas to consider. But I will step in to stop arguments, insults and circular discussions, and to do what I can to stop the project becoming unproductive and to ensure there's a friendly, considerate atmosphere. Unfortunately it's proving quite hard to give contributors "safe space" to discuss particular aspects of this topic, hence the unusual steps on this issue, but it's certainly not something I ever want to be doing. |
|
@imagico wrote:
Yes, and even while we're waiting for the hstore, we could start with getting the whole footway/path mess sorted (and don't forget cycleways with extra tags...). There are many combinations of tags to take into account, but maybe we could get them generalized into a sensible 4 or 5 patterns, similar to tracktypes. |
That could work, yes. But I still say the unpaved needs to be more visible. |
|
sent from a phone
as long as we omit information with the idea of some default in mind that everyone will somehow magically know, we are asking for not being understood ;-) |
+1 |
|
sent from a phone
I believe it depends very much on the region you are in, whether you consider them equal |
|
@Rovastar both JOSM and vespucci already include surface and smoothness as addional tags for path |
|
iD has |
|
I see footways and paths are now rendered in the same style (red dotted line). I don't think this is a good idea. A footway is distinctly purposed as a path to walk on where a path in general is not. It can be used for walking, biking and even motorized modes of transport (motorbikes). |
|
@simonpoole These editors shape a load of how people enter information into osm along with the map style and wiki. I hope that explains a little more. |
|
Highway=path wiki does have image of unpaved path. In many places highway=path alone is used only to unpaved paths. Therefore existing paths should not be assumed to be paved by default. If there is valid reason for highway=path to be assumed to be paved, old paths could be tagged automatically to unpaved. Good tagging scheme for assumed/automatic tagging would also allow different defaults to be applied in different areas, which would help in preserving information. |
|
@gravitystorm "I'm deleting any comments from this thread that suggest highway=path and highway=footway should have different default surface assumptions - please, lets stick to the topic." Right, except the topic was "highway=path should be unpaved by default" until you decided to change it. The following comment is about different assumptions on paths and footways including the surface one. Let me know if you'd like to see it arranged as a separate issue report. I didn't do it that way in the first place only because you've closed all similar reports as duplicates. As you correctly notice, this is not a duplicate but a significantly different topic. So: All these tags in the database are meaningless sequences of bytes until they get semantics attached. Outside of the OSM project, strings like "highway=path" or "highway=footway" can mean literally anything (or nothing). Now, in the OSM project there's a process where tags get a meaning assigned by a consensus of editors and such decisions get documented in the wiki and self-documented in the database. I mean not only the specific "proposal" process but discussions, arguments and agreements in wider sense: on talk pages, on forums, channels etc. On some topics there's a strong consensus with support of e.g. 90% percent of community, other topics can be less obvious or even controversial. It's true that there's an ambiguity around the path/footway usage and it's even documented on the "path controversy" wiki page. However, a significant portion of OSM editors have always assumed different meanings for "path" and "footway" and it's visible not only from the wiki but from the actual data. For example, there're 234235 cobminations of "path+sac_scale" and only 8117 of "footway+sac_scale". This basically means that people find the "path" value more appropriate for hiking/trekking rather than the "footway" one. Then, 24% of paths that has a surface specified has "surface=ground" with only 2% of "surface=ground" among footways with surface specified. This means that editors more frequently use "highway=path" when they map a ground surface rather than "highway=footway". And so on. It's not good or bad, it just is. I'm talking about existing reality, not about database normalization or good design practices. People view paths and footways differently with an overall average inclination towards applying "highway=path" to "somewhat less civilized" ways. This is, of course, a very rough generalization -- as you correctly note in the adjacent thread, details in the path/footway delimitation vary a lot. So a significant portion of editors imply different properties for a path and a footway, and it's natural for them to expect a different rendering. How strong is this expectation in the community? I don't know. YOU would know, had you conducted any of usual RFC procedures prior to making this change: e.g. a vote or a talk page with appropriate "advertising" and enough time for everyone to participate. Now we have a case when a significant amount of information that people had entered into the database is just disregarded by the main OSM stylesheet. So it's about as painful as the CC->ODbL transition, but compare how these two were implemented! |
|
I hope we all want a useful database. Assuming no difference encourages people to add surface tags to the ways. Only reviewing the highway=path (without surface) is a good start. I have added such useful metadata to a few hundreds objects in my city. |
Probably. Or it may encourage them to leave the project. You never know until you conduct a study and everything else a guess. We all want a useful database but in a short term we've made it less useful since a part of the data is now ignored (only in the rendering, but still). And long-term consequences aren't obvious to me given the disappointment that I see on github talks and on Russian and German OSM forums. Real magnitude is unknown though. Probably it's not that bad, who knows. Still, I'm sure there are better ways to encourage people. |
|
The change have rendered big portion of maps broken. I cannot see how this can be good decision. |
|
I made first version of "One new idea to check - alternating big and small dots (big from paved style, small from unpaved one) for unknown surface." It is worse than expected but at least it more or less works. Code resides at https://github.com/matkoniecz/openstreetmap-carto/commits/null_surface_differentation
|
|
I think the current unpaved footway rendering is not prominent enough. |
|
I don't think that is going to work well - also because the thin/unpaved variant is not working well in general - see #1765. Even beside that the mixed version looks mostly noisy and not all that meaningful. |
|
I am glad to see that surface tags are being considered. That provides a Here's another case to consider, the Sonoran Desert Preserve trails used to HTH, On Mon, Aug 24, 2015 at 1:59 PM, Christoph Hormann <[email protected]
|
|
sent from a phone
+1 |
|
In reply to #1698 (comment)
If there are more paths without an explicit surface unpaved then why are all such paths rendered as paved? |
|
It's not directly related to this issue, which is about default surface assumptions for footpaths, but there seem to be some misconceptions about this, so I'm replying anyways
You're confusing procedures which only apply to changing something on the wiki to what a data consumer needs to do.
OpenStreetMap Carto has never and will never be able to show all the information in people tag in OSM. Taking highways as an example, in addition to the highway tag, they have access tags, sometimes for 3+ modes of transportion, maxspeed(s), lanes, names, refs, oneway, lit, bridge, tunnel, surface, and I'm sure other tags which don't immediately come to mind. A style will need what distinct features to render, then what tags correspond to those. This means disregarding much of the information, and osm-carto does this like every other style. This is also nothing new - |
|
I opened "path/footway/cycleway - render missing surface separately, more prominent rendering for unpaved ways" PR #1788 - that is supposed to fix this problem. |
No, I'm not confusing data and data consumers or wiki and carto. If you read my comment more closely I specifically say:
Discussions are perfectly applicable to any community project whether it's a database or a stylesheet. Of course, if one doesn't care whether the community will grow or shrink, then discussions are a useless waste of time. However if one seeks to "encourage" people to do something, then it makes sense to make them feel included rather than outcast. Before this change, OSM editors were in fact encouraged by the Carto to specify the surface of a footpath. The problem was, they were doing it incorrectly, using path/footway values instead of the special "surface" tag. There're many reasons why that happened including the inconsistent documentation and I don't think this was ever done in a bad faith. There are many ways to solve this issue, but the current one is one of the worst. The message sent to database contributors sounds like this: "You did it wrong, fools. We've thrown away your mess, now go do it again and this time properly". Personally I will, but I'd understand if someone won't. |
|
I am really frustrated how gravitystorm (and pnorman, matkoniecz) arrogantly enforce their opinion. gravitystorm changed the title from highway=path should be unpaved by default to highway=path/footway should not be assumed to be paved by default !When a lot of people have different opinions, the best way to decide is make a vote and respect the vote result in decision: Even in case that answer is YES, paths with paved surface tag can still be rendered same "paved style" like footways without surface tag and footway with unpaved surface tag can still be render same "unpaved style" like paths without surface tag. |
We don't hold votes on this issue tracker. We make decisions using well-reasoned discussions. When something is not unanimous, it's up to the maintainers to make the final call, using their judgement. If you want to create a different project where everyone votes on decisions, then that would be an interesting experiment.
No. See the lengthy discussion at #1698 and #1788 Please note that none of these issues are supposed to be a "conversation", they are created and closed as we carry out our tasks. If a maintainer feels like the topic has run its course, especially on a closed issue, then they are free to lock the issue so that we can concentrate on other tasks. Meanwhile, if you want to have a ongoing discussion, there are better places like the mailing lists. The best way to contribute is, as ever, to create a pull request. Nothing actually ever changes on the stylesheet without someone creating a pull request. If you don't know how, we can help. If you don't want to, you need to persuade someone that it's a good idea, and they are often busy anyway. |
|
this is closed by #1788 |
👍 - I hold some different ideas than the core development team, so sometimes it's hard to find the solution which satisfies everybody (at least to a reasonable extent) and I'm still learning the technical side, but this effort was worth taking. Once you know what do you want and are willing to do the homework, osm-carto team is really helpful. |
and others
Note. The original issue title was "highway=path should be unpaved by default". The title was changed by @gravitystorm. He also deleted some of my comments. I'm obviously against of his way of managing the issues.
highway=path should be unpaved by default, if surface tag isn't supplied.
There is statistics prepared by @imagico in favor of this assumption:
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.
The text was updated successfully, but these errors were encountered: