Tagging lock gates that can be crossed by foot

Hi all,

Many lock gates on canals, at least around here, can be crossed by foot and often connect to a footway or path on either side. Here’s an example:

While the OSM wiki describes quite well how to tag locks and their gates, foot access is not mentioned. Based on various forum posts and bug reports, there seems to be some confusion among routers how this situation should be tagged.

I see a few options:

Drawing a linear waterway=lock_gate and adding foot=yes seems consistent with other OSM tagging. I haven’t come across this in the wild, however, and based on some googling on the topic, this doesn’t seem to be universally understood by routers, nor have I seen the foot access rendered on any common layer or other map.

I’ve frequently seen it mapped with a waterway=lock_gate node where it crosses the canal, and a separate linear highway=footway, bridge=yes, layer=1 in the shape of the lock gate. While this is both routed and rendered, it doesn’t quite pass the smell test (tagging for the router/renderer and all that…)

Another, perhaps less smelly, option that probably works with most renderers and routers, might be a linear waterway=lock_gate that is also tagged highway=footway. IIRC this generates quite a few validation errors in JOSM (and perhaps rightly so; it’s a footway crossing a canal without its own layer).

Is there any consensus on how this (quite common) situation best be tagged?

And, if so, perhaps the wiki can be improved a bit regarding this?

1 Like

I would not hope for some routers integrating lock gates with foot=yes into the routing graph, rather I would draw a footway aside the lock gate with bridge=yes and maybe a width=*

5 Likes

As the lock gate and the footway are separate objects I’d say this is the correct approach, although I would map the lock gate as a way (instead of a node) parallel to the footway.

3 Likes

Not always. See this one where the footpath is across the top of the lock gate with just some anti slip surface and hand rails applied.

It also highlights that these need more tags than just the foot tag as many people would not want to cross this even with the rails.

Image from GMaps for illustrative purposes.

P.s this one at Cape of Good Hope pub in Warwick. Some have only one handrail including the one at Hatton Bottom Lock. Those you really do cling on to for dear life if the lock water is low on the side without the rail as quite the drop!

2 Likes

tagging for router/renderer is fine - and only incorrect tagging for router/renderer is bad, see Tagging for the renderer - OpenStreetMap Wiki

that is a footway, so mapping it as footway seems entirely fine to me (though extra tags starting from wheelchair=no may be applicable)

2 Likes

then at least pedestrian passage is a different aspect of it, even if it is the same object

(like bridge may have man_made=bridge and multiple highway= railway= etc lines)

1 Like

I think it might be fine to not have general-purpose routers route people over that kind of “footpath”.

If a router really wants to, it can route pedestrians over lock_gate ways while displaying an appropriate warning…

1 Like

I would treat this as man_made=pier and simply add the highway tag to the same way. At least, this is how it is explained in the wiki (at least in German) for piers: https://wiki.openstreetmap.org/wiki/DE:Tag:man_made%3Dpier#Wie_kartieren?

At the end of the “How to map?” section there is the subline “Example with a passenger ferry landing stage:”
And then at the end of the table it says: “A footpath must also be added for routing.”

Even the additional layer of anti slip steel plates is a separate footway imo and I would map it as such.

Btw: There is another topic dealing with footways/paths on top of lock gates here

Paths that don't quite connect, and canal lock gates - #29 by ramthelinefeed

1 Like

It sounds like the general consensus is to indeed tag this with highway=footway (plus any additional applicable tags), either on the linear lock_gate itself or as a separate object.

In that case, I would argue that tagging the lock_gate itself as footway might be advantageous since, that way, one can distinguish with certainty between the case where the footway is on top of the lock gate itself versus a separate, non-moveable, foot bridge next to it (which is also not uncommon around here).

2 Likes

what do you mean with “that” kind of footway? It is clearly a footway and intended for the general public (no gates or prohibitive signs) and also safe (railing, hand rail).

The emphasis there really ought to be on the second part of that, to let people know what to expect - width, surface, perhaps hazard

Sometimes in England and Wales a footpath crosses a canal at a lock and often when it does some provision is made for it (separate bridge, wider path on lock gate, extra handrail etc.

People** don’t want to be led astray by something a cat might atruggle with.

** er, me! I’ve walked most of the way across the country*** beside canals, and a continue to do so.

*** avoid Manchester. People use the canal bridges as toilets.

1 Like

Many of these are part of the Public Rights of Way network so general purpose routers do need to route these.

Before routers when we were following paper OS maps we came across these and simply dealt with them.

I thought the UK legal designation doesn’t determine the OSM way type :thinking:

But that’s fine by me, maybe in the UK you can tag these balancing beams as footways then. Just don’t forget wheelchair=no, width=*, and handrail=* tags. And don’t be surprised when you get threads about how to retag for safety, like we regularly do for Alpine paths…

1 Like

you can tag the bridge as bridge=movable

The problem with this approach here is that it misrepresents what is actually here. People seeing a tag for a movable bridge will expect to see that, not a lock gate.

Where there’s actually a footway crossing the lock then highway=footway (with other tags - see above) makes sense, but it is not a bridge, movable or otherwise.

3 Likes

Rural public rights of way, footpaths in particular will have many features which exclude wheelchairs which greatly outnumber lock gates. Stiles and kissing gates being the most common.

1 Like

I agree with this. Especially in a case where you’re literally walking on top of the lock gate (as in the example @RobJN posted, and also common with wider gates at larger locks) it’s by definition not a bridge - much the same way a dam or a breakwater with a footway is not a bridge - and it’d be hard to argue that the walkway is a separate object (though I guess that depends on how you look at it).

At the risk of beating a dead horse (though I’m not sure it’s quite dead yet) that leaves us with a linear waterway=lock_gate with highway=footway (and additional tags describing attributes of the footway). It’s not a bridge so we shouldn’t put bridge or layer on it.

While that’s all fine, it makes validators such as JOSM’s throw enough warnings to make most mappers believe they’re doing something wrong.

It seems that, until there is some sort of documented consensus on this, it’s hard to fix those sort of issues.

This can easily be avoided by treating the lock and the footway as 2 separate objects even if the footway is not a completely separated but an addition to the lock body.

If there is a lock without any additional installation like gratings or serrated plates for walking, a railing or else there is definitely no footway and crossing this lock by balancing on top is at your own risk, so I would surely not map a footway there.

If there is some additional installation indicating that a lock is designed to be passed by foot I can’s see any reason why this should not be mapped as a separate footway then.

Not much difference to a small bridge passing a stream which can perfectly be mapped as man_made=bridge with a highway=footway on top.

I suppose that may work, if adding the appropriate layer tag as well. However, unless I’m misunderstanding you, it doesn’t seem to completely solve every case.

Where the footway is directly on top with no offset, the separate footway geometry would be completely overlapping which doesn’t seem ideal (and generates validation warnings on its own).

Alternatively, adding the tags to the same geometry as the lock_gate we end up with other validation warnings (at least with JOSM). One could certainly ignore those but, again, having some documented guidance for this specific case might help make sure everyone (mappers, validators, routers, renderers) would do the right thing.