Talk:Tag:footway=sidewalk

Add note to keep them independant of all other stuff

I don't think that the footway=sidewalk mapped as seperate line, is a good idea at all. But it may be useful in some cases. However we should add a note, that all none footway=sidewalk ways should in no case connect only to the footway=sidewalk way, but to the main street. Otherwise routing for cyclists will get seriously flawed. Take a "real" highway=footway that joins a road with a footway=sidewalk and the real higwhay=footway being only connected to the sidewalk. Why? For a cyclemap you don't want the clutter of sidewalks included. Neither do you want to blow up your map by routing cyclists along a sidewalk (while on many footways there is often good reason to (sometimes illegaly) use them for cycling, no cyclists (except if there is a traffic jam) would ever use a sidewalk instead of a road. Therefore most autorouting for cyclists, will take real footways with low priority into the autorouting (cyclists can still dismount) - but will not route over a sidewalk (as by definition the sidewalk is alongside a road or seperate cycleway, which in 99.9% of cases is better for cycling). So if someone who does not understand this, joins a real footway to a sidewalk footway without joining the real footway to the road, the map gets unusable for cycling.--Extremecarver 08:59, 26 April 2011 (BST)

The answer to this is: connect cyclable ways to the main road, not to the sidewalk, if the sidewalk is not suitable/allowed for cycling. It's not to delete compatibility statements :) --Hanska 16:06, 4 May 2011 (BST)

As long as their is no note, people do stuff wrong. And I already had to delete such rubbish where people connected footways to sidewalks. Thats the big problem if it werent called highway, situation would be much clearer. And it is clerly not compatible to cycleway=* - if it were footway:left=sidewalk it would be compatible. This proposal has nothing in common with cycleway tagging, and just causes huge problems if really used. If you think it is compatible, than write on the talk page of tag=cycleway, then everyone would have told you that it has nothing to dowith it, and cannot be considered compatible.Extremecarver 22:58, 4 May 2011 (BST)

You added a note, so that's great. Still, if a sidewalk has a cycleway lane on it, I can't see how cycleway=lane can't be used together with the sidewalk tagging. That's the meaning of "is compatible". Sometimes cycleways are on the road, sometimes are on the sidewalks. --Hanska 07:37, 5 May 2011 (BST)

Well if you mean (if used correctly) it will not obstruct autorouting, you are right. But if you consider compatible, as following a scheme, or building up on a scheme, then it clearly is not compatible. Also if you consider rendering. Mapping everything onto a middle lane, and then assigning the relative position to the middle, is what most professional GIS systems do. That's the only way to properly work with displacement on different zoom levels. Mapping things separately, will obstruct this. So if you enter cycleway:right=track & draw a separate sidewalk, there is no congruence at all in the approach. Hence you cannot consider it as compatible.--Extremecarver 09:51, 5 May 2011 (BST)

I'd rather trust those who are building country wide commercial pedestrian/cyclist routing, who've concluded that the "as properties on the middle line" data, that the national digiroad project had stored, just doesn't describe sidewalks with sufficient detail. Traditional GIS users are/were educated professionals, they might have had the tools to support the user assigning the sidewalk details as properties on the middle lane; they've had to accept the learning curve and mental workload in favor of computationally easier map scaling. Most osm users are GIS-novices and working directly with the separate geometries is more in line with the mental model of "map data", especially when josm/potlatch/merkaartor don't have tools to assist in assigning the properties (even if there's the prototype "lanetool" plugin). When was the last time you looked at the city planning maps? I'd find it impossible to describe all that detail with road centerlines only. As to what should connect where: every legal and possible connection, with, say, keeping emergency vehicles also in mind. Alv 08:00, 6 May 2011 (BST)

