Talk:Key:sidewalk

From OpenStreetMap Wiki
Jump to navigation Jump to search

Sidewalk=shared

I have been considering how to tag roads where pedestrians share the main carriageway with vehicles on a reasonably convivial way. The tagging 'sidewalk=no' would tend to imply that one would be taking ones life into ones hands to walk along it. For many short service roads with virtually no traffic then pedestrians will be expected and encouraged to walk in the carriageway (or to one side of the carriageway). Indeed for many service roads their may only be one service vehicle a hour. I am proposing 'sidewalk=shared' for this purpose. PeterIto 11:20, 4 July 2011 (BST)

The road you are describing seems similar to a highway=living_street as we know it in France. Is it the same thing or not, and what are the differences? It is not clear in the page that there is never any sidewalk in living streets, and I wonder. Damouns 14:19, 17 August 2011 (BST)
I have an example which really isn't a living street - a service road that runs through a park. It has such low traffic that most of the time it is used as a footpath. It doesn't have sidewalks, but should be considered fine for pedestrians and cyclists to use. I'll use sidewalk=shared for now. TomChance 16:52, 5 October 2012 (BST)
+1. I can also think of places where I would use this tag locally. Living Street is a legal status, and is therefore not suitable for situations where the sharing is more informal such as along some very low-traffic service roads of the type you describe. For now I had been leaving these roads un-tagged with sidewalk but will now go back and add 'shared'. I will render them on ITO Map in a similar but different way to living street. PeterIto 21:05, 5 October 2012 (BST)

Wikilinks

PeterIto. You placed the same link to Sidewalks in the fist two sentences. That's a bad style in a wiki. Wikipedia recommends to use only one link to the same webpage. I suggest to change the first link to wikipedia:sidewalk. Here someone can find the definition of a sidewalk. --Rudolf 14:03, 7 August 2012 (BST)

The lead has a link to the Sidewalks article on this wiki and the 'see also' link in the main mapping section goes to the same place (to make it obvious that it is the place to go to for more details). The Sidewalks article then has a link to the Wikipedia definition for anyone who really needs to know what a sidewalk (and carriageway, verge etc) is. Personally I think it would be confusing to have exactly the same text in this article linking to different resources. I also think that almost everyone will find the OSM Sidewalk article more useful than the Wikipedia one. PeterIto 23:25, 7 August 2012 (BST)
I don't agree. You use two different textes (sidewalk and Sidewalks) which links to the same resource. That's confusing and bad wikipedia style. My suggestion was to use wikipedia:sidewalk according to the openstreetmap wiki guidelines. This makes clear which resource is linked. What's the problem, to offer the reader any information, without detour? Not everyone reads the feature page Sidewalks first. You also included a different mapping style, which is content of the feature page. If you expect everyone to read the feature page first, you can abstain from this hint. --Rudolf 07:12, 8 August 2012 (BST)
This is not Wikipedia. This wiki has a rather different purpose, so it is not very helpful to follow Wikipedia style rules. --Vclaw 14:05, 21 August 2012 (BST)

none vs. no

This wiki page explicitly discourages the use of sidewalk=no ("Don't use no."), and as a result, none is used much more often than no. However, that's only true for sidewalk=* - other keys like oneway=* use "no" as a value, and we even have an accepted proposal to prefer "yes" and "no" over their synonyms as a rule for all tags. In my opinion, it's simply not helpful when some keys use the value "no" while others use "none" - you would never be quite sure which one is the right one. I therefore suggest that we switch to "no" as the preferred variant. --Tordanik 14:43, 4 October 2012 (BST)

