id-tagging-schema
id-tagging-schema copied to clipboard
openstreetmap
Add `sidewalk` field
Reopened #444:
I disagree with the reasons the PR was closed: The fact that there is no consensus on a specific tagging variant, doesn't give the editors a "free pass" to choose a single one of them and ignore all others. On the contrary: this would only be the case when there is consensus that a specific tagging variant is "approved".
In cases like this one, in my opinion, map editors should at least show data that has been added by mappers using either of the tagging variants. This would allow people to find out whether sidewalk data already had been mapped on a road when adding sidewalks as separate ways, thus reducing situations where sidewalks en up being mapped in a duplicate way.
//cc @arch0345 @bhousel @1ec5
@tyrasd doesn't this PR miss the part where the key is added to the preset? – I might still be missunderstanding how the whole system works, though.
And for that part, I wonder if the moreFields would be a good start for this key. That would expose existing data but also not push for the tag actively.
Another thing is the tagging schema that has the :both as part of the key, mainly relevant for sidewalk:both=separate (Example).
The reasoning is, that we have to be able to tag "sidewalk:right=yes + sidewalk:left=separate" in case only one side is mapped separately. Or, maybe more realistically "sidewalk:right=no + sidewalk:left=separate".
Unfortunately, the whole key:side=value topic is not specified well (either). For Berlin, we tend to add the *:both explicitly.
doesn't this PR miss the part where the key is added to the preset?
[
"type": "sidewalk"] isn’t a valid type
Correct. I've just used the PR from @arch0345 as a starting ground. It's definitely not ready as is. I did convert the PR to a draft now.
And for that part, I wonder if the
moreFieldswould be a good start for this key.
:+1: that would have been my idea as well.
then we’d have to account for both the
sidewalk=left/right/bothandsidewalk:left/right=yesschemes
The argument to be made here is that while sidewalk=left/right/both (~400,000 km when using a factor of 2 for the lengths of sidewalk=both) and footway=sidewalk (~400,000 km) are found in OSM data in astoundingly equal amounts, the current global usage of sidewalk:left/right/both (~10,000 km) is about two orders of magnitude less than that.
Another argument for including the sidewalk tag as a field is that this is (AFAIK) the only way to express that there does not exist a sidewalk alongside a road or street.
sidewalk:both=separate
I hadn't thought about that particular use case. At first glance, I would have argued that sidewalk:both=separate is just a synonym of sidewalk=separate (which could be hardcoded in iD if we decide it's important to show). But this still leaves the question of sidewalk:left/right=separate which are even more commonly used in practice than sidewalk:both=separate (but still many magnitudes less often than sidewalk=left/right/both). :thinking: At the moment, I don't yet see an easy solution for this particular tagging detail, to be honest.
Of the tags discussed here so far, sidewalk=separate and sidewalk:left/right=separate are the ones that matter most for pedestrian routing. I can’t think of any mainstream pedestrian routing profile that makes a major distinction between two streets that allow foot traffic (based on their access tags) where one has a sidewalk tag while the other does not. On the other hand, separate matters for ensuring that routers don’t needlessly switch between sidewalks and streets, resulting in unusable guidance instructions. Coverage of separate is currently far below where it needs to be to account for separately drawn sidewalk ways.
I'm a bit stubborn about sidewalk=separate not being usable for a few reasons
-
Sidewalks as a property of the road are useful for public transport routing, since sidewalks are never included in transport route relations. It is common for bus stops not to have sidewalks, so being able to discern if a sidewalk is present, and if so, which sides it is on, makes it a lot easier to derive information about where to board and alight with respect to the way without having to download the footway network in conjunction with the route relations.
-
Sidewalk=separate is impossible to survey without the corresponding OSM data in front of you. If I am writing down notes from a survey, or using a mobile editor with aerial imagery, I have no way to tell whether something has been mapped separately. It also would confuse new mappers.
-
It's likely that introducing it as an option will result in people removing valid information about sidewalks. Querying for the tag in most places results in a number of uses on ways where the sidewalk is not mapped separately. A lot of these aren't even mistakes, one of the most common uses of it is for tagging sidewalks separated from the road by segregated cyclepaths.
(Here only the cyclepaths have been filled in.)
Other interpretations include: parking aisles for which the sidewalk is around the parking lot itself rather than the aisle, and bridges with separate parallel sidewalks.
Based on this, it seems like every use of sidewalk=separate in India is on a way for which the sidewalk is not mapped separately: https://overpass-turbo.eu/s/1iPx
Much of these sidewalk=separate tags on ways which don't have sidewalks drawn separately can be attributed to StreetComplete. As StreetComplete is intended to be used for surveying, the sidewalk quest option of "is this sidewalk separate?" doesn't get read as the meaning of it being a separate way for most people. Examples:
- https://www.openstreetmap.org/way/232496610/history
- https://www.openstreetmap.org/way/962980312/history
- https://www.openstreetmap.org/way/226981388/history
- https://www.openstreetmap.org/way/435272758/history
- https://www.openstreetmap.org/way/802404456/history
I agree that tags in use should be reflected in the editor, and that there should be a way to do this without picking a "side" but adding a sidewalk=separate option would result in more of this, which goes against the objectives of even the people advocating for sidewalk=separate.
I think there’s a misunderstanding. sidewalk=separate is merely an (unenforced) aspect of the migration path from sidewalk=both etc. on the roadway to footway=sidewalk on a separate way. Without it, there may or may not be adverse effects, depending on the vagaries of any given routing profile. Mappers aren’t very good at eyeballing edge weights, so sidewalk=separate just makes it clear that the intention is to follow a parallel path if present.
If this tag is present but the parallel path is absent, the router would take it to mean that the separate-way approach has been taken, but there is no sidewalk to draw separately in the first place. The router might still route along the roadway, just as it would if there were no sidewalk tags to speak of.
Sidewalk=separate is impossible to survey without the corresponding OSM data in front of you. If I am writing down notes from a survey, or using a mobile editor with aerial imagery, I have no way to tell whether something has been mapped separately. It also would confuse new mappers.
I find it no more difficult to spot a parallel footway=sidewalk way in Go Map!! than in iD. Doesn’t StreetComplete show any parallel footway=sidewalk way on the map while asking this question?
As StreetComplete is intended to be used for surveying, the sidewalk quest option of "is this sidewalk separate?" doesn't get read as the meaning of it being a separate way for most people.
As of streetcomplete/StreetComplete#4030, the option is called “sidewalk, but displayed separately on map”. If you’re concerned that this wording causes people to use sidewalk=separate where no footway=sidewalk way has been mapped yet, then that’s good feedback to report in StreetComplete’s issue tracker, a feature request for iD’s validator, or grist for a MapRoulette cleanup challenge. But I don’t see how that would have any bearing on a tag that routers already find useful or a field intended for an editor that would show the separately mapped way.
Even if a router doesn't change its behavior because of sidewalk=separate having no separate way, it makes the rest of the sidewalk tags less effective, particularly sidewalk=no, if sidewalk=no and sidewalk=both alike are getting replaced with sidewalk=separate. The result would just be the sidewalk tag including no information. It also makes queries of route relations like I mentioned harder to do, because you don't necessarily need information about the adjacent footways in order to do that kind of analysis.
In the locations in India linked, there's no sidewalks mapped as ways yet so there's nothing to use as a reference point, or there are other types of footways that are rendered similarly, so it is easy to see how someone wouldn't be able to tell what the quest means. I don't think changing the wording or how its drawn would make it any clearer. . Even iD, if there aren't already footways mapped it would be very easy not to know that they're absent. Maybe this is unusual but when my phone battery runs out I write down this sort of thing on sticky notes, anything mappable should be describable without an app. When I use the quest in street complete, sometimes I'll do things like map the ways separately first and then answer yes/no in the quest to verify on site. (More necessary in areas with tall buildings really, since it's easy to miss where a sidewalk disappears to give way to a dumpster next to apartments if you're mapping in iD. Looking closely at how things are drawn on StreetComplete defeats the purpose of surveying anyway, because it in that common situation, it is too easy to see a separate path a block away and think that means you shouldn't check - if it's next to an apartment building or office tower, you probably should.)
If I am understanding these links correctly, if I were to add sidewalk=separate or sidewalk:left=separate where applicable on Traction Street, it would route along the north side of Traction Street's sidewalk instead of along the road. In real life though, everybody would walk in Traction Street on the roadway itself, and if they did get on the sidewalk, a good number would do it at the point shown. On a narrow street with discontinuous sidewalks like that, there often are too many obstructions to walk anywhere but the road, and you're not any less likely to get hit by a car walking to the side anyway. Adding sidewalk=separate would make the router produce a worse result rather than a better one, and the spatial inference it's making in the absence of that tag is actually a really good one in this case. If the one reason to use sidewalk=separate is to prevent the router from going in the roadway when sidewalks are present, that's not even an assumption that should be made anyway.
If I wanted to know what percentage of the city's alleyways have sidewalks, or if there's a correlation between an alley having a name and whether or not an alley has sidewalks, or even analyze if the difference between an alley and a residential street is easily discernable based on sidewalk attributes, sidewalk=no and sidewalk=left/right/both have clear utility for answering those questions. People replacing that where it is present solely based on whether or not they see it in the editor - not even necessarily the imagery - would be making those questions harder to answer, especially for information that can only be verified on foot. I'm fairly sure I've extended a sidewalk way too long before realizing the problem on foot later at least once before.
Making the router follow the sidewalk doesn't seem like the one good reason to remove information from the map that's usable for answering questions like that is what I'm saying. What would be even messier to deal with is if people started tagging sidewalk=no on roadways that have sidewalks which shouldn't be preferred over the roadway - that means trying to analyze what sidewalk quality or use looks like on the whole impossible altogether because then the information about the "bad" sidewalks is gone from the data. If there's some specific areas where the sidewalk=separate makes the router work particularly well, maybe there could be some kind of overlay layer for those areas so that it's clear what it's for and where it works.
On the contrary: this would only be the case when there is consensus that a specific tagging variant is "approved".
Even then - there could be a case where one variant is approved but competing is used at least as much or even more dominating
(Here only the cyclepaths have been filled in.)
untrue - see https://www.openstreetmap.org/way/329492554#map=19/51.38560/-0.12814 (has foot=yes segregated=yes - so it marks both cyclepath along road and footway along road)
I'm a bit stubborn about sidewalk=separate not being usable for a few reasons
That is not a good place to try deprecating massively used schema. Many people use it and it is useable.
Even if a router doesn't change its behavior because of sidewalk=separate having no separate way, it makes the rest of the sidewalk tags less effective, particularly sidewalk=no, if sidewalk=no and sidewalk=both alike are getting replaced with sidewalk=separate
Currently correctly mapped sidewalk=no NEVER can be replaced with correctly mapped sidewalk=separate
What would be even messier to deal with is if people started tagging sidewalk=no on roadways that have sidewalks which shouldn't be preferred over the roadway
that is as invalid as mapping sidewalk=both where sidewalk is not existing and invalid tagging is possible with any tagging scheme. sidewalk=separate is not even making it more likely
Sidewalk=separate is impossible to survey without the corresponding OSM data in front of you. If I am writing down notes from a survey, or using a mobile editor with aerial imagery, I have no way to tell whether something has been mapped separately
Mapping in OSM always requires being aware what is mapped - you cannot making edit adding POI/roads etc without checking what is mapped.
Also, typical mobile editor allows to display existing data.
Also "is impossible to survey without the corresponding OSM data in front of you" is not true. Corresponding OSM data is needed while editing, for which OSM data is inherently needed.
Overall: there could be a valid reason to ignore widely used tag, but in this case it seems personal dislike based on bunch of misunderstandings.
The vast majority of sidewalk=separate uses in India are sidewalk=no. If entire countries don't have a single use that matches the description, that is not a widely understood tag. Here is the problem with the situation in India I am pointing out:
- If you look in most of the places in India that have sidewalk=separate where the imagery is clear enough, you can see that it is really sidewalk=no.
- In an urban area which is too built up to discern sidewalks clearly from imagery, you have sidewalk=separate down Laxmi Road (middle) here - you have two options as an editor, assume that this means sidewalk=no based on the fact that this is what it mostly means in India, or you assume that it means sidewalk=both based on the idea that sidewalk=separate means mapped as a separate way.
- If you are in iD, and you see sidewalk=separate with no separate way, you might draw the separate way without realizing that this usually means sidewalk=no in India.
- Alternatively, you might switch it to sidewalk=both or sidewalk=no depending on your interpretation since you have seen there is no separate way.
Meanwhile, the imagery still does not tell us if there is actually a sidewalk here, and unless someone surveys this independently of the OSM data - meaning surveying first, checking how it's mapped later - this question of whether or not there is a sidewalk here looks "answered." Nowhere in this situation is the mapper ever able to correct this issue in iD if they think sidewalk=separate is widely understood to be sidewalk=both. This is what I mean by removing information, it makes sidewalk=no getting mapped as sidewalk=both a possibility if we ignore the fact that this is mainly used to mean sidewalk=no in many countries.
The street level imagery at that location in Croydon shows that the cyclepath and sidewalk are segregated from eachother. Mapping them together as one way when they have different geometries is not mapping the sidewalk separately.
I am not suggesting deprecating anything, I am more just pointing out that the existing use of sidewalk=separate does not even show what people are saying it does.
Surveying requires you to not look at the map in some situations. For example, one of the areas I've surveyed that I only have handwritten notes on (not mapped yet) is a stretch of road where the sidewalk and driveways were reconstructed over the course of months. On the first day it was open to walk on again, I used my phone to take photos (not possible to have OSM open at the same time) and then used the handwritten notes to get down details that can't be discerned from imagery. (For example, temporal details if you don't have images of what it used to look like but know from memory. That way you can add start_date=* to tactile paving pads that you know are there but aren't going to be in aerial imagery for another few years.)
The vast majority of sidewalk=separate uses in India are sidewalk=no. If entire countries don't have a single use that matches the description, that is not a widely understood tag.
There are only 63 instances of sidewalk=separate in India, a tiny portion of the global total and of all sidewalk tags in India, so it doesn't seem like a big issue.
Right, I am just concerned about what the tag would look like if it were presented as an option while not being widely understood the same way. As far as I can tell, there are only a few countries where the number of uses of the tag is more than 2,000. The concern about it being self-referential is still there; putting data that describes OSM data in the map seems like it could cause these kinds of issues. Anyway, I've said my piece on that, if people don't agree it would at least be interesting to see what happens with it
The need for distinguishing separately mapped sidewalks from implicit sidewalks is not theoretical. When the OSRM developers discovered that sidewalks were being mapped as separate ways, they were understandably alarmed because suddenly two dense routing networks were being connected very strongly to one another, producing alternations between the two: Project-OSRM/osrm-backend#4790.
If I am understanding these links correctly, if I were to add sidewalk=separate or sidewalk:left=separate where applicable on Traction Street, it would route along the north side of Traction Street's sidewalk instead of along the road. In real life though, everybody would walk in Traction Street on the roadway itself, and if they did get on the sidewalk, a good number would do it at the point shown. On a narrow street with discontinuous sidewalks like that, there often are too many obstructions to walk anywhere but the road, and you're not any less likely to get hit by a car walking to the side anyway. Adding sidewalk=separate would make the router produce a worse result rather than a better one, and the spatial inference it's making in the absence of that tag is actually a really good one in this case. If the one reason to use sidewalk=separate is to prevent the router from going in the roadway when sidewalks are present, that's not even an assumption that should be made anyway.
You’re assuming that sidewalk=separate would be determinative, preventing anyone from using the roadway even if there’s no other way to get to the destination – this is not the case. Below are some examples of pedestrian routers taking unlawful and unsafe shortcuts in the absence of sidewalk=separate. You can play around with the endpoints in this neighborhood to find countless more misleading routes. (Local mappers do want to add sidewalk=separate soon, so these examples may not last long.)
- Hillview Park across Ocala Avenue – crosses five lanes without a crosswalk, speed limit 35 mph (average speeds much higher), even though a slight detour to the east or west would find a suitable crosswalk (reproduces in GraphHopper, OSRM, and Valhalla)
- Orlando Drive to Bermuda Way – a classic case of finagling through a signalized intersection instead of going around it on marked crosswalks (reproduces in GraphHopper)
- Southbound Almaden Expressway – ignores perfectly usable but circuitous sidewalks in favor of walking along an expressway with a 50 mph speed limit (reproduces in GraphHopper)
Sometimes the route does need to traverse the roadway due to obstructions or discontinuities – that’s fine. A router should be able to cope with those situations by falling back to the roadway as a last resort. But in order to treat it as a last resort, it has to recognize that the sidewalk is associated with the roadway. Algorithmically associating sidewalks with roadways is hard: https://github.com/OpenSidewalks/OpenSidewalks-Schema/issues/2#issuecomment-1074404560.
I’ll make the same point I did in defending pedantic sidewalk ways and in arguing against pedantic interpretations of access restrictions: the basic job of a router is to recommend the “best” route, however “best” is defined. If you want to develop a pedestrian routing profile that recommends taking shortcuts through streets without the benefit of local knowledge and produces very confusing guidance instructions, that’s your prerogative, but let’s not force that decision on more vulnerable pedestrians surrounded by potentially aggressive drivers.
The introduction of this field would mark the first time iD presents two different ways to indicate the presence of a sidewalk, exposed in two very different places. One mapper will likely learn a different mapping style than another. Without a separate option, the two are likely to map the same sidewalk redundantly without realizing it, but routers will miss an opportunity to cleanly distinguish the two mapping styles.
The merits of relegating pedestrian infrastructure to an auxiliary detail of motorized transportation can be discussed at further length
This is not the way, such is perceived in my area: Here a street is open for all public traffic, any means of transportation. Maybe in some parts of the world, streets are for cars only and pedestrians merely regarded obstacles. Sidewalks here are but lanes. If they exist, pedestrian have to use them, except in rare occasions, where they are to walk on the carriageway, even though sidewalks exist, e.g. when carrying bulky goods, or in winter, when a certain sidewalk is not serviced. Very rare :)
@tyrasd I ran into this twice the last few days. Once with GoMap and just now in iD. The GoMap case would ideally be mapped as separate sidewalk but there was a bridge and crossings involved which I did not had the time to map on the go, so I wanted to add the sidewalk key on the centerline at least. And just now in iD on a highway=service where not even Mapillary images are available (which is pretty uncommon in Berlin…), so separate geometries are not feasible for me for this case as well.
Meaning, we need this preset – the same way we have a bicycle preset.
I write this to ping this again so this may get pushed over the finish line.
The GoMap case would ideally be mapped as separate sidewalk but there was a bridge and crossings involved which I did not had the time to map on the go, so I wanted to add the sidewalk key on the centerline at least.
iD’s validator makes it easy to add crossings and bridges (albeit with placeholder lengths). If Go Map!! lacks these conveniences, that would be another enhancement to pursue in parallel.
Meaning, we need this preset – the same way we have a bicycle preset.
I assume you’re referring to the cycleway field. Unlike the sidewalk field in this PR, the cycleway field has a separate option:
https://github.com/openstreetmap/id-tagging-schema/blob/993b6b093571b5cfd3b647e6153e115a01d9bc26/data/fields/cycleway.json#L47-L50
Even so, there’s a lot of inconsistency out there: cycleway=separate without a corresponding highway=cycleway, highway=cycleway alongside cycleway=lane, etc., and the slow-motion edit wars to go with it.
The introduction of this field would mark the first time iD presents two different ways to indicate the presence of a sidewalk, exposed in two very different places. One mapper will likely learn a different mapping style than another.
I think part of the solution would be more robust validation. Editors need to warn when the in-street and off-street mapping contradict each other. Unfortunately, it isn’t straightforward to programmatically associate a separate cycleway or footway with its street, and tagging proposals to that effect have stalled.