To alv: That data is used for autorouting for emergency services (police, firefighters, ambulances,...) and also sold to commercial map providers. Where is a link describing digiroad project shortcomings? I was one of the first to ever do autorouting for cyclists/hikers based on OSM data (well using Garmin GPS/Mapsource) - you can find the beginnings in 2008 on the mtb_map page here in the wiki. Also now with openmtbmap and velomap there are over 3000 users daily downloading my maps for Garmin GPS. Middle road line is definitely easier to parse than separate roads and relations. Last time I saw the maps and their data structure was about 8 month ago. But sure, I do say without good editors, this is more difficult to understand, but ultimately yields the better and more correct results (though it is more abstract of course).--Extremecarver 10:20, 6 May 2011 (BST)

It was few years back when I read it, so I'll need to do some digging for the document with the conclusion that it's necessary. Found some links already stating they're already set to store separate geometries for all "light traffic" ways (as the combined foot/cycleways are called here), including sidewalks, and bound to be included in Digiroad II, once it is ready: there's a publication (in Finnish) at [1] (ISBN 978-952-221-150-7), and accompanying slides [2]. Alv 11:50, 6 May 2011 (BST) And oh, in a web router for cyclists and pedestrians (for the capital region) they are using, and have been for quite some time already, separate geometries for combined cycleway/sidewalks; available also in English. Alv 12:07, 6 May 2011 (BST)

Well but there is one serious flaw. It's the government and they don't want bicycles on the street (or the big car clubs) - so what they propose is not good for avid cyclists. I do everything to be on the road, or on cycleway=lane, if there is a separate mapping it does not reflect the possibilities of quickly changing from cycletrack to road and back, which is used in reality by many cyclists. OSM should enable cyclists to use the quickest route, not the route that the bicycle hating car communities (cycles slow down cars) want you to take. As far as I understand the above, they simply did not include cylceway/footways into digiroad I - hence that's why its not inside. Then they have to care for political wishes, and put cyclists away from the street.--Extremecarver 12:37, 6 May 2011 (BST)

We should map reality, not approssimate to what "professional GIS systems do". If I were the one involved with cycleway=*, I would have specified that if it was separated by a barrier, it should've been mapped as a separate way. Using *:right/left=* scales poorly, and I've thought a lot about that when proposing sidewalks. And no, please don't take rendering into discussion, we don't map for the renderer. Can we finally agree that cycleway=* is partially compatible then? If you use cycleway:right/left:* it's not, if you use cycleway=*, it is. That should make both of us happy :) --Hanska 12:05, 5 May 2011 (BST)