Makes sense to me. PeterIto 19:14, 4 October 2012 (BST)
Agreed. Is there any reason why "none" was suggested? I looked at the original proposal, and the discussion pages for a couple of other features where "none" has started to be used, but couldn't find a rationale. TomChance 13:55, 12 October 2012 (BST)
I couldn't find any relevant discussion either, even though the value appears in a few other places such as the rejected maxspeed=none proposal. Anyway, as there are no objections, I'm going to change the wiki page. --Tordanik 22:29, 13 October 2012 (BST)
The mentioned proposal is about boolean values. This doesn't apply here since sidewalk is defined for "both/left/right/none". This is something but boolean. From a semantic perspective one could read the tag sidewalk=no as "this way is no sidewalk" though sidewalk=none then means "there is no sidewalk existing". The latter is making more sense for me. --HeikoE (talk) 21:10, 2 April 2015 (UTC)
I don't think those semantical differences exist, sidewalk=no simply means "this way has no sidewalk". As for the proposal, it contained examples of tags which had other values besides "yes" and "no". So despite the word "boolean", it was pretty clearly not limited to strictly boolean value sets. --Tordanik 14:15, 5 April 2015 (UTC)
None is short for not one and means not any. That is very different from no, which is a negative answer to a question. OSM values should be as distinctive as possible. This makes it easier for non-native English speakers. The proposal was bad, because it used non-boolean tags as examples for a boolean question. If not questioned, i'll revert this edit soon. --Hb 18:03, 16 May 2015 (UTC)
I've reverted it, as none is the value used in the original proposal and there hasn't been a proper proposal regarding the change to no. --SelfishSeahorse (talk) 19:05, 31 October 2017 (UTC)
I added it back. Maybe it is not recommended but its wide use must be documented (I have no idea whatever none or no is better and whatever there is consensus about this topic) Mateusz Konieczny (talk) 15:47, 2 November 2017 (UTC)
OK, it makes sense that 'no' is documented as well. I've just changed your comment to make it clear that no hasn't been approved unlike the rest of the page. (no is only used widely because the recommendation to use none has been added to this page.) --SelfishSeahorse (talk) 17:28, 2 November 2017 (UTC)
I tweaked language a bit Mateusz Konieczny (talk) 17:55, 2 November 2017 (UTC)
I disagree with the changes made over the last days. The reason SelfishSeahorse gave for the revert was that only "none" was part of the 2011 proposal. However, that proposal was never voted on, so I don't see how it could be considered authoritative. The "boolean values" proposal, on the other hand, was voted on, and establishes "no" as the preferred negative value for keys like this. --Tordanik 18:16, 6 November 2017 (UTC)
Hi Tordanik. I'm sorry, I didn't see that the proposal was never voted on, I just read 'Status: approved' on the wiki page. Still, I think the boolean value proposal doesn't apply here, because a boolean variable can only be true (yes) or false (no), but the sidewalk key is used to indicate if there is a sidewalk on the left side of the road, on the right side, on both sides or if there isn't any (= none) sidewalk. Besides, the value yes isn't of much use and is only used in 0.20% of cases (and the only real occurrences of sidewalk=yes I came across were separately mapped sidewalks that weren't correctly tagged with footway=sidewalk). --SelfishSeahorse (talk) 19:19, 6 November 2017 (UTC)
PS: But why does the wiki page say 'Proposed_features/Sidewalk - approved proposal for this key'?
Because https://wiki.openstreetmap.org/w/index.php?title=Key:sidewalk&diff=1034022&oldid=916069 was made. I fixed it (no/none are now described as synonymous) Mateusz Konieczny (talk) 19:42, 6 November 2017 (UTC)
"The "boolean values" proposal, on the other hand, was voted on, and establishes "no" as the preferred negative value for keys like this." - I would not protest basing description of no/none on that Mateusz Konieczny (talk) 19:43, 6 November 2017 (UTC)

Left/right

What is the convention for tagging either left or right? Should this be included in the article? What I mean is: left or right is relative to the observer, there are roads which are marked left or right (in the Netherlands carriageways of dual-carriageways are marked so emergency services know which carriageway they need to go to) but often roads are not marked left or right. Is there a rule where the direction on the map is taken into account (ie. right-left is first east-west, then north-south if the road has no east-west direction)? Do we follow the numbering of houses in a residential street? What do we use in the absence of any road numbering? PinkShinyRose 16:55, 4 January 2013 (UTC)

Oh, I found it: the drawing direction should be used. Now I'm wondering whether that should be added to this article or should be obvious. PinkShinyRose 17:12, 4 January 2013 (UTC)
How about linking the words "left side" and "right side" to Forward & backward, left & right - would that help? --Tordanik 17:19, 4 January 2013 (UTC)
Done that --Hb 18:59, 16 May 2015 (UTC)

Bicycle on sidewalk

At least in Germany we have some sidewalks that may be optionally used by bicycles instead of the street. If I would tag bicycle=yes then this would apply to the highway=* that sidewalk=* is related to. Maybe something like sidewalk:bicycle=yes? --Jot (talk) 10:23, 3 February 2013 (UTC)

Yes, use sidewalk:bicycle=yes.--Jojo4u (talk) 00:09, 7 August 2016 (UTC)
Okay, I'll also use sidewalk:foot=no to indicate a physical sidewalk exists but it's signposted as no pedestrians allowed + foot=no to indicate you can't walk on the road. --Aharvey (talk) 05:48, 25 July 2020 (UTC)

