Talk:Tag:waterway=canal

Discuss Tag:waterway=canal here:

---

Lock gates

How are we tagging lock gates then? waterway=lock_gate is already on map features. So the mention of other suggestions here (man_made=lock, lock=*, lock:name=*) is confusing. If waterway=lock_gate is the accepted way to do it, then we'll need to specify whether it's a single node or a length of way which was otherwise canal. (Should have these details on the Tag:waterway=lock_gate page) -- Harry Wood 12:46, 6 May 2008 (UTC)

I tag locks (on small, UK-style waterways) as nodes with lock=yes. A lock de facto has gates at each end, it wouldn't work very well otherwise. --Richard 14:51, 6 May 2008 (UTC)

I've been tagging locks as a short segment of waterway=lock with a node tagged as waterway=lock_gate at each end. The name and number of the lock go on the name= tag for the lock section. Seems to render nicely e.g. http://www.openstreetmap.org/?lat=53.709395&lon=-1.905365&zoom=18&layers=B0FT

--POHB 08:13, 7 May 2008 (UTC)

hmmm. Two different ways of doing it then. -- Harry Wood 16:20, 7 May 2008 (UTC)

Areas

Width

Can a width tag be applied to a canal? I'm asking because an irrigation canal that is about three meters wide is being rendered the same width as a two-lane road. — Val42 05:00, 4 October 2008 (UTC)

Width (in metres) can be added to denote the average width of a canal: width=3 in your case.

maxwidth=* can be used to define the maximum beam of boats able to use the canal which will be determined by pinch points such as aqueducts, bridges and locks. For a canal it probably makes sense to apply it to the whole length given that boats won't be able to travel from end to end because of the beam restrictions. On a navigable river with locks however, it is probably more logical to only apply it to nodes or short sections where there is a width restriction, i.e. a lock channel.

Usage

I'm not clear about usage how and for what. We've a canal (Rhine–Main–Danube Canal) here which is about 55 metres wide. But it's narrower e.g. when bridging over streets or before locks and has dents on some places. So it's not possible to get that width and shape right with a line taged as waterway=canal. Also it has tracks attached to both sides which should be done right.

It looks good as poligon tagged as natural=water or waterway=riverbank but that's semantically wrong. So what to do here? I've seen such canals done as a polygone tagged as waterway=riverbank and a path in the middle tagged as waterway=canal. Is that a standard and state of the art?

And what is waterway=canal really for then? --Miriat 15:15, 19 November 2008 (UTC)

I'm also wondering how to tag canal polygons, some experiments here: Talk:Key:water#Prevalence.

"waterway=canal is very common for ways, but there doesn't seem to be much guidance at all about area features. One might argue that waterway=*, highway=*, aeroway=* etc. are all reserved for way features only, not areas, but then we have waterway=riverbank which is already violating that. So maybe waterway=canal is ok for areas after all?" (and let the feature type decide the rendering rules, routing ability, and Xapi extracts) :-/

--Hamish 27 August 2012

I've seen a lot of canals done as the "most relevant" area type (either river lake or an extension of the coastline into the inland area) and a way down the middle tagged as e.g. Manchester Ship Canal. This allows for more complex geometries which many need (esp with branching canals) but does seem a little kludge (can you really call the edges a large branching canal coastline? It's tidal so surely you can't call it a lake and there's no flow so it isn't a river). Coastal areas also have the added disadvantage of only updating on a glacial timescale. --InsertUser 22:02, 30 August 2012 (BST)

Direction of flow

I am not sure about all channels, but many of them don't have direction of flow. It there is any tag, showing the direction of flow or its absense? If no, what about flow_direction=forward/backward/no? Dinamik (talk) 06:49, 2 October 2013 (UTC)

Well we do have a convention for rivers Tag:waterway=river#Direction of flow which is to always point the way arrows in the direction of flow (or put a FIXME tag if we don't know for some reason) It's usually easy to figure out the direction of flow of a river just by looking at what it must be flowing into, but for canals it's not so easy of course. So yeah it would make sense to have an explicit tag indicating that a mapper has thought about it (while all other canals you would assume the way direction is irrelevant). flow_direction=forward makes sense to me, but I'm not a big canal mapper. What do the experts think? -- Harry Wood (talk) 11:29, 4 October 2013 (UTC)

If there are no objections, I add description of flow_direction=forward/backward/no. Also I think, that flow_direction=unknown, perhaps, have sense. Dinamik (talk) 10:03, 16 June 2014 (UTC)

