Proposal talk:Lock

Please add discussion of the August 08 version of the proposal here:

Locks for water areas

Could this be generalized for when all water features (canals and locks) are areas, instead of just a single way? (so when the lock is not a single node but a segment) --Eimai 23:34, 17 January 2008 (UTC)

I repeat my question... --Eimai 11:34, 29 August 2008 (UTC)

When is that going to happen? Not sure what you mean by a segment, either. Locks are either nodes or ways in this proposal. If someone gives the waterway two sides, you could tag an area, sure. -- Gerv 21:03, 1 September 2008 (UTC)

The segment part is because that comment originated around the time segments were removed from the data model. And IIRC the page was discussing things about direction of the way etc to show the direction of the locks, not exactly applicable to polygons. But I see that you now only have a lock=yes value, so I guess there's not really a problem anymore for situations like this [1] --Eimai 11:31, 13 September 2008 (UTC)

Name

Generally looks good. One question: when a lock is represented as an way, how do you tag both the waterway name and the lock name (e.g. Kennet & Avon Canal, County Lock)? name:lock? --Richard 12:16, 29 August 2008 (UTC)

• Good question. Is it acceptable to say "The name of the waterway is going to be rendered in the pounds in between the locks anyway, so you just use name=County Lock in the lock, and name=Kennet & Avon Canal elsewhere"? -- Gerv 21:03, 1 September 2008 (UTC)

I think that's a bit messy semantically. A route-planner would have to parse the name tag differently depending on whether a lock tag was present or not; and a text search wouldn't be able to tell easily which canal a lock belonged to. Ideally, when there's a waterway= tag, the name= tag should refer to the waterway (as it does for highway, or railway, or whatever). --Richard 22:03, 1 September 2008 (UTC)

OK, option 2. How about putting the name on one of the end nodes? The effect is basically the same. (Are there any other analogs of this problem? I guess roads get around it with "ref", so the A413 can also be Foobar Street...) -- Gerv 08:05, 2 September 2008 (UTC)

Certainly could do that, though it seems unintuitive - you wouldn't usually expect to tag a node with the properties of a way. I wouldn't be too afraid of inventing a related tag, or 'namespacing' it - either lock_name or name:lock would seem sensible. --Richard 00:58, 11 September 2008 (UTC)

lock_name added to the proposal. -- Gerv 08:44, 13 September 2008 (UTC)

Why is it a problem that there can't be a river or canal name on a lock? Surely both sides of the lock should connect with something that has those names if you need it. The name tag should be used for the lock name IMHO.

(btw, you shouldn't change the proposal in the middle of the voting process, you don't know if the people who voted already agree with the change :-) )

--Eimai 11:39, 13 September 2008 (UTC)

Because the lock is part of the canal/river. It would have been built by that canal company and is owned/managed by the body responsible for navigation on that waterway. If, for example, you wanted to extract a list of all the locks in Britain from OSM, it would actually be pretty useless without the accompanying waterway names. --Richard 07:20, 15 September 2008 (UTC)

I can give many examples where a lock isn't part of a canal or river.

But what about things like ship lifts? It would also be part of a canal. So you'd also give it a name=waterway_name tag and then a ship_lift_name=X? Or what about inclined planes -- make a inclined_plane_name=X tag for that? I think it would make it a lot easier if we just stick with a waterway_name=X tag. That way it could be optional, and we don't need a new tag for each kind of feature that might be in a canal or river. --Eimai 11:50, 15 September 2008 (UTC)

Old proposal

Note: Discussion below this point applies to an earlier version of this proposal.

• Is there any reason why you don't just make it waterway=lock? Because the actual lock (ie that stretch of encased waterway between the gates) would be quite the same in a river or a canal, wouldn't it. Honestly I'd always tag that stretch as canal, because it's manmade and has artifical, hard shoulders. -- Fröstel 13:35, 16 February 2008 (UTC)

Using waterway=lock in stead of lock=yes would force every render style that wants to render the river/canal to know about the details of locks or there would appear strange gaps in the rivers/canals. Not everybody is interested in them. Besides all other "constructions" in ways are done with boolean keys, so this keeps it consistent. --Cartinus 16:50, 22 February 2008 (UTC)

This appears to have been pretty well thourght out. I have no disagreements to this and have had the same problem on the canal round me. Are others not commenting becuase of lack of objections and therefore should it just be accepted as its been here for some time? Is there more than one type of lock that can be specified in the key's value, or are all locks basically the same? Ben 02:18, 12 July 2007 (BST)

You will still need a symbol for a single gate for use with large locks, single tidal doors or complex locks with intermediate gates. For example the Barge Lock at Teddington is 650ft long - longer than many streets - and has a pair of intermediate gates.[2] (The water to the north of the island is in fact the lock with its lower gates open) Worldwide locks tend to be larger than in the UK, especially those into docks. The biggest are on the Panama Canal [3] There probably ought to be a property 'single', I think!--Ricka 01:53, 9 October 2007 (BST)

Seeing the extreme example at http://www.luphen.org.uk/public/2004/2004caenhill.htm, I think it might even be a good idea to keep waterway=lock_gate (only for the actual gate) and add lock=yes (for the basin which "raises and falls"). What do you think? -- Ulfl 02:35, 11 January 2008 (UTC)

I don't think you want to keep lock_gate if lock is implemented correctly. What would be helpful would be a height=x for the difference between the two ends of the lock, and to have the direction of the segments indicating the lower end. With that information you can work out the direction of the lock gates, and in future you could guestimate the transition time through a lock system. height=tidal could indicate the transition to sea Lsces 06:59, 11 January 2008 (UTC)

I'd like to have the tag supported on nodes as well as ways (tbh I'll probably tag nodes anyway, whatever's decided). Splitting and tagging a flight of 30 locks (e.g. Tardebigge) as separate ways gets very boring! --Richard 16:08, 11 January 2008 (UTC)

I think lock=yes is too ambiguous. I would prefer something like water_lock=yes. As a non-English speaker, when I read "lock" I assume the ones you need keys for. --Gyrbo 17:41, 11 January 2008 (UTC)

I have a patch that will render this in t@h. But this proposal is missing a crucial piece of information. Which way do the ways tagged with lock=yes? Should it be higher end=start of way, or lower end=start of way? 11:44, 1 December 2007 (UTC)

I was looking up the english equivalent for german Schleuse which is lock on wikipedia and sluice|lock at leo.org. When reading on Proposed features/Lock I was missing the point that it might also be an area - because it's man_made! --katpatuka 16:37, 15 March 2008 (UTC)