Proposal talk:Sidewalk schema

Current status

I've been dealing with tagging sidewalks locally and I'm wondering if the discussion around this proposal has stopped or what the status is. Thanks Cbkiyanda (talk) 14:53, 9 March 2017 (UTC)

Hi Cbkiyanda, this proposal is going through some rounds of internal development as we're working on implementing it in the Seattle, WA, USA region. There are some changes that we are adopting (e.g., we will no longer recommend adding kerb ramp node info in the middle of a sidewalk, and will instead place them proximal to the actual crossing location), but the core recommendations, such as mapping sidewalk centerlines and crossings as separate ways, will stay. We'd like to push a big update to this proposal within the next month or so, so please stay tuned (you can also contact the originators of this proposal at info@opensidewalks.com if you'd like to be involved in the internal discussion). --Nbolten (talk) 22:31, 14 May 2017 (UTC)

Hi Nbolten your last note about the status of this proposal was in 2017 and we're in 2019 now and I'm wondering what happenend in this time. The place where I live is completely uncovered, in regard to pedestrian routing. Thanks

Please include kerb:height

In mapping for wheelchair users, I am used to tag the height of kerbs (in addition to kerb=*) explicitely with kerb:height=*cm. There is some (German) documentation here: User:Species/Access2Life#Gehsteigkanten_.28Bordsteine.29.

I've also written a JOSM-Preset and map style that include kerb:height. Thanks! --Species 21:18, 6 July 2016 (UTC)

We added kerb:height=X.Xcm. Thanks for the suggestions! --Mdrouhard (talk) 17:37, 8 July 2016 (UTC)

Please use SI unit. It is not cm, it is m. --Lulu-Ann (talk) 14:22, 18 July 2016 (UTC)

Please state the the usage of a unit (separate with space) is optional (as it is with maxspeed=* and mph). --Species 14:51, 18 July 2016 (UTC)

I've updated the spec to indicate m as the default unit, and to specify optional units should be separated with a space. Thanks! Jesshami (talk)

In general I'm likely to use cm for this, but of course its sensible to add the units. Experience suggests that there is enough variation in kerbs installed as flush that the actual height may be important. SK53 (talk) 14:56, 2 August 2016 (UTC)

Please add kerb=rolled

I've used the value kerb=rolled in my JOSM-preset for kerbs. These "rolled" kerbs have an incline of 45° and are often used to ease the access for cars/trucks/buses over higher kerbs. If they are higher than 3cm, (often usual kerb height of 10-15cm, they are very difficult (and dangerous) to cross for wheelchair users. Species 21:18, 6 July 2016 (UTC)

Oh, I saw you included the "rolled" in the text below. May you add it to the table too? Species 21:18, 6 July 2016 (UTC)

Yes, you're right. We updated it to be kerb=* because all of those values might be meaningful. Thanks! --Mdrouhard (talk) 17:37, 8 July 2016 (UTC)

Mapping Issues

This discussion has been transposed from a series of emails, initiated after our proposal was presented to the accessibility listserv

a) there has to be something visible to be used by the community. This would be achieved in parts with your rendering, but that's not enough. If something tends to be abstract and is not visible in the common editors (JOSM and iD) it's hard to get it mapped by any user. --Peter 6 July 2016 (UTC)

We agree, we are interested in proposing a sidewalk layer that will highlight the proposed schema, and would be visible in the primary editor. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

b) What is a proposed crossing? For different disabilities different features are relevant. Wheelchair users need lower up to no kerbs, depending on their individual fitness, and especially upwards (downwards slightly higher kerbs might be acceptable). On the other hand, blind people want crossings they can detect, so lowered kerbs are okay, no kerbs at all without accessibility marks attached are quite dangerous. --Peter 6 July 2016 (UTC)

Our proposed crossing is in line with the highway=crossing that already exists, it has features for wheelchair accessible, and tactile paving. We treated kerbs as separate points. Are you proposing additionally accessibility features for people with low vision? The way we treat crossings as ways, would be visible to routing algorithms, and could notify people, but there is definitely space for additional tags. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

I don't have an idea here, and I don't think it' that relevant for the map data. Where low vision becomes an issue is the mapping itself (how to edit the map with low vision). But: For low vision zero-height-kerbs are particularly important, as they are a potentially dangerous thing. --Peter 8 July 2016 (UTC)

c) How to detect/provide the connection between sidewalk and street? Does the sidewalk get the name of the street as well? Tagged as "name=..." or differently? Or is there any other way to connect the two? Your proposal mentions a relation as "To be done". IMHO that's a bad idea. Relations are hard to maintain at all. Adding relations to core features like streets leads to (i) many broken ones, as people don't maintain the relation while editing the street, and (ii) bad coverage of the relation. Therefore the relation linking street and sidewalk would have to be detected by some automatic heuristic for the badly mapped cases - and if that works sufficiently the relation is not needed at all. --Peter 6 July 2016 (UTC)

I don't think this is totally resolved, but from other proposals we've seen relations seem to be the preferred choice. Naming sidewalks is probably not appropriate unless there is already a common name associated with the pedestrian way, it seems they probably wouldn't be maintained. Libraries exist to do this conversion, (https://pypi.python.org/pypi/Skeletron) but there is no agreement that, that is the correct way to do it.--Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

If sidewalks are not named, but mapped as separate ways, the routing algorithm is quite challenged to provide a useful routing description. Sure: As long as you stick to a printed map everything is fine, the user sees what's the street next to the sidewalk and can determine it, but what about blind people, or those who are not able to read a map? Something like "go straight on 'unnamed sidewalk'", "go left on 'unnamed sidewalk'"... is quite useless, even when augmented with rough distances or intersection counts. The named link is missing here, and it feels much more safe to be able to cross check with the street sign.

tldr: If the sidewalk has neither a name nor a relation connecting it to a named street, you have to put much work into implementing automatic mapping to the street, just by using the geometric shapes and by detecting something like "roughly along...".

Skeletron - according to the description, does the other way around: it generalizes parallel lines to a single one for labelling, but as you propose (in your mail) to leave out the duplication of the name, you have to find the parallel way to name it afterwards. What about streets roughly in parallel and nearby, where one has a sidewalk towards the other side - what name do you give to the sidewalk when doing that by an algorithm?

Example in Paderborn, Germany: http://www.openstreetmap.org/#map=19/51.74765/8.75638 - the footway between Schwabenweg and the Top-Zoo shop is a sidewalk. Is it the sidewalk of Schwabenweg or the one to the service road west of it? (and I'm sure there are cases where that is not a service road).

Example in Bergen, Norway: http://www.openstreetmap.org/#map=19/60.40300/5.32083 - Sjogaten and Nordre Skuteviksveien are two sidewalks (both not mapped in OSM), but imagine the Sjogaten would not have one, and there were a single one in between. even though it might be closer to the center line of Nordre Skuteviksveien (a small street, perhaps 6 meters wide), it would probabbly be attached to the Sjogaten, which has 10 meters width for sure, so that even the mapping geometry more towards Norder Skuteviksveien might be correct). Automatic mapping to the nearest street along would fail here without additional hinting. --Peter 8 July 2016 (UTC)