For a valid description we need something likeː

flow_directionːfrom=[source] 
flow_directionːvertex=[###,##m Scheitelhöhe]
flow_directionːto=[target]

Where "source" and "target" may be the name of an oher waterway.
For canals going upwards to a "vertex" from both sides, the canel has to be split at the vertex.

All tries by referencing the OSM-way-direction will be misunderstandable I guess.
What do you think? --Markus (talk) 05:55, 2 September 2015 (UTC)

Service tags

I don't recall seeing any discussion about service=* tags being used to describe canals, and there are no comments about the edit nor any more specific documentation. I have some concerns about this. First, terminology: "hydropower" is apparently a more common term than "water power" (and it wouldn't require an underscore). Second, the proposed selection of services omits some common usages such as potable water (or water being conveyed into a treatment plant where it shall be made potable). Third, the tagging of multipurpose canals is not addressed. T99 (talk) 01:06, 27 December 2013 (UTC)

River vs Canal for canalised rivers?

Does anyone have any ideas on the official or preferred tagging for rivers that have been canalised? Usually these canals follow the course of the river, albeit straightened, and most/all of the river's flow now goes down the new course. There is/was boat traffic on the new course (and often was not possible on the old natural course), however the waterway is still known as a river (or sometimes called the New River X).

Road accompanying the canal

How to map the road accompanying the canal (in Germany traditionally called "Leinpfad" or in older times "Treidelpfad"). These are private roads owned by the authority running the canal, marked as "Private Property". Public traffic is prohibited, but pedestrians and cyclists usually are allowed. Some people tag them as highway=cycleway, but actually they are more frequently used by pedestrians and formally they are private. IMHO highway=service / access=private / foot=yes / bicycle=yes would fit best. I feel there should be a recommendation on the main page. --GerdHH (talk) 10:27, 4 October 2017 (UTC)

size and canals

if we distinguish waterways only by function in this case (not drainage), it would mean our tagging system is pretty weird: we would use waterway=canal for every artificial waterway not for draining, like bringing water for irrigation, energy production, cooling, transportation. And we would have one class only, no rough but useful distinction like “can you jump over it?”, as we have for the 2 classes of artificial draining waterways. Looking at the current usage, wiki pictures and rendering rules, canals seem to have a minimum width, but there is no mention about this in the wiki. —Dieterdreist (talk) 13:23, 13 October 2018 (UTC)

It's true that canal regards artifical waterways intended to bring useful water somewhere only. width=* (or riverbank area) can be used to give the crossability by human, can't you?

ditch should be abandonned in favor of drain but this wans't in the scope of last proposal for hydropower waterways. Fanfouer (talk) 13:49, 13 October 2018 (UTC)

We have had this discussion on the tagging ML recently - no need to repeat that here. If you want to tag the size of a canal you can do so with a verifiable tag like width=*. If you want to introduce a minimum width for waterway=canal you would (a) have to review all existing >300k waterway=canal for compliance with this threshold and (b) would need to invent a new small canal tag which is distinguished from waterway=canal only by an arbitrary width cutoff and we can see with stream/river how well this works. The only reason you maybe would want that is if you want the width criterion only as a pretend verifiability but in fact want to use this as an arbitrary importance tag for artificial waterways. --Imagico (talk) 14:00, 13 October 2018 (UTC)

It must not be arbitrary, we could decide to use a different tag for navigable canals set up for the transportation of goods, this would clearly distinguish them from a 20cm irrigation canal. Being able to jump over it is also not arbitrary and is a very useful bit of information for pedestrians. For canal systems it could also be interesting to see if it is „the last mile“, i.e. a canal not leading to smaller canals. —Dieterdreist (talk) 14:30, 13 October 2018 (UTC)

As navigable canal and transportation canal is 2 words length, it mixes 2 concepts in both situations and have 1 in common. Then tagging would be better with waterway=canal + usage=transportation. We should stop to merge concepts in one single value, because it restrict its use cases in whole OSM knowledge.

We're all agree on the information usefulness, but each information or each concept should go in a separate key or value. Then width=* is the most appropriate to give width and usage=* to say what the canal is intended for. Fanfouer (talk) 14:53, 13 October 2018 (UTC)

