I’m trying to understand what the consensus is with mapping crossings as ways and nodes. Mapping with only a node that has highway=crossing is a valid option, nobody denies that. We get problems when crossings are mapped as ways. Do we map with only a way with footway=crossing, or do we also add a node with highway=crossing?
I looked at a few European cities, and got a percentage of crossings that are tagged with only a way, without a node, versus all crossings tagged as ways:
Data shows that (at least in Europe) a majority of crossings that are mapped with a crossing way, are also mapped with a crossing node in the middle.
While trying to find which mapping style is “more correct”, the only discussion I found is this one on the Discussion page of the highway=crossing wiki. There it is said that tagging both with a way and a node is a Violation of the One Entity One Object Rule, but that this state happened because people didn’t want to delete crossing nodes when adding ways.
However, if the sidewalks have been mapped separately, then I create a separate path for the crosswalk as well and tag the connection (in red) over the street with highway=footway + footway=crossing:
The linked discussion is missing some essential information for me, but I guess it is more about the fact that the node and the way get the exact same keys. So that also on the Way a highway=crossing is added, which is not allowed according to Wiki.
In general if you use footway=crossing then map the intersection with highway=crossing. There is a significant semantic difference between the two tags;
footway=crossingmust be used with highway=footway and behaves as a modifier of the properties of the actual element (a section of footway). In my view its main purpose is to allow true footways to be properly discriminated from footways which are need to provide appropriate inter-connectivity (particularly in the separate sidewalk style of mapping). Personally, I only tend to use them for staggered pedestrian crossings on dual carriageways and roundabout entrances.
highway=crossing works entirely on its own and is a primary OSM element.
At a pragmatic level, highway=crossing also helps motor vehicle routes which may need to apply penalties or warnings (especially signal controlled crossings. Any requirement to parse tags on intersecting ways to deduce the implicit value associated with a node or part of the way of interest imposes much greater complexity in parsing data, and is impossible on subsets of data (for instance all motorable highways).
tldr: the tagging represents different things and doesn’t break 1F1E, both should be used.
Well, actually, there’s just one feature in the field – the painted surface on the road. But, being a pragmatist, I don’t have issues with occasionally violating 1F1E, which I consider a guideline or an ideal rather that a hard rule. By tagging both the footway and the highway point, we help two different kinds of routers (pedestrian and vehicles).
Let’s suppose mapping both, the way and the node is the best solution. Then on a standard crossing, all tags should be identical, except highway=crossing, highway=footway and footway=crossing, right? If any other tag is different, that’s almost always an error.
Standard crossing would be one that uses just the most used tags seen on this Taginfo page.
Tags should be identical between the crossing mapped as a way, and the crossing mapped as a node. The way, and the node, should have mostly identical tags.
Why would you put this information on the node instead of the way? I see this mainly for renderers and these would like these on the way and not the node. Also, I would add crossing=uncontrolled to the way, duplicating the tag.
According to the proposal for crossing:markings, these values are always used in conjunction with highway=crossing. According to the wiki, this should only be used on nodes, not on ways. Why then should crossing:markings=* be set on the way?
To quote the wiki here: “The [crossing] tag is set for the node where both ways are crossing”
But of course, you can also give the value to the node and the way, in which case this creates the duplication that the topic creator was talking about.
Addition:
I just skimmed the Berlin section on sidewalks (in relation to the Straßenraumkarte Neukölln) in the wiki and there I can also only see that the crossing=* value should be set on the node in the middle, not on the path - or am I missing something?
I am more than confused now. What exactly does the second sentence in the Wiki contain that would be relevant to the key crossing=*? That the tag footway=crossing should be set on the way (it is assumed that it is a highway=footway), no one has contradicted here - on the contrary, I even included it in my first example, didn’t I?
I’m reading a translation of this page, and it seems the solution is for ways to only have highway=footway + footway=crossing.
But anyway, this is only a local wiki page that doesn’t hold much weight outside of Berlin. It seems the current state is, there is no consensus on this. I can see advantages in mapping only ways without the nodes, I can see advantages in mapping both, with identical tags, and in mapping both with separate tags. So in my opinion, it isn’t going to be easy to come up with a definite answer that is going to satisfy most of us. I guess for now it’s every city for itself, and maybe the best solution floats to the top
The proposal suggests nodes only, but in reality, nearly half of the uses of crossing:markings are on ways, and the wiki page also allows this.
Same for this one: 42% of the uses of crossing=unmarked are on ways, not nodes. The reality seems to be that people use it for both, ways and nodes. From a renderer-perspective, it does make sense to know the type of footway=crossing we’re looking at.
But: in an ideal world, we wouldn’t tag any highway=crossing nodes if we have detailed mapping of the ways making up the crossing. I suppose the only reason is that SC will ask for crossing-tags But yeah, the problem seems to be: iD asks for attributes on the way, SC for attributes on the nodes, thus we end up with attributes on both.
I agree - there will always be a difference between documentation and usage. But then we as a community should decide if it is an accepted “de facto” use or if this “non-proposed” use should be discouraged.
Here I wonder if this was intentional implemented by iD or if this was a mistake.
Another tags that isn’t used identically on crossing nodes and ways is tactile_paving=. tactile_paving=yes on a highway=crossing node apparently means there is tactile paving on either side of the crossing, while its presence on a footway=crossing way apparently means there is tactile paving along the whole crossing. All other crossing related tags I know of have the same meaning on a crossing node or a way and are commonly included on both from what I’ve seen.
Some mappers may omit certain tags from one or the other though. Sometimes kerb= is present on a crossing node, but not on the way because the the precise locations of the kerbs are mapped separately as individual nodes. Likewise surface= may be set on the way, but not on the node. Not sure if either of these situations should be considered an error, but these tags should have the same meaning when duplicated on both the node and way.
crossing:island can also be different - depending on the mapping method - if the street way is splitted around a traffic island. The node then has crossing:island=no, as it does not represent a traffic island. The passing crossing way, instead, can have crossing:island=yes if it’s not splitted on the traffic island and leads over the island (example: Node | Way). This dissonance could be avoided, however, by dividing the crossing way on the traffic island and tagging it with footway=traffic_island, as is now well documented in the wiki. (Following this method, crossing:island would be a tag that we don’t need on ways anymore).
I perceive that crossing mapping is one of the few spheres in OSM where double-tagging is widely used and accepted. That doesn’t necessarily mean it’s a good idea. In this case there also seems to be a lack of documentation (and maybe discussion or consensus?) on “good practice”, leading to a lot of different mapping styles and tagging methods (also influencing editor presets).
In my opinion, it would be sufficient to tag the crossing way only with footway=crossing (or path/cycleway=crossing) and to record all other specific crossing detail attributes on the node. It should be possible for renderers to extract them if they need them for way rendering (I do it exactly this way in the Straßenraumkarte), and routers traverse the node anyway. But I can imagine that there might be cases where this is not optimal and duplicate information can be beneficial (or the same tag can have different meanings, see the crossing:island example above or tactile_paving in the previous post).
The crossing:markings proposal actually says in the top box that the tag can be used on ways but the only time this is mentioned explicitly in the text is about the (rare) situation where the markings change at some point during the crossing, then the way can be split.
So we have a couple of tags like tactile_paving and crossing:island that should in theory have different meanings on nodes and ways. But do we have any confidence that these subtle distinctions are made in practice?
I suspect the real reason all of these tags appear on both nodes and ways is because iD asks about them on ways as soon as they have the tag footway=crossing and on nodes as soon as they have the tag highway=crossing.
The info text shown to users (if they click the grey ‘i’ at all) is exactly the same on nodes and on ways.
For example, for tactile paving “whether a blind or visually impaired pedestrian can detect or follow”. According to the above discussion, on nodes it should be about detecting and for ways it should be about following the crossing. Does this need updating?
Of course even then, users who don’t click that “i” or use a different editor may be unaware of the theoretical distinction.
But yeah, the problem seems to be: iD asks for attributes on the way, SC for attributes on the nodes, thus we end up with attributes on both.
