highway=path/footway should not be assumed to be paved by default

[vvoovv]

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.

[imagico]

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.

[thor]

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 surface=* coverage, when people can visually differenciate them.

[gravitystorm]

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 https://github.com/gravitystorm/openstreetmap-carto/pull/1713#issuecomment-131589531 @matkoniecz says:

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.

... 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 https://github.com/gravitystorm/openstreetmap-carto/pull/1713#issuecomment-131612727 but perhaps there are other options too.

One issue that I'd like to see considered is whether the hierarchy should be paved > unknown > unpaved , or paved > unpaved > unknown i.e. should unknown be somehow halfway between paved and unpaved, or should it be least visually apparent in order to always encourage surface tagging?

[mboeringa]

One issue that I'd like to see considered is whether the hierarchy should be paved > unknown > unpaved , or paved > unpaved > unknown i.e. should unknown be somehow halfway between paved and unpaved, or should it be least visually apparent in order to always encourage surface tagging?

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.

[imagico]

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.

[geowOSM]

One issue that I'd like to see considered is whether the hierarchy should be paved > unknown > >unpaved , or paved > unpaved > unknown i.e. should unknown be somehow halfway between paved >and unpaved, or should it be least visually apparent in order to always encourage surface tagging?

I would definitely opt for paved > unpaved > unknown to promote proper surface tagging.

[matkoniecz]

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)?

[daganzdaanda]

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. paved = solid line or long dashes, unknown = dot-dash, unpaved = dots, approximatly as strong as the "paved" is now

[daganzdaanda]

in situation where surface data is missing select style randomly

That sounds like a recipe for a lot of new bug-report issues here ;)

[matkoniecz]

paved = solid line or long dashes,

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.

[matthijsmelissen]

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.

[RobJN]

I agree with @math1985. Although it would be nice to, I feel we shouldn't force people to tag the surface.

[daganzdaanda]

Note that my significant effort to find suitable rendering with solid lines went nowhere

Yes, I remember this, a whole lot of good work. In hindsight, maybe all it needs is the colour red? This is @imagico s mock-up with @mboeringa s annotations from https://github.com/gravitystorm/openstreetmap-carto/pull/1713#issuecomment-131618252

I could imagine even a solid line might look ok there. But of course, there are so many combinations to check...

[Rovastar]

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.

[Rovastar]

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

[matkoniecz]

In hindsight, maybe all it needs is the colour red?

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.

[matkoniecz]

One new idea to check - alternating big and small dots (big from paved style, small from unpaved one) for unknown surface.

[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.

[imagico]

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.

[gravitystorm]

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.

[daganzdaanda]

@imagico wrote:

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).

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. I guess this needs a new issue?

[daganzdaanda]

@matkoniecz

One new idea to check - alternating big and small dots (big from paved style, small from unpaved one) for unknown surface.

That could work, yes. But I still say the unpaved needs to be more visible.

[dieterdreist]

sent from a phone

Am 19.08.2015 um 02:09 schrieb Vladimir Elistratov notifications@github.com:

So please don't force us to add surface for paths :)

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 ;-)

[geowOSM]

So please don't force us to add surface for paths :)

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 Basic mandatory entries in editor-presets would promote proper ground mapping.

[dieterdreist]

sent from a phone

Am 19.08.2015 um 10:54 schrieb Christoph Hormann notifications@github.com:

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.

I believe it depends very much on the region you are in, whether you consider them equal or not (whether the law says that footways are exclusively for pedestrians and exclude other traffic modes like bicycles by default or whether they allow them)

[pnorman]

Taking into account tags like smoothness/sac_scale as well would be worth considering but is technically not possible at this point

Technical issues aside, we'd have to combine all the tags into one - having distinct appearances for every combination of surface, smoothness, and sac_scale doesn't work.

So from a styling perspective, don't worry about this now, we may just in the future have a more sophisticated paved/unpaved/unknown distinction.

[simonpoole]

@Rovastar both JOSM and vespucci already include surface and smoothness as addional tags for path

[HolgerJeromin]

iD has surface as the second detail after a name for footways and path, too.

[MaartenDeen]

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). Why make paths the same rendering (and for the viewer the same usage) as footpaths and not (for example) cycleways?

[Rovastar]

@SimonPoole Yes I know they have the feilds what I am thinking is the important defaults. Also getting opinions about how they see it. Do they presume that paths are unpaved?, etc. Would it benefit us all if they changed the defaults to surface unpaved? Explaining that we at the main map style do xyz Asking on the mailing list will be pretty pointless as there will always be 1 that difficult and disagree that black is white, etc and I am not sure if things get decided. But where you have more of a dictatorship or limited democracy (like here nothing ever would be done if every decision here was discussed on the mailing list) then their opinions matter.

These editors shape a load of how people enter information into osm along with the map style and wiki. There is currently zero communications between the main groups of people that look after the main map style, the main editors and the wiki. If we have a concensus then I believe it will be benefit openstreetmap. If it is fragmented then that doesn't help openstreetmap. This was always my thought over the years about looking in detail at css carto to join up these dots.

