Sounds reasonably:

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

taginfo 719 on a way, 17 on a node.

The usage seems insufficient.

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

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.

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.

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

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.

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.

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?

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.

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.

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.

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?

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?

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?

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.

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 .

Marked as “de facto” in the wiki by @matkoniecz and now up to 1300 uses: https://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dfish_pass&curid=107799&diff=2083627&oldid=2060920

I've naively submitted #4388 to render this just like a stream for now, after noticing that my "de-facto" tagging wouldn't show up :)

Although I'm a total noob, using waterway=canal + usage=fish_pass seems very good for the connecting waterway, just the fish steps (-> not a canal) itself could maybe better be mapped with waterway=fish_pass.
What do you think?

I looked into the use of the tag a bit today and it seems this is quite clearly the dominant way to tag fish passes/fish ladders. Secondary tags for existing waterway features:

https://taginfo.openstreetmap.org/keys/fish_pass
https://taginfo.openstreetmap.org/tags/usage=fish_pass

have only insignificant use.

It seems the tag is quite consistently used - though only very sporadically outside of central and western Europe. The main variability in use is if the fish pass is mapped as component in the waterway network (i.e. connected to the waterway network so you could do 'routing for fishes') or if it is just drawn for the physical feature itself without connection to other waterways.

Examples:

https://www.openstreetmap.org/way/103152318
https://www.openstreetmap.org/way/763019340

In the former case there is also no clear consensus if the segments connecting the fish pass to the rest of the waterway network (without actually being a fish pass themselves) are tagged waterway=fish_pass or otherwise.