Your concerns over naming make a lot of sense. We are still sorting out exactly how this will work, but after some discussion it seems our best options are:

A. Recommend people manually name sidewalks with cardinal direction as they are being added

B. Push forward with the sidewalks as relations approach, and develop a way to assign cardinal directions to the sidewalk names.

Both of these could be enforced / human verified in our import tool, however unfortunately as with everything we can not mandate compliance in manual contributions. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 13 July 2016 (UTC)

Accessibility issues

This discussion has been transposed from a series of emails, initiated after our proposal was presented to the accessibility listserv

a) Dependent on traffic conditions, an unmarked crossing on a slow moving road in the middle between two intersections can be seen as more secure for blind people than a marked one directly at the intersection. One reason for that is, that audible detection of traffic is easier when there's less traffic along your route.--Peter 6 July 2016 (UTC)

OSM generally excludes traffic because of the transience, so that is probably something that is better addressed through routing algorithms, but it is something we are considering in our application.--Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

I don't think there is any data set a routing algorithm could use that can determine the right crossing according to traffic conditions at all - even when using live data. But even when that would be used, the proposal to map the "preferred" crossing is insufficient as the mapper decides what's the preferred crossing at all.--Peter 8 July 2016 (UTC)

This still seems to fall outside of the domain of our OSM spec and more a routing issue. There appears to be external traffic information available from projects like [[1]] or alternatively people could reference speed limits to get a sense of traffic conditions. We have been thinking about different cost functions identifying "preferred crossings" for different users, based on user preferences --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 13 July 2016 (UTC)

b) How to deal with missing data? The effort to create global coverage might be worth it, but in OSM any application has to deal with missing data in some way. A map rendering is easy: If you show any object, that's fine, and where no data exists, nothing is shown. But what about routing? If you fall back to "no sidewalk exists" and want to provide a secure route for blind people, you would have to omit streets that have no sidewalk mapped - so routing get's unuseable while the data isn't complete enouogh. But nobody maps data in OSM as long as it's not useful/used by someone.--Peter 6 July 2016 (UTC)

We are working on tools to facilitate the import of municipal data, but ultimately routing software has to handle missing data and our proposal of standardizing conventions alleviate the problem.--Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

c) Sidewalk width: something not reflected in your proposal yet, but very important e.g. for wheelchair users, when sidewalks of e.g. 50cm width are mapped as sidewalk: Far too small for any wheelchair, but a sidewalk.--Peter 6 July 2016 (UTC)

We are proposing sidewalks use the existing highway=footway the width attribute exists already, are you suggesting we include it in our core features? That makes sense, we will update that. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

I think, attributes like width should be referred to as useful additions, it doesn't has to be part of the proposal as there's nothing new about it. --Peter 6 July 2016 (UTC)

A lot of the tags outlined in the proposal already exist, we are highlighting them for relevance in the pedestrian layer. We will work on clarifying the spec with diagrams and additional notation, keeping your comments in mind --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 13 July 2016 (UTC)

d) when suggested kerbs should be marked explicitly - what if there is no "best fit" kerb? How should some fit walker with normal sight determine what's the best fit, if there's no lowered kerb at all at a block (yes, stuff like that exists)? Should there be any crossing mapped at all in that case? If so, where? If not: what's the proposed fallback for routing?--Peter 6 July 2016 (UTC)

Crossings are not dependent on kerbs, they can be wheelchair=yes/no, marked, unmarked, signaled, have kerbs or not, routing software is also free to infer crossings for individuals depending on their needs.--Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

I don't think we disagree here, I just wanted to highlight the term "recommended crossings" is not very clear. You can interpret it as "well, recommended crossing is always the one with kerb at the intersection, so the other ones should not be mapped" - which is sometimes wrong.--Peter 6 July 2016 (UTC)

