Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support waterway=tidal_channel & retroactively waterway=stream over tidalflat #3865

Open
Roburetto opened this issue Sep 3, 2019 · 9 comments
Labels
new features Requests to render new features water-features

Comments

@Roburetto
Copy link

Expected behavior

In the recent past one was able to represent scenarios where a river or stream met the sea by excavating a channel, visible at low tide in the tidalflat bed, by using waterway=stream (which, as far as I recall, drew a line over wetland=tidalflat).

A recently approved proposal consecrated an even better solution for this, by using a new specifically dedicated tag: waterway=tidal_channel.

Reference:
Tag:waterway=tidal_channel
Proposed features/Tag:waterway=tidal channel

Actual behavior

Presently, neither work. waterway=stream is not drawn over wetland=tidalflat (only the label) and waterway=tidal_channel is ignored.

Links and screenshots illustrating the problem

https://www.openstreetmap.org/way/699646354

@jeisenbe jeisenbe added water-features new features Requests to render new features labels Sep 4, 2019
@jeisenbe jeisenbe added this to the Bugs and improvements milestone Sep 4, 2019
@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 4, 2019

@Roburetto, thank you for opening this issue. There are 2 issues here:

  1. Start rendering waterway=tidal_channel:

This is a new tag, and the first step would be to request support for it in the major editors like JOSM and iD, so that more mappers will start using the tag. Thank you for adding more features, and changing those that are inappropriately tagged as waterway=stream or =river to the correct tag.

EDIT: however see discussion below about this particular example; streams and rivers that continue into mud flats should usually stay as waterway=stream or waterway=river

I agree that it would be beneficial to render the name of tidal_channels, and to show a line rendering when narrow tidal channels are mapped over the land.

But as stated on the wiki page, ideally most tidal channels should be mapped outside of the coastline.

If the tidal channel passes through a wetland=tidalflat, it is recommended to map the sides of the channel as the end of the tidalflat area. This will currently render properly. For example, notice how the central channel of this tidal channel renders in solid blue, since it is excluded from the beach and wetland areas:

z17-ashburnham-wales-tidal-channel-mapping

z16-ashburnham-wales-tidal-channels-streams

  1. Line rendering of waterway=stream is no longer drawn over wetland=tidalflat (only the label)

This is the result of the changes in #3738 which changed the layers so that all marine water bodies are above landcover features and water lines like streams. This was intentional, because there were many cases where the coastline was not rendered properly previously.

As mentioned above, precisely mapping the edge of the wetland=tidalflat to the edges of the water at low tide is the best option. Generally the stream (or tidal channel) will still have contain water at low tide, so it ought to be excluded from the tidal flat area.

Unfortunately this is more work than just mapping the centerline of a stream, but it's a more accurate representation of the tidal flat as being limited to the area exposed at low tide.

@imagico
Copy link
Collaborator

imagico commented Sep 4, 2019

Note the linked to case (https://www.openstreetmap.org/way/699646354) is a great example of how this well meaning tagging idea is unfortunately quite likely to badly dilute the existing semantics of waterways by encouraging retagging the tidal section of any kind of waterway (stream, river, canal, drain, ...) into an undifferentiated umbrella tag.

We will need to watch this - so far this is not the dominating use and the tag is still new so it might develop in a way that avoids this. But it definitely would be a bad idea to render it in a way that gives positive feedback on the kind of abuse described above. Right now i see no option for rendering that would prevent that (other than through heavy pre-processing analysis of the data obviously).

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 5, 2019

The text of Tag:waterway=tidal_channel says that the tag should be reserved for features which are a "natural tidal waterway within the coastal marine environment with bi-directional flow of salty water which depends on the tides", thus excluding canals and ditches, and river estuaries are specifically excluded as well:

"These channels can be distinguished from rivers due to the higher salinity levels and because the flow of water away from the sea at high tide is equal to the flow of water towards the sea at low tide."

"In contrast to a river estuary, in a tidal channel the water flowing towards the sea at low tide is often slightly higher in salinity ... the flow of water towards the sea at low tide is not significantly greater than the flow away from the sea at high tide in a tidal channel."

I was going to "fix" the problem, but I'm not certain if there is a real problem with https://www.openstreetmap.org/way/699646354. It's hard to tell from just aerial imagery, without local knowledge, if this feature has any significant flow of fresh water. Looking at the aerial imagery, a 2 meter wide, 2 kilometer long stream "Rio Judeu" enters a wide shallow bay. At low tide the "stream" is almost entirely dry (or absorbed into the mud of the tidal flat).

Stream south of the bay (probably about 2 meters wide?)
high-zoom-rio-judeu-stream

This is in the northern (seaward) portion of the way, on ESRI, which is at lowest tide:

high-zoom-rio-judeu-ESRI-tidal-channel-section

Bing shows slightly higher water level, so now there's some water in the channel, probably seawater?:
high-zoom-rio-judeu-bing-tidal

And Maxar imagery shows the whole area covered in water at higher tide, with no visible flow:
high-zoom-rio-judeu-tidal-maxar-p

For features like this, I think it depends on the size of the stream which enters the tidal area. If there is a significant river, then it's clearly in estuary. But in this case, the bay is over 100 times wider than the stream, and so the flow of fresh water from the stream may not be noticeable after the first short section entering the bay.

z16-rio-judeu-tidal-channel

Perhaps the southern 100 meters of they way should have remained as waterway=stream, where it is still narrow and not covered by water at most high tides, but is that northern part distinguishable as a stream? I'm not sure if it's verifiably different than the surrounding tidal channels, like the big one to the northeast which has no stream inflow:

z16-baia-do-seixal

(Note very end of orange line representing way 699646354 on lower left, versus tidal channels on right side)

@Roburetto
Copy link
Author

After digging into the details, following your discussion, I must agree that the example given was probably hastened and does not fit well a waterway=tidal_channel.

“bi-directional flow of salty water” where “the flow of water away from the sea at high tide is equal to the flow of water towards the sea at low tide” seems to apply to a “closed circuit”, sort of speak, where water out is equal to water in, which is not the case. Water out is higher since it includes the additional flux of sweet water.

In short: yes, it’s probably better tagged as waterway=stream (the extension/part of a stream which, during low tide alone, becomes visible and exists on the tidal flat, where it digs a channel/depression).

Either way, it would be useful to have it shown/superimposed :)

