Remove overlay pattern for natural=sand

[jeisenbe]

Related to #3707 and #545
Reverts #2746 - addition of beach.png pattern for natural=sand

Changes proposed in this pull request:

• Remove pattern rendering for natural=sand from landcover-area-symbols (where it renders above water areas)

Explanation

• The tag natural=sand is currently rendered with a unique color fill, different than beaches or bare_earth, so the pattern is not needed to distinguish sand from similar areas. Removing the pattern will make the map less busy. This will also make it easier to add a pattern for natural=dune areas, if desired.
• Removing the natural=sand pattern will also hide areas tagged natural=sand outside of the coastline. These should be tagged natural=beach or natural=shoal.

Test renderings

Horton's Nose - sand next to beach

http://www.openstreetmap.org/#map=17/53.31607/-3.50920
z17 before

z17 after

Point of Ayr - natural=beach next to natural=sand (dunes)

http://www.openstreetmap.org/#map=15/53.3569/-3.3175
z15 before

z15 after

[jeisenbe]

@kocio-pl mentioned that he has some concerns about this change.

It would also be possible to continue to render the "beach" dot pattern on natural=sand polygons, but in the main landcover layer instead of the overlay, so that the pattern is not inappropriately rendered above water layers.

This would have the disadvantage that the pattern would still be adding noise to the map without providing additional information.

It would also make it difficult to render natural=dune with a pattern - it appears that some areas of natural=dune overlap with natural=grassland and some with natural=sand, which makes sense for a landform which can be partially covered with grass but is usually a sand surface.

[kocio-pl]

I think this would be a step back, see https://github.com/gravitystorm/openstreetmap-carto/pulls#issuecomment-526096452

[jeisenbe]

@kocio-pl, the link to your previous comments doesn't work for me.

[imagico]

As already indicated in #3851 (comment) i support this change. Some of the reasons @jeisenbe has already mentioned:

• using a pattern on sand does not transport any discerning information to the map user.
• adding a pattern despite this is just adding noise and uses space and map user attention that could be used for other purposes.

Beyond that there are the following further arguments

