Proposal:Lock
| The Feature Page for the approved proposal Lock is located at Key:lock |
| Lock | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | David.earl |
| Tagging: | lock=yes |
| Applies to: | ways, nodes |
| Definition: | Marks a stretch of waterway bounded by lock gates, forming a lock |
| Statistics: |
|
| Rendered as: | black V shape, pointing upstream |
| Draft started: | |
| Proposed on: | 2006-12-13 Revision-date:2008-08-10 |
| RFC start: | 2008-08-10 |
| Vote start: | 2008-08-28 |
| Vote end: | 2008-12-07 |
Proposal
Presently, locks themselves are not represented, only waterway=lock_gate on a node. This has several problems, and this proposal is to supplement waterway=lock_gate on a node with lock=yes on a way. That way would be also tagged as waterway=river or waterway=canal in much the same way as you get bridge=yes on highway=primary. waterway=lock_gate would become optional, although it's probably necessary for larger locks.
The "lock=yes" way points from the higher to the lower end of the lock, i.e. in the direction of water flow. So the lock "mitre" symbol would point in the opposite direction.
Additionally, for low-resolution work, lock=yes could also be applied to a single node in the canal way (currently, lock_gate=yes is used for this, which is just wrong - a lock entails two sets of gates, some distance apart). However, this representation may be harder for renderers to deal with correctly in some circumstances (see Rationale).
Because the canal name uses the "name" property of the canal, the tag "lock_name" should be used if the lock has a name.
Tagging
key=lock value=yes
key=lock_name value=Withrington Bottom Lock
Rationale
The obvious symbol for locks is the mitre of the gates at either end. This is directional - it should point in the direction of the lock (with the pointed end upstream). For waterway=lock_gate or waterway=lock on a node, or any representation based solely on a node, determining this direction is quite hard for renderers to do, as it requires information about surrounding elements. More importantly, it requires the surrounding elements to be laid out according to several assumptions:
(a) there should be exactly one way running through the lock_gate (the river or canal way). So a path going across the lock gate can't actually connect to the lock gate. (Actually, a render could be more intelligent and ignore connections to non-waterways, but this undocumented convention is what was suggested should be the case in the discussion thread on the topic).
(b) the direction cannot be determined from the node alone but depends on the direction of the connecting way, conventionally downstream.
(c) This has particular problems at canal summits where the direction of flow must change at a node on the summit which is not at one of the locks if the locks at either end are to be represented properly.
(d) using the lock_gate-on-a-node method, it is not possible to determine the difference between a staircase of locks and locks separated by a pound. Consider
-->--->--->--->---
Is this two locks with a pond between or three in a starircase? It is true that if the rendering uses just the mitre symbols, you can't tell by looking, however it is represented. However, the lock_gate method makes it impossible to represent as well as render. You could imaging a lock being rendered mitred ends with thick black borders between the gates. Then you'd see
-->===>--->===>---
or
-->===>===>===>---
in the above cases.
Representing a lock as a property of a way tagged also as waterway=river or waterway=canal avoids these problems and is simpler to render. The direction depends only on the direction of the way itself; it doesn't care what else is connected to the ends; and it lets the lock itself have a visual representation.
However, this means that the name of the lock also needs to be on the way; as the "name" property will contain the name of the canal, a new "lock_name" property is needed for the name of the lock (by analogy with ref_name, old_name etc.).
Comments
Please use the discussion page for comments.
Voting
- I approve this proposal -- Gerv 21:32, 28 August 2008 (UTC)
- I approve this proposal -- EdLoach 22:25, 28 August 2008 (UTC)
- I approve this proposal -- Aurel 23:29, 28 August 2008 (UTC)
- I approve this proposal --Vrabcak 11:56, 31 August 2008 (UTC)
I oppose this proposal. I do not agree with the addition of the lock_name=* tag, the lock name should be in the name=* tag. --Eimai 11:42, 13 September 2008 (UTC)- I approve of this proposal. Eimai - just putting it in the "name" tag doesn't work; that refers to the waterway name. A lock is typically (say) Grove Lock, Grand Union Canal. --Richard 07:18, 15 September 2008 (UTC)
- I approve this proposal --R2D2 16:26, 23 September 2008 (UTC)
- I oppose this proposal. - This is just an elevator on a waterway. --Lulu-Ann 09:05, 25 September 2008 (UTC)
I approve this proposal. --Zottel 14:30, 1 October 2008 (UTC)- I approve this proposal. --JND 14:17, 21 October 2008 (UTC)
- I oppose this proposal. To be put on single node on a waterway, waterway=lock and name=* will not interfere with waterway=canal and name=* on the way. --Skippern 15:02, 1 November 2008 (UTC)
- I oppose this proposal. To be put on single node on a waterway, waterway=lock and name=* is a beter way. --Nickvet419 05:46, 2 November 2008 (UTC)
- I approve this proposal. --Willem1 16:11, 23 November 2008 (UTC)
- I approve this proposal.--Walley 07:20, 28 November 2008 (UTC)
- I oppose this proposal. To be put on single node on a waterway, waterway=lock and name=* is a beter way. ----Pshipley 00:15, 2 December 2008 (UTC)
Approved by majority vote, 2008-12-07.