I agree that width is an important property, but what I wanted to express is that different size may also lead to different quality. In a big canal you can drown, it is a significant barrier, a 20cm canal is not a barrier to pedestrians and you will not drown. Should we map 2 m high towers as man_made=tower, if the shape satisfies the definition? We could add height=7cubits to it for distinction. Does this sound reasonable? If not, why would we do it for waterways? Would it seem right to tag an intermittent drain along every kerb? Looks as if it satisfies the wiki definition;-) —Dieterdreist (talk) 15:48, 13 October 2018 (UTC)

Yes its is reasonable to use tag when the feature matches the definition. Giving as many information as we get on a particular object, like width and height is useful. Grouping several concept in one key/value doesn't improve data quality at all. Ok to add intermittent drain along kerbs if and only if it occurs water to flow along the kerb, which may not be mandatory depending of the place. Fanfouer (talk) 18:01, 13 October 2018 (UTC)

Completely agree with Fanfouer here - should focus on individually observable and well separable properties - not some kind of classification based on compound criteria. The stream/river distinction is of very limited usefulness - as a data user you can not rely on this and typically always have to consider both streams and rivers. Duplicating this scheme to canals would be pretty useless and would distract from the more meaningful properties like width and usage. Navigability is not very well defined by the way - is usability for a kayak something that qualifies for navigability? usage=transportation is more meaningful here. --Imagico (talk) 19:00, 13 October 2018 (UTC)

I will start retagging every waterway to canal that is neither used for draining nor is it of natural origin. Width is easily measurable when it doesn’t vary much, but it is not the only relevant criterion and may be quite misleading if it is the only parameter that is mapped. Speed of the flow and depth / quantity of water per time are similarly relevant but are much harder to survey and may vary a lot within the same section of waterway. Without these, the picture will remain pretty incomplete. —Dieterdreist (talk) 20:51, 13 October 2018 (UTC)

water for cooling purposes

What about waterways that are built for the transport of water for cooling? Currently these aren’t included in any of the waterway definitions, at least not the way from a river to the facility (because one could argue the return from the facility to the river is a drain).—Dieterdreist (talk) 20:58, 13 October 2018 (UTC)

Rendering of canals

I don't like the way the canals are rendered with very wide lines even when the widths of the canals are explicitly given as only a meter or so.

This is especially bothersome in some foothill areas where narrow irrigation canals go sideways across every other hillside. The rendered canals are dwarfing the natural rivers and creeks at the bottom of the valleys.

-- T99 (talk) 16:36, 28 May 2019 (UTC)

Should you mention it on https://github.com/gravitystorm/openstreetmap-carto/issues instead? Wiki isn't responsible of how feature are render on a particular render Fanfouer (talk) 10:56, 29 May 2019 (UTC)

Please report rendering issues in this particular style at https://github.com/gravitystorm/openstreetmap-carto/issues - reporting issues elsewhere is not recommended (though, as usual, please check whatever there is already issue for given problem - maybe problem is known and it waits for someone to implement a solution). Though are you sure that tagging is actually good? I am surprised that "meter or so" wide canal exists (note that not everything named "XYZ canal" should be tagged waterway=canal) Mateusz Konieczny (talk) 16:52, 29 May 2019 (UTC)

Tag canal=*

There seems to be a new canal=* with a number of suggested uses. Once it's mature enough it probably needs to be linked from here. Not sure in what way... --JoeG (talk) 23:22, 18 June 2020 (UTC)

I think this tag shouldn't be confused with usage=* Fanfouer (talk) 21:26, 20 June 2020 (UTC)

Boat?

What if the canal is just wide enough for a gondola but not for the big oars of a rowboat? -- T99 (talk) 07:09, 21 June 2020 (UTC)

You can use width=*. There is also an access tag for canoes (which seems to include kayaks and similar narrow paddled vessels) canoe=* - most likely this is relevant for Italian-style gondolas too? --Jeisenbe (talk) 19:48, 22 June 2020 (UTC)

interrupted canal

How should a disused, interrupted canal be mapped, where sections no longer exist (e.g. built over with roads and buildings)?

Is everything still in one relation or a separate relation for each section that still exists?

Does the waterway have to be continuous in the waterway relation?

If so, how should the sections that no longer exist be mapped and tagged, especially if the course can no longer be traced exactly? --Heiko aus Fürth (talk) 07:23, 29 September 2024 (UTC)

If it still exists but no water inside, disused:waterway=canal is appropriate and removed from the waterway relation.

If it no longer exists and have been destroyed it shouldn't be in OSM anymore. Fanfouer (talk) 07:38, 30 September 2024 (UTC)