• Adding pattern for natural=sand #2746 completely broke with the overall design system for patterns established before to limit patterns for additional differentiation at the highest zoom levels. This way sand areas in the overall map design at the lower zoom levels form kind of a foreign body - further emphasized by the fact that they are exempt from the overall area color fading.
• Overall our area color and pattern styling is based on the principle of showing semantic differences for the map user rather than differences in physical appearance (i.e. we don't aim for a simulated aerial imagery style). Re-purposing the pattern for sandy beaches for rendering natural=sand and this way implying that natural=sand is more similar to a sandy beach than different kinds of beaches are to one another is at odds with this. And it sends a highly confusing signal to map users.

I completely agree with @kocio-pl that this change is a step back - that way correcting a step forward in the wrong direction.

[kocio-pl]

This should be a proper link to my comment: #545 (comment)

I hope we could keep the discussion in just one ticket for the moment, please.

[jeisenbe]

This was the comment from @kocio-pl:

We have:

• one color for beach, which is abstract type of land (so no grains)
• another color with grains overlay for sand, which is physical (so grains)
• we can show sandy beach with beach color with grains (abstract part + physical appearance), because it's a mix of both
  If we show a pattern for sandy beach, but remove it from sand areas, we would loose this coherence (we show that sandy beach is similar to sand area in some way, and sandy beach is similar to general beach in another way).

We don't generally focus on the surface of features in this style, but try to render different "features" in distinctive ways, since this matches how the tagging system works.

For example:

1. both orchard and wood / forest consist of trees, but these are rendered with different colors and different patterns. The orchard color is also used for vineyard and plant_nursery (so the 3 of these are distinguished with different patterns at high zoom levels)

2. Scrub and heath are both areas of shrubs - heath shrubs are smaller - but they have different fill colors and only scrub has a pattern.

There is only one case that I know of where the same pattern is used for 2 different features: plant_nursery.png is used for garden and plant_nursery. However, this is a very abstract pattern of regular dots, and I don't think we intend map users to think that gardens and plant nurseries are the same in any particular way.

Also consider that all sorts of paved areas are rendered differently: parking lots, aeroway=apron, runways, roads, garages etc are all different colors, since we are trying to render features, not surfaces.

So it's very unusual to use the same pattern for beaches (which was intended to show the difference between sand and pebble/cobblestone beaches) and for areas of wind-blown sand dunes and sandy deserts, with a different fill color: that is focusing too much on the surface or landcover, and not on what actual feature has been mapped.

[jeisenbe]

Looking back at #2746, the initial plan in the first comment was:

"Irregular wave pattern for natural=sand would make it visibly different from farmland (and also from beach)."

That made since at the time, since back then beach color was perhaps too similar to farmland, but now farmland is a light green-yellow color #eef0d5 so there is no longer a risk of confusion (the old farmland color was going to be used for schools and hospitals, but this was changed).

Also, the initially proposed wavy pattern was not identical to beaches.

Later in PR #2746 it was decided to use the beach pattern instead. Initially @kocio-pl said in this comment "Maybe natural sand should use a random pattern we use for beach now and beach could use regular one instead." - And the unique pattern from OsmAnd was also considered.

But in the end, the last commit used the beach pattern - note that there were no responses or further discussion after this comment and new commit, before the PR was merged, so there wasn't really consensus about the change.

Therefore, I think it's reasonable to revert #2746 unless there is consensus that the change in that PR was necessary.

[imagico]

Answering to #545 (comment) here since this is the more fitting place and #545 is more about if and how to render natural=dune.

* one color for beach, which is abstract type of land (so no grains)

* another color with grains overlay for sand, which is physical (so grains)

* we can show sandy beach with beach color with grains (abstract part + physical appearance), because it's a mix of both

If we show a pattern for sandy beach, but remove it from sand areas, we would loose this coherence (we show that sandy beach is similar to sand area in some way, and sandy beach is similar to general beach in another way).

Your opinion seems to be based on the assumption that our use of patterns follows the principle that patterns indicate physical properties while the fill base color indicates non-physical semantics. This is not the case for any use of polygon patterns in this style i think.

In almost all cases patterns are used as a secondary classification of areas, secondary to the primary classification indicated by base color. This is the case for example for forest/wood, orchard/vineyard, cemetery, bare_rock/scree/shingle and beach. We have also a few cases where a pattern is used as primary distinction only together with the base color to make the difference to other areas with similar base color clearer to the map user - like allotments, quarry and scrub.

(not really that relevant here but the only major exception from this principle is wetlands - where historically the wetland dash pattern indicates the primary classification and the base color is - where it is used - a secondary element. This has various reasons and is not without problems but does not really have a bearing on the discussion here)

As @jeisenbe already mentioned the only case where a pattern is re-used for a different tag with a different primary classification other than sand is garden/plant_nursery. And that is a suboptimal use of patterns as well - both because the irregularity artefact in the pattern and because of the potential confusion resulting from this reuse. The ac-style therefore by the way uses different patterns there:

https://github.com/imagico/osm-carto-alternative-colors/blob/master/symbols/patterns/garden.png
https://github.com/imagico/osm-carto-alternative-colors/blob/master/symbols/patterns/plant_nursery.png

Note back when the bare_rock/scree/shingle rendering was introduced (#1217) it was discussed to reduce the rendering of natural=sand to a secondary classification indicated with a pattern. But it was (IMO rightfully) decided to maintain a separate base color with no pattern for sand. We could revisit that decision - that would however mean sand would be rendered in the grayish color scheme of scee/bare_rock and would - even if the pattern geometry from sandy beaches was reused - appear very differently in the overall look (beach, sand and scree):

As you can see this would - even if the same pattern geometry is used - clearly maintain the color as the primary classification. You would probably want to use a coarser pattern for scree though for better differentiation. And like with scree (and bare_rock before #2852) the secondary classification via pattern would be dropped at z<13.

[kocio-pl]

Sorry for not answering full message, it can take me more days to read and analyze this, so I start at least with something.

In short I can reply to some of your previous message that it is semantic element. I don't agree, natural=sand means only "I don't really know what it is, but it's covered with sand". What I would call semantic tag, would be a beach, a desert, a sandbox etc.

In other words (relating to your classification of primary/secondary, which sounds good for me): it really has no primary meaning, only secondary. If we take it dead serious, we could render only sand pattern if no semantic tag is given, so it's clear that some important classification is missing.

[imagico]

I see what you are getting at but i think you are wrong on two levels:

• if natural=sand was indeed just a secondary tag (i.e. a synonym for surface=sand essentially) we should completely drop rendering it.
• your implication that tagging a sandy beach natural=sand would be correct is wrong - there might be a few cases where this is incorrectly done but that is not correct use of the tag and there is consensus about this in the community. Mappers are fairly consistent in this so it is important for us to support this through proper, non-confusing and not misleading feedback.

Frankly i am not quite sure why we are discussing the meaning of natural=sand here because there is hardly any tag in OSM that is clearer and less disputed in its meaning than natural=sand.

I encourage you to take your time to read and think about the arguments presented by @jeisenbe and me here. As @jeisenbe already explained there was no substantial discussion back in #2746 about the specific design decision made and that the circumstances back then where fundamentally different.

[jeisenbe]

...reduce the rendering of natural=sand to a secondary classification indicated with a pattern... it was (decided to maintain a separate base color with no pattern for sand. ... sand would be rendered in the grayish color scheme of scee/bare_rock...

... like with scree the secondary classification via pattern would be dropped at z<13.

I initially wanted to drop the pattern for natural=sand so that it would be possible to use a pattern for dunes, but that isn't essential (there are other ways to render dunes, perhaps using a semi-transparent shading rather than dots).

I'd be willing to consider this change, to unify natural=sand with the @bare_earth fill color used for natural=scree, natural=shingle, and natural=bare_rock, along with dropping the pattern at low zoom levels and adjusting the scree pattern for better distinction from sand, if @kocio-pl and others are more in favor of this option.

It would be nice to free up another color which could be used for other features.

However, I'm also OK with continuing the initial plan for this PR; keep the color but remove the pattern.

[Adamant36]

Personally, I'd like to see some rendering examples of the grayish color. I think it might work and be better then removing the pattern. As there's a need for a darker, more natural yellow tone with social amenities and the yellow color currently used for natural=sand might work well.

[jeisenbe]

There was this sample from above:

Sand with bare_ground fill color (`#eee5dc)

Test images:

Horton's Nose - sand next to beach

http://www.openstreetmap.org/#map=17/53.31607/-3.50920
z17 before

z17 this PR - no pattern

Option - @bare_ground color but with pattern

Point of Ayr - natural=beach next to natural=sand (dunes)

http://www.openstreetmap.org/#map=15/53.3569/-3.3175
z15 before

z15 without sand pattern - this PR

Option - with @bare_ground color and pattern

z13 current

z13 this PR: no pattern, same color

z13 Option - sand in bare_ground with pattern

z12 current

z12 This PR: no pattern, same color

z12 Option - sand in bare_ground, no pattern at z12

Bae Trearddur

• sand, beach and bare_rock
  z16 current
  

z16 this PR - no pattern

z16 sand as bare_ground

[jeisenbe]

I've made a new branch with natural=sand in @bare_ground color for testing, if anyone is interested:

https://github.com/jeisenbe/openstreetmap-carto/tree/sand-color

[jeisenbe]

@kocio-pl what do you think about the different options above in #3855 (comment)?

[kocio-pl]

I haven't had the time to research it and given the current speed of discussions, it might take even more than i expected.

My current idea is that this is the right way to go, but first we need to have and render primary (I mean real, semantic objects) tags for sand-covered areas. Which inclines me to close this ticket as way premature and depending on better tagging first.

[jeisenbe]

we need to have and render primary tags for sand-covered areas.

There 2 established tags for semi-natural sand-covered areas are natural=beach + surface=sand (for beaches, water-formed sand) and natural=sand (for wind-blown dunes and sandy desert areas). I don't see anything missing from these 2 tags. What do you mean?

this is the right way to go

Which way?

Render natural=sand in current color without pattern, or in bare_ground color with pattern?

[kocio-pl]

I mean any sand area, like mentioned dune, desert, sandbox, possibly sand quarry and whatever else (the main work would be to find missing types of objects).

The idea is to always have the object for full rendering (color+pattern), so we can resort to rendering the sand (natural/landcover/surface etc.) as just the pattern.

[jeisenbe]

I would like clarification if your preference is rendering natural=sand in current color without pattern, or in bare_ground color with the pattern.

dune, desert, sandbox, possibly sand quarry and whatever else

Sand boxes, deserts, dunes and quarries are quite different features.

Quarries already have a pattern already, dune is not yet rendered and may not be - see #545 (comment) - where it's noted that the tag is often used in the same way as natural=sand to map both dunes and flat areas of sand in between.

And natural=desert is no longer rendered due to discussion in #773 + PR #1072.

I don't think we should render children's sand boxes in the same way as deserts, quarries or beaches. Specific playground equipment rendering was rejected in #3161 and renderingplayground=sandpitthe same as natural=sand was discussed in PR #3230 - see #3230 (comment) - which was closed.

The one other feature is golf bunkers. These are often tagged as natural=sand but the more precise tagging is golf=bunker - we have not yet decided if such specialized features are worth rendering in this style. The issue is currently closed: #661.

So really we only need to concern ourselves with how this will look with natural=beach and natural=sand.

[imagico]

I would like clarification if the way to go is rendering natural=sand in current color without pattern, or in bare_ground color with the pattern.

There is another important factor that speaks against degrading natural=sand to a sub-class of bare ground. For human use and navigation without a prepared path sand is fundamentally less difficult than scree and bare rock. If i want to follow the paradigm that the differences in rendering between different types of features should foremost be based on their difference in meaning and purpose for the target map users then a well visible difference between natural=sand and natural=scree/natural=bare_rock is quite essential.

[jeisenbe]

For human use and navigation without a prepared path sand is fundamentally less difficult than scree and bare rock.

True, but there are also other types of natural bare ground which we do not yet render, but are even easier to walk on: dry clay, dry silt, dry loam, and dry salt flats. These are all rare in the database since they occur only in desert areas (cold or hot) with too little rainfall for vegetation to grow or mud to form.

@kocio-pl, would you like to clarify your technical objections to this PR? Would you be clearly in favor of the alternative: changing the natural=sand color to @bare_ground instead of this PR?

[kocio-pl]

I understand what you think is the right way, but I have already plenty of opinions and problems to consider and I don't want to discuss them before I will be ready with synthesis and this is the hardest part. More analysis and more discussions is not the only way to make good decisions.

[imagico]

@kocio-pl - i don't think it is quite fair (and also not quite efficient) to delay a change made by someone else (for good reason) to allow you unspecified time to develop a possibly better solution.

The change proposed here is very simple and it just reverts a previous change that has been added without in depth discussion and the results of which are - as explained - not very good. It does not in any way prejudice future changes.

Now i understand you might have a design concept in your mind for which the current situation would be a more logical starting point than after this PR. But if you can't present this concept at this time as an alternative the best way to go ahead is accepting this PR i think.

[kocio-pl]

Well, the discussion about this solution happens exactly in this ticket (and it hasn't yet concluded), I don't see how ignoring this would make any sense. I also don't understand why do you think the decision should be taken immediately - at least that's how I understand your position.

Besides - I might be overreacting, but could you please refrain from judging (for example what is "fair" or not)? I'm happy with you writing short comments with simple sentences lately, it makes me much easier to communicate, but this style is something that still makes it harder than I would like it to be.

[imagico]

I might be overreacting,

Yes you are IMO, but i don't mind you being somewhat thin-skinned in that regard, that is OK with me. Ultimately however you don't get to dictate my style of communication of course.

But getting back on subject - my suggestion stands. There has been plenty or arguments and evidence as well as alternatives been presented for this change and you have engaged relatively little in arguing with that. This is completely fine. But if you block the change i think it is a matter of fairness to engage in arguments about the reasons for the change presented. What you however seem to be saying (and i could be misunderstanding obviously) is that you don't want to discuss your thoughts about it until you have formed a final opinion ("I don't want to discuss them before I will be ready with synthesis") - or in other words: you don't want to engage in an open ended discussion based on arguments and evidence.

[kocio-pl]

Ultimately however you don't get to dictate my style of communication of course.

Sure, I just wanted to give you a feedback of the problem I have with communication which includes judging statements.

What you however seem to be saying (and i could be misunderstanding obviously) is that you don't want to discuss your thoughts about it until you have formed a final opinion ("I don't want to discuss them before I will be ready with synthesis") - or in other words: you don't want to engage in an open ended discussion based on arguments and evidence.

Oh, I mean "final" not as "I don't want to discuss it", rather "I need to remove some noise before going further". Is this what is bothering you here or is it something else?

[jeisenbe]

In #3957 (comment) @jragusa was in favor of #3957, not this PR.

[jeisenbe]

EDIT: comment on wrong issue, sorry

[jeisenbe]

In #2831 it was claimed:

sand pattern (beach.png) is invisible for me, it just makes the natural=beach/sand area darker

The suggested solutions were:

• enlarge beach.png, use bigger elements for beach_coarse.png
  OR
• use darker color for beach_coarse.png

But removing the pattern from natural=sand would be a good idea if the pattern is not really visible in a clear way: if it is just making natural=sand look darker we can adjust the color.

(Note: I do not see this problem (#2831) myself; the beach.png pattern clearly looks like a different pattern than beach_coarse.png or beaches with no pattern to me, but @kocio-pl opened the issue and we need to decide what to do with it)

[Adamant36]

However, I'm also OK with continuing the initial plan for this PR; keep the color but remove the pattern.

I say go with the initial plan. I think its an improvement. Plus, the reasons for it are compeling, the reasons against it are thin, there doesn't seem an alternative anyway, and 3 months later there's more important issues to get to. Also, while I'm all for consensus and don't believe in rushing things, in this a resonable amount of time has passed IMHO without @kocio-pl figuring his side out to bypass him.

Btw, I think a realistic "decision time frame" is probably something you guys should decide on as part of figuring out the whole consesus thing. Otherwise, it can lead to stalling and hold up the projects progress.

Feel free to completely ignore me on any of that though.

[imagico]

I think that is a useful consideration - although i would prefer not to bypass/overrule individual maintainers but instead appeal to their sense of community and the realization that blocking a change should always be accompanied by understandable reasons and a clear alternative perspective how to proceed - as discussed in #3951.

@kocio-pl - setting aside the question if this change is an improvement or not for a moment - what do you think are the big issues this change would introduce and why you feel the need to block its acceptance? As mentioned in #3951 it is quite essential for consensus based decision making for everyone to use their right to object carefully and only where it is really essential from your point of view.

[jragusa]

Just two questions for everyone about this issue:

• my consideration to keep pattern concerns mapper feedback about the use surface=sand. Do you consider this feature important or useless regarding natural=beach ?
• sandy pattern over water would indicate exposed surfaces during low tide. Again, do you consider this feature important or useless for the style ?

Honestly, if most of people consider both cases useless or of minor importance, I would not vote against this issue because that won't change considerably the rendering.

Note that only 23.18 % of beaches have a surface tag and 18.09 % of them are sandy beaches. We can assume that most of the beaches are sandy.

[imagico]

Since this PR removes the pattern from natural=sand, not from natural=beach i am not sure of the relevance of the questions.

The use of patterns to indicate surface tagging on natural=beach was added in #1990. The reasoning was - and still is - that surface tagging on beaches is used consistently where applied and it is highly useful so it is in support of consistent use of tags. The main reason why still only a relatively small percentage of beaches have a surface tag is because it requires on-the-ground knowledge to reliably tag it. The reason why most beaches with a surface tag are surface=sand is because sandy beaches tend to be more interesting for human use.

That beach mapping across the coastline does not obscure the coastline location is also an important aspect for constructive mapper feedback.

But as said i don't see what either of these have to do with this PR.

[jeisenbe]

my consideration to keep pattern concerns mapper feedback about the use surface=sand.

As mentioned above, this PR will not change the rendering of `natural=beach` areas.

sandy pattern over water would indicate exposed surfaces during low tide.

This will not change for beaches. It will change for `natural=sand` areas - but the tag `natural=sand` is not to be used for features which are in the tidal zone: these would be a `natural=shoal`, `natural=reef`, `natural=beach` or `wetland=tidalflat`. We have an open issue #3854 for adjusting the rendering of areas of beach, shoal, reef, mud etc. when they are outside of the coastline or overlapping water. I think this is important, and the solution in that issue does not require relying only on the pattern to make these areas visible outside of the coastline.

[kocio-pl]

So what is the current rule for rendering related sand/rock/beach/.. features on the land?

[jeisenbe]

Currently all non-vegetated semi-natural areas are in different shades of earth tones: that is, yellow to orange hues with varying levels of saturation.

Mud is low saturation, bare_ground is mid-low, sand is medium, and beach is higher). Beach is most yellow, sand is a little between beach and bare_ground (scree/shingle/rock).

Currently patterns are used to distinguish different types of rocky areas (smaller rocks like scree/shingle vs large rocks/bedrock), and natural=beach features which have a certain surface= tag (sand or more rockY). The wetland pattern is used to distinguish wetlands (mud / tidalflat ) from non-wetland areas.

Oh, and since #2746 natural=sand has a pattern which is the same as the surface=sand pattern for natural=beach, but there isn't a reason for both a unique pattern and a unique color for this feature.

[jeisenbe]

It would be good to get input from the other maintainers about merging ths PR (#3855) and removing the pattern added to natural=sand in #2746, or the alternative option of PR #3957 which keeps the new pattern but combines the natural=sand color with the color used for scree, shingle and bare_rock (and mud on land).

[imagico]

with the color used for scree, shingle and bare_rock (and mud on land).

Small correction: mud uses a different color.

[jragusa]

mud also uses the same pattern as wetland

[jeisenbe]

@pnorman, @matkoniecz, anyone else want to consider whether this PR (#3855) or the alternative (#3957) is the better solution?

[pnorman]

@pnorman, @matkoniecz, anyone else want to consider whether this PR (#3855) or the alternative (#3957) is the better solution?

I prefer this PR to the other, but haven't formed a strong opinion on the cartography.

[jeisenbe]

It looks like we have rough consensus in favor of this PR. Are there any other reviews or comments?

[pnorman]

Besides the reviews of one change requested and one approval we have comments indicating approval from @imagico and @jeisenbe. We've had this open for months and I don't see agreement developing, but I'm going to merge this because the consensus seems to be to go with it.