On top of that there are the many many corner cases not (yet) included of course: (especially wide) stairs, elevator mapping (where are exits, where are none?), multi-level mapping (bridges on bridges, ways or stairs in parallel on top of each other and many more.--Peter 6 July 2016 (UTC)

Descriptions of crossings, and many other features should be available through the attributes already established.--Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

In Phase 2 the project aims to build import tools, but data without usage is worse than no data at all. Routing for blind people needs different routing descriptions and has to be accessible without a graphical map representation at all. SO what about routing with announcement of side-of-the-street, description of crossing types and stuff like that?--Peter 6 July 2016 (UTC)

What do you mean by side-of-the-street? Do you mean shoulders that are not sidewalks? Descriptions of crossings, and many other features should be available through the attributes already established. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 8 July 2016 (UTC)

In both cases the street serves both as a tactile (by kerb or strip of grass) and audible (by cars sounds) landmark, so it's useful to announce the side, like "go along Main street, you're on the left sidewalk". In my tests with a blind co-student he mentioned that as relevant information as the alternative sometimes is to walk straight until the GPS tells you to turn around.--Peter 8 July 2016 (UTC)

Correct me if I am wrong, you are pointing out the importance, for people with low vision, of indicating which side the street lies on in relation to the direction they are moving. We have not totally sorted this out, however one way we are thinking about it is: If we have a sidewalk with related street, then based on the street and direction our route is moving this user, we should be able to reveal which side of the user the street is on. --Jesshami (on osm, edits, contrib, heatmap, chngset com.) 13 July 2016 (UTC)

Footway adding

See [2] for automated footway adding for routing by Nathanael Lang (Geofabrik)

Pictures

Can you please add / include existing or new images to the tags. That's very helpful for non native speakers and those who translate pages. --Lulu-Ann (talk) 12:11, 19 July 2016 (UTC)

Added, thanks for pointing this out! Jesshami (talk)

Kerbs as nodes: 3rd image wrong

correct position of kerb= nodes (with JOSM wheelchair style).

It is very important not to map a kerb=* on the intersection node of 3 ways, (as seen in your example), but to draw a small section (footway=sidewalk) from the intersection to the crossing, add a kerb, and then continue the way (with footway=crossing) to the other side of the road.

If you keep a kerb=-node on the sidewalk itself, a router would not be able to route along the path (if the user doesn't intend to cross)! -- Species 12:35, 19 July 2016 (UTC)

Thanks for your feedback! Could you send us some examples of the routing software you are thinking about? We are concerned the representation you propose is unintuitive for mappers, and not necessarily representative of what actually exists, routing algorithms on the other hand is seems can be adjusted to account for a kerb set on a sidewalk. Jesshami (talk)

An example would be OSRM with wheelchair profiles. See also its live instance (area: city of Graz).

wrongly mapped kerb

What in reality exists is that the kerb is between the sidewalk and the crossing, and not blocking the sidewalk across its way. If you put the kerbs on the node where the crossing and the sidewalk joins (see my 2nd image), this is just plain wrong and your proposal will get rejected (what I don't want to, as having explicit sidewalks accepted is something I would highly appreciate ☺). -- Species 17:40, 19 July 2016 (UTC)

There was some discussion about this issue here. I replaced the example picture on Key:footway#Example according to the consensus on the talk page which was the same as User:Species's and my opinion.--Jojo4u (talk) 12:27, 2 August 2016 (UTC)

Thanks for your clarification. It's a little difficult to tell from the images, but it appears that the curb ramps are still on the sidewalks, but are not blocking users who would wish to continue on the sidewalk instead of crossing. Is this not the case? My understanding is that several routers including OSRM use only local information when evaluating the cost to traverse a node such as a curb ramp, so a user who requires curb ramps for crossings might also be prevented from continuing along the sidewalk on the same side if that user had to traverse a curb ramp node where the curb ramp wasn't suitable. Is this the problem you're articulating? If so, we are in the process of extending our wiki page to address it more explicitly. Thanks! --Mdrouhard (talk) 21:43, 3 August 2016 (UTC)

I just wanted to jump in as well (this is Nick Bolten, Open Sidewalks project lead working with Meg, Jess, and others) to thank you for pointing out this situation, Species and Jojo4u. As mentioned earlier by Jess, the 'Solution 1' (the method you used in your OSRM example) completely solves your routing problem, but does add a significant level of complexity to mapping of the sidewalks (I would anticipate a large number of erroneous edits by new users, for example).

It's our hope that we could put this problem on the routing solutions themselves - OSRM, Valhalla, OpenTripPlanner, etc. with minimal tweaking. All that should be required is to (1) assign 0 cost to traversing a curb ramp node, so sidewalk-to-sidewalk traversal isn't messed up, and (2) determine the highway=crossing way cost by querying the endpoints (which would contain curb ramp information). While this is not the easiest thing to do right now with OSRM, it should require only a minimal level of pre-processing the data, and is not dissimilar to using elevation (DEM) data to calculate way costs.

Thanks again for the feedback! We want to have an immediate routing solution available (at least for Seattle, WA) that can use this specification ASAP.--Nbolten (talk) 22:04, 3 August 2016 (UTC)

Good to see that you agree on 'Solution 1' as the correct way to map things. Now please also do it this way. Modifying every router to work on 'wrong' data is not the way to go. Taking only kerbs on highway=crossing into account is a very bad idea! There are e.g. also kerbs on driveways (and other types) which have to taken into account, (e.g. here). And if you need a solution fast, don't map it wrong, because your edits will get reverted, an nothing is won. Every mapper that thinks a little farther than the length of nose will shake its head on heaving curb-nodes on T-intersections ^^. --Species 22:27, 3 August 2016 (UTC)

Ah, I think I gave the impression that we were agreeing to 'Solution 1': we are open to evaluating it, but have not decided to advocate for by any means, due to the increase in complexity (and accompanying maintenance problems) that it implies. Sorry for the miscommunication! 'Solution 1' also violates the principle of mapping what's on the ground - the small sidewalk 'offshoots' are not centerlines of any existing features - and as a result it wouldn't be obvious for new mappers. So we're interested in more discussion!

We are also subscribing to the idea that routers (and renderers, and the database) should accommodate good data, and not the other way around, within reason. It would be best if a routing solution worked on day 1, but it is much less work to fix the router to take endpoints into account than it is to maintain millions of slightly-wrong sidewalk data points. For this reason, we are engaging with the maintainers of routing software (OSRM/Mapbox, Valhalla, and OpenTripPlanner) to benefit from their expertise and opinions and come to a solution that works for everyone. Routing as I suggested above, with the schema in its current state, is conceptually very easy to do using something like pgRouting, and what I currently use for a private pedestrian layer in Seattle. And to be clear, there are very few worldwide routing solutions that can currently do very much with sidewalk information, due to how incompletely it has been mapped, so we are not proposing the immediate deprecation of sidewalk=* tags (nor your local use of 'Solution 1') until routing solutions are in place.

In terms of being able to enter the street or cross the street (with e.g. driveways), that is indeed a big challenge, but I believe it is an intrinsic problem of representing transportation paths as centerlines: in reality, an able-bodied person can traverse almost any flat-ish landscape, but that's not something that centerlines are meant to describe. Perhaps some day we will map streets and sidewalks with areas and can mark them as 'crossable' by pedestrians, which will more naturally accommodate free-form pedestrian movement. Until then, there will necessarily need to be workarounds of some kind. For one example, Nathanael Lang's bachelor's thesis involved adding 'fake'/'invisible' lines crossing the street as a pre-processing step for routing, which is compatible with interfacing with the street between crosswalks (marked or unmarked). --Nbolten (talk) 23:32, 3 August 2016 (UTC)

Solution 1 does not violate what's on the ground, tagging the way to the kerb as being sidewalk is just a finer approach that people are used to. It may be simpler to tag the 'offshoot' to the kerb as "crossing" - but this is also not correct, if you 'look' at it from the perspective of a blind person, who can usually feel the zebra markings.

stop sign with obvious false position

On the ground there are no kerbs blocking the sidewalk (usually, but there are some). Please compare the approach of mapping kerbs on the node of T-intersection to where you would map a "stop" sign (see image on the right) This should be obvious for every newbie mapper. If your mappers are not capable of getting this difference, I fear you are doing OSM not a favour. I care less if you are doing it the wrong way in your city, but if you do it in mine you will get reverted. And if you propose it to do it worldwide, you will get rejected.

About the routers: I doubt you can convince the router-programmers to ignore kerbs on two joining footway=sidewalk-ways. You are free to write your own implementation, but you will have to the same discussion as here with every routing-developer. And if you try to use the argument "because the data is wrong" - you will be laughed at and hear "fix your data".

About driveways: This is easy, just add the driveway and a kerb where is on, see routing example, and the kerb (example) on the appropriate places and it will work. Until we have areas (and all kerbs as ways), we will have to stick with one dimension less. I admire Nathanael's work, but his solution is not supposed for complicated crossings. We had some discussion about that with him on this years FOSSGIS conference in Salzburg. Routing for able-bodied people and the disabled differ heavily. I would not let a blind person cross a primary road on arbitrary points, but route him to explicitly marked crossings. --Species 10:48, 5 August 2016 (UTC)

When I say that Solution 1 may violate what's on the ground, I mean that it's not tracing a centerline as happens in other situations. The sidewalk way = a centerline of the sidewalk (traceable), the crossing = a centerline or center of the implied (or marked) street crossing, but the small offshoot isn't the centerline of the sidewalk, it's the centerline of the curb ramp itself. Your suggestion of kerbs as ways is an appealing one. The 'offshoot' itself could be tagged as a kerb ramp (ideally with its own visualization), which is compatible with tracing the centerline. It would work with current routing software (including OSRM), with the only downside is that it would be a new convention and potentially require a new tag (or an interpretation of existing tags, like ramp=*). The dual-use of kerb=* on ways and nodes to mean different things, particularly in combination with barrier=kerb, can be unclear (and completely invisible on the renderer), so this may solve other problems as well. This may be a discussion that warrants its own proposal.

I'm not really getting the T-intersection example. Which part would users not get / what is obvious? In either case, if new users aren't able to accurately contribute basic information like 'there is a sidewalk here' or 'there is a curb ramp here', that is a UI/data model design problem that we can all work together to fix more than something that's wrong with them. The iD editor goes a long way towards making it easy to contribute to OSM without learning all of its inner workings, for example, and brings a lot of new mappers into the fold.

For routing, doing a spatial join on endpoints is extremely common, just not for OSM routers (and this wouldn't even be a spatial join, as a node lookup can be used instead). We've spoken to several people that have worked on or maintain some of the big OSM routing packages and they seemed very receptive to treating pedestrian, particularly accessible, routing as an open problem that they haven't completely solved yet, and don't seem to be laughing! I believe OSRM/Mapbox is actively working on their own solutions right now. All of the routers fall back on routing on streets right now anyways, due to poor sidewalk annotation coverage. If OSM creates a better data model for something that routers don't really use right now anyways, it's not unreasonable to start having the discussion of enhancing routing software to work with the data model.

We're very impressed by (and excited about) that driveways example! It's great to have a concrete example to address that concern, as it's been raised numerous times on the tagging mailing list.

This feedback is excellent and we're taking it very seriously. The discussion of curb ramps in particular is leading us to brainstorm solutions (like the implications of kerb-ramps-as-ways), so thank you for taking the time to point out the limitations of the currently-proposed model and your fantastic routing examples. --Nbolten (talk) 20:16, 5 August 2016 (UTC)

As an image says more than 1000 words, I've created a visualisation of my T-crossing example (I've searched for a place where the "T" is upright:

Visualisation of tagging of objects on "T"-crossings

.

What I meant if user don't get that e.g. a stop-sign shouldn't be on the crossing node itself, it would be more useful for OSM if they just take pictures with mapillary and let the digitalization to us^^.

Feel free to invent new tags for the ramp itself! I would use ramp=yes, incline=*. Please do not use kerb= on the ramp itself. What I meant was when mapping everything as area, the kerb lines can be mapped as line where they are in reality (like a miniature cliff). I've tried this here, but as area mapping is in its infancy, it didn't make much sense now.

What I meant with 'laughing': that if someone tries to convince me that I only have to obey the "stop"-sign tagged on a node that is a at a T-intersection if I'm coming from the "bottom" side of the T… I would laugh at him (or the misplaced stop-sign…). --Species 21:56, 5 August 2016 (UTC)

Aha, I get it now (those pictures are worth at least 2000 words)! I thought of an issue for curb-ramps-as-ways, which is that it reverts to Solution 1 when there is *not* a ramp but there is a raised curb. In that case, I would still want to make a crossing, indicate a curb, and need to connect it to the sidewalk without adding a barrier to the sidewalk itself. This highlights that the 'crossing' (particularly unmarked) is itself is an abstract concept that involves several surfaces features: sidewalk -> curb -> street -> curb -> sidewalk, and we want to somehow indicate that this might be a safe place to cross the road. 'Solution 1' represents that surface feature transition very well, so I can see where it comes from, now. I am tempted to call that whole set of surface features a 'crossing', either with tagging or a relation.

What would you think about using footway=crossing;sidewalk for the initial offshoot in Solution 1? To reuse your example image,

your example

the green sidewalk offshoots would also be tagged with footway=crossing, which, though more complex, makes the purpose very clear. --Nbolten (talk)

I'm happy with your insights ☺. You are right that if there is a raised kerb, the ramp-approach doesn't work. I'm also drawing crossings on places with raised kerbs like marked ones, I just use crossing=unmarked on the highway=crossing node when there is a good opportunity to cross the street on this point.

I wouldn't recommend ";"-separated values on main features. Technically, if you're standing on the "offshoot" between the kerb and the "main" sidewalk line, you're still standing on a footway=sidewalk. The difference between standing on the sidewalk and standing on the zebra-crossing on the street is especially crucial for blind people. I also see your point that the 'offshoot' should be able to be recognised as being part of the crossing for routers ("turn left on the crossing"). What about enhancing the offshoot with crossing=* (and also the crossing way kerb->street->kerb)? Therefore, I would propose the following:

• highway=footway, footway=sidewalk for the 'main' sidewalk

• highway=footway, footway=sidewalk, crossing=* for the 'offshoot'

• barrier=kerb, kerb=* for the node between the 'offshoot' and the crossing on the street

• highway=footway, footway=crossing, crossing=* for the part of the crossing on the street

• highway=crossing, crossing=*, crossing_ref=* for the crossing node between footway and road.

· to be continued (mirrored) to the other side of the road.

Would you like to have a sketch for the proposal?

Sidewalks in jurisdictions without jaywalking laws.

This proposal seems not to take into account typical pedestrian access and highway layouts outside North America.

The specific problem which I have encountered in the UK with separately mapped sidewalks is at this location. Along this road there are no dropped kerbs, and because pedestrians can cross the road at any point in the UK (there are no jaywalking rules) the actual mapping of the sidewalks is technically accurate.

However the following problems occur:

• Pedestrian routing breaks (islands are created, overly long routes are proposed, timings are wrong). Contrary to what is stated on the proposal: OSM data has been used for many years for pedestrian routing for able-bodied people, notably using Garmin GPS devices. Because of a mild disability I currently impose a higher penalty for ways with steps using mkgmap.
• It raises a need to map implicit features (specifically, potential crossings which are not marked by any feature) in order to resolve the issues above, if the data is to be usable by all kinds of pedestrian/wheelchair/mobility scooter users.
• Mappers need to be aware of these extra rules, so as to avoid making the data worse for many routing cases.
• Incomplete mapping (as here) may be worse than none at all. ideally any schema needs to be resilient & work just as well with incomplete data as with a full data set. (Similar examples exist with current sidewalk mapping in Seattle).
• In places where drop kerbs are not yet the norm (such as this part of Cambridge), mapping for less-mobile users may also require mapping of driveways to houses as many of these will have lowered, dropped or rolled kerbs.
• The sidewalks on Roseford Road are separated from the kerbs by narrow grass verges. For blind users this information would also need to be incorporated in some way, not least because of dog fouling. One way would be adding a tag saying whether the kerb was at the edge of the sidewalk or not.

In addition one other factor I've experienced from using the data at this location is that in most cases my GPS actually latches onto the highway proper and not to either of the sidewalks. This is fairly open suburban development with no canyon effects. In major cities with tall building it is likely that some lock to road or map matching algorithm would be needed, but I can't see how it would choose between 3 ways (highway & 2 sidewalks) on a narrowish urban street. SK53 (talk) 15:25, 2 August 2016 (UTC)

Does Species' example address some of these concerns? Also, crossing the road anywhere (jaywalking) is common in the U.S., too, and often not illegal - it depends on the locale. In fact, it's basically required in certain areas (suburbs, places without sidewalks) and the layout of the streets/pedestrian ways can look nearly identical to your example: https://www.mapillary.com/app/?lat=47.6924923&lng=-122.3472098&z=17&focus=photo&pKey=50wq0onWI0tm97JK7Z5s5g.

Your GPS example makes sense. Smartphones' accuraces are on the order of 7+ meters, bluetooth GPS-enhanced phones on the order of 2-5 meters, and even pricey standalone GPS units are often only good to ~1 meter. You're right that it's non-obvious how, standing on a sidewalk, you would distinguish between the road/the two sidewalks. In terms of UI, this may elevate the importance of 'draggable' origin/destination handles, which has relevance in many other cases as well. --Nbolten (talk) 20:28, 5 August 2016 (UTC)

Another example of a country where mapping sidewalks as footways breaks pedestrian routing is Austria. In Austria, it is legal to cross a street at any spot that is either a pedestrian crossing or at least 25 meters apart from the closest pedestrian crossing. So the set of legal crossings is really an area rather than a few lines. There is no reasonable way to map this in OSM, and all the existing places in Austria where sidewalks are mapped as footways that I could find are incorrectly mapped. (They all get this important detail wrong.) This is all the sadder considering that the "proposed feature" (like earlier similar proposals) is marketed as a way to improve routing. Abstracting the sidewalks to a feature of the road (as has been done almost everywhere so far) makes pedestrian routing just work, it will just send you along the road, and it should be obvious to anybody that you don't walk on the driveway. And if you really care about the detailed route, implementing the 25m rule would also be much easier with the abstracted tagging (where the crossings are points on the road segment, so you just need to move 25m along the road in either direction, which is a trivial polygon operation) than with the micromapped "footways". --Kevin Kofler (talk) 21:08, 6 August 2016 (UTC)

To improve routing, noone prevents you from adding additional crossings (crossing=unmarked) where it makes sense to cross the street and is legally allowed. For an example see here. On this point, there is neither a zebra crossing nor a lowered kerb indicating a crossing. But it makes sense to cross here, and people do it regularly - so I added a footway crossing the street, and added the raised kerbs to block wheelchair users. It would look a little weird to to this on every road in the OSM-datase e.g. every few meters (as e.g. Nathanal Lang's batchelor's thesis approach does in its routing DB), but where it makes sense and is actually used in reality, why not? --Species 13:17, 7 August 2016 (UTC)

Requiring mappers to improve routing by adding extra (and non-verifiable) data does not seem like a step forward to me. As others have pointed out one of the problems of having 3 ways for each urban road is that it imposes a burden on mappers. For instance I have not corrected the data I cite as an example because it would require a really careful survey: even though I know the area well. Nor has the original mapper carried on with their work. The fundamental issue is one I state quite clearly in my original post: incomplete or inaccurate data will tend to degrade the utility of OSM for routing by pedestrians of all kinds. In general we should support tagging which offers incremental improvement at the level of individual elements. SK53 (talk) 11:32, 9 August 2016 (UTC)

This would still only mark a discrete set of crossing points when there is actually a continuum of legal crossing points. I am not going to arbitrarily mark crossings in arbitrary distance intervals. The actual practically possible crossing points can also vary several times a day depending on where and how people decide to park their cars. And even where that is not the case, it is also highly impractical to spend hours walking through all the streets to mark good crossing points after a single armchair mapper spent a couple minutes splitting the sidewalk for no good reason. But without going on site, marking crossings at arbitrary distances is the only thing you can do, and the result would be really ugly map spam. Your example where you marked an unmarked crossing to fill a hole in a footway is just an obvious special case, not the norm. --Kevin Kofler (talk) 10:21, 11 August 2016 (UTC)

What if there was a tag that indicates if pedestrian crossing is possible/advisable anywhere along the street? (This would possibly require that road and sidewalk are part of a relationship.) Then a pedestrian router could connect any two points on sidewalks on either side of a street, without any connection existing on the map. --Pbb (talk) 10:26, 15 August 2016 (UTC)

I like that idea! There's already such a tag: crossing=unmarked/no - what about applying it to the way too? We now have to connect the street to the sidewalks in some way... --Species 18:12, 15 August 2016 (UTC)

What about data users that need a relationship between sidewalk and road?

From the perspective of a data user, there is a big unresolved problem with separately mapped sidewalks: They make it very hard (or perhaps impossible) to algorithmically determine whether any given piece of road has sidewalks, and what attributes these sidewalks have. As far as I can see, the authors of this proposal have not yet addressed that issue.

Calculating this relationship is necessary for many use cases, such as...

• pedestrian routing, in places where it's possible/legal to cross the road everywhere, not just at crossings. Lacking that ability can cause less than ideal routing results.
• mentioning the name/type/etc. of the road for pedestrian navigation instructions. This can be worked by copying tags from the highway onto the sidewalks, admittedly.
• generalized rendering. Renderers exaggerate the width of roads in most zoom levels, so the separate sidewalks will be hidden behind the road (or vice versa). Having sidewalk attributes available when rendering a road would allow for better designs, such as indicating the presence of a sidewalk with a coloured casing of the road.

Personally, I work in 3D rendering, and I likewise rely on sidewalk attributes for realistic road rendering. So I hope we can agree that a solution needs to work for all use cases, not just a few, in order to resolve the split in the community. --Tordanik 16:49, 2 August 2016 (UTC)

You are right, creating the relationship between roads and their sidewalks is an open problem. What would be approaches to connect sidewalks to roads:

1. set name=* on all elements

• Easiest, most newbie-friendly. Also stated on footway=*.

• Would lead to a lot of double names on rendering… but… we don't tag for the renderer.

• Would instantly solve the pedestrian routing instructions problem.

• what to do if street has no name?

2. put all elements in a type=street relation

• Prepocessing would be needed for routing instructions.

• doesn't look ugly on current renderers

3. create a Wikidata object and set wikidata=* on all elements

• Prepocessing would be needed for routing instructions.

• Additional step of creating Object in Wikidata needed in 99% of cases... but maybe the Wikidata object is created anyway in the future by someone.

• doesn't look ugly on current renderers

I would be in favour of (1.), but could also live with other approaches. --Species 21:31, 3 August 2016 (UTC)

We've been evaluating this situation as being similar to what is done for buildings, debating between a relation vs. the addr:street tag.

Our conclusions have been similar to yours so far.

1. Using tags:

• pros: Easy to visualize and add (potentially why they're so popular for tagging street associations for buildings). Can be arbitrarily edited to accomodate routing directions.

• cons: Duplicates information (presents a maintainability problem) while making available less information about the associated street.

2. Using relations:

• pros: A relation has a huge advantage in terms of informational content: it doesn't store redundant information, and gives the added benefit of making it easy to ask the question, "how many streets have sidewalks", or, "can I cross the street and expect a sidewalk at this location?". Because not all streets have names, having the option of extracting tags from the associated streets could be useful for routing.

• cons: Relations are fairly 'hidden' elements and as a result, present a serious mapping/maintenance problem: how do we ensure that a relation is made for every sidewalk segment, and that they aren't broken? The answer to those questions might imply changes to the major editors.

I would be very interested in knowing how common implementations of similar relations (like restriction or even associatedStreet) have addressed the problem of mapping them 'on the ground' and for maintenance. --Nbolten (talk) 22:25, 3 August 2016 (UTC)

In France at least, the associatedStreet relations are used in several QA tools used for checking missing addresses. It is used extremely often, and there's a huge density of node addresses in almost all cities and towns, and even in many villages (notably those in sururb areas), because French municipalities are collaborrating into larger local authorities to manage addresses, residences of voters, or panification of various services, including public transports or securty services, whose cost will be shared between municipalities.

It has been demonstrated that just using nodes did not resovle many issues for finding addresses, or that it required a lot of data duplication in these nodes, where a single street relation really facilitated the work needed.

What is the risk with relations ? Possibly the fact that some member ways (composing the same street) will be broken by subdivisinf them. Address nodes themselves extremely are rarely deleted (even accidentally), unless some users are just deleting everything in an area to redraw something else (those bad edits are easily detected by QA tools and reverted, in fact most of these redraws also delete too many other things such as POIs).

In fact it is really easier to resurect what is missing with relations, as they are much easier to assess in terms of quality and completeness. But relations are rarely deleted compeltely and keep micy enough information to resture what is missing by accidental incorrect edits.

We found the same with bus routes that are easier to check and reconnect/consolidate when some editors forget to update them when splitting ways (this does not happen any way with users of iD, as all realtions are correctly updated when splitting ways, but this heppens sometimes when some streets/roads are redrawn (after some local works, suc has building a new roundabout in a crossroad, or some changes with segments with new speed limits).

Only in terms of maintenance, relations are really good helpers: if something is broken, we need much less "guessing" to reconnect things together. In fact this is the same case as boundaries: relations for them are easier to maintain, including after some administrative changes).

However I don't see why associated street relations (for addresses) would not be reused as well for sidewalks (however this would require defining new roles for these sidewalks). But note that most streets are not drawn with separate ways for their sidewalks (only some tags are added to most part of the ways, it's possible to interconnect the two representations on street crosssing nodes, while explicit ways for sidewalks are most useful only around crossroads). — Verdy_p ^(talk) 23:12, 3 August 2016 (UTC)

I don't think any of the possibilities mentioned above solve the core problem:

• 1: Duplicating the name tag, and possibly other required tags, helps with routing instructions, but doesn't help with the other use cases.
• 2: Street relations are not a solution for the general problem. They group everything with the same street name together. With side streets, forking streets and so on, this can be an arbitrarily long and complex networks of streets. What we need is an 1:1 relationship between sidewalks and carriageways.
• 3: The wikidata tags are not a solution either, for the same reason that street relations are not.

I hope it's clear why those don't solve the issue. If not, I can try to create an illustration emphasizing the problem. --Tordanik 10:21, 7 August 2016 (UTC)

Illustrations are always welcome!

Would the information that there is a sidewalk explicitly mapped (left,right or both) help on rendering? (e.g. sidewalk:both=explicit) With the knowledge that there is a sidewalk explicitly drawn, you could either a) render them normally and don't render footway=sidewalk or b) render the road a bit wider on this side (+½ the usual sidewalk width), and render the footway=sidewalk later, so it is painted 'over' the road by the painter's algorithm.

I don't think it makes sense to tag the object IDs of the adjacent sidewalks (e.g. sidewalk:right=way395324096) because ways can be split arbitrary. --Species 13:49, 7 August 2016 (UTC)

sidewalk=separate is quite common for the main street, to indicate that sidewalks have been drawn as separate ways (IIUC) Saintam1 (talk) 19:47, 11 August 2016 (UTC)

Thanks, I have changed my sidewalk:*=explicit tagged ways to the more common scheme "separate" on the objects I mapped. --Species 21:10, 7 October 2016 (UTC)

Software can associate the tagged sidewalks to the nearest (almost) parallel carriageway, checking that there are no other barrier-like features (like buildings, retaining walls, fences etc.) between the sidewalk and the carriageway, as they build their own files/databases. It should not be necessary to explicitly tie them together. And if the sidewalk is between two very closely placed but separate carriageways (so that somebody could claim that associating with the nearest carriageway would fail), it shouldn't really matter: then the sidewalk exists as a connection between those carriageways, and it is accessible from all the connection points it has to the crossings on either carriageway, and would have been drawn separately anyway.

Even for housenumbers, there was a map layer on some of the osm tool sites in the past that nearly always associated house numbers to the correct road when they didn't have the addr:street tag, just the number. Somewhat related, the routing software Traveling salesman had algorithms in place to identify both carriageways (and the transition sections to a single carriageway) of dual carriageway roads, when it created continuous road features spanning the whole length of the road for better routing instructions. That's just to say that it's not just "in theory it should work" but a similar association task has already been demonstrated to be possible with osm data. Alv (talk) 05:00, 12 August 2016 (UTC)

Please include a mechanism to map the absence of a sidewalk

There doesn't seem to be a way to indicate that a sidewalk is not present -- as opposed to being unmapped -- sidewalk=no covers this case.

See Walkable City mapping http://product.itoworld.com/map/132

Tagging with geometry and with attributes are not "different stages".

Usage of sidewalk=* is not a "different stage", it's a different level of verbosity and detail. Indeed, in the United States, probably every populated place is covered by high- (0.6 m/pixel) or very high-resolution (better than 0.6 m/pixel) imagery, where you can easily see separate sidewalks and other details. However, there are places, where medium-resolution (6-15 m/pixel) imagery is a luxury, so you can only roughly place a centerline, representing a roadway. Also, there are roads, mapped by GPS tracks only. In these two cases, it is impossible to use geometry to map smaller features such as sidewalks and especially - kerbs or ramps. In addition to that, we can't force anyone to map at the full level of details if this particular mapper doesn't have a time or simply doesn't want to spend it. So, there must be the way to describe a road at the simplified level of details, which doesn't contradict more detailed method, where separate geometry is used. Briefly speaking, I'd recommend stopping discouraging usage of sidewalk=*, since it still has its specific purpose. Please, keep in mind, that OSM tagging schemes have different levels of abstraction and details. Each one has an own purpose (such as in the case of centerline/centroid mapping and area mapping in general). --BushmanK (talk) 17:37, 26 August 2016 (UTC)

"Advanced user input requirement" is not an argument

Many OSM tagging schemes are really complicated (such as lanes, turn restrictions, turn lanes, 3D buildings), however, anyone can easily see, that even the most complicated schemes are widely used. Which means, that the argument about the requirement of advanced user input is too broad since there are enough mappers capable of using these very complex schemes. So, in simple words, "this is too complicated" is not a valid argument, because it ignores existing situation and refers to the least knowledgeable mappers while OSM mappers are very different. In the same time, while discouraging single conventional sidewalk=* key, which serves well but not ideally for describing situations like roadway without sidewalks, you have proposed the relation for Linked Pedestrian & Motorways, which is still "TBD". It is the well-known fact, that relations are less likely to be used by less experienced mappers than conventional tags. It looks like your reasoning here is self-contradictory in addition to being too broad. --BushmanK (talk) 17:56, 26 August 2016 (UTC)

Crossings as ways are nothing new.

In Proposed_features/sidewalk_schema#Crossings_as_Ways section of this proposal, you have mentioned that current street crossing scheme only involves an intersection of centerlines, representing two streets. This is quite far from the truth, at least, on the worldwide scale (I admit, that it is very often true for the United States). Take a look at Moscow, where relatively newly developed residential areas have wider spaces between the buildings, which allows placing sidewalks at a certain distance from a roadway. The current scheme, as I already have mentioned above, doesn't prohibit mapping sidewalks with own geometry, however, it's not always possible due to imagery availability or additional work it requires. In the United States, majority of urban residential areas can actually be mapped quite precisely with sidewalk=* scheme, since all sidewalks are parallel and adjacent to grid-forming roadways, while nothing prevents anyone from using another method of mapping in cases, where sidewalk=* is not enough. For me, it seems like this proposal is based on a certain lack of knowledge about the diversity of mapping practices and only minor improvements can be achieved if it would be approved (not earlier than obviously redundant parts of it will be eliminated). --BushmanK (talk) 18:20, 26 August 2016 (UTC)

The problem is, that "can actually be mapped quite precisely with sidewalk=*" does not apply, if you want to map in detail for wheelchair users. A wheelchair user can only cross on a lowered kerb, and mapping these (if they differ on both sides) is only possible with a separate way at the moment.

If you can map all your ways precisely with sidewalk=*, then fine. This proposal is intended for the cases where you can't. --Species 18:29, 7 October 2016 (UTC)

In this section, I'm talking exactly about the fact, that separate ways can be used and are widely used (in Europe), so there is nothing to propose regarding of this aspect. Therefore, your counter-argument, targeted to secondary statement, is irrelevant to the main topic of this question. --BushmanK (talk) 05:14, 7 November 2016 (UTC)

Hi BushmanK, thanks for the feedback. I'm not totally sure that I understand everything you're saying, but I'll do my best to answer it. First, we will absolutely rework the introduction of the document to be clearer, and to separate what is a totally new tag vs. what is a new recommendation for using existing tags. As an example, it is currently recommended elsewhere on the wiki to tag sidewalks as a feature of roads, i.e. the road itself gets a sidewalk=left/right/both/yes/no tag. We did not invent the use of sidewalk=* on highway=footway, but a core part of this proposal it pushing for its adoption, as it is a much better description of the actual pedestrian path, and it is typically separated by a physical barrier (such as a hard curb) that prevents the pedestrian equivalent of 'lane changing', including wheelchair users. The wiki will go into more detail on that soon, this is just an example where we should clarify what is a proposed tag vs. what is a standardization suggestion.

If I understand correctly, you're suggesting that sidewalks are commonly tagged as separate footways in Europe. I agree that some cities have adopted this convention, but to my knowledge it is actually the exception, not the rule, and in fact, the proposal to map sidewalks as footways have received the greatest pushback from European OSMers, so I think there's a bit more diversity there than you might expect!

If it helps clear anything up, the purpose of this proposal is not just to say, "we should map sidewalks separately because they will have more accurate shapes". That is a benefit, but it is secondary to describing the pedestrian transportation network - where are pedestrian ways, where are they physically separated vs. connected, and what features does one encounter along them? It is not possible to ask basic questions about the pedestrian infrastructure via OSM right now due to the way sidewalks (and other pedestrian features) are mapped, due to the fact that you cannot effectively derive an annotated transportation network from them, which is something you absolutely can do for cars. The best example is for a manual wheelchair user: the vast majority of paths you can provide a manual wheelchair user will include some form of impassible barrier, such as a hard curb, bad surface, a missing crossing location, or steepness. Only that last feature (steepness) can be adequately represented with tags on streets.

You could probably find a way to almost get there with linearly-referenced data on street lines, but that would lead to deeply-nested and confusing taggings ("there's a surface type change on the sidewalk on the left side of the street" --> applying something like "sidewalk:left:surface=concrete". But if the street itself is split along that area (because, for example, there are lane changes), it must be applied in 3 separate ways, rather than one - and actually, likely 5, as the sidewalk surface probably doesn't change at the same place as the lanes. If we use other recommended schemas that place even more data on street centerlines, such as parking, this problem is massively exacerbated: the tags are even more redundantly duplicated, hard to locate as a mapper and as a map user, and use those deeply-nested tagging schemas.

Mapping separate ways elevates the visibility of pedestrian infrastructure and provides a natural place to describe pedestrian features, and is a natural complement to the street network - both use the same basic concepts for routing, so routing engines can more easily provide accessible routes on separate pedestrian ways.

I hope this addresses what you were saying - again, thanks for the feedback. --Nbolten (talk) 22:51, 14 May 2017 (UTC)

The fact that we decided on tags to represent lanes despite very similar arguments, e.g. the need to split ways when the attributes of one of the lanes change, makes me confident that we can work with tag-based sidewalks for situations where there is no physical separation. Most of the considerations you mentioned ("natural place", "elevate the visibility", "confusing") don't strike me as hard requirements, but merely preferences. Meanwhile, you still haven't done anything about the fact that your proposed tagging breaks other use cases such as my 3D rendering example mentioned above. And I mean "breaks" as in "will not be possible anymore", not just requiring some minor updates. I hope you understand why this makes me a little worried about the possibility of your proposal gaining traction. --Tordanik 14:05, 21 May 2017 (UTC)

Regarding lanes, there are two primary issues. The first is that sidewalks are, semantically, very different from lanes. Lanes add information about where cars can travel in already-existing road lines, whereas sidewalks are a separate, dedicated pedestrian way that is usually (but not always) curb-separated. For sidewalks, the traffic is different, the rules of travel are different, the mappable factors impacting travel are different, they connect to different infrastructure, and the routing topology is not maintained without tortuous guess-work (due to the awkwardness of crossings). One of the outcomes is that the pedestrian-mode routers you commonly see out there are just a slowed-down version of street routing with pedestrian ways added on top. The second issue with adopting a lanes-like schema is that such a schema is rapidly self-limiting, the more classes of them you add to a given way. If you only need to split up a way every time the lane situation changes, you need to split one way and edit the resulting 2-3 ways. If you want to add sidewalk information that varies just as much, you'll need to edit even more ways: not 2-3 - more likely 4-6, because they will not coincide with lane change positions. Imagine adding the proposed parking schema to this, which is also to split + tag road ways, and you can imagine the difficulty of maintenance. If the only information you wanted to encode about sidewalks was inventory (yes/no/left/right/both), that would be fine, because it would only vary when the sidewalk ended early. Our goal is to facilitate adding the information that pedestrians, and particularly people with greater accessibility requirements, need to know whether they can safely navigate their trip, and the schema needs to be planned to accommodate that.

I am also confident that we could work out a lanes-like schema that describes the core features we need to map for accessibility. But that's a necessary, not sufficient, reason to adopt a tagging schema, because you could also technically describe all buildings as street metadata. The question of how maintainable and approachable the mapping process is is just as important, because it dictates whether the tags will actually be used, and it should be considered a hard requirement. I invite you to try out both sides of the road-centric schema approach: tagging and routing. Try adding all of the features listed on the main page to a street line, then try to use it to do a constrained route using any routing engine (require curb ramps at crossings, for example). You'll need to preprocess all of the pedestrian ways that intersect streets to figure out whether they meet on the right or the left, and create an expanded edge graph for each side, and connect at those crossings. It's theoretically doable (some people are thinking about doing it), but it's not natural or fun, and requires a lot of guesswork. It also relies on a high degree of accuracy and detail in tagging, a problem that's exacerbated by a non-obvious tagging schema.

Unfortunately, I'm having trouble evaluating the suggested schema breaking 3D rendering - any chance you could provide a link or image? I personally think it's important to be able to ask the question, 'does this street have a sidewalk?' and 'what street does this sidewalk go along', if losing that is the primary objection. For me, only question is what tagging schema to use, not whether we should tag it. I think it would benefit from more discussion. Ideas proposed have been relations (efficient and descriptive but hidden, so harder to maintain), tags on streets (sidewalk:left=id - a bad idea for many reasons), and tags on sidewalks (associated_street=name). It is essentially the same problem as 'associated_street' for buildings, where both relations and tags on buildings have been used with success. However, I would like to suggest that one can figure this out spatially as well, it just raises the technical barrier for data consumers interested in inventory questions, versus data consumers interesting in connected pedestrian infrastructure. We frequently derive sidewalk=left/right from street + sidewalk lines in our projects in order to redraw better sidewalk line estimates. In fact, inferring sidewalk=left/right is probably necessary for getting an accurate analysis, because there will always be sidewalks tagged as footways and it's easy to miss adding sidewalk=* to the street. --Nbolten (talk) 15:53, 21 May 2017 (UTC)

How to tag the main road for pedestrians?

I’m not sure how this works in other countries, but over here, if a road has a sidewalk, pedestrians must stay on the sidewalk except to cross the road. But if the road isn’t tagged with foot=*, it is assumed that pedestrians are allowed on it, so route planners happily guide pedestrians to it even if there is a separately mapped sidewalk: MapQuest example. Should the road be tagged with foot=no? Perhaps foot=use_sidepath like for cycleways? Izumichanto (talk) 12:33, 6 October 2016 (UTC)

I wouldn't tag it foot=no if it isn't explicitly forbidden by a sign. Especially for wheelchair users, you quite often have to use 1-10m of the road to get to the next possible lowered kerb (a driveway e.g, if it is not lowered on the crossing itself). It should be left to the routers to penalize e.g. highway=primary over footway=sidewalk (see example routing profile here). --Species 18:35, 7 October 2016 (UTC)

That’s fine for highway=primary, but sidewalks as ways can be added to other kinds of roads too. I guess the same argument applies there too, and indeed I see the code you linked penalizes various kinds of roads to various extents. The argument about wheelchair users is good, too. Certainly, routers should do that, and clearly, the routers I tried need to be improved in that regard.

Heh, I’ve just discovered that I can search routes on www.openstreetmap.org. I feel bad for not noticing this before, although I’ve rarely used OSM before now. Indeed, the walking routers here handle the example I originally posted correctly, using the sidewalks unless one endpoint is directly on the roadway. --Izumichanto (talk) 23:17, 7 October 2016 (UTC)

Still, in jurisdictions where you aren’t allowed to cross the road if there’s a pedestrian crossing nearby, I can imagine that a router that merely penalizes roadways relative to sidewalks may prefer to lead the user onto the roadway to cross a road rather than guide them along the sidewalks to the nearest proper crossing if this crossing is a little distance away; or it may prefer the roadway if the sidewalk is a bit off the side of the road (e. g. separated from the roadway by a strip of grass) and/or less straight than the roadway.

Worse yet, this may lead a router to think it is possible to cross a busy road where it is both illegal and dangerous: imagine a dual carriageway intersecting another road or having a U-turn link. In Latvia, pedestrians are absolutely forbidden from crossing dual carriageways, as well as all bidirectional roads that have at least four lanes, except at designated pedestrian crossings. If a router finds any way of getting the user onto the roadway (e. g. from another crossing elsewhere), then it will happily lead them along the roadway onto this intersection and onto the other road or the opposite-direction carriageway. If there is a pedestrian crossing at the same intersection, this might be tolerable; but if not (as in the linked examples), this is bad! In fact, the same also happens when a road like this branches into multiple roads. Pedestrians walk along the right/left edge of the road, so they can’t get to any of the branches other than the rightmost/leftmost one (as they can’t cross!), but if the roads don’t have foot=no, a router won’t know this.

From another perspective, not tagging the roadway with foot=* simply fails to capture the legal restrictions that pedestrians are not allowed on the roadway. The road may not have a dedicated “no pedestrians” sign, but they still aren’t allowed on! In fact, I suppose technically, wheelchair users aren’t allowed either, but wheelchair routing is especially hard to get right. On small, local roads, it’s very useful to route around kerbs even if that means using several metres of the roadway. On big, busy roads entering the roadway is dangerous and should be avoided. I don’t know how to solve this. …Oh, actually the law here states that pedestrians are allowed on the roadway “if the sidewalk is unusable”. Being unable to get across kerbs in a wheelchair might qualify, resolving at least the legal issue. Admittedly, this doesn’t make routing any easier.

As a matter of fact, I’ve noticed that a large amount of roads around where I live actually do have foot=no. Some cases have road branching where pedestrian crossing is forbidden, and some cases have a separately-mapped sidewalk. This tagging doesn’t seem to be comprehensive though, and it would be nice to have an official recommendation about this.

For what it’s worth, if I understand correctly the discussion that accompanied bicycle=use_sidepath when it was introduced, the situation with bicycles and cycleways is very similar, and the only reason bicycle=no is not used when a dedicated cycleway is present is because the legal semantics of that case differ ever so slightly from a “no bicycles” prohibition sign. And in any case, the roadway is marked with some tag to show bicycles can’t use it; the only real question was which tag. So I think we need either to use foot=no or to introduce foot=use_sidepath if the semantic difference is deemed important here. --Izumichanto (talk) 22:50, 7 October 2016 (UTC)