Openstreetmap-carto: waterway=fish_pass

[printmaps]

Fish ladders are currently not rendered. I recommend to draw them identically as waterway=stream.

[kocio-pl]

Sounds reasonably:

https://wiki.openstreetmap.org/wiki/Tag%3Awaterway%3Dfish_pass

[polarbearing]

taginfo 719 on a way, 17 on a node.

[pnorman]

The usage seems insufficient.

[kocio-pl]

What do you think would be sufficient usage in this case?

[pnorman]

There isn't a specific number. And if there were more usage, we'd still need to consider if it's desirable to render it, since usage alone doesn't mean we want to display it.

[kocio-pl]

It's best to know all such things beforehand to make deciding easier. I don't expect a number or hard limits, even general estimation would be helpful.

[dieterdreist]

2017-10-18 3:16 GMT+02:00 Paul Norman [e-mail]:

There isn't a specific number. And if there were more usage, we'd still
need to consider if it's desirable to render it, since usage alone doesn't
mean we want to display it.

these are (artificial) parts of natural waterways like rivers, I don't see
why we wouldn't want to render them. 700 seems already quite significant
usage for a relatively rare feature like this.

[printmaps]

Please consider that a fishpass divides the landscape and is the reason for bridges. Example (the small waterway is the fishpass):

[matthijsmelissen]

I dont think we should increase the amount of tags in the waterway namespace for such specialised purposes. That will make life difficult for every data consumer. Better something like waterway=canal (or ditch?), canal=fish_pass.

[dieterdreist]

2017-10-18 12:08 GMT+02:00 Matthijs Melissen [e-mail]:

I dont think we should increase the amount of tags in the waterway
namespace for such specialised purposes. That will make life difficult for
every data consumer. Better something like waterway=canal (or ditch?),
canal=fish_pass.

yes, waterway classification is a pity. For fish passes, none of the
established artificial waterway tags apply: canal (usually navigable)
doesn't seem appropriate (they're too small), neither are (by their
meaning) ditch (at least many are not ditches) or "drain" (nothing drained
here). You can always subtag the details, but the generic class should
contain the subclasses, otherwise this is tagging for the renderer.

[kocio-pl]

It's definitely not a canal:

Use waterway=canal for man-made waterways used for transportation or also for the largest waterways created for irrigation purposes.

It has also nothing to do with drainage system:

Use waterway=drain for minor artificial waterways, typically lined with concrete or similar, used to carry storm water or grey-discharge.

Use waterway=ditch for simple narrow artificial waterways used to drain nearby land, to remove storm-water or similar.

I agree that this would be tagging for rendering and we don't know how many of them are tagged this way already. Unfortunately waterway=* also contains other objects than just a water line (like dam or weir), so it's not easy for data consumer to pick just the water, but our database has no explicit "contains water" property.

[kocio-pl]

I dont think we should increase the amount of tags in the waterway namespace for such specialised purposes. That will make life difficult for every data consumer.

Honestly I don't understand - how would rendering already existing tag on osm-carto make problems for data consumer?

[SomeoneElseOSM]

Honestly I don't understand - how would rendering already existing tag on osm-carto make problems for data consumer?

I'm not sure I understand that either, but http://map.atownsend.org.uk/maps/map/map.html does render fish passes (in the UK and Ireland) so if there's a problem, someone should be able to find an example there.

[ZeiP]

The usage has grown and there are some places where the tagging has not been used because it's not rendered. In some cases the fish pass is separate from the main waterway, so in my opinion it's important to have the fish passes rendered, and I support the suggested rendering as a stream – this is also mostly used in the cases where the tagging has been done based on the rendering.

[jeisenbe]

There is some debate about this proposed tag on https://wiki.openstreetmap.org/wiki/Talk:Tag:waterway%3Dfish_pass - It would be good to discuss further whether waterway=fish_pass or waterway=canal + canal= or usage= =fish_pass is preferable. Note that waterway=canal is now used with usage=spillway on dams, a similar feature in some ways.

[gpsvisualizer]

Regardless of how the debate turns out on the OSM wiki, is there any reason NOT to simply render waterway=fish_pass as either a canal or stream?

[jeisenbe]

If there are a significant number of fish passes which are tagged with waterway=canal + usage=fish_pass then that would be a problem. At the moment this does not appear to be the case: https://taginfo.openstreetmap.org/search?q=usage%3Dfish_pass (16 uses)

If someone wants to submit a new PR showing a rendering for this feature, and tests how it works in a number of places, it would be welcomed. @gpsvisualizer would you be interested in doing this?

[gpsvisualizer]

I have no idea how to do "pull requests." I don't even understand what Git is, to be honest — and my brain is full enough already.

But I still don't understand why it'd be a problem if both schemes were rendered, regardless of how many tags exist out there. What's the harm?

[SomeoneElseOSM]

I have no idea how to do "pull requests."

Just in case you (or someone else) did want to do this, I wrote a diary entry a while ago that was designed to be a step-by-step guide to what would be required, with no prior knowledge of git or github: https://www.openstreetmap.org/user/SomeoneElse/diary/43041 . I'm sure other guides are available too.

[sun-geo]

Small update, the current count of waterway=fish_pass osm-items crosses the 1k line, see

^{https://ohsome.org/apps/dashboard}

The hack for displaying fish passes would be, while having the 1d waterway=fish_pass tag by additional adding a 2d water area e.g. using a tagging like natural=water + water=fish_pass ;-)

See examples here .