Talk:Key:lock
What are the tags for size of the lock ?
We could use width, length or maxwidth, maxlength. Usage show that maxwidth and maxlength are more used (see tag info). Moreover, theses tags are used by OpenSeaMap on harbors
For the height (the difference of water level from the top and the bottom basins), height, lock:height, lock_height and maxheight are used. height is more often used and simple :-)
- We should clarify the difference between the physical dimensions of the lock itself and the advertised restrictions for vessels using the lock, as otherwise they can be very ambiguous. (see Inland navigation)
- * The physical dimensions could be specified with width=*, length=*, height=* and depth=*
- * Presumably lock:height=*, lock:width=*, and lock:length=* would be much less ambiguous but aren't used; and draft=* and deep_draft=* are used to some extent too instead of depth, with the latter common in the US according to taginfo albeit undocumented.
- * The restrictions should probably be maxwidth=* (beam), maxheight=* (air draught/draft), maxlength=* and maxdraft=* (deep draft/draught).
- There are also Seamarks equivalents of some these, just to make it more complicated: seamark:lock_basin:* with height, clearance_height, width, clearance_width, length, minimum_depth.
- Length is particularly important to distinguish between vessel and lock basin as vessels need to be shorter than the lock's length to avoid any inward-opening gates and cills.
--Tractiveeffort (talk) 21:19, 16 May 2021 (UTC)
See also
- CEMT key
- Classification of European Inland Waterways on wikipedia.
Caution : in the english page, there is more classification RA, RB, RC, RD and one VIc "3×2 convoy"
What tags to use for contact information ?
- phone, contact:phone, lock:phone, waterway:lock:phone ?
- vhf, VHF, lock:VHF_channel, waterway:vhf_channel, vhf_channel, VHF_channel, VHF-channel, lock:channel, contact:vhf ?
- website, url ?
I suggest :
- phone
- vhf_channel (like OpenSeaMap harbors)
- website
- I reply to myself 6 years after ;D
- vhf is more used than other tags
- I reply to myself 6 years after ;D
| Count | tag |
|---|---|
| 996 | vhf |
| 244 | vhf_channel |
| 72 | contact:vhf |
| 63 | waterway:vhf_channel |
| 44 | lock:VHF_channel |
| 28 | VHF |
| 3 | maritime_vhf_ch |
| 2 | tunnel:VHF_channel |
| 1 | communication:VHF |
| 1 | contact:vhf:tower |
| 1 | contact:vhf:approach |
| 1 | waterway:lock:vhf |
--Pyrog (talk) 19:23, 18 September 2019 (UTC)
Derelict locks
And suggestions about how to tag derelict locks? PeterIto (talk) 10:35, 23 August 2013 (UTC)
- It depends on the condition of the lock. If the lock is disused but still in good condition, just add the tag disused=yes to the the waterway that are tagged with lock=yes and to the two waterway=lock_gate features. But probably you meant a lock that has been abandoned and cannot be returned to service without extensive repairs or complete rebuilding. In that case, if the lock is still mostly intact and still looks like a lock, I would still use lock=yes + abandoned=yes for the waterway or water area, but use abandoned:waterway=lock_gate for the gates, since they are no longer functional - this makes it clear to database users that there are not gates that will open or close (I assume they are stuck in the open position). If the lock is in ruins and the gates are no longer in place, but there are still clear signs that this used to be a lock, then I would use abandoned:lock=* and abandoned:waterway=* since the original features are no longer existing, but the ruins are still evident. If the lock is completely gone and there are no obvious remnants, then don't tag it at all. --Jeisenbe (talk) 23:39, 18 September 2019 (UTC)
Boat rollers?
These are where there is a dry slope, usually with rollers (hence the name) which can be used by small boats and canoes to bypass the lock. Sometimes a small part of the river stream flows through them, as at Sunbury Lock.
There doesn't currently seem to be a convention for mapping these - they can be part of a through route which could be useful for navigation in appropriate craft. For the moment I've started to tag the river route with lock=* and the actual slope with leisure=slipway, as described on User:Threefoursixninefour#Waterway_locks. Are there any suggestions for a better system? Threefoursixninefour (talk) 12:33, 12 July 2018 (UTC)
Tagging convention for names
Locks tend to be part of a larger waterway system such as a canal and canals can be relations of a series of segments. Should the name=* be used strickly for the name of the waterway while lock_name=* be used for the name of the lock? Then when relations are used, do segments of the waterway even need to be named? Or is the name inherited from the relation? DFyson (talk) 19:16, 25 June 2019 (UTC)
- Yes, lock_name=* is better for the name of the lock, especially when you are tagging the waterway=*. When using a type=waterway relation it's still a good idea to tag the individual ways that make up the river or canal with name=*, since these relations are not handled by all database users, and when editing them it can be confusing if the way does not have a name. Also, the names of long rivers and canals often change over their course, especially when they cross into different linguistic regions, so it's good to put the locally used common name=* for each waterway segment. --Jeisenbe (talk) 23:43, 18 September 2019 (UTC)
- There is some big issues:
- Neither Nominatim or OsmAnd... find the lock by it's name (these tools don't index lock_name=*)
- Some users add the name of the lock to it's chamber: this usage "break" the How to map scheme. (i.e. name=Potters Lock).
Nominatim find the lock :-), but unfortunately describe it as "water" :-(. - Other users use the name of the lock for the waterway: this usage "break" the scheme described above. (i.e. name=Northmoor Lock)
- What should we do?
- update all tools to index lock_name=* and lock_ref=*?
- update old tools that doesn't support relations?
- propose lock:name=* to be consistent with bridge:name=* that is indexed by nominatim. And update all tools?
- --Pyrog (talk) 07:35, 19 September 2019 (UTC)
- There is some big issues:
- OsmAnd does now seem to render the lock_name=* if you zoom in far enough using the Boat profile... I do agree that lock:name=* would be much neater. It's a bit of a shame that most tools won't render the lock name without using name=* instead as these are often important features locally.
- --Tractiveeffort (talk) 21:19, 16 May 2021 (UTC)
Multiple lock basins
How should multiple locks in a row be mapped? Single way spanning the set of locks (with nodes for gates) or split into individual ways per lock basin? A set of locks will typically grouped together under one name but each individual lock might have it's own name or number. DFyson (talk) 19:00, 20 August 2020 (UTC)
- I have the same observation: currently the page assumes just 2 lock gates to be present, but sometimes there is a series, also called a "lock flight". Example lock flight with 16 locks at Caen Hill:
--Dieterdreist (talk) 21:46, 13 February 2021 (UTC)
Lock landing stages
Many locks have landing stages on either side of the lock, for craft to moor whilst waiting for transit or to allow a crew member to disembark to work the lock (or embark after working the lock). The mooring=* key allows for this - I'd recommend using mooring=yes+maxstay=load-unload on an appropriate way to map these (although not sure many tools really render these yet). Any objections to adding this to the wiki? --Tractiveeffort (talk) 21:19, 16 May 2021 (UTC)
lock=yes
To maintain consistency with the rest of the water body, the lock chamber should be tagged as water=canal + lock=yes, for precisely the same reason as prescribed with the waterway.
--DaveF63 (talk) 12:14, 5 July 2022 (UTC)
What about Control locks?
They are not used to lift up boats, but rather to control the flow of the water.
Here's an example: https://www.openstreetmap.org/node/2533739822
What tagging should be used here? This one stood out because it's one of the few lock=yes on a node.
I guess they would be waterway=sluice_gate?
Joost schouppe (talk) 08:48, 1 December 2023 (UTC)