Pedestrian

redundant info? two artickle decribes same Pedestrian ... ich meine damit, zwei Artikel beschreiben das gleiche... ? --cptechnik - DE:NRW:Windeck (talk) 10:34, 11 August 2014 (UTC)

Perhaps you mean merging with Sidewalks instead ? --Jgpacker (talk) 11:13, 11 August 2014 (UTC)

Sidewalk along railway=rail?

I do not have example right now, but it seems possible pedestrians to walk near railway. Should we have to draw separate ways tagged `highway=footway` alongside, or `sidewalk=*` is OK? Wiki says that main way should be `highway`, not `railway`.Plamen (talk) 06:28, 4 February 2016 (UTC)

If a highway line has a footway besides it draw a separate way. The definition of the sidewalk=* tag allows it only for carriageways (roads).--Jojo4u (talk) 00:08, 7 August 2016 (UTC)
I'd draw a separate way too, but a couple of people have used the sidewalk tag with railways http://overpass-turbo.eu/s/hJf --SomeoneElse (talk) 11:28, 7 August 2016 (UTC)
11 ways as of now - I added a short sentence about using a separate way.--Jojo4u (talk) 15:38, 7 August 2016 (UTC)

sidepath

This addition looks more than a bit iffy. I've commented at: https://wiki.openstreetmap.org/wiki/User_talk:Ftrebien#cycleways --SomeoneElse (talk) 14:11, 22 January 2018 (UTC)

Sidewalk completeness

Does the presence of a left or right tag indicate that the sidewalk is fully complete on that side, or that some sidewalk exists on that side of the street. For example, if a sidewalk runs down the left side of a residential street but ends before meeting the curb of a connecting arterial, would that be considered 'left' or 'none'?

I split the road where the sidewalk stops and starts, so the part that has sidewalk at the left has "sidewalk=left" and the part that does not "sidewalk=none". SomeoneElse (talk) 09:25, 7 February 2020 (UTC)
"ends before meeting the curb of a connecting arterial, would that be considered 'left' or 'none'" - neither, you need to split the way and tag part as having sidewalk, and part as without it Mateusz Konieczny (talk) 09:28, 24 July 2020 (UTC)

Deprecated

I would like to mark this page as deprecated and include links to the new approved tagging so the new users don't get confused. Tag:footway=sidewalk, Tag:footway=crossing, Proposed_features/Sidewalk_as_separate_way

--Mashin (talk) 23:26, 10 July 2020 (UTC)

According to taginfo there are 1,711,571 uses of the "sidewalk" key currently. It doesn't look very deprecated. SomeoneElse (talk) 00:13, 11 July 2020 (UTC)
Why you think that this kind of sidewalk tagging is deprecated? Mateusz Konieczny (talk) 07:41, 11 July 2020 (UTC)
This older sidewalk tagging scheme has been superseded, by the newer approved proposal. Therefore we should mark it as: we don't recommend tagging this way, please use the newer version. Otherwise new users get confused about what is current and what is old. The fact that the tagging is still present in the data doesn't change this, but it is a reason why to keep this page so OSM data users are warned that such-and-such tags can still be found. --Mashin (talk) 16:47, 11 July 2020 (UTC)
"has been superseded, by the newer approved proposal" it doesn't say that.
"we don't recommend tagging this way" We don't always recommend what level of detail should be mapped. It's up to users to decide.
"please use the newer version" The "newer" version simply provides a higher level of detail. New is not neccessarily a replacement.
"Otherwise new users get confused about what is current and what is old." sidewalk=separate is pretty clear to me.
-- Kovposch (talk) 19:40, 11 July 2020 (UTC)
The new one has been approved by OSM community vote, while the old one has never even been voted on. So yes, new supersedes old.
Yes, a person that is adding the data decides, but we certainly recommend how to tag things -- thus the whole point of this wiki portal.
Yes, new version contains the same information as old one and provides more level of detail on top of that (supersedes the old one). But that is not the point, the point is that we have a new approved version and this page should reflect that.
Yes, the text relatively clear (though it could be improved), but the point is that it is buried on the bottom and the old scheme still presented as current. Therefore I would like to do the said changes. --Mashin (talk) 20:37, 11 July 2020 (UTC)
  1. The proposal that you mention approved tag for marking sidewalk mapped as a separate way, without deprecating sidewalk tag.
  2. Without explicit deprecation approving new tagging scheme does not mean that competing tagging schemes are invalid or deprecated. In fact some approved proposals knowingly introduced duplicate tagging schemes without deprecating originals
  3. Primary function of Wiki is to document tagging, not act as director managing mappers
  4. Sidewalk tag is current and widely used
  5. Approved version is not new, it is from 2011
