Yes, that’s precisely my point. The presets in id-tagging-schema (which are used by multiple popular editors) simply present this tactile paving option as a checkbox, with a button to see the wiki’s documentation about the key. Apparently this presentation is too ambiguous and leads to rampant mistagging, but I’m not sure what the solution should be. Should editors simply not offer the ability to tag tactile_paving on a way unless you add the raw tag manually? That would be a sensible solution for the U.S., where longitudinal tactile paving is unheard of, but where else is this an issue?
Additionally, there is the issue that the mistagging is so rampant that – again only focusing on the U.S. – this nuance described on the wiki has been muddled to the point of fiction. So either we need to make a very large MapRoulette challenge or mass mechanical edit to remove all these tags, or data consumers cannot rely on the wiki’s definition of this key on ways.
If the existing tagging is (de facto) ambiguous then maybe the introduction of a subtag might be a better option than mass deletion? Ideally with input of people who actually use them.
tactile_paving=guideway vs tactile_paving=kerb for example? Based on values currently in use
A question just for clarification: the rampant mistagging that you mean is tagging tactile_paving=yes on a highway=footway (footway=crossing) if there is only tactile paving at the kerbs and not along the crossing way itself? (Sorry to ask, I didn’t saw such a mistagging here – in my town in Germany – so far. … But an Overpass Turbo query found 6 cases – all of them are wrong, I will change them. And all of them look like accidental mistakes, because there are ways with tactile paving after the crossing along the sidewalk or on a crossing island).
For me it was always clear, that such a tag on a way can only mean: tactile paving along the way and not on its ends. I am surprised that such a mistagging is a problem somewhere.
For the editor presets and to avoid such a mistagging on ways it would perhaps already be enough (and not too complicated), if the text for the key would differ for a way vs. a crossing node, e.g. on a way: “Tacile paving (along the way) : [ ]”.
Yes, I only did a spot-check but am pretty confident that this is the case with virtually all of the 50,000-plus occurrences on ways in the U.S., if not elsewhere.
Perhaps, but then we need consensus that it is ambiguous. It seems that there are still differing opinions on that point. Some would like to preserve the current definition.
I think subkey would be necessary if we intend to capture this distinction in tags versus based on the element type it’s tagged on. This suggestion conflicts with the orthogonal values of tactile_paving. How does one indicate that there is tactile paving on the curb ramp but that it’s primitive?
If we only have to worry about crossings in the U.S. that have been mapped as ways with adjoining sidewalks, then the answer is simple: editors should make it easy to add tactile_paving to the barrier=kerb node on either side of the crossing. tactile_paving on either highway=crossing or highway=footway ways would be considered underspecified, and this option would be removed from editor presets. Of course the reality is not so simple.
id-tagging-schema does have a capability to vary presets by geographic region, but not by whether an intersection has been modeled with sidewalks and crosswalks as ways. StreetComplete in particular would have difficulty with a tagging scheme that depends on separately mapped curb ramps.
I don’t think anyone would mind a proper (re)definition of tactile paving. The tag hasn’t evolved much and people have been misusing it, because they wanted to be helpful, but were actually mis-tagging things.
The problem is that there aren’t many people with proper knowledge and ambition to change the current tagging schema.
tactile_paving=warning and tactile_paving=directional would be more reasonable values. The fact that most warnings are because of lowered or flush/missing kerbs, doesn’t mean it’s their only purpose.
The easiest answer is: Add a node to where the kerb is, and add barrier=kerb + kerb=* + tactile_paving=primitive.
If people can’t be bothered to add a node for proper tactile paving, but instead want to add all this information to the highway=footway, we’re never going to end up with a usable tagging-schema.
If I understood you correctly, you’re suggesting to have something like this on a footway=crossing:
At least for cases where both are present. Did I get that right? There are 2 issues for me with this approach:
If we would also make people use tactile_paving:warning=yes (instead of tactile_paving=yes) on the highway=crossing node, this would now make it easy for people to just copy information from the highway=crossing to the footway=crossing. What exactly is the benefit?
Instead, we should stop the double-tagging and tag things like kerb=* and tactile_paving=* on the nodes where they are. Once you have a crossing way, we should not add information that is unimportant to the people on the crossed way (read: cars) to the highway=crossing-node. We’re already micro-mapping now, so why add the “rough” information to the crossing node, like kerb and tactile paving?
If people don’t understand that tactile_paving=* means different things on a node than it does on a way, I’m not sure if they will understand a new tagging schema where they have to explicitly understand the difference, instead of just adding tactile_paving=yes and be done. I’m not saying they won’t, I just don’t find it very likely.
That being said, it would still have its benefits. As you’ve already said: copying a tactile_paving:warning=yes from the highway=crossing to the footway=crossing could now be pointed out by the editor as a possible mistake, because they are never along the way of a footway=crossing. It would also allow us to tag warning tiles on a barrier=kerb-way exactly, and enable us to tag directional paving that leads to warning paving perpendicular to the footway. Something like this:
The latter can already be achieved by adding a mini-way to the kerb, but I hardly ever see that.
Maybe, we could combine all of this into a refinement that could be used alongside the less specific tactile_paving=yes. Interested to hearing your thoughts.
To be clear, my strong preference would be to add tactile paving information to the barrier=kerb node and nowhere else. However, the most popular editor for contributing tactile paving information is StreetComplete, which is unfortunately unable to create new nodes or edit nodes other than the one that turned up in a query.
Additionally, we need to somehow accommodate crossings that haven’t been mapped as ways yet. While it may seem like a contrived scenario to have tactile paving information without the full crossing geometry, this can definitely happen when local mappers aren’t on board with separately mapped sidewalks, or the crossing isn’t visible in aerial imagery, or the crossing is for a pedestrian lane that isn’t physically separate from the roadway – and then a StreetComplete user comes along and contributes tactile paving information. Even in my area, where I tend to map crossings as ways and curb ramps as separate nodes, I still see StreetComplete users come by and contribute (usually consistent) tactile paving information on the highway=crossing nodes.
I hope that, someday, we can deprecate the redundant mapping of a node and a way at the same crossing. Until then, a tag on the highway=crossing node would make more sense for backwards compatibility than the highway=footwayfootway=crossing way, because the highway=crossing node itself is a concession to routers and renderers that aren’t sophisticated enough to handle crossing ways. Some tags on the highway=crossing node should match the highway=footwayfootway=crossing way while others should match the barrier=kerb nodes. Communicating this distinction is difficult, so I wonder if editors other than StreetComplete should stop offering tactile_paving as a discoverable option on anything other than barrier=kerb.
Then I must have misunderstood you, because I thought you were seeing issues when people start copying the highway=crossing-node-information to the footway=crossing.
If we want to tag the presence of tactile paving on kerbs and/or street purely on a highway=crossing, then the suggested tagging would still work. Adding tactile_paving:warning=yes and/org tactile_paving:directional=yes to highway=crossing I mean. On the other hand, it feels like crossing:tactile_paving=* would be more suited/natural for describing a tactile paving that goes all the way over the crossing only and not affect the crossed street at all. It’s tricky to come up with something proper that works for both cases, given that one meaning is supposed to be “roughly” and the other “precise”.
Indeed, I was raising the concern that mappers are copying from highway=crossing to footway=crossing for completeness’ sake, muddling the documented meaning of tactile_paving=*. Crossings that are only mapped as a node are a related twist on the problem, one we’d have to consider in any change to the tagging schema. I think a subkey like crossing:tactile_paving=* or tactile_paving:location=* would address both cases, but I would just as well be happy to see the end of tagging curb-specific information on crossing ways or nodes, if that would be technically feasible in popular editors.
By the way, it might be possible to micromap one level further. If the tactile paving isn’t at the curb ramp but somewhere before it, affecting pedestrians coming from one direction but not another, would it be correct to tag tactile_paving=yes on its own? The wiki doesn’t really seem to address this case as far as I can tell. If it needs a different tag to serve as a primary feature tag, I don’t think barrier=* would be the appropriate key; it’s more like a form of traffic_calming.
Although I have a lot of experience with blind people, I might not be qualified to answer this question, because I can only speak for the situation in Germany. That said, I think you should not map a warning tile independently of its kerb (or what it’s warning about), because it loses the context. For blind people, the tactile paving is a warning, that they will have problems “feeling” the kerb. It’s going to be very, very hard for a router for the blind to understand that the kerb 50 cm next to the warning tile are related to each other.
In general, I agree that something as close as 50 centimeters would be far too pedantic. However, in this case, which is more like 3 meters away from the curb, the tactile paving only protects pedestrians approaching the flush curb ramp from the south, but not those coming from the north. I suspect routers would be able to handle this case in a similar manner as highway=stop nodes placed at the stop line rather than the intersection. After all, the routing graph is a collection of edges, not vertices. That said, this case could be extremely rare and not worth fussing over, but never underestimate American traffic engineers/city planners/property developers!
Please, do not use :left and :right on nodes. :left and :right works with ways but not on nodes and it is not a smart idea to have to look at parent objects to understand the meaning (e.g. direction in this case) of a tag plus most editing software do not treat this tagging properly if the direction of the parent way is changed. Additionally, there might be problems if the node has several parent ways.
Using cardinal directions might work better and do not rely on other objects.
If software can identify :forward and :backward on a node (as needed for give way, signs, traffic lights, etc.), then it should be able to know where :left and :right is. The problem really is that the information is put on the road from a car’s perspective, while it’s consumed mostly from a pedestrian’s perspective. Mostly, because in some legislations, parking on a lowered kerb is forbidden, so that’s something the car driver needs to know.
But the same argument could be applied on putting kerb=* on a crossing of ways: How is the software supposed to know which way this applies to without looking at both ways?
Software only supports forward and backward as values and these tags already make problems as soon as two parent ways are involved which often happens in case of city limits and maxspeed signs. It is just a poor concept but we already have a solution in using cardinal directions or values in degrees.
I guess, the best solution in these cases is to draw the kerb as separate way which by the way solves another problem as it is the only way to tell which side is above or below.
I know that left and right is mainly used for ways, not for nodes. For me, that’s not a knockout criterion. (Just open your mind, and see a highway=crossing node as a punctual, simplified representation of a short segment of a road. And because such nodes are always on a highway=* way, left and right are well defined. This should be enough to use it in a proper way on a highway=crossing node.)
The only case for me which is a little problematic is a crossing node with crossing:island=yes, because this means 4 locations with possibly different values for kerb and tactile_paving – left and right left could only mean the outer positions (rightmost and leftmost), not the two on the island. From a pragmatic point of view, this should usually contain the relevant information at least for pedestrians or wheelchair users - but of course it again describes the crossing incompletely. Then it’s perhaps time for switching to extra drawn footway lines and a separate tagging of kerb and tactile_paving there.
By the way it’s not the only case were left/right is used on nodes. Other example: highway=passing_place (should be used for nodes only!) with passing_place=left|right|both. See Wiki. Perhaps the wording on the Wiki pages for left/right should be modified/enhanced …
I know that is not a very smart idea if you have to look at parent objects, but it is a very clear, straightforward and pragmatic solution for these cases, were tactile_paving (or kerb) is different on (normally) two sides of a crossing. And it should be a no brainer for any software. If anyone suggests a better way, I’ll gladly adopt it - it was the best and most obvious way I could think of, without giving up the “kerb” and “tactile_paving” keys entirely in such cases (or inventing new values or using quite useless and confusing multiple values like kerb=lowered;raised. And otherwise, the two keys tactile_paving=* and kerb=* can practically not be set (correctly) at many crossings and it’s definition for these cases simply is incomplete.
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.)
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.
“Additionally, there might be problems if the node has several parent ways.”: Could you perhaps give an example of such a situation with a highway=crossing node? I personally don’t know of any case where a highway=crossing node belongs to more than one parent highway - then it would have to be mapped in the middle of a crossing - which at least in the part of the world I know doesn’t happen for pedestrian crossings. (Maybe there is – that as a pedestrian you have to walk straight across an intersection. But I can hardly imagine that setting “kerb” and “tactile_paving” on such a crossing node can make sense, perhaps if it’s the same in all directions.) I am focussing on the normal case, that a pedestrian crossing node exactly belongs to one parent way. But maybe I’m missing something.
What do you mean with “the software” as a general term? Which software only supports “forward” and “backward”? And why are we tagging now for any (poor) software?
What do you mean with “two parent ways” which are involved if we are speaking of nodes on a way? At crossing points of ways?
I am also quite familiar with tagging traffic signs …. I know the problems there and it’s not very clean and good defined … but there is a bunch of possibilities covering every situation. From separate nodes beside a highway line (with the key direction=* and cardinal values or degrees) to nodes on a way for ONE sign (with direction=forward|backward) to nodes on a way for TWO signs in the two directions (with traffic_sign:forward=* and traffic_sign:backward=*). Maxspeed signs or city limit signs shouldn’t be a big problem.
Is this really a problem? Why? It can be consumed from any perspective were it makes sense. And doesn’t it matter from which perspective the information comes? The important thing is that it is well defined and unambiguous (thus evaluable for software, which can then easily change the perspective in its output for the user.)
Of course, aside from all the points above regarding highway=crossing nodes, my preferred method is also to tag both kerb=* and tactile_paving=* much more precisely e.g. on highway=footway lines – at their respective exact locations as nodes or along a path. I see the tagging of highway=crossing nodes only as a simplified method (which occurs very often when there are no crossings or sidewalks as separate lines – but it perhaps cannot cover any case regarding kerb and tactile_paving). It would be nice if both were possible – at least for the most common cases – without the now defined values for kerb and tactile_paving (without using suffixes like :right and :left) becoming incomplete so quickly.
Perhaps this could be a rough path for a tagging recommendation for crossings and kerbs: for all the simple and clear cases (which should be defined/explained), one can use highway=crossing nodes plus kerb=* and tactile_paving=*, but for all more complex cases separately drawn footway lines should be used (and kerb/tactile_paving should not be set on the crossing node at all in ambiguous cases were no value is fitting).
When a crossing is mapped as a highway=footwayfootway=crossing or highway=cyclewaycycleway=crossing way, it must connect to the roadway it crosses. That intersection node is tagged highway=crossing for backwards compatibility, in particular for car routing profiles that sensibly remove footways and cycleways from the car routing graph. Of the 7.7 million highway=crossing nodes globally, over 2.5 million connect to highway=footwayfootway=crossing ways and almost 90,000 connect to highway=cyclewaycycleway=crossing ways. This accounts for virtually every intersection node that belongs to a crossing way.
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.
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.
If a piece of software is incompatible with your proposal, that doesn’t necessarily mean it was poorly written. It could just mean the developers didn’t have the benefit of your insights when writing it.
There are fundamental differences between a node and a way that cannot easily be overcome by arbitrarily imagining a node with certain tags as a short way going in a particular direction. Due to the underlying OSM XML data model, OSM-based processing tools such as Osmium segregate OSM elements by element type, reading all the nodes first, then all the ways, and finally all the relations. Routing engines like OSRM must process OSM data into a routing graph that assigns all relevant information to edges (i.e., ways), so anything on nodes requires a nontrivial “rewriting” process.
All this to avoid having to represent a 2D geometry as a 2D geometry or mapping the curb ramps where they’re physically located. I think at some point we have to accept that tags alone aren’t very effective at encoding spatial relationships. Even if a mapper personally finds crossing ways to be repulsive and prioritizes mapping highway=crossing nodes, they may still need to make an occasional exception when a crossing is too inconsistent for a single atomic node representation.
I myself used to insist that highway=traffic_signals and highway=stop should only ever be mapped at the intersection node, for simplicity, but sometimes the intersection is too inconsistent for that to be accurate. Eventually I encountered enough edge cases to break my will, and now I mostly tag these nodes at the stop bars instead.
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’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.
These are not my insights … it’s simply the task to manage such suffixes which are not used specifically for these cases here. IMO every OSM editing software has to take this into account, or it is poorly written.
I know all of this about the “single atomic node representation” and its limitations (I personally avoid to put too much information in a single atomic node – I prefer drawing extra footway lines, kerb nodes at their correct positions and so on) … And I am aware that there are fundamental differences between a node and a way. Nevertheless we have tags/keys on such crossing nodes which represent indeed a way segment (like a kerb) and a software that wants to use all information (e.g. for disabled persons using a crossing) has to evaluate these tags in some way. I only wanted to express this, because it’s a fact. We are not tagging for renderes, aren’t we? But we’re supposed to tag for certain difficult software cases? Really?
But then maybe we should look for an agreement that these tags, which can’t be parsed cleanly or meaningfully on a node anyway (if that’s your position), should be avoided or deprecated. Or that they only have a descriptive, subordinate purpose or something like that.
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?
In this example, the highway crosses the footway. These are getting more and more common here to separate low-speed-limit zones from main streets. Don’t assume things are always 100% clear, when they don’t have to be.
If a crossing node of 2 or more ways has kerb=*, then routers will have to guess where this attributes to. It would make far more sense to be explicit about this (e.g. footway:kerb=lowered, or unclassified:kerb=lowered as a stupid example). I agree that once you know the “parent” way, you should be able to make use of :left and :right.
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.
