[OSM-talk] Mapping canals

[Gervase Markham]

Richard Fairhurst wrote:
> A few more comments, and like Stephen, I've not commented on those  
> where I agree. Generally we should make sure that tags are applicable  
> to all navigable waterways, so river navigations as well as canals.

Sure.

> If you have correctly tagged a waterway with maxlength and maxwidth,  
> then, there is no need to tag bridges, and lock nodes, with maxlength  
> and maxwidth: this is implied.

So you are suggesting we tag the entire canal way with these things, 
instead of the individual parts and features? That does make sense. I 
don't particularly want to measure every lock.

> can be). The channel will typically be more than twice this width. So  
> we need a way of tagging the exceptions - places where only one boat  
> can proceed at once. Something simple like "narrows=yes" would work,  
> or maybe "channel_width=7ft".

narrows=yes is normally all that maps show, and any width measurement 
would be a guesstimate anyway. Do you think that would be sufficient?

>> "boat=private" is used for private parts of the canal.
> 
> In Britain, at least, all canals are essentially private. There is no  
> public right of navigation on canals. I see what you're saying, but  
> the terminology will need to be made explicit on the wiki page.

Fair point.

>> The wiki page makes some good points, but I suggest we have *both*  
>> "waterway=lock_gate" on nodes (useful for large locks, optional for  
>> small ones) and "lock=yes" on canal/river ways (compulsory, easy to  
>> render).
> 
> I still strongly recommend that lock=yes is optionally applicable to  
> nodes (and whatever the wiki decides, that's how I'll tag). 

How does that interact with the lock_gate tag? Are you just arguing for 
a minimalist way of tagging locks, with a single node in the waterway 
with "lock=yes" plus any and all ancillary info attached? Or have I 
misunderstood you?

> It will  
> make editing _so_ much easier than tagging up countless little ways up  
> the Tardebigge Flight would, and there is no loss of meaning.

No-one's saying _you_ have to do this if you don't want to. :-)

> (In fact, tagging a lock as a way could be misleading. For a UK 70ft  
> lock, the length of the way will typically not be the length of the  
> lock, unless your GPS is really accurate. Elsewhere, locks are  
> generally bigger, and the way approach makes more sense.)

Any GPS can distinguish two points 70ft apart, can't they?

> The same tags can still apply to the node, and the direction is  
> inherited from that of the canal.

Isn't there an issue with this directional inheritance, as explained on 
the wiki page - the renderer has to have special knowledge about which 
way passing through the "lock" node is actually the canal.

> Mooring is on the water so I'd submit it makes more sense to tag the  
> waterway, not the towpath - not least for routing purposes. The side  
> could be indicated by mooring=offside or mooring=towpath.  

I couldn't work out how to do this well; your solution has promise :-). 
Would problems arise when there was mooring both sides, perhaps with 
different restrictions? How would this work for canals without towpaths?

>> Bridges
>> -------
>> New tag: ref_canal_bridge=<number> for bridge numbers.
> 
> Just ref_bridge. Some river navigations have bridge numbers, and I  
> wouldn't be too surprised if a few railways did.

The reason I went for ref_canal_bridge is that I was concerned about 
what would happen if a particular bridge had two refs - one allocated by 
the thing passing underneath, and one by the thing going over the top! 
For example, all railway bridges (I believe) have a ref; some of them 
even have them written on in case of a bridge strike. There's such a 
bridge near me. If a canal passed underneath instead of a road, such a 
bridge would have two refs.

But perhaps this is rare enough for us not to need to care.

>> Amenities
>> ---------
>> New tag value: amenity=sanitary_station
> 
> Sanitary station is a really misleading (but sadly widespread) term.  

If it's misleading, then we can pick a better name. If people want maps 
saying "Sanitary Station", the renderer can translate.

> Better to group all the constituent services  
> (amenity=pumpout;water_point), 

BTW, is there a technical limitation which prevents keys having multiple 
values on an object? Or is that entirely possible, and the above is just 
how you write it? Or is the above the workaround for the limitation? Is 
there any agreement on separator character?

> and to come up with a separate tag for  
> what we refer to as "Elsan disposal" (a drain where you can empty your  
> Porta-Potti!). amenity=poo_hole could be misconstrued.

Elsan's a brand name, so probably best avoided. amenity=excrement_disposal?

> We have a convention that metric units are used unless you explicitly  
> specify otherwise... but you _can_ explicitly specify if you want to.  

How far does this go? Furlongs, firkins and fortnights?

> maxspeed=110   <-- assumed km/h
> maxspeed=70mph <-- unit stated
> maxwidth=2.14  <-- assumed metres
> maxwidht=7ft   <-- unit stated

If that's true, then I agree it would be better to specify measurements 
in feet.

> Final note: suggest we encourage use of the operator tag for the  
> navigation authority: operator=British Waterways, operator=VNF, etc.

Would it be reasonable to say that BW were the default operator for UK 
canals? Or would that be considered to be having required information 
outside the map?

Gerv