Mateusz Konieczny (talk) 22:42, 11 July 2020 (UTC)
Uf. First, could we please stop discussing on the meaning of my words? The approved proposal is new as: it came later than the other. I though the context was clear or am I wrong? Besides, what is that argument supposed to mean?
Again usage of the tag is not an argument. Newer proposals will always have less count at the beginning. Plus the cause is also that the approved version has not been correctly referenced so far.
There were two ways how to tag sidewalk, community chose the other so it superseded this one. No one is saying that something is wrong. Just want to bring the correct information that we have an approved way of tagging now. This one will still exist and it won't change that.
And I don't think many people are going to agree with you that approval process has no meaning and you can declare any other proposal as equal.
--Mashin (talk) 18:53, 12 July 2020 (UTC)
  1. "Again usage of the tag is not an argument." - yes, it is. There are many tags that were never approved but are de facto standard due to usage (sometimes of of standard ways of tagging given feature)
  2. "approval process has no meaning" - I am not claiming that, I am claiming that it is less important than actual use of a tag
  3. "you can declare any other proposal as equal" - in case of tags with similar use approved/not approved status is important, approval may also indicate that community decided to start migrating from one tagging to another. In this case it is an ancient vote so it is not indicator that community wants currently to transition to a new tagging, usage of both tagging schemes is clearly significant
  4. Mateusz Konieczny (talk) 07:46, 13 July 2020 (UTC)
