Proposal:Towpath (way)

Towpath
Proposal status:	Abandoned (inactive)
Proposed by:	Gerv
Tagging:	towpath=yes
Applies to:	way
Definition:	Indicates that a particular highway/footway etc. is the towpath for the adjacent canal.
Statistics:
Rendered as:	As whichever highway
Draft started:
Proposed on:	2008-02-03

Proposal

Most UK canals, and many canals in other countries, have towpaths. One could just have a way alongside which is otherwise unassociated, but it seems to make sense to indicate the towpath's status as such, so it can be unambiguously picked out for rendering on e.g. canal maps. This is particularly important where the towpath leaves the canal (e.g. for tunnels).

Tagging

towpath=yes on the towpath way (not the canal way).

Applies to ways

Rendering

As the normal footway/bridleway/cycleway, at layering level immediately above that of water, but below all other ways.

Discussion

• While my brain has no problems connecting a waterway=canal to a highway=whatever/towpath=yes printed right next to it on a map, I think a computer can't. It might be better to model this with a relation in stead of a tag on only the towpath. --Cartinus 01:00, 5 February 2008 (UTC)

• no, it's pretty simple. a slightly botchy way would be to change the rendering for a canal whenever towpath=yes is present. in that case, it draws it wider with a distinct path added to the side. not sure about routing though, lots of towpaths are used by walkers Myfanwy 02:30, 7 February 2008 (UTC)

• If the "no, it's pretty simple." is aimed at my "I think a computer can't." (There is no indentation, but I don't see what else above it can be relating to.) Then can you please explain why there is a proposal for a relation for dual carriageways so the rendering can be improved? If it was simple for computers to associate ways because they are relative close to each other without a relation being present, then the renderers would have already done that, I think. --Cartinus 23:04, 14 February 2008 (UTC)

• It's not much use just to draw a towpath as part of the canal if it doesn't correctly show which side of the canal it is on. --POHB 13:33, 15 February 2008 (UTC)

• Correction. Most canals *in the UK* have towpaths. (Even this I'm not sure about I don't live there). Please don't assume this applies to the rest of the world... Kleptog 11:30, 15 February 2008 (UTC)

• I have been using "towpath=left" or "towpath=right", which gives more information. The direction of a canal should be downstream and is needed to represent locks properly. Chrismorl 13:38, 15 February 2008 (UTC)

• I just noticed that this proposal is ambiguous, and maybe some of the comments above have misunderstood it. My apologies. The idea is to tag the way representing the towpath with "towpath=yes", not the canal. Clearly, IMO, the towpath needs its own separate way, because it needs to take e.g. surface quality information for walkers and cyclists. As for associating the towpath and the canal, if someone wants to propose a relation, that would be great. I'm not sure I understand them well enough to propose one. Gerv 09:45, 16 February 2008 (UTC)

• Having the towpath as a tag on the canal is analogous to roads having associated footpaths and cycletracks represented as tags. A country footway might be joined to a way with highway=primary, and it would be assumed that a walker would use the associated footpath (usually implicit) rather than the main carriageway. Similarly a cycleway could be joined to a canal that had a towpath tag. If there was also a surface or an ncn_ref tag, it would be obvious what they referred to. A pedant may prefer a towpath:surface tag.

Making a specialised canal map would be much easier if towpath information (and indeed bridge numbers) were associated with the canal. The combined canal/towpath structure is not currently rendered, and indeed is a bit of a challenge for Osmarender because making one-sided, parallel, displaced ways in SVG is not easy. But renderer difficulties should not govern the choice of an appropriate data structure, and I favour this representation.

It may be necessary for the towpath to be a separate way for really detailed mapping (and is currently done in some places, for instance between Edinburgh and Glasgow), but it is overkill for most of the British narrowboat canals. The extra nodes do not contribute new real information and drawing them is actually a bit of a pain. As mentioned, you would also need a (yet to be devised) relation between a towpath and its canal.

A third possibility is to have the towpath and the canal as separate ways sharing nodes. This might be tidier when they diverge and be easier to draw, but it would not render well and would still need a relation. It seems the least attractive option. Chrismorl 14:54, 18 February 2008 (UTC)

• I don't agree that having the towpath as a tag on the canal is like roads having cycleways as tags. The towpath can diverge from the canal (e.g. when the canal goes in a tunnel and the towpath goes over the top). How would you mark the towpath then? The canal and towpath are not a single structure. Also, the towpath crosses the canal, sometimes using a turnover bridge which requires very careful mapping to show the crossing correctly. A separate way is not "overkill", it's necessary. I don't think it's good to have the tags for the towpath and the tags for the canal sharing the same "space" on the same way. Only confusion can result. Gerv 18:50, 5 March 2008 (UTC)

These arguments apply just as well to cycleways and roads as to towpaths and canals. When the towpath has diverged from the canal it is not a towpath any more and obviously needs to be explicitly represented. But, for 95+% of the canal length, implicit representation is clear and efficient. (That this explicit/implicit dilemma is difficult to resolve can be seen from an example on OS Explorer maps; a cycleway on A5117 S of Ellesmere Port is explicit but on the Northwich bypass A556 the cycleways are implicit.) Prohibiting implicit towpaths on canals is similar to prohibiting implicit cycleways on roads. Chrismorl 10:34, 6 March 2008 (UTC)

Just like the existence of highway=cycleway doesn't prohibit the use of highway=whatever/cycleway=track, this proposal in it's current form doesn't prohibit someone to devise a tagging scheme for implicit representation of towpaths. IMHO it is better to keep the implicit and explicit tagging schemes in separate proposals. So just like I will never use highway=whatever/cycleway=track when mapping a Dutch city (You can't put enough information in that.), Gerv is free to only use this explicit tagging scheme for the canals he maps. --Cartinus 17:17, 6 March 2008 (UTC)

I agree it would be useful to have a relation to link the towpath and canal. If we had one, the towpath tag might possibly become redundant. Perhaps someone who understands relations better could comment. But we would still need the towpath as a separate way. Gerv 18:50, 5 March 2008 (UTC)

I don't see a need for this. Why not just tag it using Proposed features/Path or highway=footway? Maybe a proposal for a relationship of "towpath" between the path and the canal would be useful though.

Voting

...is not open yet.