I’m wondering if there is OSM Community consensus on the mapping of pavements/sidewalks on OSM. I’ve seen some people prefer to map them separately whilst others prefer to leave them, and just mark them using the sidewalk= tag.
This can be confusing for pedestrians, as the difference in mapping standards leaves a question of how to mark obstacles and information specific to the pavement, such as steps, elevation data, etc. It also means using the map effectively can be difficult, as it can’t be clear without delving into the tags where someone can and cannot navigate by walking.
It would be nice to discuss this with the community and see if a more agreed standard could be formed.
In general I find mapping sidewalks as separate ways in typical suburban neighborhoods simply adds clutter and potential errors. For example, you need connecting nodes for every driveway the sidewalk crosses. In my area many sidewalks are not continuous so every place a sidewalk stops or starts you need to:
Terminate the the way at a node. But then your pedestrian routing is broken and the QA tools complain. You can add a noexit=yes to keep the QA tools happy but that does not fix the foot routing.
Or you need to add a connector from the sidewalk to the road to make the foot routing work. But those connectors are not really there, they are simply aids to allow routing and keep the QA tools happy.
So I generally just add sidewalk=left|right|both to the road itself. The exception for me is if the sidewalk does not exactly follow the road. When that happens then I will use a separate highway=footway.
Short answer: When the level of detail you want to map is easier to represent on a separate line then do so. Otherwise, an implicit tag is good enough.
Longer answer: Sidewalks have many special cases e.g. varying surfaces, geometries that deviate from the underlying street, or passing through tram platforms. Also, the geometry that results from the carriageway’s center line might be unacceptable as geometry of the sidewalk because of e.g. transition from one to two separated carriageways or for uncommon design of crossings. So there are situations where a reasonable mapper will come to the conclusion that a separate way models best the actual situation on the ground.
However, for most streets we simply lack the information whether they have a sidewalk at all. A survey in my neighbourhood and during the SotM France in France, followed by looking on aerial images elsewhere resulted in that ways with “highway=residential” have sidewalks on both sides in less than 80% of all cases on the ground. Other highway types are even less likely to have sidewalks. This means that we basically need a sidewalk tag on every car-passable highway. And by the length of the street grid it is a huge project to collect that information everywhere. Allowing for tags instead of explicit geometry helps to speed up collecting the information a lot.
This insight is the result of building a wheelchair-enabled routing myself in the metropolitan area here and presenting it in a talk on the FOSSGIS, the German SotM.
I want to emphasize this also goes the other way around.
I often see people “painting” separate sidewalks and breaking pedestrian routing, because it’s hard to get all the little connections right that are needed therefore.
Personally, I map sidewalks separately because I’m often trying to improve pedestrian routing. I use e.g. BRouter’s hiking-beta algorithm, and look for places where it doesn’t send me where I know it should be able to, and then add sidewalks and connections as required. It can sometimes make for cluttered rendering, but I think that’s a matter for the renderers to sort out (and some of them do very well).
A core reason for this situation is that both commonly used approaches lack the ability to capture some important knowledge about the world: Tags on the main highway=* cannot faithfully represent sidewalk geometries (and struggle to represent details such as barriers on sidewalks), while separate ways fail to capture the information which road a sidewalk belongs to. As a result, either choice makes some use cases of OSM data much harder or impossible to implement.
Notably, this means that – contrary to the answer by @drolbr – neither of the approaches has a higher level of detail than the other: Both are omitting information which would be readily available with the competing approach.
I believe that a sustainable consensus will require a solution that works for all use cases and doesn’t force mappers to choose the lesser evil. I expect this will involve mapping sidewalks as separate geometry, but expressing the relationship to the road in a machine-readable fashion. Some solutions have been suggested (e.g. the is_sidepath:of:name=* tags), but so far, none have gained traction.
As a developer of both rendering and navigation software, I can attest to this tradeoff. Sidewalks need to be associated with roadways for pedestrian navigation using wearables and especially for assistive technology for visual impairment. The latter use case relies exclusively on voice guidance, so the street name is essential, but so is accurate data about obstacles. I’ve seen at least one wearable application configure Valhalla’s costing model to avoid sidewalk ways just to get road names in voice guidance, but it’s clearly suboptimal.
Despite this tradeoff, I lean in favor of separate ways. Tags on ways are inherently incapable of representing geometries effectively, whereas the problem of associating sidewalks with roadways is hopefully solvable. In regions like mine where sidewalks are generally separated by a curb or verge, if someone is willing and able to draw separate sidewalk ways, I think they should be encouraged to do so. Eventually someone will have to draw the ways anyways, so we should take advantage of that zeal when it arises.
Some cities have been adding name or street:name to sidewalks. In principle, data consumers should be able to infer that the sidewalk and roadway are related by comparing their names, in much the same way that Nominatim matches addr:street to road names or Skeletron generalizes dual carriageways based on road names.
I suspect this approach hasn’t caught on more broadly because of the assumption that data consumers can already infer these associations based on geometry alone, or maybe based on sidewalk=separate. Unfortunately, a typical city abounds in cases that violate this assumption, requiring a more explicit approach.
As a counterpoint, if the sidewalks are only tagged on the roadways, a non-sidewalk footpath would also need virtual connections with roadways to avoid breaking pedestrian routing. Here are some trivial examples of non-sidewalks that would result in oversimplified routes if connected directly to a roadway without separate sidewalk ways:
Long ago, I started out using the sidewalk key exclusively. Over time, I discovered a steady stream of these edge cases, each one necessitating an oasis of more detailed mapping, until the point where it just made common sense to link the oases together with separately drawn ways.
Technically, taking a shortcut across Abby Way would require trespassing on private property (the verge), followed by jaywalking. Obviously, this is quite pedantic next to a park in a quiet subdivision, but the laws are on the books. Anyhow, the legalities matter less than telling the user something helpful. A mapper could sarcastically tag the whole park as a pedestrian area if no sign forbids walking on the grass, but the reason someone would consult a map or a router is to know where one is expected to go, whether they end up listening to the router or taking a shortcut.
I understand that jaywalking is a completely foreign concept in some countries. But putting that aside, hostile architecture and facepalm moments are surprisingly common in many parts of the U.S., where pedestrian infrastructure is often built for reasons other than facilitating travel on foot (like aesthetics). The #sidewalks channel in OSMUS Slack is a perpetual blooper reel. Hopefully this helps to explain why there’s so much enthusiasm for mapping sidewalks and crosswalks in greater detail.
As creators of a detailed cycle routing engine, we support the use of separate ways.
Fundamentally, a separate way makes it easier to give more detailed information about the path, e.g. width, surface, etc., and more accurately reflects the reality on the ground.
However, it must be done carefully, e.g. proper connectivity, ensuring street names are included, etc.
The question of separate paths is addressed in significant detail in our State of the Map 2019 conference talk:
As a European who has moved to the United States 11 years ago, I can attest to the peculiarities of U.S. pedestrian infrastructure from a European perspective. Just a couple of examples:
Sidewalks can just end at random without any indication of where you can legally continue on foot:
When I moved here I was a strong proponent of mapping sidewalks as attributes on the street. Don’t make things more complicated than they need to be. I quickly changed my mind. Someone already mentioned that mapping sidewalks as attributes creates a need to split ways into tiny segments in some places because the random nature of sidewalk coverage. Access limitations further complicate this: some sidewalks are wide enough (and with high enough quality of paving) to allow for wheelchair access, but very often this is not the case:
Do you have an example of a router automatically associating sidewalks with roadways? It’s one thing for the router to prefer the sidewalk over the roadway, but that’s just a matter of boosting sidewalks or penalizing roadways. It’s a bigger feat to include the sidewalk geometry in the route but reliably refer to it by the road’s name in guidance instructions and avoid overly detailed instructions around intersections.
I’m pretty sure one could get decent results by map matching the sidewalk coordinates to the road network, in the same manner that one might clean up a messy GPS trace (with all the same caveats). But I don’t know if it would be practical to perform this map matching performantly as part of a standard pedestrian route calculation.
That’s a poor excuse for a data model that won’t yield sensible routes for able-bodied pedestrians.
Also, I happen to fall into the category of “somewhat impaired people” myself and that does not magically make safe crossings appear on the roads around my home. So I can choose to either cross the road where there is no crossing or take a taxi everywhere.
More generally, these sidewalk discussions could be a lot more productive if we started with an agreement that the data model should meet the requirements of all use cases. I’m sick of 10 years of “your use case is irrelevant, let’s just throw it under the bus”.
This is a consideration that varies considerably from one locale to another. On one end of the spectrum are countries like Vietnam where crosswalks are rare, and the normal way to cross a busy street is to hold up your hand and cross anywhere as dozens of speeding motorcycles swerve around you. As I mentioned earlier, the U.S. is at the other extreme: in some cities, people without mobility issues do routinely jaywalk, but elsewhere, they seldom do, which means drivers are unaccustomed to watching out for someone who is crossing the street.
Either way, a router that glosses over implicit safety considerations would have to lean quite heavily on its disclaimer of liability – hardly an incentive for developers and users to trust OSM for accessibility.
Right, sidewalk mapping shouldn’t be a zero-sum game. From a typical router’s perspective, there are very few things that would disqualify a way entirely, like access=no or hazard=dragon; the rest is about balancing priorities and penalties.
That balance is difficult to achieve. In principle, each of these very common examples of poor routing could be solved by omitting detailed sidewalk ways or by having the router avoid all roadways. But sometimes using the roadway is truly required and probably safe. Other times, it’s probably legal but very risky. Is cutting out a 1½-mile-long detour worth the risk of road rage and serious injury? I’m not sure that a router should automatically answer that on behalf of a pedestrian visiting an unfamiliar place. At most, a router might present a shortcut as an alternative for the user to select at their own risk, but not as the main route.
The more context we can give routers, the less that routers will need to guess without the benefit of local knowledge, and the more that end users can trust what the routers recommend. There are indeed many use cases, not all of which are satisfied by a one-size-fits-all routing profile. Just as micromapping has given rise to alternative rendering styles and even 3D rendering, maximizing detail about pedestrian infrastructure can promote the development of alternative routing profiles for additional use cases.
While it is correct that it allows for higher level of details, I’d point out that this in itself does not imply that “it is always the best”. Separate mapping has disadvantages too; e.g. to name a few (without intent to spark discussion about which is better, but just to show that other side exists too):
it increases database size (e.g. “sure, million of natural=tree nodes each with its own species=*, height=* and diameter=* is way more precise then one (or a few) areas with just landuse=forest and leaf_type=*”, but except for some outliers, majority of users would probably agree that it is bad idea to that precise in that case). While in the past it was often suggested to disregard this aspect as more detail is often deemed more important, it does cause problems (slower operations, requiring better mobile devices and better servers, discouraging local custom instances due to time and resource requirements to replicate DB etc). Separate sidewalks (and by extension, separate cycleways too) ways are only somewhat less extreme.
it often (i.e. almost always if we disregard imports) increases initial effort. e.g. I can mark sidewalk situation on the ground using StreetComplete in literally three clicks per street without even slowing down my stride, while mapping them as separate ways in iD, JOSM or Vespucci is significantly more work.
it increases maintenance effort. E.g. if better / more precise imagery becomes available, it is not enough correct one way, but 3 (or 5, if sidewalk+cycleway) need to be corrected. And unless uses some helper functionality, it is very likely the result might be ugly (e.g. roads and their sidewalks not being parallel) and thus less visually pleasing and harder to interpret and use.
it is harder to associate related elements and to keep them in sync, and it is less neat. More precisely, if sidewalk is considered integral part of the road infrastructure connected to some road, one may need to detect what road it is associated with (e.g. sidewalk:left=separate, footway=sidewalk, is_sidepath=*, relations etc.) It also breaks 3NF (IIRC database purists out there).
By that logic, all the sections of sidewalk with a railing or narrow verge between the carriageway and the sidewalk would somehow cease to be sidewalks. Would they also cease to be sidewalks where there is a legal prohibition of stopping next to the sidewalk?
Defining a sidewalk only by its utility to a motorist isn’t why people map separate sidewalks. Pedestrian navigation and accessibility considerations are far more important to me.
It should be noted that all signatories of the Vienna Convention on Road traffic will have national legislation that allows pedestrians to cross the road in any place as long as there isn’t a crossing nearby (Art. 20 5.).
Earlier this year, the infamously car-friendly state of California relaxed its crossing-related laws so that a police officer can only stop a pedestrian for jaywalking if they walked carelessly into oncoming traffic. The motivation was that racial minorities were getting fined or arrested for jaywalking much more frequently than white people, reflecting an apparent bias. However, jaywalking remains prohibited per se; an officer could still enforce it in relation to some other offense. If you jaywalk and get into a collision, you could be found at fault.
Even if jaywalking were perfectly legal, it remains the responsibility of an OSM-based router to recommend the best route according to the requested criteria. It should be the router’s responsibility, not the mapper’s, to optimize the route by taking shortcuts based on the user’s comfort level. This goes for pedestrian and wheelchair routing as much as for bicycle and motorcycle routing. If a router is unable to satisfy actual user expectations because of the tagging scheme, the problem might turn out to be orthogonal to whether we map sidewalks as separate ways, and the solution might turn out to be more tractable than this debate.
More broadly, it may be tempting to map a workaround for suboptimal infrastructure on behalf of users, but this can paper over the problem, making it more difficult for community members to argue for better infrastructure, perhaps relying on an OSM-based analysis.
The lack of consensus was instead about remaining 95% (or whatever) of footways that could reasonably be tagged either as a separate way (with advantage of allowing for more details and precision) or as additional tags (with advantage of being vastly easier and faster)
there is another advantage with drawing an own way for footways: we don’t have to split the road for changes that only happen on the footway, and we can map obstacles and barriers (e.g. bollards) and other stuff (e.g. telephone booths, vending machines,…) on the footway both, topologically correct and without resorting to complex indirect descriptions/tagging.