Again. Yes, have one way of tagging, it has some use count, we vote for different way, we start to use that one. This happened and happens all the time. This case is nothing different. As you said, community wanted to migrate.
I agree, this wiki does not command you what to use, but gives a recommendations and so I just simply want to put the one that we agreed on there.
I don't think that many are going to agree with you that after some arbitrary time we can just drop the accepted proposals and start ignoring it as we will. --Mashin (talk) 02:50, 14 July 2020 (UTC)
"This happened and happens all the time." - and as it often happens it ended with two ways of tagging, neither deprecated (see phone=*/contact:phone=* or amenity=hospital and its intentional duplicate). Not by switching to a single scheme. 9-year old proposal is far less important that large scale use and continued acceptance/support/use of a tagging scheme. Mateusz Konieczny (talk) 08:38, 14 July 2020 (UTC)
Accepted proposal is very important, because it directly expresses the will of the community. That the other scheme is still present in the data has no influence on this. Obviously, it will be highlighted that some regions or communities still prefer using the alternative way of tagging and mappers should discuss with locals first. Those regions can be named in some form of table. --Mashin (talk) 08:57, 15 July 2020 (UTC)
"Accepted proposal is very important, because it directly expresses the will of the community" Yes, so why don't you read and comprehend closely what that proposal expresses? -- Kovposch (talk) 09:37, 15 July 2020 (UTC)
"we vote for different way" They aren't "different" as in mutually exclusive or conflicting. They exists as two levels of details.
It's not "community wanted to migrate". It's a scheme of addition. You can't "migrate" between them.
"we can just drop the accepted proposals and start ignoring it" You are ignoring the content of "accepted proposals" you raised repetaedly
-- Kovposch (talk) 09:37, 15 July 2020 (UTC)
Community wanted and voted to have one recommended way of tagging sidewalks and in that context they are exclusive and conflicting. Only the accepted one can be recommended. So far you are the one ignoring the accepted proposal and the will of the community. --Mashin (talk) 23:40, 16 July 2020 (UTC)
"Only the accepted one can be recommended." - this is untrue. "will of the community" - mapping activity is also important and indicates will of community Mateusz Konieczny (talk) 08:23, 17 July 2020 (UTC)
You keep using the same argument over again. Mapping activity has nothing to do with what we recommend. The mapping activity was there also before and yet the community decided that we want to recommend the other way. If you want to keep using the old way, then keep doin so. --Mashin (talk) 16:43, 19 July 2020 (UTC)
Why don't you first stop keep using the same misunderstanding of that proposal over and over again? The community now has one "more" method of further mapping sidewalks. What makes you think this is a mutually "exlusive and conflicting situation"? -- Kovposch (talk) 09:35, 20 July 2020 (UTC)
I don't think there is any confusion about that on my side. What is conflicting is that both are presented as equal methods of tagging, while the community has clearly chosen to prefer tagging with separate ways.
Since there don't seem to be any new concerns, I tried to implement what I already read here. I would like to do the following: Mark separate ways proposal as recommended primary way of tagging sidewalks. Tagging on the roads would be marked as additional/extended way of tagging that provides useful information. There would be a warning that some users or areas prefer tagging that way with perhaps a table where those would be listed. --Mashin (talk) 03:48, 22 July 2020 (UTC)
Approval De Facto is fully justified. A "principled" approach that would deprecate, the common meaning of which is, mark for future invalidation, so much carefully created data - if I may say so - borders on the insane. Besides, this scheme here has several merits over the other: My personal favourite being, to read aloud the itinerary for a walk in a city, where the "new" scheme has been adopted; that feels a lot like listening to the song "Where the Streets have no Names". Then of course, to be of any real use, when micro-mapping separate side-walks, what can be a single annotation will require at least one, most often though, several new ways. Much an effort, with not much gain, as routers can use annotations just as well, watch e.g. https://media.ccc.de/v/sotm2019-1265-routing-for-humans#t=500 --Hungerburg (talk) 11:25, 17 July 2020 (UTC)
That is great topic for conversation (Some of it took place during the approval process), but not the point of this discussion. --Mashin (talk) 16:43, 19 July 2020 (UTC)
What makes you think this is irrelevant, please explain. --Hungerburg (talk) 21:34, 19 July 2020 (UTC)
The discussion is about highlighting the tagging method that the community has chosen, not about advantages/disadvantages. When the vote was cast, everybody had all those information already in mind. --Mashin (talk) 03:48, 22 July 2020 (UTC)
Of course it is about the value of the scheme. The community has chosen the annotation method "de facto" for good reasons. While in your evangelism you do not give any reasons apart from repeating on end a pseudo-legal doctrine without even quoting source and calling something new, that is just as old as the old. Deprecation requires more than missing "approval", e.g. "culvert=yes" is deprecated, because of ambiguity. --Hungerburg (talk) 09:53, 22 July 2020 (UTC)
Again, that issue was solved when from two competing proposals, one went for vote and was approved. All of what you are saying was already discussed by others. --Mashin (talk) 00:31, 24 July 2020 (UTC)
Why you think that approving one proposal in a vote means that all alternatives are deprecated/discouraged/wrong and should be discouraged/not used? Mateusz Konieczny (talk) 09:27, 24 July 2020 (UTC)
I thought we discussed this. Please, just read the discussion carefully again. There can be only one recommended way of tagging of certain objects. I just simply want to move the approved proposal up so it is visible. I see you concerns, but I don't want to delete or invalidate the old way of tagging. Just put the note that community agreed on to tag sidewalks primarily as separate ways, tagging on roads is still used and is encouraged to use as supplementary way of tagging. So I don't know, let's call this state as "soft deprecated" or something like that. --Mashin (talk) 20:58, 26 July 2020 (UTC)
"There can be only one recommended way of tagging of certain objects." is not true in OSM. OSM is not so tidy Mateusz Konieczny (talk) 22:10, 26 July 2020 (UTC)
And that is why we vote and then recommend one way of tagging to keep it tidy. Otherwise, it would be a Babylon of hundreds of different styles and ways how the same things get entered into the database. --Mashin (talk) 01:32, 27 July 2020 (UTC)
Actually, we have multiple styles for the same thing. See see phone=*/contact:phone=* or amenity=hospital and its intentional duplicate, see Forest Mateusz Konieczny (talk) 06:54, 27 July 2020 (UTC)
De facto, just means that it's been used not that it is recommended. --Mashin (talk) 23:28, 29 July 2020 (UTC)
On osm wiki "in use" status is for things that are in use but on minimal scale or there are serious issues with the tag. "de facto" is for things used so widely and with so widespread acceptance that their status is equivalent to features with proposal (or greater) Mateusz Konieczny (talk) 09:26, 30 July 2020 (UTC)
Please note, that your proposal to deprecate this scheme here received no voice in support, but lots to the opposite. Any changes to the article in this direction therefore are to be considered unapproved by the community. --Hungerburg (talk) 08:52, 24 July 2020 (UTC)

When something is not a sidewalk

Recent changes by BudgieInWA turned this article about the sidewalk key into an advertisement for not using it. I am going to shorten that. The changelog is hard to read, but I will try to reinstate the previous version as much as possible, some deliberate exceptions included:

  • If the sidewalk does not run in parallel, then it is not a sidewalk, no need to mention that twice.
  • A verge is, by definition there, useful for pedestrians, to step out of traffic, so it cannot not a barrier.
  • Some adverts left to please the separate way apostols

