Kerb height node/way

[peternewman]

I think I'm being asked unnecessarily about kerb height on a node when it's present on the way. Similar to #2347 for tactile paving on the node/way.

How to Reproduce
This way (the kerb):
https://www.openstreetmap.org/way/427341975

Has kerb=lowered, but I'm still being asked at that point, is that because it's not on the node itself ( https://www.openstreetmap.org/node/5125180422 ) I think?

Versions affected
v27.1

[matkoniecz]

Is it likely that barrier=kerb is tagged with kerb and on crossing itself kerb is further lowered, and that info is not tagged?

[peternewman]

The adjacent kerbs:
https://www.openstreetmap.org/way/427341966
https://www.openstreetmap.org/way/427341972

Are just tagged as barrier=kerb, so the bit leading onto the crossing is all the lowered bit.

Lowered should possibly be tagged as flush, I'd need to check onsite, but certainly it doesn't get any further down that that.

What's the difference between kerb=flush and kerb=no and "There is no kerb on this side of crossing" is that for living streets where there's say just a marking and not a physical demarcation, or nothing at all?

[westnordost]

OK to summarize, there is a way tagged with barrier=kerb + kerb=lowered and you expect that the vertex at the intersection between the kerb barrier way and the crossing/sidewalk way should not be tagged with kerb=lowered.

Do you have a link to documentation for this tagging (that kerb=* is tagged on the barrier=kerb way)?

[peternewman]

OK to summarize, there is a way tagged with barrier=kerb + kerb=lowered

Correct.

and you expect that the vertex at the intersection between the kerb barrier way and the crossing/sidewalk way should not be tagged with kerb=lowered.

No, but after #2347 I went to look on OSM and was surprised to see it already tagged with a value, yet still being asked in SC.

Do you have a link to documentation for this tagging (that kerb=* is tagged on the barrier=kerb way)?

The wiki says it can be used on nodes and ways:
https://wiki.openstreetmap.org/wiki/Key:kerb

[matkoniecz]

What's the difference between kerb=flush and kerb=no and "There is no kerb on this side of crossing"

As I understand it, and it seems to match wiki:

kerb=no - there is no kerb (there may or may not be marking of some kind) I uploaded photo of that case and added to https://wiki.openstreetmap.org/wiki/Key:kerb#Tagging ( https://commons.wikimedia.org/wiki/File:Completely_missing_kerb_IMG_20200927_133654.jpg )

There may be physical demarcation in form of a tactile paving or some extremely subtle like tiny gap between different layers of asphalt.

---

kerb=flush - there is kerb but on exact level of road and footway - https://commons.wikimedia.org/wiki/File:Flush_kerb_IMG_20200927_134537.jpg

---

is that for living streets where there's say just a marking and not a physical demarcation, or nothing at all?

Not only for living streets, "no kerb" image is from residential or tertiary road (both would be viable, not sure how it is tagged in OSM).

[westnordost]

The key is kerb=*, and is used on the node of a highway=footway, highway=cycleway, or highway=path at the location of the kerb (at the edge of the street).

Well I'm reading this in the wiki

[peternewman]

What's the difference between kerb=flush and kerb=no and "There is no kerb on this side of crossing"

As I understand it

Thanks for clarifying, the "no" photo is great!

The key is kerb=*, and is used on the node of a highway=footway, highway=cycleway, or highway=path at the location of the kerb (at the edge of the street).

Well I'm reading this in the wiki

I was going off the infobox. It's also mentioned as an open issue:
https://wiki.openstreetmap.org/wiki/Key:kerb#Open_issues

I don't know which wins? 😕

Given the location of the kerb (at the edge of the street) is inherently a linear thing, it seems a bit of a broken schema if you can't tag it on a way, which is presumably why they allow it. I guess it could possibly be argued a lowered bit is a point, but it still has a distance. Consider something like this where it could/may be lowered as one continuous bit for the three routes from each corner:
https://londonist.com/2016/08/oxford-street

It would be most accurate to tag that as one lowered way than three lowered nodes.

From a technical perspective, presumably its possible to find the tags associated with a way that intersects, not just a node?

Also if this is the detailed scheme, surely it should be detailed, otherwise wouldn't it be more simple to just tag left and right kerb on the crossing node or something.

[matkoniecz]

From a technical perspective, presumably its possible to find the tags associated with a way that intersects, not just a node?

Yes, disabling this quest on crossing of footways with barrier=kerb with tagged kerb=* (and asking just on ones with no kerb tag) is simple.

Inheriting tags from way to node on it is doable while processing OSM data (though it may be impossible or tricky in some tools or workflows)

But I am unsure whatever it is preferable to do this change or not.

[westnordost]

Isn't it basically the same issue as whether the surface of a highway=pedestrian should be left out if it crosses a plaza (tagged with highway=pedestrian)?

[matkoniecz]

Isn't it basically the same issue as whether the surface of a highway=pedestrian should be left out if it crosses a plaza (tagged with highway=pedestrian)?

Yes, with the same issue that in typically it is repeating info from parent but in some rare cases it is useful. And sooner or later someone will map it anyway.

[westnordost]

I'll close this then. Such duplication has its merits for data consumers as they then don't need to puzzle together tags inherited from containing areas etc.

There could be Osmose-QA/JOSM validator checks that check if information that is duplicated differs.

[rhhsm]

I don't want to open a new issue for this small thing, but when I solve a kerb quest, they show in iD as having "incomplete tags". This is because SC only adds kerb=value to the node; selecting "Upgrade the tags" in iD adds barrier=kerb. It would save some work if SC would add barrier=kerb as well as kerb=value

[westnordost]

@matkoniecz what do you think?

[peternewman]

I'll close this then. Such duplication has its merits for data consumers as they then don't need to puzzle together tags inherited from containing areas etc.

Although presumably realising something is an area and working out if a way is contained by it is far more complicated than just finding out if two ways intersect each other?

I don't want to open a new issue for this small thing, but when I solve a kerb quest, they show in iD as having "incomplete tags". This is because SC only adds kerb=value to the node; selecting "Upgrade the tags" in iD adds barrier=kerb. It would save some work if SC would add barrier=kerb as well as kerb=value

Surely SC should only be finding ways/nodes with barrier=kerb to be asking the question? Otherwise how did it know it should pose the question. Or is it a literal continuation of my query where it's found a way tagged with barrier=kerb intersecting with a crossing but then it's added the kerb=value to the node not the way?

If we're saying duplication has benefits, then shouldn't it tag the equivalent bits that it found (i.e. the way if it found the kerb tag on a way), even if it tags the node as well.

[westnordost]

Although presumably realising something is an area and working out if a way is contained by it is far more complicated than just finding out if two ways intersect each other?

If you mean by intersection that two ways share a node, then yes.

Surely SC should only be finding ways/nodes with barrier=kerb to be asking the question? Otherwise how did it know it should pose the question.

See #1305 (comment)

By the way, it is preferrable that if you have something more to add, to add another comment rather than modify what you've written. I oftentimes only read the email and not actually go to github to read the (maybe edited) message.

[peternewman]

Surely SC should only be finding ways/nodes with barrier=kerb to be asking the question? Otherwise how did it know it should pose the question.

See #1305 (comment)

Yeah IMHO if SC is adding the kerb=value tag on a node when it found barrier=kerb on a way it should add barrier=kerb too (although personally I think it should still mirror the existing tags, i.e. if it was found on a way it should add it to the way).

By the way, it is preferrable that if you have something more to add, to add another comment rather than modify what you've written. I oftentimes only read the email and not actually go to github to read the (maybe edited) message.

Apologies, I think we all fall into that trap occasionally 😉

[HolgerJeromin]

A OSM router will probably only look an the tags of the route and not connected ways. So +1 for adding the barrier tag.

[westnordost]

Okay, makes sense, @HolgerJeromin

@matkoniecz this is your quest, what do you say?

[westnordost]

Well, I added it now. If you have objections, put them here.

[matkoniecz]

@matkoniecz this is your quest, what do you say?

From what I remember it may lead to some duplication, but in case of crossings everything is duplicated already so...

[peternewman]

A OSM router will probably only look an the tags of the route and not connected ways. So +1 for adding the barrier tag.

Personally I'd have thought that means the routers should be fixed, but maybe that's more complicated than it seems.

From what I remember it may lead to some duplication, but in case of crossings everything is duplicated already so...

Given we're already potentially duplicating a way tag onto a node already...