Reality is definitely not helped, if you map separately, as when we start adding all lanes (in map reality a sidewalk is just a special lane, no matter how it's separated) separately we don't reach a better reality. *:right/left=* scales perfectly, because there are no displacement problems. And while we should not map for a renderer, we should map in such a way that it can be correctly rendered, which is not the case when all lanes get mapped separately (except if all ways are drawn absolutely parallel AND there is a width of each way indicated AND they are all joined in one relation - this is no easier to achieve, than a complex tagging structure alongside a middle line, with the disadvantage that we don't know the middle of the road - hence we would need another line to declare the middle of the road, so renderers are able to render the correct placement of the street in lower resolutions). As used here footway=sidewalk is fully compatible to higwhay=cycleway used for cycleways alongside roads (which some people prefer over cycleway=*) -- But for that case usually highway=path is the better option. So what you propose in reality is to map the road by lanes (that is if the same system is used for lanes as here indicated for sidewalks), then map cycleways separately, and then map sidewalks separtely. The footway=sidewalk is in no way as compatible to cycleway=* (no matter if left/right is used or not) to say it is compatible.

If lanes are physically separated (no, a continuous white line is not "physical separation"), then yes, I'm saying we should separately map them. I don't believe we can find a solution here, since you're not trying to find a compromise. --Hanska 17:07, 5 May 2011 (BST)

There is only a fundamental unsolvable problem, if lanes go a completly different path. A kerb or a greenstrip is nothing, which couldn't be described by a middle lines based model. Also for lanes you might want to have different rules (e.g. hgv only on right lane, right lane forward direction width 3m, left lane forward direction width 2m, right lane backward direction width 2.40m or traffic lights compliance, and many more). You don't sea that also for a single lane, non physically separated, there can be complex rules, no more complex than for a sidewalk besides. This can be solved by drawing separate lanes all the way (a), or mapping everything onto the middle line (b). This page is about (b), the cycleway=* key is about (a), so one cannot say there are compatible, they are completly different approaches to achieve a map. And yes, I'm not searching for faulty compromise. Why should I try to find a compromise going "it is compatible"? That line is like saying landuse=forest is compatible to natural=wood. It does have some things in common, but can clearly interfere if used wrongly. Instead it is much more important to explain the people, how to use each key so that they don't interfere. And for footway=* the most important thing to tell is that all other highways (also highway=footway) need to be connected to the main street, or if not (because that will happen, as people don't see that while a joining pedestrian will use the sidewalk.

One example I corrected was a footway=sidewalk besides a large street separated from the street by a standard guardrail, so cyclist could not directly hop over onto the street. Cycling was forbidden on both the footway joining the sidewalk, as well as the sidewalk itself. However many cyclists would use the footway and then the sidewalk to get onto the street. The footway was tagged highway=footway, tracktype=1, bicycle=no, the sidewalk as highway=footway, footway=sidewalk, bicycle=no. While for any routing program for cyclists, you will take such a highway=footway into calculation at very low importance, you would not do so for a footway=sidewalk, because there must be some streets besides that is better for cycling or a separate cycleway (which in this case only existed as cyclway=lane, tagged onto the main highway). Looking at this situation, it would be reasonable, to say mapping is correct. But the problem is that in this case, it should be indicated that it is useful for cylists to push the bike. A clever renderer for cyclists, would therefore consider a footway=sidewal & bicycle=dismount, while dropping a footway=sidewalk (without bicycle, or with bicycle=no). Including all footway=sidewalk into the map as routable lines (although at very low priority) would not be practical, once everywhere sidewalks are mapped separately, as this would (at least in Europe) probably double the map size, as roughly guessed 50% of all roads have sidewalks on both side. Also for rendering, with the chance of a very nearby separately mapped highway=cycleway, displacemnt would make the map look bad (note we can safely assume a max of 10% of all footway=sidewalk will be joined using Associated Street relation to the main highway, as people find it clutchy to use such relations. (like on a map made for cardriving, you would neither consider any cycleway=* or footway=sidewalk to be rendered).

I hope you understand that point, and notice that it is important to explain users, to be careful with separately mapped footway=sidewalk (and not treat them like normal non sidewalk highway=footway.) Due to theese problems that are not easy to understand their implications, not using highway=footway as primary key, would have been less confusing (and people don't do it for pathes and cycleways mapped separately either). Still of course it is better to indicate that the footway is a sidewalk, and not go the same route as mapping it separately without telling it belongs to a street (and then even worse often adding bicycle=no to the main higwhay, even though usage is forbidden only implicit, not explicit. --Extremecarver 18:00, 5 May 2011 (BST)

Do not add foot=no to the underlying road

Foot=no means that walking on the street is forbidden. There is no country where if a sidewalk is present, walking on the road is actually forbidden. There is only a usage obligation to walk on the sideway. That is not the same as if walking on the street itself were forbidden--Extremecarver 08:59, 26 April 2011 (BST)

It is in Italy (you can get fined). And it's only a suggestion, it should be used at mapper's discretion :). Also, it's indicated nowhere in this page. --Hanska 09:55, 26 April 2011 (BST)

Relation-related revert

I've reverted this edit because it promoted relations from "optional" to required without providing a reason for doing so. --Tordanik 20:56, 21 June 2011 (BST)

Does this imply path=sidewalk and cycleway=sidewalk?

Should this be extended to representing shared-use highway=paths and dedicated highway=cycleways running parallel to the carriageway in the space you'd expect the footway to be? footway=crossing mentions it for bikes and cycleways at least. --achadwick 12:51, 22 June 2011 (BST)

I've wondered the same thing, and I think it should be. The only tricky thing is naming, since we have "walk" in sidewalk. This comes down to the definition of sidewalk, which I think another topic below is addressing, so see my response there. -- Joshdoe 16:54, 23 June 2011 (BST)

If it's any help, we're using adjacent=yes in Oxford to represent dedecated-ish cycleways that run alongside the larger roads (as it happens, pedestrians use them too). However, this "foo=sidewalk" thing got voted in, for all that's worth; and it's in use, which is a more valuable thing. Maybe "sidewalk" is enough of a thing in itself to be independent of walking; I dunno, I am not an American English speaker. It sounds odd to me for the reasons you mention. --achadwick 10:33, 24 June 2011 (BST)

Based on my definition in the When to tag: what makes a parallel way a sidewalk? topic, both shared-/multi-use highway=path and highway=cycleway can fall into that definition. Even dedicated cycleways could be considered sidecycleways, though that is a horrible term. Perhaps it would have been better to use footway=sidepath, path=sidepath, and cycleway=sidepath, or some other common term, I'm not sure. -- Joshdoe 17:07, 23 June 2011 (BST)

There may be a case for path=adjacent or cycleway=adjacent - see comment above. --achadwick 10:33, 24 June 2011 (BST)

When to tag: what makes a parallel way a sidewalk?

Resolved: Any parallel path which you can see the main street from, and step onto it from. Mustn't be too barriered off from it. --achadwick 17:06, 27 June 2011 (BST)

What makes a parallel way represented like this a sidewalk? I assume footway=sidewalk is for ways that have just a kerb separating them from their main carriageway, and that anything with wider separation - like a bit of grass or a barrier - is not a footway=sidewalk. Does that seem reasonable? The difference is that you can step from one to the other more easily in the is-a-sidewalk case in order to cross. --achadwick 12:59, 22 June 2011 (BST)

A sidewalk?

Hard to define, but as long as you can easily cross most of the time (no continuous barriers), I would still tend to consider it a sidewalk. A bit of grass or the occasional tree doesn't necessarily make something a not-sidewalk. For example, I would consider the image on the right a sidewalk. --Tordanik 15:32, 22 June 2011 (BST)

At the end of the day, it's whatever you call a sidewalk (or a pavement, or a footway). Maybe a rough rule of thumb to state: "At a bare minimum, there should be sort of physical separation no matter how minimal. The separation shouldn't be too big laterally or vertically to prevent you from seeing the road or stepping out onto it easily, and the thing should run in parallel with the main road most of the time". There are barriers like runs of anti-crossing fences (still a sidewalk, but map the fence too) or big earthwork banks (not a sidewalk if you can't see over them) which may cause problems, but mostly you can leave it to common sense. --achadwick 10:00, 23 June 2011 (BST)

I would say a functional definition of a sidewalk is that a sidewalk provides an allowable/alternate/safe mode of transportation for pedestrians/cyclists separate from the main roadway. From this comes the requirement that the sidewalk way should roughly run parallel to the road, although the separation can vary from being right next to the shoulder/kerb to being separated by a buffer (grass/plants), barrier (guard rail, fence, retaining wall), etc. However it is expected that at regular intervals (at least at road intersections) the sidewalk will connect back to the road to allow crossing to the other side of the road. So I'd definitely say that image shows a sidewalk. -- Joshdoe 17:01, 23 June 2011 (BST)

I'd add that from (what I call) a sidewalk one can at least see and sense what's happening on the main carriageway. It's actually a functional enough description of what makes the pavement part of the street's life - Jane Jacobs would doubtless agree. But we're in agreement on having a high degree of connectedness and running parallel. Good stuff. --achadwick 17:06, 27 June 2011 (BST)

Compatibility with the existing scheme (sidewalk=* on road)

Is this new scheme compatible with the existing sidewalk=*? I would argue that it is. The existing scheme just states whether a road has a sidewalk or not, but it doesn't specify precisely where it is. This new scheme can be used in addition to sidewalk=yes,both,left,right on the main carriageway to detail where the sidewalk is. Obviously there's the possibility of creating contradictions (sidewalk=no), so don't do that. --achadwick 09:51, 23 June 2011 (BST)

I've wondered the same, especially after seeing a preview version of an ITO Map which shows footway=sidewalk and sidewalk=* ways. It showed green for sidewalk=yes/both/left/right, and red for sidewalk=no, grey for roads lacking a sidewalk=* tag, and purple for footway=sidewalk ways. I guess we have to ask:

1. Is there value to add sidewalk=* tags when footway=sidewalk ways are already present? It may, because it helps in giving an indication how many roads have had sidewalks accounted for, whichever scheme is used (think coverage map).
2. When someone invests the (laborious) time to add footway=sidewalk ways next to roads that are already marked with sidewalk=* tags, should those tags be kept or removed? Same question/answer as #1 really.
3. If both schemes are applied in a given area, how are routers to handle this? It is likely that routers would need to impose a slight bonus on the footway=sidewalk ways in order to route over them versus the road, since the sidewalk may be slightly wavy while the road is straight.

-- Joshdoe 17:20, 23 June 2011 (BST)

I suggest that it is desirable to always have a sidewalk tag on the road itself even if there are sideways described using the separate highway=footway/footway=sidewalk tags. I suggest that for roads where sidewalks are separately represented then the road should be tagged with sidewalk=no to avoid confusion. Possibly an additional tags which expresses the concept 'there are sidewalks but they are represented as separate ways' would be better that using sidewalk=no. PeterIto 10:06, 26 June 2011 (BST)

How does this avoid confusion? An application is either able to properly use separately mapped sidewalks - then it can do so just as well when there is a sidewalk=left/right/both - or it relies exclusively on sidewalk=* tags, in which case it will get completely wrong information from a sidewalk=no. In my opinion, the sidewalk=* and highway=sidewalk tags express slightly different information ("this has a sidewalk" vs. "this is a sidewalk"), and I don't see a reason against using the normal sidewalk=left/right/both tag when the sidewalk itself is mapped. --Tordanik 15:59, 26 June 2011 (BST)

I have been doing some trial mapping in my home town this morning and I have found it easier to make a decide for each road as to whether I consider that there is a footway intimately connected to the highway in which case it gets a 'sidewalk=both/left/right' tag as appropriate or if there is a looser connection between the sidewalk and the highway in which case the highway gets a 'sidewalk=no' tag and I create some new paths to the side with 'highway=footway' and 'footway=sidewalk' tags. This seems to be easy to describe to people on the wiki and rendering is also very straightforward. Relations are then used to associate footways with roads, but the relation is only for route descriptions, not for rendering. Can I suggest that we continue to explore and discus this issue for a few days keeping an open mind. I have produced a new rendering style to allow us to see what things might work like. See the next section for details. PeterIto 11:18, 27 June 2011 (BST)

Perhaps we could resolve this impasse by defining a value like sidewalk=separate on the main way to indicate that footways alongside a road are both present and represented by separate objects? The concept is extensible to things like cycleway=separate or even lanes=separate too at some point - but those are different discussions. --achadwick 16:55, 27 June 2011 (BST)

Let's not consider this an 'impasse', I see it more as an exploration of a tricky issue before coming to a conclusion. separate is good unless one is coding a sidewalk on one side as a separate way and on the other as associated with the road. I certainly prefer it to using the standard sidewalk tagging though. Possibly 'sidewalk:left=separate for those situations'? Thinking about it sidewalk:left and sidewalk:right are more powerful than sidewalk=left/right as it leaves the value free to take any value. PeterIto 20:11, 27 June 2011 (BST)

I have just updated ITO Map 'Sidewalks and footways' and 'Legible cities' layers to accommodate the 'sidewalk=separate' tag. I have also taken the liberty to introduce it in a small area of downtown Toronto where it's use seems to be appropriate. I am continuing to tag the centre of my home town of Ipswich using this approach. PeterIto 11:08, 30 June 2011 (BST)

I expect that sidewalk=separate will be misunderstood as "sidewalk is physically separate in the real world" (e.g. separated by a strip of grass from the main road). A less confusing value would be sidewalk=mapped_separately. Still, I'm not sure whether I like the idea at all, because a tag like that wouldn't tell you anything about reality, only about a mapper's data modelling preferences. --Tordanik 16:27, 30 June 2011 (BST)

Confusion will be reduced by clear documentation and it seems that tagging is better than no tagging which can also create confusion or relying on relations which is too difficult for beginners. sidewalk=separate is shorter than mapped_separately which is a bonus. PeterIto 23:17, 1 July 2011 (BST)

Confusion cannot be sufficiently reduced by documentation: many won't read it, others won't feel bound by anything documented on the wiki as a matter of principle, and ultimately someone will document the "alternative opinion" too, and we will argue for years about the "true" meaning of sidewalk=separate. The OSM community has a ridiculously bad record when it comes to disagreement between written documentation and intuitive understanding of tags. Just look at highway=path, or landuse=farm, or smoothness=*, or any similar example of tagging controversies.

A tag where people simply don't know what it means can be acceptable, they will have to look it up. But problems are inevitable when people think they know what a tag means, but their intuitive assumption is wrong - and I suspect that exactly this would happen with sidewalk=separate. If making the tag longer reduces confusion, I think that we should almost always choose do so. The length of a tag is almost irrelevant, since modern editors support presets and autocompletion. --Tordanik 20:31, 2 July 2011 (BST)

ITO Map sidewalks and footways mapping

Do check out the new sidewalks and footways mapping on ITO Map which is now published and available to all. The key provides an explanation of the colours used. Washington and Toronto are good places to see how the tags are being used.PeterIto 09:56, 26 June 2011 (BST)

I have now created a new 'legible city' layer for ITO Map. It is available for use but is currently unlisted and doesn't appear in the layers list so you will need to bookmark it. The roadways (carriageways) for roads with sidewalk tags are shown in black. Those without are a light red colour. Sidewalks are shown in blue as are paths/cycleways/footways. Note that currently the rendering treats sidewalk=left/right as if they were 'both'. This will be fixed soon. The colours follow the 'Legible London' styling which was created for Transport for London and which they are keen to promote. Here are some good views - central Washington and this view of part of Totonto. The Washington view curently highlights some missing tagging. The Toronto view shows some 'double sidewalk' rendering where there is both a sidewalk=both tag on the highway and a separate sidewalk 'footway'. See above section for discussion. PeterIto 11:29, 27 June 2011 (BST)

Footway=both/left/right/no

It has just come to my notice that some people in the UK and in German have been using footway=both/left/right for the role proposed by sidewalk=*. Examples in Nottinghamshire and in Norwich and also in German, for example here and here. This tagging was proposed here. For now I have adjusted the ITO Map views to accommodate this coding although I realise that this is overloading the use of the footway tag. PeterIto 23:31, 1 July 2011 (BST)

Don't add a highway-tag

While I agree that for complex situations it is helpful to have dedicated geometry in OSM, I fail to understand why this should be tagged with highway=*. Usually a distinct highway should be drawn only in the case of a separated carriageway. The suggested tagging is IMHO "tagging for the renderer". For tagging sidewalks it would be sufficent to tag them with footway=sidewalk without the highway-tag. In analogy to this tagging we would optionally be mapping an ordinary street as dual carriageway and tag each with highway=residential, oneway=yes, residential=lane. New tags should be constructed in a way that doesn't change the meaning of existing tags, but only adds detail to the existing meaning in the case of a suggested tag-combination. In the case of sidewalks dataconsumers that don't evaluate the footway=sidewalk tag will get those highway=footway, which are tagged like this, wrong. --Dieterdreist 17:42, 10 April 2012 (BST)

If the footway is not an extra way, it could be called street. So it is an extra (foot) way, but a special one beside the street. So adding footway=sidewalk is not tagging for the renderer, as this footway exists. --Fabi2 21:51, 12 April 2012 (BST)

I think you misunderstood him. Adding highway=footway is tagging for the renderer (footway=sidewalk is enough), and I agree with him. --Jgpacker (talk) 13:49, 2 October 2014 (UTC)

1000+ Please say that louder/bolder!!! Still 99.9% of all renderer and routers don't support footway=sidewalk and therefore highway=footway is needed. This means 99.9% of all renderer and routers just see a highway=footway and nothing else. That's wrong and crap as well as these are no highway=footway !!!

Secondly what if a cycleway=track is 'integrated' into this sidewalk. This is a very usually case! The proper term is cycleway=sidewalk (not lane, not track). So it is not kind of footway at all!

We need to get rid of this highway=footway ASAP!!!

--EinKonstanzer (talk) 16:16, 30 March 2015 (UTC)

Necessary?

If parts of a street are drawn as separate lines, it is an accepted rule to create a relation of street type comprising all these elements.

If a highway=footway is a member of the same relation as the neighbouring carriageway, it is clearly defined as a sidewalk, even without footway=sidewalk.

What is whose benefit, if that tag is added?--Ulamm (talk) 13:00, 2 October 2014 (UTC)

The majority of streets don't have the street relations, and various bits of software don't support the relations. Smsm1 (talk) 08:57, 3 October 2014 (UTC)

O.K.

And a suggestion: These reasons should be written in the advice. OSM as an open-source-project has always to cope with problems of nonsense advices and nonsense customs. The best remedy is to give the reasons for everything, or in other words, not to present any rule without its reasons.

Respecting the English versions as an international "gold standard", I'd like if you do this job in this article.--Ulamm (talk) 09:19, 3 October 2014 (UTC)

How to model sidewalks, crossings and kerbs with respect to routing applications?

Problem description

As it is mentioned by User:Joshdoe in Tag:footway=sidewalk#Examples, there is a problem with tagging kerbs on sidewalks, when it comes to routing along sidewalks.

The following figure illustrates a possible situation:

The green lines indicate sidewalks. The red/orange lines indicate roads. The white dots indicate nodes marked as Proposed features/kerb=*

Now imagine that all kerbs are tagged with kerb=raised, which implies wheelchair=no. In this case a routing application that evaluates whether certain nodes are passable would come to the result that a the crossing at B is not possible to be used since 2 non-wheelchair accessible nodes would need to be crossed. This would be what we would expect the routing application to do.

However, if you now image a route from A to D, there would also be 2 non-wheelchair accessible nodes required to be crossed. However, for this route these kerbs are not relevant since an actual wheelchair user could stay on the sidewalk and would not actually cross these kerbs Tag:footway=sidewalk. Since, given the current tagging situation, there is no distinction between these two situation a routing application would in this case come to the wrong result that the direct route from A to D is not possible for wheelchairs, since the non-passable kerbs would need to be passed.

There are 4 possible options to overcome this situation:

Solution 1: Nodes not directly on sidewalk junctions

• As has been recommended by User:Joshdoe in Tag:footway=sidewalk#Examples the kerb=* node may be off the main sidewalk, such as by using a short way from the center of the sidewalk to the kerb. The following figure illustrates this. Note the different positions of the white dots (kerbs) in comparison to the original situation.

• Advantage: This would be a more natural way of modeling since the kerb really does not need to be passed when just going along sidewalks
• Disadvantage: This might make the editing process more complicated since new nodes would need to be inserted in the sidewalks the cross the roads

Solution 2: Relations with conditional turn restrictions

• When going from D to C one could use a (conditional) restriction at B.
  • E.g.: restriction:wheelchair=no_left_turn (cf. Relation:restriction#Tags)
  • Alternatively one could tag a relation consisting of the sidewalks coming in from D and passing B with kerb=raised and perhaps also with Proposed_features/kerb#kerb:height=<height> <unit>

The same could be applied equivalently for all other kerbs and all other possible routes.

• Advantage: Kerbs could be tagged on the already existing nodes

• Disadvantage: Strictly speaking a kerb is not a restrition in the narrow sense. For wheelchair users a kerb is more like a natural barrier/obstacle that they are not able to pass rather than not allowed to pass (the latter one is the actual intention of a restriction.

Solution 3: Tag the crossing way

• It is mentioned in the tag proposal Proposed_features/kerb#Proposal, that in case the kerb is identical on both sides of a crossing, it is possible to add the kerb=* tag to the highway=crossing node, which sacrifices accuracy for simplicity. Presumably, identical kerbs on both sides of a road will be a commonn situation.
• Likewise one could think of adding a kerb=* tag to the sidewalk (footway=sidewalk) segment at B

• Advantage: This would be the option that is easiest to implement for routing engines as the information would be directly attached to a way (edge) element
• Disadvantage: In a routing graph a (lowered) kerb is actually more like a point, not an elemnent of the way crossing a road. Moreover: How to handle situations where the kerb is not identical on both sides of the sidewalk (however: probably a rare case. In this case the worst value could be tagged)?

Solution 4: Tag the crossing node

• It is mentioned in the tag proposal Proposed_features/kerb#Proposal, that in case the kerb is identical on both sides of a crossing, it is possible to add the kerb=* tag to the highway=crossing node, which sacrifices accuracy for simplicity. Presumably, identical kerbs on both sides of a road will be a commonn situation.

• Even in a case of a footway=sidewalk feature crossing a highway=* one could add a highway=crossing tag as well as a kerb=* tag directly to the node where both features are crossing each other

• Advantage: It is an option easy to implement and also easy for tagging.
• Disadvantage: 2 distinct kerbs/point features are reduced to one feature. Only feasible, if both kerbs are identical.

--Shahmann (talk) 17:45, 7 Mai 2015 (UTC)

If you want to stay on this model with kerbs as node, solution 1 seems the easiest. Alternatively I can imagine having the kerbs modeled as ways as well, and model the true topology (i.e. the highway=footway in the centre of the footway/sidewalk). This way you could use area-relations (type=area) to make actual area:highways for the road (from kerb to kerb) and the sidewalks (from kerb to the border), hereby having an additional benefit.

The mapping as shown in the problem description is definitely wrong, considering the conventions we use (highway-ways are in the centre of the highway, hence their crossings cannot be the kerbs). --Dieterdreist (talk) 10:30, 8 May 2015 (UTC)

There might be a misunderstanding of the illustrations. Note the white square on the green lines are meant to be the kerbs, not the white dots on the red/orange line --Shahmann (talk) 17:29, 8 Mai 2015 (UTC)

As I personally in favour of avoiding separate ways for sidewalks where possible, it should be allowed to add the kerb tags to the highway=crossing element. --Tordanik 11:26, 8 May 2015 (UTC)

Looks like solution 1 is prefered by the community, cf.: https://lists.openstreetmap.org/pipermail/tagging/2015-May/024270.html However, using solutoin 3 in addition simplifies implementation for most routing engines --Shahmann (talk) 09:45, 29 Mai 2015 (UTC)

I also prefer to avoid separate sidewalks, as I don't see it as backwards-compatible. I also don't think the smaller accuracy of tagging sidewalk information in the way with highway=* would actually make a difference when using a router (unless the sidewalk is significantly different). --Jgpacker (talk) 12:56, 9 June 2015 (UTC)