--Hungerburg (talk) 21:41, 1 August 2020 (UTC)

I reworded the intro some more to make it read less prescriptive. After all, the separate way approach is a true alternative and the Sidewalks article already explains the options in depth. --Hungerburg (talk) 09:27, 2 August 2020 (UTC)

Same surface in sidewalk and highway

How to tag a highway that has sidewalks with the same kind of surface, for example surface=sett? --AntMadeira (talk) 02:16, 21 March 2021 (UTC)

Exactly the same as you would when they differ: sidewalk:both:surface=sett (or left or right instead of both), unless the sidewalk is mapped separately, then both ways get surface=sett. --JeroenHoek (talk) 06:46, 21 March 2021 (UTC)
Sorry, I don't know why my last edition doesn't show here, but I added "but different material or pattern?" to the end of my sentence. --AntMadeira (talk) 06:51, 21 March 2021 (UTC)
I don't think you can tag the pattern of the stones, but if that is the only thing that sets off the sidewalk from the street, you could tag sidewalk:both:kerb=no to tell users they should not expect a kerb. Also if the colour of the stones differs, surface:colour=* and sidewalk:both:surface:colour=* (or left or right instead of both). You would be the first to use that compound key! (It is valid though: search for surface:colour on TagInfo for related examples). Another tag to consider is sidewalk:both:width=*.
But I wouldn't worry about it. As long as it is clear that it is a sidewalk, just mapping its existence is fine. --JeroenHoek (talk) 07:14, 21 March 2021 (UTC)
Thanks for your input. I know it's a stretch, but consider this: a highway=residential + surface=sett. Then, you want to use this scheme to say there is a special kind of sett on the sideways, like sidewalk:both:surface=sett + sett:style=portuguese. How would you say that the style is from the highway or the sidewalk? (this hypotetical question arose in the Portuguese community, which approved the sett:style=portuguese tag.) --AntMadeira (talk) 16:51, 21 March 2021 (UTC)
sidewalk:both: (and sidewalk:left: and sidewalk:right:) is a namespace prefix. That means that essentially, you can use it in front of any tag that makes sense. So this would be OK: sidewalk:left:sett:style=portuguese. --JeroenHoek (talk) 17:06, 21 March 2021 (UTC)
If the style is the same on both sides, shortened to sidewalk:surface=sett + sidewalk:sett:style=portuguese might do too - not that I am aware of any data consumer that makes use of this, but you can create one, that does. For the sake of clarity, specifying :both: might be better, but rest assured that users will find the shorthand. --Hungerburg (talk) 21:13, 21 March 2021 (UTC)

Deprecate sidewalk=separate

Resolved

"This road has sidewalks but these are mapped using separate ways.". In my opinion you should still always set sidewalk=both/left/right/no because

  1. It makes it easier for data consumers. If they prefer to know which roads have sidewalks then it's an easy tag check. If they prefer to do accurate routing on the exact sidewalk way they can use the separately mapped way.
  2. It's a more OSM way of doing things. One real world feature = one object in OSM. The sidewalk is a real world feature, so it get's its own way object, which can have it's own surface, width, lit etc tags. However it's still considered an attribute or feature of the road, because they are kind of linked. "The road has a sidewalk on the right here", so you should also tag this as a tag on the road "sidewalk=right" to reflect that.

--Aharvey (talk) 01:37, 7 June 2021 (UTC)

One use is for data consumers to be able to count the number of streets that have sidewalks in a neighbourhood (which can be a goal for improving living quality). In that case you want to count the streets tagged with separate as having a sidewalk, but renderers that want to change the casing of a street if there is a sidewalk would only want to do that if the sidewalk isn't mapped separately. So there is a need for this value.
And of course, sidewalk=separate, sidewalk:left=separate, and sidewalk:right=separate are used over 100,000, 9,000, and 13,000 times respectively. That means they fulfil a purpose for a lot of mappers, and with those numbers deprecating them is not realistic unless you have an alternative for the data they represent. --JeroenHoek (talk) 06:39, 7 June 2021 (UTC)
Good point, you've convinced me, and on further reflection for data consumers who just want to know about sidewalks per road segment and don't care about separate paths they can treat sidewalk=separate as being the same as sidewalk=both in their evaluation, same goes for sidewalk:left=separate being the same in this context as sidewalk=left.

I withdraw my suggestion, thanks for your feedback.--Aharvey (talk)

You're welcome. --JeroenHoek (talk) 11:17, 7 June 2021 (UTC)

