[OSM-talk] waterway=lock

Peter Childs pchilds at bcs.org
Fri Aug 28 18:48:46 BST 2009


2009/8/28 Richard Fairhurst <richard at systemed.net>:
>
> Peter Childs wrote:
>> The Canal way will need to be split at the lock gates, (or in
>> some cases where a diversion starts (due to some rivers
>> going over weirs) while there is a lock for boats.
>
> (UK-specific tagging stuff follows)
>
> Ideally I'd like to discourage people from using a (non-closed) way for
> locks where possible.
>
> It makes dealing with the data vastly harder; doesn't actually give you many
> real advantages; and is actively misleading in that it suggests the length
> of the way is significant. Given that UK locks have a tolerance measured in
> inches, and our mapping doesn't, the length is much better expressed in the
> maxlength tag.
>
> About the one thing to be said for mapping the lock as a way, with lock-gate
> nodes at either end, is that you can route a footpath over one of them.
> Which is quite nice in a micro-mapping sort of way but so much of an edge
> case (99% of footpath crossings are actually on lock bridges) that I don't
> see a real issue.
>
> If there's a _large_ lock - say, those on the Manchester Ship Canal - then
> it should really be mapped as an area, not an unclosed way.
>

While I agree that a maxlength tag is a good idea. maxlength still
needs to be on a way otherwise its saying the max length of the gate
which is utter rubbish.

Your suggestion is even more complex. a Closed area would not work as
you need to map the gates so you would need 4 ways, one for each bank
and one for each gate.

I have no knowledge of Canals and shipping, so maybe we need an expert
on how to map waterways properly.

I guess you need two parallel ways for each bank of a river or canal
and a third for the river itself right, When I was adding Tenston Lock
I did not the banks where not maped only the river so there was no
clue to river width.

Oh sorry a river is a series of Area (he frowns) What event happens at
the joins are they completely arbitratory.

Peter.




More information about the talk mailing list