Tagging lock gates that can be crossed by foot

General talk Tagging general discussion
41

I guess I’m a little bit late to this discussion, but I have to admit, I’m a little bit confused about some aspects of the proposed solution.

It is my understanding that a way describing a form of transportation or linear route (e.g. a waterway=*) indicates travel along the length of that way. Mapping a lock gate as linear way tagged with waterway=lock_gate would then seem to be counterintuitive, as the waterway traffic does not travel along the way (along the width of the lock gate), but rather across the way (through the lock gate). This immediately rules out options 1 and 3 from the OP — a way tagged as waterway=* cannot be mapped perpendicular to the actual real waterway.

I don’t know how often the numbers on the wiki update, but they suggest that the majority of examples of waterway=lock_gate are mapped as nodes. This is entirely intuitive as canals are mapped as linear ways, and from the perspective of boat traffic on the water, the lock gate is not a way on which you travel, it’s a point through which you pass as you enter/leave the lock.

So for the simple case of a lock gate without a foot crossing, there’s no reason why a lock gate itself should be anything other than a node (except for micromapping purposes).

Having established that lock gates should be mapped as nodes, how do you then apply a foot crossing to this? Well, you just draw a way across it. This doesn’t and shouldn’t affect how we map the lock gate itself, which is still a node, albeit with a footway now connected to it.

This is essentially the second option listed in the OP, which is described as “doesn’t quite pass the smell test”. Except… it literally does pass the smell test? This isn’t tagging for the router/renderer, it is the literal truth on the ground (or water). A way that is traversible by foot factually does cross over the water, therefore it must be mapped as such. This isn’t in any way complicated or controversial, and the presence or absence of the footway doesn’t affect how the lock gate itself should be mapped.

I’m curious as to what validation errors JOSM would throw for this ‘way and node’ solution, because iD quite correctly does not show any errors for that. If JOSM does throw errors, that’s something that should be fixed within the validator itself, not by us working ourselves into knots to try to trick the validator by offering it unreal workarounds.

Compare the example of roads where sidewalks are mapped separately. Essentially the same principle is applied there when a footway crosses a road. The pedestrian is walking on the road surface, rather than on a separate paved walkway, yet nobody would suggest to map both a highway=footway and a duplicate highway=road going perpendicular to the actual road. Similarly you cannot map a waterway perpendicular to the real waterway.

Similarly, there can be no possible justification for mappng separate parallel/overlapping ways for both lock gate and footway, as that does not accurately describe the reality on the ground. A lock gate is a node. If a footway happens to pass over it, so be it.

42

True, this is not much of an issue for lock gates mapped as nodes. The original situation that “didn’t pass the smell test” referred to a linear lock_gate, not a node.

I guess opinions may differ on whether mapping lock gates as ways, rather than nodes, is “micromapping” or “counterintuitive”, but the fact remains that the OSM wiki considers both correct (at least currently), and so do most QA tools as far as I can tell.

I’ve assumed that waterway=* may refer to waterways themselves as well as related features, so I don’t necessarily see a problem with two perpendicular waterway=* crossing.

43

Indeed, for example:

44

IMHO the footway shouldn’t share a node with the waterway if you do not get wet boots, this is why you would not want to connect the footway to the lock gate if it is represented by just a node, and why it would be cleaner to have the lockgate mapped as a way in these cases.

45

I think you’re imagining a conceptual problem where one doesn’t actually exist.

Connecting the footway to the waterway doesn’t imply that you would get your feet wet. The footway and the lock are one and the same thing, and therefore the footway way must touch the lock gate node to represent that.

The reason you don’t get your feet wet is not because the footway is separate from (or, per previous suggestions, on a higher layer than) the lock — it’s because the lock gate closes, thereby blocking the passage of water. No water = no wet feet. The short distance between the height of the footway and the height of the water is not what an OSM layer represents, i.e. where there’s clear space for traffic on both ways to pass at the same time.

My point is that the lock gate shouldn’t be mapped as a way if you wouldn’t map the equivalent non-foot-crossable lock gate as a way. If you would map a lock gate as a node, then a crossable lock gate must also be a node. Being crossable on foot doesn’t change the inherent nature of the lock gate, and therefore doesn’t change how it’s mapped. Having the footway touch this node does not represent a conceptual problem.

The only possible justification for mapping the lock gate as a way is if you would normally be in the habit of micromapping all lock gates as ways. But the fact is that most people don’t micromap lock gates like that.

46

The Barriers on waterways section of the wiki page list the various waterway barriers such as dam, weir, waterfall, rapid, lock_gate and floodgate and the major dams are even mapped as polygons and this is not «micromapping». Note that the bridge does not stand over a simple node but over a lock_gate wall.

47

shared node for waterway and highway typically is done for fords and not done for bridges

48

So, again, trying to summarize the consensus on this topic:

It seems like the best way to tag foot access on top of a waterway=lock_gate is to add a separate linear highway=footway (and other relevant tags such as access, width and surface properties). The footway can be either offset from the gate or directly on top of it (but not sharing the center node), depending on the physical situation.

The above is true whether the lock_gate itself is mapped as a node or a way.

Adding bridge=yes (or perhaps bridge=movable as was suggested) as well as layer=1 would make sense to clarify that the footway is physically above the lock gate and the canal.

4 Likes
49

Since there seems to be little opposition to the above, I’ll add something along those lines to the relevant section of the wiki.

50

From the point of view of someone who has written a (perpetually unreleased) canal navigation application, I’m not enormously happy with the “offset from the gate” suggestion.

It implies that there are two separate structures, a bridge followed by a lock gate. There aren’t - there’s one structure. With this data, a navigation app would say “500m to footbridge” and then “501m to lock”, which is just plain inaccurate.

If this is to make any semantic sense at all, I would say that bridge=lock_gate for a coincident (_not_ offset) way would be tolerable. But really I don’t see the issue with having a single way tagged with both waterway=lock_gate and highway=footway. If JOSM’s perpetually sniffy validator has an issue with that, fix the validator.

5 Likes
51

I am unhappy about this for no validator reasons: I am not really happy about “waterways and footways are not sharing nodes unless ford is present” turning into something more complex.

1 Like
52

Is that a rule written in stone, though? Maybe it’s worth sacrificing some simplicity here to make other aspects of mapping easier and more manageable?

Besides, as far as I can tell, it’s already more complex than that. Off the top of my head, I swear I’ve seen (and probably mapped) dams with a footway on top as a line tagged waterway=dam and highway=path. And that’s correct according to the wiki (although noting that QA tools will complain, and that this tagging was also “disputed”, so I guess that’s why we’re having this discussion).

53

It seemed like a lot of mappers were arguing that these are (and should be mapped as) two separate structures regardless of whether they are physically attached. But besides extra complexity when mapping it, as you mention it also adds a bit of ambiguity. Hence my statement much earlier in this thread:

1 Like