@jragusa
Copy link
Contributor

jragusa commented Oct 16, 2019

“the flow of water away from the sea at high tide is equal to the flow of water towards the sea at low tide” is not necessarily true. Sometimes, the flow in one direction is stronger than the other. Moreover, a tidal channel is normally not connected to a river and mostly disappear in the tidal flat. But in some cases, water flow follows river channel during high tide such as tidal bore.

Finally, a tidal channel is potentially dry during low tide and should be drawn as an intermittent stream consequently.

@ZLima12
Copy link

ZLima12 commented Jul 22, 2024

I think the tag is now well enough established to be rendered.

  • JOSM added support in November 2019.
  • iD added support in January 2020.
  • Usage of the tag grew moderately from its inception to the beginning of 2024, and then rapidly accelerated, which continues to this day. (view page shown in photo here)

2024-07-22_141005

@imagico
Copy link
Collaborator

imagico commented Jul 22, 2024

Unfortunately this turned out nearly exactly as prediced above in #3865 (comment) - as an umbrella tag for the linear mapping of any and all bodies of water with some kind of tidal influence. There are areas where use locally follows a more narrow definition (like what the tag was originally intended for) but globally it does not.

<1000 of these have a name tag and many of those duplicate the name of a polygon or other linear feature. Like:

https://www.openstreetmap.org/way/934757176
https://www.openstreetmap.org/relation/6637159

https://www.openstreetmap.org/way/73534883
https://www.openstreetmap.org/relation/10560004

https://www.openstreetmap.org/way/1172325759
https://www.openstreetmap.org/relation/4209

A cross sections over the current range of applications of the tag:

https://www.openstreetmap.org/way/172665233
https://www.openstreetmap.org/way/1210005936
https://www.openstreetmap.org/way/726177946
https://www.openstreetmap.org/way/398545892
https://www.openstreetmap.org/way/394173648
https://www.openstreetmap.org/way/670139204
https://www.openstreetmap.org/way/1214950921
https://www.openstreetmap.org/way/1223967722
https://www.openstreetmap.org/way/1020371469
https://www.openstreetmap.org/way/86304971
https://www.openstreetmap.org/way/1251690563
https://www.openstreetmap.org/way/694437313

I do not currently see a way to provide constructive feedback on this spectrum of use, especially since it practically overlaps with consensus use of all of the major waterway tags (waterway=stream + tidal=yes alone has 20k uses - more than all of waterway=tidal_channel).

More significant for better mapper feedback in terms of tidal zone and waterbody mapping are IMO #3854, #3895 and #3896.

@Klaus-Tockloth
Copy link

A fundamental distinction should be made as to whether the tidal creek is on land or in the sea (e.g. mud flats) located. The negative arguments do not apply to objects located on land. In this respect these objects should be rendered.

Example:
https://www.openstreetmap.org/way/230964454#map=15/53.56585/6.72475

@imagico
Copy link
Collaborator

imagico commented Sep 16, 2024

The negative arguments do not apply to objects located on land.

That is not true, on the contrary: The presence of a waterway=tidal_channel land-side of the coastline is clear proof of the expansive use of the tag beyond its original purpose for any and all waterway=* with some form of tidal influence. This is not something we want (or or even can) reasonably support. It is clear consensus among mappers that waterways are differentiated by size and origin (artificial/natural) in the primary classification and the idea to suddenly stop doing that once there is some kind of tidal influence and flatten everything out then to a single primary tag - no matter if we are talking about the Amazon river or some nameless stream with a drainage basin of a few square kilometers - is not likely going to gain broad support. It is just going to devalue the existing data we have.

As said: what we really need is making progress on #3854, #3895 and #3896. This would give mappers more useful feedback on accurate mapping of waterbodies, in particular coastline placement (which is severely off in the sample area you showed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new features Requests to render new features water-features
Projects
None yet
Development

No branches or pull requests

6 participants