I hope that explains a little more.

[gmazy]

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.

[AlexeySalmin]

@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!

[HolgerJeromin]

I hope we all want a useful database. Handling footway and path different did not do a good job to encourage better tagging (for example with surface). Otherwise we would not have this debate. This style is about the mapper feedback loop.

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.

[AlexeySalmin]

Assuming no difference encourages people to add surface tags to the ways.

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.

[gmazy]

The change have rendered big portion of maps broken. I cannot see how this can be good decision. Changes to rendering could be done gradually so mappers have time to fix maps while they are still somehow readable.

[matkoniecz]

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

[matthijsmelissen]

I think the current unpaved footway rendering is not prominent enough.

[imagico]

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.

[drkludge]

I am glad to see that surface tags are being considered. That provides a reward for mappers to add the information. The problem with the white casing for unpaved or ground is that it makes the footway unusable in a nature conservation/preserve area. The footpaths are the most important feature in this area. You can see a segment of the National Trail that has the surface=ground and another segment with nothing set for surface yet. The two segments meet at Goat Hill. Moreover, the National Trail is part of the 200+ mile Maricopa Trail. No route settings have been created in this area yet because it is unclear how many routes are required. I bring the route issue up because it was mentioned in this discussion too. http://www.openstreetmap.org/way/330787693#map=15/33.3295/-112.0901 https://www.maricopa.gov/parks/MaricopaTrail/pdf/2014maps/82k-regional-trail-south-mountain-bw-8x11.pdf

Here's another case to consider, the Sonoran Desert Preserve trails used to be visible and useful on the OSM map. Now the system is almost invisible against the non-water default color for land.. The dirt trails receive more use than the concrete trail along the road yet the bike trail is prominently shown compared to the footway. http://www.openstreetmap.org/#map=15/33.7830/-112.0640 As yet, I have not found a freely licensed Sonoran Desert Preserve boundary. Otherwise, I'd have the same issue with the South Mountain Preserve as noted above.

HTH, Greg

On Mon, Aug 24, 2015 at 1:59 PM, Christoph Hormann <notifications@github.com

wrote:

I don't think that is going to work well - also because the thin/unpaved variant is not working well in general - see #1765 https://github.com/gravitystorm/openstreetmap-carto/issues/1765. Even beside that the mixed version looks mostly noisy and not all that meaningful.

— Reply to this email directly or view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/1766#issuecomment-134378612 .

[HolgerJeromin]

@drkludge please add any valueable information to issue #1765

[dieterdreist]

sent from a phone

Am 25.08.2015 um 06:15 schrieb drkludge notifications@github.com:

I am glad to see that surface tags are being considered. That provides a reward for mappers to add the information.

+1 while I agree that most people likely assume paths to be more often unpaved than paved, the best solution to this problem is adding more information into the database (namely surface tags), rather than endlessly debating what would be the more sensible default in absence of such information

[zdila]

In reply to https://github.com/gravitystorm/openstreetmap-carto/issues/1698#issuecomment-134951241

Of course, many of the paths without an explicit surface will be unsurfaced, and probably more than 75% of those. But a significant fraction of highway=path are actually surfaced.

If there are more paths without an explicit surface unpaved then why are all such paths rendered as paved?

[pnorman]

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 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.

You're confusing procedures which only apply to changing something on the wiki to what a data consumer needs to do.

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.

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 - highway=path bicycle=designated is rendered the same as highway=cycleway - we've done this from the start, and osm.xml has done this since svn revision 11633, back in 2008.

[matkoniecz]

I opened "path/footway/cycleway - render missing surface separately, more prominent rendering for unpaved ways" PR #1788 - that is supposed to fix this problem.

[AlexeySalmin]

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.

You're confusing procedures which only apply to changing something on the wiki to what a data consumer needs to do.

No, I'm not confusing data and data consumers or wiki and carto. If you read my comment more closely I specifically say:

I mean not only the specific "proposal" process but discussions, arguments and agreements in wider sense: on talk pages, on forums, channels etc.

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.

[PaloTT]

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

1698 conversation has been locked and limited to collaborators.

!When a lot of people have different opinions, the best way to decide is make a vote and respect the vote result in decision: Question for path,fooway rendering (answer just yes or no) is: When surface tag is not present, should be highway=path rendered with "unpaved style" and highway=footway rendered with "paved style"?

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.

[gravitystorm]

When a lot of people have different opinions, the best way to decide is make a vote and respect the vote result in decision

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.

When surface tag is not present, should be highway=path rendered with "unpaved style" and highway=footway rendered with "paved style"?

No. See the lengthy discussion at https://github.com/gravitystorm/openstreetmap-carto/issues/1698 and https://github.com/gravitystorm/openstreetmap-carto/pull/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.

[HolgerJeromin]

this is closed by #1788

[kocio-pl]

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.

:+1: - 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.