Beaches overlapping water too similar to water

[georgek]

Many beaches in the British Isles, and probably around the world, are only accessible at certain states of the tide. At high tides these beaches can be partially or wholly covered with water. There are numerous examples of this but, nevertheless, they are used as beaches, called beaches and are beaches.

Notable examples in England:

• Hunstanton. Seaside holiday town. Beach is wholly covered with water at high tide.
• Brighton. Seaside holiday town. Sandy beach is revealed only at low tide.

Expected behavior

1. Users can easily see the beach and its surface properties,
2. Users can tell which parts of the beach are available only at low tides.

Actual behavior

Tidal areas of the beach essentially look like water.

Links and screenshots illustrating the problem

Recently #3738 was merged which attempts to address expected behaviour 2, above, but, in my opinion does so at the cost of expected behaviour 1.

Before #3738

Beach is clearly shown with surface properties.

After #3738

(In this first example note also how different the new tidal beach rendering is to a tidal flat, this looks very strange).

Alternative behaviour

The intent of #3738 is good. We should clearly show intertidal regions. But the current solution is a regression. There are better ways to show this without compromising what we had before. Ordnance Survey show the above region like this:

They use a thick blue line for mean high water spring and a thin blue line for mean low water spring. This is a very good alternative.

We can't do this at the moment because we don't properly store MHWS or MLWS in OSM (you can't just render a line over natural=coastline for MHWS). I am planning a proposal to properly record MHWS, MLWS and other tidal water levels in OSM.

Another alternative is simply to make the difference more subtle. Somehow show that it's tidal, but still make it clear that it's a beach. This was made by using the "tidal=yes" tag:

(Note I'm also rendering natural=coastline as MHWS, which doesn't really work in general).

[imagico]

I changed the title to reflect the specific issue you describe.

I am not sure i agree in terms of design but this will require a broader look at beaches in various settings when this change is rolled out.

There are some constraints on what styling is possible using overlays and comp-ops so specific design ideas would need to come with a workable implementation.

[imagico]

For understanding your specific example and since i don't know this area personally - why is Stubborn Sand tagged natural=beach and Ferrier Sand wetland=tidalflat?

https://www.openstreetmap.org/relation/9745513 https://www.openstreetmap.org/relation/9745485

https://mc.bbbike.org/mc/?lon=0.439425&lat=52.888078&zoom=14&num=3&mt0=bing-satellite&mt1=mapnik&mt2=mapbox-satellite

Considering the latter is indicated to be from an external data set - might that be faulty attribute conversion during an import? OS maps tend to distinguish between 'Mud' and 'Sand', not between beach and tidalflat:

https://www.ordnancesurvey.co.uk/docs/legends/25k-raster-legend.pdf

[georgek]

Snettisham Scalp is a beach, notice the nearby Beach Road: https://www.openstreetmap.org/way/66609586

Ferrier Sand is separated by a creek (tidal inlet) and there is no beach that I'm aware of. Instead the higher parts of the tidal area are salt marshes and mostly inaccessible.

Drawing the line between a beach and a tidal flat has to be done somewhere. Intuitively one could say a beach is somewhere you can reasonably walk and play while a tidal flat is essentially a danger zone where you can't walk. That is correctly reflected in the current mapping of this area to the best of my knowledge.

[imagico]

I was looking for a locally observable difference.

The suitability for walking is mostly a matter of how fine grained the material is. This is limited for beaches to coarser types by physical constraints (fine grained silt or clay does not form beaches since it would get carried away by the water under wave dominated conditions). But this is not a matter of beach vs. tidalflat but one of sand vs. mud.

Anyway - this was just a question about the specific example asked out of curiosity. The matter of contrasts and readability of the rendering is not tied to this specific situation.

[jragusa]

A tidal flat is almost wet while a beach a dry. Water infiltrates in between grains whatever their grain-size (gravel or sand) in a beach which is not possible in a tidal flat because of the dominant mud drapping. Moreover, you can identify channels in tidal flat. Tides follow these channels to expand and to pull out.

[georgek]

I would like to be clear that I'm not taking issue with the way tidal flats look. Making the distinction between tidal flat and beach is a mapping issue, not a rendering issue. For me tidal flats look fine currently.

My issue is only concerning beaches and specifically beaches which exist in the intertidal zone. These beaches are common, they are not tidal flats, but they currently look like water.

[jeisenbe]

As mentioned in #3854, it would be possible to use a different color fill for areas of natural=beach which are outside the coastline, if we change the way the layers work; see #3854 for details.

We could also do this with other features that are found in the intertidal zone, eg. wetland=mangrove, wetland=saltmarsh, natural=bare_rock, natural=reef, natural=shoal, perhaps using a similar shade of darker browish-blue like the current tidalflat rendering over water. Or we could create different fill colors for certain features, eg. darker blue-green for mangroves over water, lighter blue=green for saltmarsh over water.

Since this wouldn't require extra work by mappers splitting areas and adding tidal=yes, It would be a significant advantage.

[jeisenbe]

I noticed that the intertidal areas is rendered as a darker, grayish-blue color on Norwegian topo maps; this is somewhat similar to the current tidalflat fill that we use over water.

There is also a similar rendering on Australian maps for shoal/reef/tidal shelf:

Australian maps use brown dots for the foreshore, similar to our current rendering (and blue dots for saline flats above the MHWS line):

USGS topo maps normally show "foreshore flats" as dotted areas, or with a line and "mud" on hand-drawn older maps. Coral and rock reefs had their own rendering, just black lines over standard light blue water:

But there are special USGS maps that show Bathymetric lines (for sea navigation), and these show the foreshore with a brown fill color:

Old OS maps in Britain used to show the foreshore areas with black dots and similar, over the standard blue ocean color. This legend is from the 1945-1948 series "New Popular Edition": (Oh, and there's another natural=dune rendering, "sand hills")

But the Popular Edition (1919-1926) and the current Landranger maps show the foreshore in solid colors mainly (except for rocks and shingle, which are in white):

So I understand why @georgek expects the foreshore, especially beaches, to be rendered more like the land color, but this is not necessarily the most common practice around the world.

I like the look of the Norwegian or Australian map, using a darker and less saturated blue color, and it would match with our current tidalflat rendering. This could be achieved by the use of transparency, but ideally we could implement the ideas in #3854 for better flexibility.

[georgek]

I think the main reason to render sand with a colour is to be able to distinguish it from mud. The current tidalflat rendering does not actually distinguish between sand and mud at all.

Here's an area which has a beach and tidal flats (a very large area of mud is revealed at low tide and it's very dangerous):

It would certainly be an improvement to make the "tidal beach" closer to the tidal flat, but would it be clear that one part is sand and one part is mud?

For comparison, OS shows it like this:

[jeisenbe]

@imagico has shown this rendering sample from a similar map style which he has created, called "alt-colors".

In it there are now different renderings for wetland=tidalflat with surface=sand; see the second column with "tidalflat" above "mud" and "sand"; there is a pattern for surface=sand under water (outside of the coastline) too:

This would require making the changes suggested in #3854, so it will take a couple of months, and that depends on if everyone things it's worth the extra complexity.

[Bibi56]

My issue is only concerning beaches and specifically beaches which exist in the intertidal zone. These beaches are common, they are not tidal flats, but they currently look like water.

Same here. But not only beaches declared as such in OSM. natural=sand, natural=gravel with tidal=yes, in fact any feature on the sea side should still be rendered. Note that @imagico changed the definition of a beach on the wiki but many beaches are described the "old" way with beach on shore side and sand (or gravel) on the sea side. They vanished on the sea side.

So I understand why @georgek expects the foreshore, especially beaches, to be rendered more like the land color, but this is not necessarily the most common practice around the world.

At least similar in France. I guess everywhere the tide is non negligible, as the coastline is defined using high tide, people except to see beaches, sand, mud on the sea side. At least I would say up to the 0 m level (as defined on shore).

Due to an error in the coastline we can see on the same map how it was looking (inside the mouth of the Laïta) and how it's looking now (at open sea):

How it looks: https://www.openstreetmap.org/#map=16/47.7667/-3.5274

How it looks on OpenStreetMap France (based on an older version of this style). It looks way better.

How it looks on an official portal (IGN).

And last an aerial view (IGN).

Note: as the sand is moving quite fast, it's normal that the shape on the various aerial imagery and on maps. But OSM France and OSM share the same data.

So as seen on IGN map a possibility is to ignore the coast line for features: such display them, add the 0 m isoline (from a DTM).

Another possibility is to use tidal=yes to add an almost transparent blue on those features: sand below low tide wouldn't be rendered.

Note : beaches are still rendered on the new map, sand is not. It doesn't make much sense to me. A sandy place starting from the shore is a beach, isn't it?

[imagico]

Note everyone is welcome to suggest a solution for this issue. The technical basis for this is explained in #3854. It should preferably also work in combination with #4128

A number of things to consider that will most likely be essential for support::

• the land-water distinction should be the primary visual distinction (see https://github.com/gravitystorm/openstreetmap-carto/issues/3864#issuecomment-527406501)
• no use of transparency (see https://github.com/gravitystorm/openstreetmap-carto/issues/3864#issuecomment-527407931)
• no dedicated support for use of natural=sand outside the coastline as an umbrella tag for natural=reef/natural=shoal/natural=beach/wetland=tidalflat+surface=sand - it is not widely used that way (almost all uses of natural=sand are on land) and we have the mentioned broadly accepted more precise tags for that.
• no use of tidal=yes to display the coastline (because natural=coastline is the accepted way to map that)
• no use of external data (not that there would be any available on a global level for either mean sea level or low tide level with even a remotely suitable level of quality)

Given the disadvantageous existing rendering illustrated in https://github.com/gravitystorm/openstreetmap-carto/issues/3840#issuecomment-526820875 i think an overall reasonable approach would be to render wetland=tidalflat and natural=beach outside the coastline with the same base color. They would still be distinguished by pattern and doing so would help keeping the number of different fill colors low.

[Bibi56]

no dedicated support for use of natural=sand outside the coastline as an umbrella tag for natural=reef/natural=shoal/natural=beach/wetland=tidalflat+surface=sand - it is not widely used that way (almost all uses of natural=sand are on land) and we have the mentioned broadly accepted more precise tags for that.

I don't mind if Sahara is mapped with surface=sand. BTW, I said natural=sand but I meant surface=sand. The sandy intertidal portion I mentioned in the picture is described with both tags (and tidal=yes). In the above example, tidleflat would be dangerously be misleading.

Which is? tidalflat? tidleflat is not the same. Sand is not necessary flat. You have submarine dunes for instance. By astronomical tides, the sand is really steep.

no use of tidal=yes to display the coastline (because natural=coastline is the accepted way to map that)

tidal=yes is not intended as a replacement for the coast line. I'm fine with natural=coastline (even if coastline=yes would have been more logic, but we don't need to break this).

I guess you mean the second point of your comment on #3738: i don't like that natural=beach and natural=sand are shown identically when overlapping water. Removing the pattern from sand would solve that. natural=sand in general does not make much sense overlapping water - either natural=beach/shoal/reef or wetland=tidalflat with surface=sand would always be a more accurate mapping. This is not something this PR should solve but it is an issue this would open.

Historically - before you changed the wiki page, beaches were upper part of the beach, surface=sand, tide=yes. Not necessary the best but using beach for the whole puts beach names on sea side. Maybe beaches should be mapped as node (key tourism?) and keeping unrelated properties separated (surface and water level) separated would help as beaches consist usually in 4 parts, using one way to render 4 parts has little chance to be well done and the meaning of the tag in OSM has changed over the time.

And I would say quite the opposite: I would rather remove the pattern for beach.

For water level we have shoal (shallow_water=yes would be better - not ambiguous) and tidel=yes. Now tidalflat is misused as used to render the intertidal zone. Non sense IMHO. And beach has nothing to do with that. Describe the surface of the seabed or the shore on one side (surface) and describe the water level above (tidal, shallow waters) on the other side. Could also be a unique key water_level=tidal/shallow.

[Bibi56]

For the transparency issue, a pattern, not necessary in a solid color (background transparent, foreground 50% transparent could be used: for intertidal zones and

for shallow waters, the background (sand,... would be still visible). Note: just as POC, not meant for real usage

[georgek]

It looks like this change has led to the beaches at Dunkirk being tagged as wetland=tidal_flat: https://www.openstreetmap.org/relation/7397679#map=13/51.0714/2.4539

Can't blame them. When carto breaks the rendering of something, people avoid those tags. It's annoying because the distinction between beaches and tidal flats is good, but get beaches right first. Most people care more about those.

[Bibi56]

@georgek indeed. It has also happened in Loire-Atlantique, degrading the database.

[imagico]

This is not the place for tagging discussion but except for the overlap between beach and tidalflat:

https://www.openstreetmap.org/way/520745148 https://www.openstreetmap.org/relation/7397679

which is evidently not mapping for the renderer and which OSM-Carto reveals nicely here (https://www.openstreetmap.org/#map=19/51.05281/2.40544) this seems to be accurate mapping.

Again as a reminder: This issue is open, solutions for this along the lines of https://github.com/gravitystorm/openstreetmap-carto/issues/3840#issuecomment-625935175 would be welcome. Complaining about the state of affairs does not lead to progress, actually developing solutions does.

[jeisenbe]

Note in the comments above (e.g. https://github.com/gravitystorm/openstreetmap-carto/issues/3840#issuecomment-625935175) we have a possible technical solution which would allow rendering areas of natural=beach which are outside of the natural=coastline (that is, below the high water tide line) with a background color that is somewhat similar to the current tidal_flat rendering.

I have not worked on implementing this because we currently need consensus on merging or rejecting PR #4128 - additional comments there might be helpful.

[Bibi56]

This issue is open, solutions for this along the lines of #3840 (comment) would be welcome. Complaining about the state of affairs does not lead to progress, actually developing solutions does.

@imagico, do you mean the comment made on May 16 is not a proposal, would a revert as proposal be welcomed? We observe that the usage is changed due to the renderer. I'm not fine with that.

@jeisenbe, last comment from @kocio-pl is quite disappointing:

Just for the record - ocean/river border looks even worse than river/lake border without the gradient line:

Originally posted by @kocio-pl in https://github.com/gravitystorm/openstreetmap-carto/pull/4128#issuecomment-710542796

Nothing to add there... Except if something is wrong with the tagging of the region.

[imagico]

With solutions for this along the lines of https://github.com/gravitystorm/openstreetmap-carto/issues/3840#issuecomment-625935175 i mean an actual pull request meeting the requirements listed there.

A revert of #3738 would - apart from failing the first requirement - require us to re-open four issues and it would be incompatible to various changes made since then that fixed several other issues. The whole point of switching to water polygons in #3694 was to be able to do the layer reordering. This was one of the most important strategic decisions of this style in recent years. So a revert of that simply because the current rendering of beaches (which was decided on way before #3738 in #1990) is not ideal would be unrealistic.

@jeisenbe explained how we can adjust rendering of features separately over water and land. Not that this would necessarily be the only way to resolve this issue, modifying the existing beach patterns and adding a pattern for beaches without surface tag would be an option as well.

[verdy-p]

Why did you not contact OSM France via its list? Do not decide internationnaly without consulting them.

In my opinion nationg excludes a "tidal flat" (which indicates a part of soild that is submerged or emerged episidically by water du to tide twice each day) from covering a part of the beach (this is almost always the case, except for some artificial beaches), and parts that are not beaches (rocky soils and mixed sediments) possibly populaled by algaes and other living species.

What we see at low tide is a beach even it is larger than at high tide: the OSM costal line is defined at high tide, so the beach naturally extends further than this OSM coastline inside the "OSM sea" area. As the tidal area includes that part independantly.

What you mùay have decided to do in the Netherlands or Belgium will not magically have to apply to France, without informing them first (and allow them to discuss it in French on their mailing list and online forums or other channels). So please contact them and do not decide anything here, in English only!

[mfrasca]

Please don't forget the 4~5m tide on the Pacific. There's places in Panamá where the tidal flat extends 800m into the sea, and even though most are muddy, some are sandy. The difference is of obvious relevance to tourism. What happens is that people into tourism who know OSM will simply remove the sandy tidalflat in front of their location, because the current default rendering suggests a muddy surface. When that happens I refuse to start an edit war, because I think they have a point. Please do remember that this part of the world speaks mostly Spanish, not French, not English.

[harahu]

@jeisenbe @georgek This is a slight digression, but I'm strongly considering importing the intertidal area or Norway, in bulk, and would appreciate seeing it rendered somehow.

This data isn't combined with surface information, and also goes deeper than MLWS, specifically LAT - 0.5 meters. I opened a discussion on this topic here for anyone in this thread who might be interested.