Only to the same extent as mapping any roadway or pathway as a linear feature. Mapping pathways as lines isn’t equivalent to mapping an informal shortcut. It also shouldn’t dissuade anyone from also mapping pedestrian plazas, running track multipolygons, and roadway and footway areas so that, say, a pedestrian simulation game could take the path less traveled.
I tend to think that most of this infrastructure should be mapped separately for many reasons, but I can see the arguments that people make for tagging it on streets. That said, tags on streets are far less useful to me as a pedestrian consumer of data, and if we want to, as a community, consider street-based sidewalk tagging as anything other than a preliminary step before someone maps it as separate infrastructure, there are some major tooling and rendering issues we need to resolve. This is separate from the “which is better” argument that we could go all day about what’s proper, and instead showing where the incentives are to map things separately:
- Very few renderers of the map will show sidewalks if they’re tags on roadways rather than separate infrastructure. We shouldn’t map for the renderer, but the renderer should map for the users of the data, and right now, renderers don’t yet support the user that wants to casually plan their foot path and make sure they can stay on sidewalks - unless those sidewalks are mapped as separate ways.
- The big 3 pedestrian routers will inconsistently use sidewalks when mapped separately, in my experience, but when they’re mapped as tags, it is completely opaque to the user whether or not they’re being routed on a sidewalk or down a street. I know at least some use the data and I suspect they all do, but it’s not passed along to the user so they can decide if the route makes sense.
- Intersections and curbs are nearly impossible. The tagging/node schema for an intersection to map whether or not there are crosswalks and whether those crosswalks have flush curbs is challenging and confusing, and still doesn’t help a user evaluate the safety of the route. This is of concern for accessibility, but also for anyone with anything that rolls - a wagon, a stroller, etc - which probably make up a decent chunk of people looking for pedestrian routing. This could be improved with better documentation and making these nodes more visible, but even still, I think they’re harder to interpret for a user of the map/data than an actual line for a crossing. That’s just my opinion though.
Regardless, I think we often debate these things as if the choice of how to map them is a neutral decision for the end user and is just about how to best store the data. But unless we make improvements to how tooling/routers/renderers handles the tagging data, the experience is very poor for pedestrian users unless the infrastructure is mapped separately - and that’s not a shot at the people doing the work of maintaining these tools, but just a reality of the current experience. I think that should be front and center in these discussions.
2 Likes
What is the point of trying to redefine the concept of sidewalk? Do anyone expect the 3 million ways to thier tags changed. ID has supported the idea for ay atleast 10 years. I realize it bugs people that use the term for their at grade footways. There are plenty tags that are equally entrenched that annoy me. Please move on to other tags that need work!
Well. That issue has been discusses many times, and never has a consensus been reached, so I’ll find it a waste of time to invest too much time into discussing it again.
So just one thing for your consideration. Even if I agree that separately mapped sidewalk can contain more details and thus be more useful than just tagging sidewalk=yes on a existing highway=residential for example; the amount of effort needed to do so is absolutely not worth such minor difference. So I disagree with that “far less useful” qualification. I’d use “slightly” or “somewhat” instead of “far”.
But the biggest thing is that I can tag sidewalk:both=yes on 100 roads in StreetComplete in the same time that it would take me to draw that sidewalks on 1 road in Vespucci (and likely with less errors). Yet, clearly mapping those 2 sidewalks as separate ways around 1 road does not provide 100 times more value.
Thus, in vast majority of cases, I just tag them as additional tags instead as of separate ways, and use my time do add other useful things on the map. As in my mind, 100 roads with sidewalk:both=yes (or similar tags) is much more useful than 1 road with separately mapped sidewalks.
If that is important feature for you, then perhaps you should lobby those routers to do the better job with displaying the data they’re using? I’d guess that investing time in writing such issues (or even PRs) has a much bigger chance of being successful, then writing a post on community forums has on radically swaying opinion of countless thousands of mappers which were unconvinced for past several decades?
And there is another option to be the change you wish to see in the world. If you’d like to see more sidewalks being mapped as separate ways, you can just go and map them as such. In most communities which do both, nobody would deride you for changing a simple tag (like sidewalk=yes) to a separate highway=footway way(s) mapped with more details (and replacing that tag with sidewalk:xxxx=separate). On the contrary!
But you should probably not expect that others must share the same enthusiasm for investing their precious time to do such minor (as it may seem to them!) improvements.
TL;DR: IOW:
In theory, the question might be about “should sidewalks be mapped as simple tags or as a separate ways?”
But in practice, for many mappers, that question is really more of a “should sidewalks be mapped as simple tags, or not at all?”
2 Likes
This dilemma is mostly predicated on the ergonomics of whichever editor you’re using. For an iD user, for instance, tagging sidewalk:* isn’t necessarily simpler than drawing a sidewalk way. And even if iD adds a sidewalk field, there will always be mappers who gravitate toward a separate-way representation, just as some newcomers instinctively map each shop in a strip mall as an area. On the other hand, it’s pretty hard to imagine StreetComplete in its current state helping its users map sidewalk and crosswalk ways when even stop signs pose a difficult challenge.
If the goal is to maximize coverage while prioritizing ease of entry, then I wonder what folks in this thread think of using automated approaches based on imports, road geometry heuristics, or computer vision as a starting point. None of these approaches is perfect by any means, but the quality triangle only has so many vertices.
Maybe if the question were posed differently, this thread wouldn’t go on forever. It has been pretty clear from the start that there’s no one way to map a sidewalk. But if there could be consensus about the acceptability of sidewalk and crosswalk ways, then most of the proponents of that mapping style would take that as a very positive change. Beyond that, I’m stubbornly hopeful the community will someday come around to sidewalk ways, just as I finally gave in about stop bars, if only because reality defies any attempt at simplification.
1 Like
The consensus in the 한국/조선(Korea) community is that if it is protected by a curb or solid obstacle, it should be drawn separately, and if it is just a floor marker or unprotected plastic obstacle, it should be included in the street attributes.
I think this applies to two-way streets as well as sidewalks and bike paths.
한국/조선 커뮤니티에서는 연석이나 견고한 장애물로 보호받는 경우에는 되도록 따로 그리고, 단 차이가 없고 바닥 표시로만 표시되어 있거나 보호받지 못하는 플라스틱 장애물 같은 것은 길 속성에 포함해서 그리는 쪽으로 의견을 모았습니다.
이것은 양 방향 도로도 마찬가지이고 보도나 자전거 도로에도 적용할 수 있다고 생각합니다.
2 Likes
Where I live, the relief is profound. Sometimes there are two pavements running parallel on a single side to a residential road, each at different heights.
Separate footways is a necessity here.
Yes. We don’t draw separate “lanes” (i.e. only floor markings) as separate OSM ways, so in that case one would just use additional tags instead of drawing separate ways (see e.g. Pedestrian lane on the road)
And also yes, sometimes the footpaths diverge from the road or have some special reasons (e.g. become bridges, crosses the road, etc) that makes it reasonable to always map such cases as separate ways.
But this historic lack of consensus (which is being talked about here) was never about either of those two categories mentioned above (which happen to be minority of cases globally).
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)
I doubt that bringing “do you like AI in OSM?” into any topic will make it less contentious 
- I have no problem (and in fact, encourage if they like doing that!) human mappers to convert
sidewalk:left=yesorcycleway:right=trackinto separate ways tagged ashighway=footway/cyclewayin order to improve details and add extra details (surface,smoothness,lit,barrier,obstacle, …)
(though they should remember to replace original value with*=separatein order to avoid confusion) - I have no problem with automated imports and AI adding data where no data is existing, providing they add the tags to indicate it was result of import / AI detection.
- I am even OK with some kind of program or AI assisting human in tedious task (like making sure drawn
highway=footwayis parallel to original road, or follows aerial imagery) as long as the human does the important part of the work (just in less clicks) - I am however not OK with AI / import tools messing autonomously in areas where human mappers are doing that same type of work. I don’t find them nowhere near good enough for that, and they damage the community (not only by dubious data quality, but on sociological level too - see several articles linked at bottom of Import - OpenStreetMap Wiki). IMHO, that amount of bot autonomy should be accepted only when we’re at level of removing humans completely from OSM mapping, and having autonomous drones map everything instead. However, I’m not sure if our AI overlords would care much about OSM at that point
5 Likes
Fortunately, everyone seems to be on the same page about minimizing the need for conflation, because conflation is hard. After all, if it were straightforward to conflate linear navigable features, we’d have dramatically more speed limit coverage in the U.S., and plenty more sidewalks too.
Building conflation
Buildings are a lot easier to conflate than sidewalks, but practically every building import sticks to backfilling only the buildings that don’t overlap with existing buildings, and only some eventually get around to conflating the rest.
Data consumers like Bing and Mapbox only backfill CV-detected buildings where they don’t overlap. It would be nice if they could also respect demolished:building as a signal not to revivify a demolished building. It would also be nice if they could exclude whole localities where the community has already imported buildings comprehensively and is doing a good job of keeping them up to date.
When we imported sidewalks in San José, California, there were already some sidewalk and crosswalk ways, but they represented a tiny fraction of what was being imported. (Also, I was the one who drew them by hand, so I think my support for the import mattered a bit.) We handled conflation manually as part of reviewing each task in JOSM before upload. That kind of review isn’t particularly amenable to the binary thumbs-up/thumbs-down review that Rapid is focused on. Any conflict requires performing surgery on the map – not too difficult to do in iD, but not much different than ordinary, unassisted mapping.
We still have to blanket the city with sidewalk=separate tags, so thanks for that reminder. It hadn’t been an urgent priority at the time because the tag had just been proposed and no router supported it yet, but I suspect the situation has improved now that sidewalk ways are more common.
2 Likes
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.
11 Likes