OSM iD asks me to mark any intersection between a crossing way and another road with a crossing node, but it doesn’t copy all the properties over, so I have to either manually copy them over (and make sure they stay in sync in the future) or replace its generated crossing node with a generic point node.
Is there a better way (pun unintended), something like linking the crossing node’s attributes to the way? Or is it actually okay to use generic points for the intersection between a crossing and a road? (I’d argue iD would need to be updated either way, either by generating generic points instead of crossings to link the ways, or by adding a new warning for generic points that join crossings and roads)
In an ideal scenario the crossing node should describe the crossing in terms of what’s important for both ways. The crossing way should describe the way itself and on top you have kerb-nodes describing the kerbs.
I’m talking about actual crossings, where I’m already using 2 curb nodes connected by a marked crossing way. iD seems to want me to duplicate the refuge island & raised info from the way + the tactile paving info from the 2 curb nodes onto the crossing node.
I generally tag the crossing info on both the node and way (including the kerb). I gave a thumbs down because removing it from the way removes information specific information for pedestrian routers. Like how long the crossing is and how big the traffic island in between is. The nodes with the information of the kerb also contain very specific information about the crossing. In the crossing node I can’t tell if one kerb is lowered and the other one flush for instance. Or if the highway for the cars isn’t split around the traffic island, you maybe have four kerbs (2x lowered and 2 flush for instance).
The whole node wouldn’t be necessary. A router could detect a footway crossing a highway, so there is a crossing. If there are traffic lights, they could (or should?) be placed on the highway. More information wouldn’t be necessary for a car router I would guess. Most crossing tags are related to the footway, thus I would put them on the way.
Only tag that useful for both ways, is the traffic_calming=*.
Unfortunately this is currently an unresolved problem in OSM.
iD and other editors have to be updated. This is feasible, but someone would have to program it.
With Every Door, we have at least one fairly widely used editor that only updates one but not the other (as Every Door does not currently support editing ways, except for areas).
I am aware there is one JOSM plugin that aims to keep the tags in sync when changing them, but it doesn’t know of all the tags that should be synced over, and of course it doesn’t help users of other editors.
There are some historical reasons for the double tagging. I believe initially tagging on the crossing node was more common, then iD presets drove adoption of tagging on ways, but AFAIK without making sure the tags on ways and nodes are in sync.
There is at least one pitfall in that tactile_paving=yes on the crossing node means something else than tactile_paving=yes on the crossing way. I’m not aware of other such cases, but there might be some.
Personally, I think at least some tags should remain on the node, in particular those that would influence road routing (e.g. crossing:signals, crossing:continuous, traffic_calming, or tags which indicate right-of-way like some crossing_ref values), to avoid routers having to check every crossing way to see what kind of crossing is on the road. On the other hand, tags like crossing:markings or tactile_paving IMO don’t need to be on the crossing node because in places where they’re not particularly relevant to road users, particularly legally.
Might figure out how to make iD not ask for tactile paving info on the node, or auto-duplicate it from the curb, if it’s already connected to a curb with tactile paving info
Might manually move some traffic_calming from ways to nodes
Might manually duplicate some crossing:island from ways to nodes
Endgame is to move all technical info from crossing ways to crossing nodes but that would be a giant process
To be clear, the crossing tags on the crossing node are mandatory and are what’s actually used by all the data consumers out there. The crossing tags on the ways came afterwards and are nice to have, but currently aren’t used for much in comparison.
So, if you really only want to tag one of them, put the tags on the node.
The markings are absolutely relevant for road users. Not only for simple visual recognition, but also because they usually/often have legal implications for how road users need to behave.
Sorry maybe I should have qualified that it probably depends on the region. Where I am in Toronto the markings have no legal implication. The features with legal significance here are being tagged with crossing_ref and crossing:signed / traffic_sign, see User:Jarek/Ontario crossings - OpenStreetMap Wiki
When a footway next to a road ends at a crossing with a lowered kerb, tactile_paving is often used to indicate the dangerous spot tactile_paving=yes. This is set separately for each side of the road, because it can be different! Use in the same way on traffic islands.
This reads to me like tactile_paving shouldn’t be set on crossing nodes. I personally dislike the duplication, and I know that some others say
Is there any reason to have tactile_paving on a crossing node when the curbs are already separately mapped, or would it be worth trying to transfer all tactile_pavings from crossing nodes to curb nodes?
That would be quite a lot of work to do it worldwide.
Personally I’ve been moving to mapping curb nodes when sufficiently reworking intersection geometry, especially at more major intersections, but I think in meanwhile tagging tactile_paving on the crossing node is still a valid simpler style.
Noting that I map in an area where sidewalks might be right next to roadway, so it’s at best 1 metre between middle of sidewalk and curb, and it’s often hard to tell what’s the correct or best aligned aerial imagery. And if there’s trees in leaf overhead I’d be just guessing at where the curb is.
Yeah at the time of the post I didn’t realize that more tags belong on the node than the way.
I’ve set up a site to track some of the initiatives I’m running:
A few notes:
“traffic_calming should only be on the crossing node” is a simple and sane rule, and I’m excited for iD to adopt it
“crossing:island should be on the node, not (just) the way” obviously makes sense; my current iD PR tries to do this by copying it from the way to the node when a crossing node is automatically created, which is right most of the time. Of course ideally each =yes case would be a micromapped footway=traffic_island but there are 484,726 =yes cases (admittedly a few are wrong).
tactile_paving gets complicated. Thoughts:
It’s definitely silly that it’s currently put on the crossing node since it actually applies to the kerb
According to my agent, Soundscape for Android, OSM_Maps_For_Garmin, and Touch Mapper need to be updated to look at kerbs
Two ways to avoid adding tactile_paving to crossing nodes:
Apps like StreetComplete either need to be updated to not ask about tactile paving on crossing nodes if it can ask on the kerbs or already has the answers on the kerbs + perhaps update iD to not ask about tactile paving on crossings when kerbs are attached
Make a proposal for tactile_paving=separate - more formal and unambiguous but also more work to tag than just doing nothing
From what I understand, the handful of renderers that consider crossing tags at all are symbolizing nodes based on crossing=*, crossing:markings=*, and crossing:signals=*. Conversely, the handful of pedestrian routers that consider crossing tags at all are identifying or penalizing ways based on crossing=*, crossing:markings=*, and crossing:signals=*. This has been the divide all along between node-based and way-based crossing mapping. Beyond that, some navigation applications warn road users of upcoming crossings based on highway=crossing on an intersection node, but I don’t know of one that distinguishes crossings based on secondary tags.
Just the opposite, … on a way. And I delete (replace) the node ones, sometimes, depends on the traffic_calming. (edit)
For example traffic_calming= table on the way gives the length of the table.
Where the up and off is.
Often the footway/cycleway goes smooth (road surface at the same level) on the table and goes straight over, on a node (junction) this give the wrong impression that there is a traffic_calming working for cycling and foot, there is no up and off.
When there is a link connection, on the node (+) left or right, you only have a off at the table end.
-------===+======-------- residential
cycleway |
Somethimes it is needed to extra tag the up or off, because, there is not a fluently up or off, and they used some kind of a driveway entrancekerb. Which need a special tag.
This give much more information how the table works.
Also you can control, if a table is to short, then it is a hump, or otherwise.
The same with the node crossing, I set it on the way, and not on a node with highway=crossing
This give more advantage, knowing the length, etc.
On these section I do not tag tactile_paving on the kerb, the exact position of it is in front of the kerb, the warning_block.
Mostly a kerb does not have tactile_paving profile.
A lowered kerb is the band, not the lowered sidewalk.
but when there are no tags on the node and all on the way, they give these warnings also for the cars, even with only way footway=crossingcrossing=unmarked. (magic earth)
So there is no need, to set it all on the node. Routers can use way crossing tagging, if they want. So also crossing:markings, they only use this to visualise it, if they want, topographical.
This is basically vandalism - you’re making the experience of any apps that only look at nodes along street ways worse. Don’t do this. As the wiki says…
Don’t remove tags that you don’t understand
Sometimes you will come across elements with tags that have no meaning to you. This doesn’t automatically mean you should remove them. They may have been added for a specific purpose. If you think they might be junk then try to contact the author. See also: Chesterton’s fence on Wikipedia.
Don’t remove objects that you don’t need or like
Be brave in what you add but careful in what you delete. Someone added a catenary mast or a manhole? And you think it’s stupid or unnecessary because it doesn’t display on the map? Inaccurate mapping is not forbidden, but you certainly should not work the other way and remove details that someone else added. It is known that not everything is always needed by everyone, but you should not remove something just because you do not need it / you think it is stupid / the validator ordered it so.
The hard truth is that there’s only one point where you can add traffic_calming info to street ways: the crossing node. It’s weird but acceptable and important for node-based consumers in the same way as putting tactile_paving on the node.
On the other hand, putting traffic_calming info on the crossing way fails to give drivers the info they need while giving pedestrians info they don’t need.
There’s nothing called a warning_block. When a kerb is tagged as a node, it’s just saying “this is the transition point between sidewalk and street”, which is entirely valid to put tactile_paving on.
