Hi all,
>François >I'd add that waterway=canal is really often supported by an artificial >structure and use it to cross a lake as a logical connection between entry >points is awkward. I fully agree that it is not ideal, but in the current situation it is the lesser of all evils. And please note that I am not proposing a new way of tagging, I am just pointing out the current mapping practice in The Netherlands (which is full of navigable waterways with canals changing into lakes or something in between and back again and where the distinction between natural and man_made is theoretical at best) and some other countries I have seen. I came across the undocumented tag waterway=lake by accident. Personally I like that much better than waterway=canal on a lake, but as long as that tag is not widely accepted by data users I thing it really should not be used as a replacement where waterway=canal is currently being used. However, if someone feels so strongly about the negative aspects of the current use of waterway=canal and starts a formal proposal, please let me know, I would be happy to support that. >Why simpler waterway=stream or waterway=river aren't suitable for routing purposes? I fully agree that waterway=river would be much better than waterway=canal in a situation where one more rivers (described in waterway=river as as “linear flow larger natural waterways” ) run into a lake and out again, I think / hope that that is not disputed. My mentioning of using waterway=canal was meant for situations with either isolated lakes (because of the portages I understood the Alaskan example as such) or lakes in a watersystem without linear flow, such as a boezem (separated from and often lower than the open water/sea, to which it is pumped up, the direction (north/south/west being dependent on the pumping station being used). Waterway=stream would be appropriate for a linear flow connection between two lakes if it is so narrow that (according to the wiki) can be jumped across. Waterways so narrow are normally not navigable even for canoes (some specialized/limited whitewater canoes excluded, but you won’t be navigating that acroos a lake). Putting waterway=stream across a lake would suggest that the lake passage is also narrow enough to jump across and not navigable, so there I would suggest waterway=river nstead of stream for the part across the lake. >Volker Schmidt > For the canoe routes, which started the canoe side of this discussion, I > would say that the in-water ways should be tagged as route=canoe without > problems and in concordance with the wiki for the route key "route=x". I pointed out several problems with the use of route=x in my previous post (see below). These problems seem to be a lot bigger than the problem with waterway=canal. Furthermore, using route=x with a value that is similar with an transport mode (as described on https://wiki.openstreetmap.org/wiki/Key:access ) is NOT in concordance with the wiki, for instance see: https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot https://wiki.openstreetmap.org/wiki/Tag:route%3Dbicycle https://wiki.openstreetmap.org/wiki/Tag:route%3Dhorse The wiki states in all these cases that route=foot / bicycle/ horse should be used on relations and NOT on ways. And this is for good reasons as I mentioned earlier, because route=foot an a way would have a really different meaning than the same tag on a relation You will the same for route=canoe, but that is just because I copied the template for route=horse > I could go along with the extension of the definition of waterway=canal to > cover also navigation channels in larger bodies of water, if this solution > is accepted as a result of voting process on a formal proposal. Personally > I prefer a new tag for nautical or navigation channels. I agree that a new tag (waterway=lake seems fine to me) would be better, but until that is formally proposed and widely accepted by data users I see no advantage in banning current practice which is also in concordance with the wiki for instance waterway=fairway (fairway on a lake is added as an addition to waterway=canal/river ) > BTW, the quoted 1800 uses of canal=x are nearly all "canal=fixme", so to > say that "canal=x" is an established way of tagging is misleading. You are right, I saw that after writing my post, apologies. Nevertheless other values are also used and in doesn’t hurt to have a key that specifies a tag wich already (besides this discussion) has multiple uses in the wiki (“transportation, hydro-power generation or irrigation purposes”) >> *Linear elements in the lake / lagoon etc* > >> > >> For the linear elements across the lake route=ferry would be very > >> misleading; as I hiker I would expect a boat there to bring me to the > other > >> shore (like the nice 3 rowing boat-system in the Scandinavian artic). > >> > >> Route=canoe seems better when you just look at the wiki definition, but > >> in actual use it doesn’t work out that well. First it is actually mainly > >> used as an addition to highway/waterway tags instead of as an > alternative. > >> > >> Besides that, using route=* instead of a waterway-tag would have making > >> routers look at different keys for the needed routing information , > instead > >> of the different values within the waterway-key. > >> > >> Furthermore using route=* for these cases near waterway=* makes life for > >> tagging and data consumers unnecessarily difficult with multiple values > in > >> the same key, for instance when you want to tag that a route=* is for > canoe > >> and motorboat, but not for sailboat (which is easy on a waterway with a > >> separate access-key for each category). > >> > >> And besides it is confusing between routes on relations (only to be used > >> when the route is physically signposted/marked) and on ways (to be used > >> when the way itself is not visible). > >> > >> *which waterway-value?* > >> > >> Although it might not be perfect when you look of the normal definition, > >> the common practice is that such routable linear elements across bodies > of > >> water are either [waterway=river] or[waterway= canal], depending on the > >> situation (there are a lot of them in The Netherlands and also elsewhere > >> where routable networks are made). > >> > >> This common use is also illustrated in the Wiki for signposted routes [ > >> waterway=fairway] is an _addition_ to waterway=canal in a lake or a > sea > >> and not a replacement: > >> > >> “Use waterway=fairway for the artificially created navigable route > marked > >> by buoys in large waterbodies like a lake or a sea. Do not use it as a > >> replacement for waterway=river or waterway=canal.” > >> > >> And furthermore in a lot of situations the difference between natural > and > >> man_made is really not that clear-cut (nowadays even the top few meters > of > >> the seawater could be argued to be man-made by out CO2-emissions :-) > >> > >> When setting something form the ground up we would probably use a third > >> tag that indicates such navigable, but more abstract waterways, but > >> changing that now would mess up a lot of routing applications and/or a > >> massive retagging and need for changes in applications. > >> > >> But since the current use of the waterway=canal-tag doesn’t really hurt > >> anyone, that seems more like creating a problem than solving one to me. > >> > >> But on the other hand I can imagine the wish to be able to distinguish > >> between actual canals as you normally would imagine them (within a > >> natural=water / water=canal) and these [waterway=canal] linear elements > >> across bodies of water that are themselves not canals. > >> > >> For that purpose I just created a wiki page for the key canal=* (a tag > in > >> addition to waterway=canal). > >> > >> If a value is added for the type of canal (virtual? ; navigation?) those > >> who wish to do so can distinguish the different types without messing up > >> current routing applications by using another key instead of [waterway] > or > >> a value for [waterway] that is not recognised as being routable for > boats / > >> canoes. The key was already been used more than 1.800 times before the > >> wiki was made, so there seems to be a market for it. > >> > >> Hope this can work for all of us. > >> Cheers. >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
