-
Notifications
You must be signed in to change notification settings - Fork 819
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
Comments
@Roburetto, thank you for opening this issue. There are 2 issues here:
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 EDIT: however see discussion below about this particular example; streams and rivers that continue into mud flats should usually stay as I agree that it would be beneficial to render the 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
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 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. |
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). |
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?) This is in the northern (seaward) portion of the way, on ESRI, which is at lowest tide: Bing shows slightly higher water level, so now there's some water in the channel, probably seawater?: And Maxar imagery shows the whole area covered in water at higher tide, with no visible flow: 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. Perhaps the southern 100 meters of they way should have remained as (Note very end of orange line representing way 699646354 on lower left, versus tidal channels on right side) |
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 :) |
“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. |
I think the tag is now well enough established to be rendered.
|
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/way/73534883 https://www.openstreetmap.org/way/1172325759 A cross sections over the current range of applications of the tag: https://www.openstreetmap.org/way/172665233 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 ( More significant for better mapper feedback in terms of tidal zone and waterbody mapping are IMO #3854, #3895 and #3896. |
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: |
That is not true, on the contrary: The presence of a 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). |
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
The text was updated successfully, but these errors were encountered: