[OSM-talk] Mapping canals

Sven Grüner sven at schunterscouts.de
Thu Jan 17 22:39:20 GMT 2008


Hi Gervase,

first of all: OSM evolves (as steve is saying). Take on step after the
other and apply everything you've learned from the previous one to the
next. So it's not smart to do everything in the first step because then
there's nothing left to make better for the next, if you catch my drift.
(I love that phrase since "loose change" :-)

As you said this is still the start, but you should start by picking
only a couple of your points, use them for mapping, try to render them
on maps specialised for baoters and then use the experience from that to
approach the other "problems".

I will try to point out some existing tags which might do a good start
for that.

> Looking at the Map Features section for waterways, it seems that the 
> amount of detail available is insufficient. Here follows a sampling of 
> issues and queries. Should I make proposals for the following changes?

Generally speaking: yes!

> - waterway=lock_gate might be great for the Manchester Ship Canal, 
> doesn't work so well for narrowboat canals. Locks are 70ft long or less, 
> and marking the upper and lower gates individually seems unnecessary and 
> makes them harder to render. Locks also have names (e.g. "Hatton Bottom 
> Lock") which seems to make them better rendered with nodes.

There's an active proposal for that, join the discussion.

> On the other hand, canals have no direction of water flow (with a couple 
> of exceptions) but locks are directional. So one might want to indicate 
> that by using a short directional way. (But should the way point low to 
> high or high to low?) Or perhaps level tags either side of the lock, but 
> that could interact badly with bridges if this persisted along the 
> canal. (I'd expect the entire canal to have "level=-1" to make creating 
> bridges over it easier.) One might also consider "ele" either side, but 
> accurate data is hard to obtain with a GPS. Is there best practice in 
> this area?

Many sluices I know from France, Germany and Scotland have small tags
(or even carved stone) stating the height above sealevel or at least
their level-difference. You can then go and tag the nodes in the
waterway right next to the lock and give them ele-tags, according to
level-difference. If I understand this correctly is absolute height
(accuracy) of secondary importance.

> - Locks have a maximum width and length, universally measured in feet. 
> It should be possible to indicate what it is, presumably using maxlength 
> and maxwidth. Is there a danger of these being rendered with symbols 
> appropriate only for roads?

Speaking for my own: I don't see why this should cause interference with
roads. That must be a dumb routing-algorithm sending cars over canals
because of such a tag :-)
But please keep in mind that distances and height in OSM are generally
saved in meters, not in feet. If the british boaters are used to feet
the renderer would need to convert for their charts.

> - Sometimes you have a "staircase lock", where the exit of one is the 
> entrance of another. These need denoting.

The discussion in the locks-proposal are aware of that.

> - It is useful to denote the rise/fall of a lock (again, universally 
> measured in feet). There needs to be a tag for this. We could 
> appropriate "depth", but it's not actually the depth of the canal.

Is this the same as level-difference? I'm a landlubber...

> - waterway=aqueduct should surely be applicable to ways rather than nodes?

pheew... maybe that's to be discussed later

> - waterway=mooring should also be applicable to ways, so that the length 
> of the mooring can be seen. It should be possible to indicate what side 
> of the canal the mooring is on (perhaps by reference to the towpath 
> side?), and any conditions attached to mooring there (usually a maxstay, 
> measured in days, or perhaps a fee).
> 
> - Navigation on canals is done by means of bridge numbers. All bridges, 
> including those between two fields (and so with no associated road) have 
> a number. There needs to be a tag to associate a bridge number with the 
> short "bridge=yes" way.

We have the ref-tag to store all kinds of IDs. There are extensions like
int_ref, nat_ref and loc_ref or ncn_ref and so on to tell to which
network the id belongs. Mybe it would make sense to invent something
like canal_ref or some kind of abreviation.

> - Sometimes bridges which no longer exist (but you can see the remains) 
> have numbers. How could this be denoted?

Just set a node with the ref mentioned above. Maybe there will be a way
in the future to tag no-more-structures as well. There's already
historic=ruins...

> - Some bridges are swing bridges, which means they need to be moved out 
> of the way, by one of various means; these need notating. "bridge_type"?

This cries a new proposal :-)

> - All canals have towpaths. These paths are of varying quality, and this 
> information is useful to walkers and cyclists. The towpath can be on 
> either side. How should the towpath be denoted? As a separate way 
> parallel to the canal? What tags should be used? 
> ("highway=footway,bicycle=yes")? How should quality be denoted?

Tag them seperately! Depending on their condition and usage it could be
footway, bridleway, track or even residential. The tracktype-tag might
not be the best way to tag quality

> - There are several sorts of "waste disposal" on canals - rubbish 
> points, where bags of refuse can be left, and "sanitary stations" and 
> "pumpout" points, where different types of toilet can be emptied. 
> waterway=waste_disposal will not do for all three. (In fact, the 
> description - "A place to release used water e.g. for caravans" - fits 
> neither.) New tags are needed.
> 
> - Canals sometimes have narrow sections, perhaps where a bridge used to 
> be. These are useful to know about and for navigation. Are these best 
> denoted with maxwidth? All you really need is an on/off toggle for a 
> section.

If you make separate ways for each bank that should suffice. But maybe
an additional tag (which is generic enough to be also used on roads)
would be a good idea.

> - Tunnels often have rules about who can enter and when (e.g. transit 
> north beginning between :00 and :15; south between 30: and :45). We have 
> "hour_on" and "hour_off" - is that enough? How should such tags be 
> applied, given that the restrictions are different in each direction?

Defenitely something for the lower end of the wishlist.

> - Turning points ("winding holes") have a maximum length; this could be 
> done using "maxlength" on the node, but that's confusing, because if the 
> node is part of the canal, it implies that only boats below that length 
> can pass that part of the canal. Which is wrong. So how should this be 
> handled?

Same as for narrow sections.


> - There are "mile markers" along the canal which are useful for 
> navigation and as points of reference and interest.
> 
> And this is just a start :-)

Dito :-) I hope I could shed some light on your thoughts.

regards, Sven




More information about the talk mailing list