I find this reasoning backwards: rather than reporting an issue to fix the buggy validator, we should replace reasonable, straightforward tagging (in this case, highway=footway + waterway=lock_gate) with a convoluted workaround, such as:
If the footpath sits on supports on top of the lock gate and water can (but does not have to) flow over the lock gate when it is closed without the footpath getting wet, then I don’t understand why it can’t be a bridge=movable, bridge:movable=swing.
As the Wiki page itself disclaims, “This principle is not absolute… Examples include but are not limited to: More than one of something on the same site.”
What I advocate, arguably, is the case of “two features, one OSM element”, which is not very well covered by examples on that page. But the bridge case is explicitly addressed:
Using bridge=yes on highways is an example of functional mapping to tell the router there is a bridge (with optional information like the maximum vehicle weight). When mapping object oriented, the actual shape (footprint) of the bridge can be mapped with man_made=bridge, which can be enriched with information like the name of the bridge or wikidata. The same real world feature is mapped twice with different purposes.
Drawing a man_made=bridge area for the likes of Golden Gate, carrying multiple modes of traffic? Yes, absolutely. Doing the same for a plank over a creek deep in the woods? No, thank you.
I think the different views and opinions in this thread highlight the need for some clarification and guidance on this topic.
However, it seems there’s consensus that, if the lock gate can be crossed by foot, we should map it as a line (rather than a node). Then add highway=footway, layer=1 and other applicable attributes (surface, width, access, etc), either to the lock_gate itself, or to a separate parallel line. Additionally it may be tagged as bridge=movable, depending on the circumstances.
Would anyone object if I added something along these lines to the relevant section of the wiki?
I wonder if there are any issues using layer=1 on the lock gate itself if you don’t draw a separate line. The layer tag would have to be understood as applying to the footway but not to the lock gate and related tags (as the gate should really be on the same layer as the waterway). But I don’t know if that matters in practice.
I think the problematic case is when the footway is right on top of the lock gate, with no offset (which is not that uncommon). Either put two copies of identical geometry on top of each other, or artificially offset one from the other. Neither seems great to me. Or how would you suggest handling that case?
We have various 3D like situations whith for example building parts where we duplicate ways and add a layer tag. The same with an highway over a dam where we again are adding a layer tag. Looking at the lock, we do see a footway structure fixed over the doors of the lock. Then, the logic is to add a new way for the footway with layer=1. Then should we avoid to share node with waterway and add a duplicate node? Again, the Quality tools would report a problem.
Fair enough, they are not identical in that they don’t share the exact same set of nodes, but the same set of coordinates.
While perhaps that is the right solution (at least for now) it’s not trivial to accomplish and maintain with the tooling we have, especially for an inexperienced mapper. And, as mentioned, validators and other QA tools would complain.
It’s a bit unfortunate that a quite simple situation like this requires such a difficult solution. But perhaps it is not common enough to justify trying to change the situation?
it is trivial to draw and tag, but it may not be trivial to understand and maintain, especially for an inexperienced mapper, agreed. It is always the case with overlapping ways though.
We can tag the way with highway=footway, bicycle=[yes, dismount], bridge=movable, layer=1
We can use duplicate nodes for the geometry of the footway with the tag layer=1. And if there are still QA rules problems, the rules should adjust to the mapping !
Hopefully this thread can help towards that. It’s obviously easier to “fix” a problem when it’s clear what the solution is. Based on the discussion so far, I think it’s safe to say it wasn’t clear to everyone (myself included, and I’ve been mapping for a while), but I think we’re getting there.