I’m prototyping a new wheelchair/pram router and mapping kerbs as part of this. Generally the distinction between flush, lowered, and raised is pretty clear from surveying in person. But a few cases around London have stumped me:
This is one half of a driveway in Westminster. Is this flush?
This is the other half. I don’t know what this should be – it’s kind of flush on one side? Is wheelchair=limited a decent way to tag this as a possible issue?
On the other side, there’s a kerb with tacile paving that looks raised to me – is that right? I’m not equipped to measure height accurately while I’m surveying, so I’m trying to be systematic about how I gauge whether something is likely to be a barrier for wheelchair users or not. I’ve heard (maybe from an Ideas with beers way back?) a heuristic to check by stacking a few coins.
For more context on my plans: I’m surveying in London, where there are already separate sidewalks and crossings mapped (or I’m filling them in for consistency). The group I’m working with is running a trial in Greenstead, so I’m working on filling out the same data there. As a first preparation step, I’m mapping separate sidewalk and crossing geometry, like in Changeset: 188972472 | OpenStreetMap. Ed Loach reminded me to update the sidewalk:{both,left,right} = separate tags on the roads. I’m visiting Colchester next week and going to survey kerbs and crossings in person. I’ve got a web app to collect the data on my phone:
And the hard part is afterwards adding the nodes to OSM correctly. Here’s my test run in London, with the green points already matching a barrier=kerb node with the right tags, and the red points being something I need to go add later:
I’ve found it easier to add my surveyed points when the sidewalk and crossing ways are already mapped. I’ve also found it nice to prepare by creating some blank barrier=kerb nodes on the ends of crossing ways, so I wanted to ask if it’s reasonable to create those first, then fill out later. It’d also help workflows using Street Complete, because there’s a node to ask about.
I’ve skimmed through many of the threads about separate sidewalks. I’m trying to do this preparatory mapping as best as I can from the grainy Bing imagery, and then fill out the crossings and kerbs from surveying. I’m hoping the prototype router I’m working on will show the value of mapping this level of detail. If there’s any concerns about this approach or ideas for doing it better, happy to discuss.
One difficulty you’ll find mapping kerbs in London as that we’ve got too many crossing ways drawn between the separate sidewalk ways, rather than just the width of the carriageway. SC (correctly) won’t prompt for kerb and tactile paving at these sidewalk-crossing intersections,
I don’t understand what you mean; could you link an example please? It sounds like the opposite of what you’re saying, but Way: Walworth Road (43122728) | OpenStreetMap is an example I find hard to work with – the footway=sidewalk goes all the way to Elephant Road, then continues with another sidewalk immediately after. I find crossing ways like Way: 1109040580 | OpenStreetMap that carve out the width of the road being crossed more accurate, and then the node at either end is usually the barrier=kerb.
I’ll be at Geomob, yes – would love to discuss all of this in more detail.
There’s a visible bump at the bottom; I want to somehow capture that this is worse than most lowered kerbs in the area. Do you think wheelchair=limited is appropriate? I’d like to avoid having to try and measure a precise height, but at the same time, apply consistent judgment about how bad the bumps are.
The crossings at this junction are a mess in several different ways (thanks, Uber), but it’s the first example I could quickly find without resorting to Overpass.
The footway=crossing way ( Way: 1516827143 | OpenStreetMap ) on the south side of the intersection is drawn between the separate footway=sidewalk ways, rather than being split at the kerb line. Street Complete won’t prompt for kerb height or tactile paving at either end, as that would place a barrier=kerb tag on the sidewalk way and mislead data consumers into believing that a kerb needed to be traversed while simply turning the corner.
The southern half of the crossing way in the west side of the junction was split at the kerb position and the node ( Node: 13842488493 | OpenStreetMap ) was originally left untagged. The kerb and tactile paving tags on it were added later by a local mapper using StreetComplete.
If anybody wants an overpass query to find crossings incorrectly mapped like this: https://overpass-turbo.eu/s/2jxC shows places where footway=crossing ways meet footway=sidewalk ways without a barrier=kerb node. This is sometimes just a case of simply adding a barrier=kerb node, but many of these examples need the crossing way shortening so it does not continue all the way to the pavement centreline. We worked out there was about 27,600 nodes missing barrier=kerb tags in Greater London, which would take approximately 240 hours to fix.
I also have a set of Overpass queries on my profile page to identify various potential sidewalk and crossing mapping errors. The corresponding documentation is in French though. If anyone is still interested you will find queries to:
I tried to keep the false positives rate reasonably low but there is only so much one can do with overpass. So exercise caution before fixing anything. (Also with the current state of Overpass the queries time out frustratingly often)
… I am realising I’ve misunderstood how crossings at corners work. Way: 1553498166 | OpenStreetMap is one I’ve messed up like this. Thinking about where the barrier=kerb nodes will be encountered made me understand this.
Thank you for explaining this and the example. I’ll fix up all the new work I’ve done around Greenstead and put barrier=kerb nodes to mark the correct spots, before surveying and filling out the types of them. I’ll also think about if some of these Overpass validations could go in GitHub - a-b-street/speedwalk: Assess and map separate sidewalk ways in OSM · GitHub, which can read from any osm.xml/pbf file you’ve got, or alternate Overpass servers, and might be able to help accelerate the process of fixing the 27k possible issues in London.
I’ve just updated Speedwalk to detect a few problem cases like this. Indeed there’s a mess everywhere in London. I’ll try and start chipping away at these.
I might be misunderstanding lowered vs flush – which is really what I want to clarify before I map a whole bunch more kerbs!
I thought kerb=flush means it’s totally flat between the road and the sidewalk. In London, they’re usually at traffic_calming=table places. Here’s one:
It’s flat between the road and the bottom of the tactile paving, but then there’s a slight incline up, so I’m interpreting this as kerb=lowered. Maybe a better example with a more obvious ramp is here:
The cases I’m still confused about are where the pavement and road are not at the same level, there is a ramp, but there’s a big bump at the bottom of the ramp. It’s somewhere in between kerb=lowered and kerb=raised. In these cases, maybe I just need to explicitly measure height, but I think as it’s phrased now, that’d be the total height from the road up to the pavement. The problematic thing I’m trying to map is the bump between the road and the bottom of the ramp.
I may be confused in turn, but I used flush for cases where kerb and sidewalk and carriageway were at the same level, with no gutter etc, also where there was very gentle slope like
Unfortunately the Kerb wiki page isn’t very helpful (it’s not entirely clear if the heights referred to are total drop or the drop right at the edge). There was some previous discussion of this at Distinction between kerb=lowered and kerb=flush? but I think that just showed different people were doing different things.
Yes that topic made it pretty clear that kerb=lowered and kerb=flush mean different things to different mappers. It seems that the the only sane thing for a data consumer to do is to interpret them as synonyms both as meaning “a curb cut of some kind”. Any more specific interpretation about curb edge height greater or less than 3cm or presence of a ramp vs level transition is going to be wrong for a significant portion of curb nodes, depending on who mapped them.
Given the disagreement, I figure this distinction is not worth my time to worry about and I’ll just use kerb=lowered for all curb cuts regardless of the details.
That’s… problematic, but not the worst thing in the world, since flush and lowered are both wheelchair=yes functionally.
For now, I will make my best effort to distinguish these two when I map. kerb=raised are the big problems I’m on the lookout for, and for cases that seem to me to be questionable, I’ll mark them with wheelchair=limited, unless anybody has a better suggestion. Thanks all!
