Please render waterway=floating_barrier

[BertMule]

As discussed here. Why doesn't my floating_barrier get rendered?

[imagico]

Thanks for the suggestion. Tag has 360 uses so far, almost exclusively on linear ways, use it mostly limited to a few localized concentrations by individual mappers.

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfloating_barrier https://taginfo.openstreetmap.org/tags/waterway=floating_barrier

[BertMule]

365.

Just added quite a few, not counted yet.

I really hope they will become rendered. Some line would suffice, of course.

Then also some more inappropriate tags can be converted.

[matkoniecz]

Below 400 uses for this kind of feature is too low to even consider rendering on general purpose map.

I would try first to try with dedicated rendering focused on topic such as https://github.com/OpenSeaMap

[BertMule]

Please note this is not so much about boating and navigation, but for recreational swimming in the first place.

I consider that pretty 'general purpose'.

Also note that once this does get rendered and discovered by mappers, the applied number will typically grow.

Question of the chicken and the egg.

[jidanni]

Now that floating barriers are in the headlines many days in a row. I think it's high time that they get rendered. (Rio Grande River, https://en.wikipedia.org/wiki/Operation_Lone_Star)

Also they are very important at many swimming bays, to keep people in the safe area, like guardrails on the side of highways, which do get rendered.

Yes they don't exactly stay in the same spot, but are still anchored, like trees that wave in the wind, which also get rendered.

[BertMule]

Current usage: 690.

I keep adding them when present at a swimming_area. Hoping they eventually become rendered.

If not, I need to replace them. It's pointless to have valid objects that are not rendered.

Often the discussion resulting in yet another not to, is longer than implementing a very simple rendering.

[imagico]

I am reopening this because use has widened since 2022, not so much in bare numbers (these are still low) but in geographic scope and in number of mappers actively using it.

The tag is well defined and used consistently according to that definition and there is little risk of there being counterproductive incentives from rendering it. Since it is exclusively used over water there is little risk that rendering it would seriously affect readability of other (land based) map features.

Personally i would be moderately in favor of adding this if a suitable design can be found (main constraints being existing waterway=weir and solid barrier signatures) but given the low volume of use this does not have priority and i perfectly understand if others see this more critically.

Design wise also related is #1774.

[danieldegroot2]

Example rendering with a row of empty circles (rings) :o: with same style as waterway=weir. (similar to row of barrier=bollard nodes, smaller than current natural=spring.); or, a lighter version of the base icon for buoys in openseamap. Similar to entrance nodes they could get a slight fill but this is unlikely to work.

(when made too small or too thin outline, they become invisible to the eye. or, in case of raster, look blurry.)

For delimiting areas openseamap uses T-shapes. ( from https://openseamap.org/ )

Example rendering

others, i.e. adjacent half-circles, line broken up with half-circles, waves (snake) are unlikely to work. Dots, dashes(, slashes, or rotated H-shape) may be confused for weir or administrative boundary.

Design-wise, this is further related to #1908, #1753. See also #4679. Keep in mind rendering of swimming areas: https://github.com/gravitystorm/openstreetmap-carto/issues/4976#issuecomment-2145212019