Consider adding validation to create kerb nodes.

[Bonkles]

Description

While mapping sidewalks and crossings, we should consider adding automagic validations for creating kerb nodes wherever crossing ways meeting sidewalks.

We could also consider a power user feature that would just create the kerb nodes with extreme prejudice. According to chad and Said, there is basically never going to be a sidewalk / crossing way intersection without a kerb node needing to be there.

Ex: This user is in the process of drawing a crossing way and has left it close to the sidewalk, and rapid has generated a lint showing the fact that they should probably be connected.

After connecting the two features, we should at least put up a lint saying that there should probably be a kerb node here:

[tordans]

+1 for looking for ways to automate adding kerbs!

After connecting the two features, we should at least put up a lint saying that there should probably be a kerb node here

I think this touches the area of local conventions on how to map sidewalks. In Berlin we would never join the three lines at the kerb but have the crossing reach into the sidewalk area as a link. The kerb is then on this crossing part. And even this mapping style is "controversial" locally with people splitting the crossing section. Example:

However, maybe this can be simpler with a yellow hint…

This crossing has no kerb notes. Add kerb notes (and position them afterwards) Ignore

The yellow box could just place some notes with the right tags on the line and the user can then position them at the right place.

[bhousel]

This is a good suggestion - We just got back from State of the Map US, and there were something like 6 talks on sidewalk mapping. It's good that there is a Pedestrian Working Group now, and that they are starting to put together some guidance on how to map these features in a way that's most useful for consumers.

We should probably just do whatever @geocruizer and the working group ends up recommending, after they've had some time to discuss among themselves.

[Bonkles]

Team discussed- here's what we're proposing for our first cut.

• [ ] Flag any crossings without kerb nodes with a new validator.
• [ ] The validator will give the user a button to 'fix' by adding kerb nodes 1m from the endpoints of the crossing.
• [ ] It will be up to the user to position the kerb nodes and add any additional tag/type info to them (lowered, flush, etc).

Should we offer different fixes in the validation pane?

• Flush
• Lowered
• Raised

[tordans]

Team discussed- here's what we're proposing for our first cut.

That sounds like a good plan!

Should we offer different fixes in the validation pane?

That will add a bit more complexity … and apps like StreetComplete are great at adding this data later, if it where missing.

• The UI to select becomes more complex with choices
• There are cases (in Germany) where left/right kerbs are different – the UI cannot represent all those edge cases

---

Another thing that might be interesting:

We have this double tagging of kerb=* on the crossing node whenever no separate sidewalks but crossings are present. Rapid recently added the validation that syncs tags. Can there be a warning when the crossing node and the kerb nodes on the crossing way do not match?

---

(Sidenote: Crossings have this added complexity of having crossing nodes and crossing ways. I suggest to always add that for clarity.)

[bhousel]

We have this double tagging of kerb=* on the crossing node whenever no separate sidewalks but crossings are present. Rapid recently added the validation that syncs tags. Can there be a warning when the crossing node and the kerb nodes on the crossing way do not match?

I'm not sure if I am familiar with this style of mapping.. I wouldn't recommend for people to add a kerb= tag on a node anywhere except where the kerb actually is - anything else would likely lead to confusion.

[tordans]

I'm not sure if I am familiar with this style of mapping.. I wouldn't recommend for people to add a kerb= tag on a node anywhere except where the kerb actually is - anything else would likely lead to confusion.

It is confusing, I agree. My understanding of the usage is…

• When no sidewalks are mapped or sidewalks are mapped on the centerline, we add a highway=crossing node on the centerline to indicate the pedestrian crossing. In this case, this node can have a kerb=* attribute to indicate "that there is a kerb somewhere near this node that someone visiting the node might want to know about" (Quote source)
• When sidewalks are mapped separately (which "we" are recommending as well), the kerb attribute makes a lot less sense on highway=crossing but should instead be mapped as a separate node. In this case, the kerb on the crossing node can be seen as a denormalization so no geometric processing is needed to know if this crossing has (which) kerbs.

Other signals

• It has ~350.000 usage https://taginfo.openstreetmap.org/tags/highway=crossing#combinations (searchterm kerb)
• There is a StreetComplete Quest on this "What’s the height of the curbs at this crossing?" – Source https://wiki.openstreetmap.org/wiki/StreetComplete/Quests
• It is already part of the tagging schema presets for a while https://github.com/openstreetmap/id-tagging-schema/pull/1201/files#diff-80c62ab58eed5127f95fc2a356aa487a317f7fc828656c2a464178af9af3dc11L11 (one commit on this, probably more)
• The wiki has sections on both usage styles