Is sidewalk=none valid?

Resolved

There is some effort underway to deprecate sidewalk=none in favour of sidewalk=no:


While I am not opposed to this per se (neutral in fact). It does clash with a patch I submitted last week which treats no and none as synonyms as per the documentation here. Deprecating sidewalk=none seems like something that should be discussed and documented first (@ZeLonewolf: I may have overlooked any recent discussion on this though; if so, please link to it!). --JeroenHoek (talk) 06:55, 23 August 2021 (UTC)

note that treating "no" and "none" as synonymous and at the same time replacing "none" by "no" is not clashing. It is fine to support existing duplicate in data display while at the same time eliminating it Mateusz Konieczny (talk) 07:45, 23 August 2021 (UTC)
in this case usage was nearly flat before SC started using it (what can be confirmed after the next SC release when it will switch to sidewalk=no) and I support such deprecation Mateusz Konieczny (talk) 07:45, 23 August 2021 (UTC)
So in my opinion (1) sidewalk=none is valid (2) sidewalk=none has the same meaning as sidewalk=no (3) sidewalk=none should be replaced by sidewalk=no Mateusz Konieczny (talk) 07:46, 23 August 2021 (UTC)
Sure, but if one is to be deprecated, than that should be discussed and then documented first. The documentation provides guidance for contributors and authors of tools like ID and JOSM too. Presenting it as a fait accompli by first changing the tools and then changing the documentation seems the wrong way around.
These two points clash though: sidewalk=none is valid and sidewalk=none should be replaced by sidewalk=no. If none is valid, replacing it is not desirable. It should be deprecated in that case, while remaining a valid value only for data consumers. I think that is what you meant though. --JeroenHoek (talk) 08:03, 23 August 2021 (UTC)
I see no problem with value being at once "valid" and "deprecated". It is OK to use it (with "no" being preferrable), but also OK to replace it Mateusz Konieczny (talk) 09:54, 23 August 2021 (UTC)
And in this case I see it more as "lets cleanup unpreferred tags added by SC". Note that in JOSM users see tags, in iD they can see if they really want, in SC tags are almost 100% hidden and user has no option to change tagging scheme. And I think that this talk page discussion may be sufficient Mateusz Konieczny (talk) 09:57, 23 August 2021 (UTC)
That would make it fine for mappers to use none, but at the same time the patches proposed by ZeLonewolf will have tools constantly change these to no. That sends a mixed message. Either the value is valid and mappers and tools can use it (and tools should not automatically change it as suggested here), or it is not and its use should be discouraged. (Deprecating a value doesn't mean data consumers should treat it as invalid right away of course.).
You can have both values valid and prefer one: that would mean presets would only offer no for example, but once you start having tools suggesting fixing none to no you are effectively deprecating none. That is probably fine, but document it first. --JeroenHoek (talk) 12:02, 23 August 2021 (UTC)
In my mind, "valid" and "invalid" aren't concepts in OSM. The tickets I opened are simply reflecting the current state of OSM editors, which have all coalesced on sidewalk=no as the tagging for no sidewalks. Since the editors have all agreed that no is the tagging for this, adding auto-fixes is appropriate to help increase consistency across the database gradually, as objects are edited. Actual usage has spoken; none is a flat-line once you subtract StreetComplete's (fixed) bug while no was increasing continuously. There is no need to perpetuate pure synonyms. --ZeLonewolf (talk) 01:19, 24 August 2021 (UTC)
If you are auto-fixing none, you are deprecating it. This is fine, it's not a dirty word, just document it. I was working on #21235 and from the documentation, the number of uses, and the discussion on this talk-page from 2017, you can only conclude that none and no are both equally fine. If this isn't the case — and you are both giving good reasons for it not to be! — then document it so others know why. There is no 'you should really use no' or 'none is considered non-standard for this type of value and is falling out of use' anywhere on this page, and no mention of StreetComplete inflating its use either. With hundreds of thousands of instances of sidewalk=none that documentation is really step one. --JeroenHoek (talk) 07:23, 24 August 2021 (UTC)
To clarify two additional points. One; great work on improving the tools we use. I am not objecting to that. Two; once you start having tools offering to fix a value instead of just using the other one in presets and so-on, then you cross the boundary from 'use whichever you like' to 'this is wrong, don't use this one'. After all, if both are OK to use, then there is no reason to change one to the other. If there is reason to stop using one, then you are deprecating it. Deprecation means that the value should still be considered by data consumers (for years probably), but that data producers should no longer emit it. If you wish to avoid the word 'invalid', that is OK. Just call it deprecated.
Also, have a look at the history of sidewalk=*. In 2017 no was documented as being an unapproved synonym of none, so the current view on this tag-value is a reversal of that. More reason to clearly document it so everyone is on the same page. --JeroenHoek (talk) 07:58, 24 August 2021 (UTC)
sidewalk=no is shorter, seems to be more popular, and at a glance seems to have better software support. I agree with changing the wiki text to deprecate sidewalk=none. --JeroenvanderGun (talk) 16:48, 24 August 2021 (UTC)
Bit late to this discussion, but I also support deprecating sidewalk=none in favor of sidewalk=no. --Woazboat (talk) 14:33, 31 October 2021 (UTC)
Same here. It seems like there's no point in dragging the decision further: all the discussions linked from the section about the deprecated none value (including this one) appear to be in favor of dropping none as long as that's documented — which has been the case since this edit from almost 3 years ago. I'm also in favor of wrapping up the discussions and give the topic some closure by fully embracing the deprecation of sidewalk=none. --Waldyrious (talk) 14:33, 8 July 2024 (UTC)
I support the deprecation and dropping of none in favor of no, and encourage @Waldyrious: to implement it and close the discussion. JesseFW (talk) 23:40, 8 July 2024 (UTC)
Ok, I went ahead and updated the page to explicitly acknowledge the community decision (in this discussion and the others), and remove the bits that hinted at lack of consensus. I'm marking this section as resolved, but please make any further adjustments that may be needed to complete the deprecation. Cheers, Waldyrious (talk)

Sidewalks without curbs

I assume that by default, sidewalks are assumed to have curbs, at least in developed places. But what about sidewalks without curbs? Any way to tag this?

A common situation that may be considered as a "sidewalk without curb" is a country road with a compacted strip on each side (that isn't wide enough to be used as a shoulder). Also, such situation is often found in villages with less developed infrastructure or generally in less developed countries where e.g. at least the road is paved and there is just a compacted "area" left and right of the road where pedestrians mill about. Functionally, this is a sidewalk. But without curbs. --Westnordost (talk) 13:28, 7 January 2022 (UTC)

The classic sidewalk in most countries used to have a kerb, but with an increased focus on accessibility this is no longer the default in many places. There has to be some boundary to separate it from the carriage way though, but in addition to kerbs there are gutters (example on Google Streetview) and various kinds of barriers (chaings, fences) as well. In some cases there is only a change of surface colour or tile pattern, despite being clear in their function as a sidewalk (often due to spaced repetition of (lamp) posts or bollards). But proper sidewalks of the kind that I think fall under this key tend to have been built as such, offering protection to the pedestrians in some way (kerbs, posts at intervals, etc.), and often fall under some kind of legal protection too (e.g., not being allowed to park on it, drive on it, or block it). A compacted surface next to a road where you would walk but which lacks any clear sings of it being a sidewalk probably falls outside of the current definition of this key.
There is something missing though. I've come across examples in the Netherlands where a pedestrian might be allowed to walk along a road where even cyclists are forbidden to come lacking even a parallel cycling way or footpath (these are admittedly rare though). In such cases pedestrians can use the verge of the road, but must (by law or necessity) stay of the paved carriage way. Your example seems similar. I think some key that indicates the state of the verge for pedestrian use might be useful, and help indicate to other mappers that there is no sidewalk=*, only an informal (but usable) verge (which can be grass or compacted soil or gravel). The benefit of such a key would be that routers could penalize it over roads with proper sidewalks (and actual footpaths and cycleways obviously). This seems useful in cases where legally you could walk somewhere, but most people would rather not if given the choice. Such a key would by definition not be used together with sidewalk=* on the same side of the road. --JeroenHoek (talk) 09:46, 8 January 2022 (UTC)
Such a key could take inspiration from shoulder=*, which can already (theoretically extrapolating from shoulder:bicycle=*) be used to mark pedestrian access. --JeroenHoek (talk) 09:52, 8 January 2022 (UTC)

Lines every few feet

Many sidewalks contain regular perpendicular lines across them every few feet. https://wonderopolis.org/wonder/why-do-sidewalks-have-lines . As such lines are even visible from aerial imagery, some consideration should be given to how to map them too! Jidanni (talk) 14:02, 20 October 2022 (UTC)

No, they should not. Contraction joints are a standard part of the surfacing construction. Look into paving_stones:*=*, or recent discussions of surface=concrete:plates. --- Kovposch (talk) 11:32, 21 October 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:sidewalk&oldid=2734685"