Improving the Wiki documentation of barrier=kerb and kerb=*

[dieterdreist]

I agree that once you know the “parent” way, you should be able to make use of :left and :right.

unless it is split at this point…

I don’t understand why some mappers insist on adding direction dependent tags on nodes which inherently cannot have a relation. Guessing which way these tags should apply to may work in a majority of cases, still it always remains ambiguous and guesswork.

[Minh_Nguyen (Minh Nguyễn)]

@goodidea

I am surprised – I would never call a crossing highway=footway, footway=crossing (or cycleway) a parent way for the crossing node. This is a weird, confusing semantics. The crossing is the crossing of e.g. a highway=residential – it’s clear what the “parent” way is – it’s definitivly not a highway=footway, footway=crossing way – this is not a parent and not a child of the crossing node, it’s quite the same, only another form of representation.

A software could easily determine what the real parent way of a highway=crossing node is, or am I wrong? (If it’s not placed at the crossing of 2 streets).

I think we all agree that the crossing way and crossing node semantically represent the same concept. But I think @skyper was referring to a “parent way” in terms of the raw data model, not semantically. Every way is composed of multiple nodes; the way is the parent of these child nodes, regardless of the tags on the way or the tags on the nodes.

For software to distinguish one of the intersection node’s parent ways as the more relevant parent for suffixes such as *:left and *:right, it would need to special-case certain tags. This is probably abnormal among common OSM tagging schemes; normally directional suffixes don’t change meaning depending on which parent element you evaluate them on.

@goodidea

@Minh_Nguyen

What’s more, a pedestrian scramble crosses two roadways simultaneously at a 45-degree angle. Other difficult-to-model configurations are also possible. Even when the crossings in a given locality are only mapped as nodes and not ways, we still need to consider what happens when a bona fide footpath or bike path crosses a road midblock, not an uncommon scenario.

I’m sorry - I can’t imagine what that means or what you mean. And what is a pedestrian scramble? Never heard this term in this context, but I am not an english native speaker.

Sorry about that, a pedestrian scramble is a signalized crossing where pedestrians are supposed to cross diagonally across the intersection during a dedicated signal phase. Here’s a video of it in action:

File:DiagonalCrosswalkYongeDundas.webm

And here’s a pedestrian scramble intersection with kerb=raised on either end of the diagonal crosswalks but kerb=lowered on either end of the non-diagonal crosswalks:

File:2012-03-10 Oakland 039 Chinatown (6991602121).jpg

@goodidea

We are not tagging for renderes, aren’t we? But we’re supposed to tag for certain difficult software cases? Really?

In a word, yes. OSM doesn’t exist in a vacuum. We shouldn’t bend over backwards to accommodate a single data consumer or even a single kind of data consumer, but what you’re actually questioning is OSM’s basic data model, which every data consumer relies on. A node is a node; even if it represents the same thing as a way, it has the same constraints as any other node, including ambiguity about what “left” and “right” would mean. There are efforts to reimagine the data model, but a lot of consideration has to go into it, and not only for a specific tagging need that has more compatible alternatives.

@goodidea

And not to forget: I was only speaking about using a suffix like “:right/:left” on a node … for a feature like kerb, which is right or left of a crossing anyway … and left/right seems to be in use on passing_place nodes, too – as I wrote. What is your suggestion how to tag it on a node, if it’s different on the right/left side?

I’ll admit this is an open question, also for a knuckle-shaped highway=turning_circle that’s only on one side of the road. Should I really kink the road to one side at this turning circle?

What if the protrusion is more extreme?

Ultimately a node can only be stretched so far before a new way starts to look attractive:

[Nadjita]

@dieterdreist

unless it is split at this point…

I don’t understand why some mappers insist on adding direction dependent tags on nodes which inherently cannot have a relation. Guessing which way these tags should apply to may work in a majority of cases, still it always remains ambiguous and guesswork.

If it was for me, I wouldn’t map kerb or tactile paving on a highway=crossing-node at all, but as long as there are non-separately-mapped footways in OSM, there will be the need to somehow tag this. Unless we agree that kerb=* and tactile_paving shouldn’t be on a highway=crossing that is a member of more than 1 way, what else would be suggested?

[skyper]

@goodidea

Could you please describe your way to solve such a situation with different values of kerbs/tactile_paving=yes|no on a highway=crossing node using cardinal directions? How should that work? Cardinal direction as a suffix? tactile_paving:SW=yes, tactile_paving:NE=no? I know about using cardinal directions (or degrees) in combination with the direction=* key, e.g. on traffic_sign nodes which are not connected to a way. (And then you need to define what the direction should mean, like the “face” of a traffic sign for example.)

Yes, tactile_paving:SW=yes, tactile_paving:NE=no and similar could be a solution. For sure the meaning of the direction needs to be defined.
kerb:S=lowered would even solve situations where the crossing road and not the crossing footway or path have kerbs.

@Minh_Nguyen

@goodidea

I am surprised – I would never call a crossing highway=footway, footway=crossing (or cycleway) a parent way for the crossing node. This is a weird, confusing semantics. The crossing is the crossing of e.g. a highway=residential – it’s clear what the “parent” way is – it’s definitivly not a highway=footway, footway=crossing way – this is not a parent and not a child of the crossing node, it’s quite the same, only another form of representation.

A software could easily determine what the real parent way of a highway=crossing node is, or am I wrong? (If it’s not placed at the crossing of 2 streets).

I think we all agree that the crossing way and crossing node semantically represent the same concept. But I think @skyper was referring to a “parent way” in terms of the raw data model, not semantically. Every way is composed of multiple nodes; the way is the parent of these child nodes, regardless of the tags on the way or the tags on the nodes.

Yes, in the section I was writing about software and “parent way” in the terms of the raw data model.

@Minh_Nguyen

For software to distinguish one of the intersection node’s parent ways as the more relevant parent for suffixes such as *:left and *:right, it would need to special-case certain tags. This is probably abnormal among common OSM tagging schemes; normally directional suffixes don’t change meaning depending on which parent element you evaluate them on.

Exactly, if we get to a point where the tagging schema depends on parent objects, gets too demanding on editor software, does not work on all cases and still can be ambiguous, we might have to rethink the tagging.

@goodidea

For me it’s not an argument that editing software could perhaps not treat such a tagging – then it’s a bad software and it should be improved asap. I use Vespucci and JOSM and both do support a change of the left/right values if the direction if the parent way is changed! It is not our job as mappers to align our tagging to poor coded software.

Oh, sorry, I was wrong about the support but:

@Minh_Nguyen

iD behaves similarly to the other editors: if you add *:left and *:right to the crossing node and then reverse the roadway, the values of these tags will be swapped. But the same thing happens if you reverse any other way that happens to be connected to the roadway at the crossing node.

Here we go. First thought would be to filter by highway=* but we cannot be 100% sure that the kerb belongs to the lower class and should only be swapped changing the direction of the highway with the higher class.
By the way, JOSM does not check keys of the parent way to offer the swap.

@dieterdreist

I agree that once you know the “parent” way, you should be able to make use of :left and :right.

unless it is split at this point…

Yeah, which even could lead to a cascade of changing the ways’ directions of connected ways which might not be loaded at all.

@dieterdreist

I don’t understand why some mappers insist on adding direction dependent tags on nodes which inherently cannot have a relation. Guessing which way these tags should apply to may work in a majority of cases, still it always remains ambiguous and guesswork.