Render ocean and seas differently than fresh water

[jeisenbe]

Expected behavior

• The location of the natural=coastline should be clearly visible to provide good mapper feedback
• There should be a visible difference between sea water and inland fresh water
• The color of the seas should be less intense than inland waters, since they take up a very large part of the rendering at lower zoom levels
• Mappers should be discouraged from using natural=water polygons over the oceans to render labels for seas

Actual behavior

• The ocean polygons are rendered in the same color as all inland water areas
• Mappers do not have feedback on the location of the coastline transit in debatable areas near estuaries and rivers. It's not obvious if another user changes coastline to natural=water or waterway=riverbank
• Since the ocean and natural=water are the same, some mappers tag areas of seas with natural=water to get a label rendered.

See Also #3893 - rendering salt water lakes differently

[kocio-pl]

Mappers should not be able to use natural=water polygons over the oceans to render labels for seas

How do you expect to achieve this?

[jeisenbe]

How do you expect to achieve this?

Rendering oceans in a different color and moving water areas back above oceans would work, but this conflicts with the first point: "The location of the natural=coastline should be clearly visible to provide good mapper feedback" - that is more important, so I believe the oceans polygons should continued to be rendered above the other water areas.

[jeisenbe]

It's quite common for printed maps to render marine water bodies in a lighter shade of blue than lakes or rivers. Here are examples from atlases and wall maps in my kids' school (which also show rivers in a much darker blue, as is common):

[StyXman]

What about salty lakes? https://en.wikipedia.org/wiki/Salt_lake#List

[jeisenbe]

See issue #3893 about rendering lakes differently when tagged with salt=yes - I agree this is also a good idea to consider at the same time.

[kocio-pl]

The initial idea took me by surprise, I was not aware of such cartographic tool. I also have a problem with the ocean color proposed by @imagico, because it is both different shade of blue and looks too pale for me.

When discussing possible salt lakes rendering (#3901) I started to see that if we use just a lighter blue which is similar to the salt lake (standard water blue with white dots), it sounds more acceptable for me. The salt lake rendering is not yet decided, but this way or another this would be good to have more or less uniform rendering for all the salty waters.

Another problem for me is rendering of a verge. It looks artificial and unpleasant for me to see hard line between two water colors. Is it possible to use some gradient at the borders of the ocean, for example?

[jeisenbe]

The proposed color for seas (left) is still quite similar to the current water color (middle):

Compared to the printed maps above, which use much darker and more saturated blue for rivers, and very light blue for coastal sea waters, this is a subtle difference.

Test images with 3 colors:

z14 Bremen before

z14 Bremen after

z12 Bremen before

z12 Bremen after - without landcover fading, and with 3 different colors for ocean vs river vs lakes, and a 1 pixel wide outline around the ocean polygons. (e.g. After PR #3670)

z8 Anchorage before

z8 Anchorage after

Is it possible to use some gradient at the borders of the ocean, for example?

Yes, see https://github.com/gravitystorm/openstreetmap-carto/issues/3854#issuecomment-525969407 - we can use a gradient if we use comp-op dst-over so that the lines to not overlap with land. There are some test images at https://github.com/gravitystorm/openstreetmap-carto/issues/3695#issuecomment-479903108 and https://github.com/gravitystorm/openstreetmap-carto/issues/3695#issuecomment-526086657

[StyXman]

I would like to see how it behaves at Rio de la Plata's mouth:

https://www.openstreetmap.org/search?query=rio%20de%20la%20plata#map=8/-35.142/-56.743

[kocio-pl]

I'd like to spot on the corner cases, where waters have long verge - for example here I can't say it's a gradient (Amazon z6, 1 px example), it's not even close, looks to me like an artificial "barrier", and on high enough zoom level (like z9+ - https://www.openstreetmap.org/#map=9/0.0824/-49.2119) this problem will become evident:

I'm also skeptical if it would work with vector version.

BTW: are there any online maps example of water color mixing?

[jeisenbe]

That example from the mouth of the Amazon is based off of old shapefiles and different layering. The current plan is to render the oceans above rivers and lakes, so any areas that are tagged as both river and coastline (like the mouth of the Amazon and some other major rivers) would be in ocean color; this looks better and gives better feedback about the coastline transit position across the river or estuary.

There shouldn't be any issues with adapting this to vector tiles: the inland water areas and river are rendered separately either way, and the "gradient" would be produced by overlapping lines, which is compatible with vector or raster tiles.

[jeisenbe]

Re: Rio de la Plata's mouth - that's a politically-fraught tagging issue, which might be exposed by this change - for example, the location of the coastline here does not seem very reasonable: https://www.openstreetmap.org/#map=13/-36.2987/-56.7912.

We could choose to render natural=water + maritime=yes in ocean-color to hide this particular tagging issue, but it might be better to show the coastline / river limit.

[StyXman]

the location of the coastline here does not seem very reasonable

I don't see what's the problem, but mostly due to ignorance. Can you explain the issue?

[kocio-pl]

The current plan is to render the oceans above rivers and lakes, so any areas that are tagged as both river and coastline (like the mouth of the Amazon and some other major rivers) would be in ocean color; this looks better and gives better feedback about the coastline transit position across the river or estuary.

I don't understand why it should look better and how the feedback would be better then? Simple example would be helpful.

But my main problem is still here - water is a fluid and usually has no sharp borders, so I would expect soft gradient between different water shades.

I have a suspicion, that "different colors for waters" technique is a legacy - I guess it's meant for low zoom printed (fixed scale) maps. That's why I'm asking if there are online maps that use it too. When the verge is small, it's strange, but passable that there are visible water junctions. Zoomable maps show this deficiency pretty clear, so a proper use of gradient is important.

[kocio-pl]

It looks like German fork has already deployed 3-color water scheme, so it's easy to test. Here are the most obvious problems with verges (Amazon delta looks like tagged different, so the difference is softer, still a strange line is visible) - on higher zoom levels there will be more of them:

[kocio-pl]

There's also some problem with Nile data, but it's strange (it should be only a visible verge, we don't have this artifact):

[imagico]

@kocio-pl - i am not sure what your main statement is here.

• do you think the style should avoid showing this kind of differentiation because the mapping consistency in that regard is too low? I would disagree with that - the existence of a few prominent cases of this is no indication of an overall lack of mapping accuracy.
• do you think the differentiation between maritime, riverine and other water domains is insignificant and therefore this style should not provide feedback on mapping of those?

In my eyes the samples you show mostly indicate something quite obvious: If we start using more differentiated rendering of waterbodies this will look less than ideal in areas where quality of mapping these differences is low. That is expected and is IMO also desirable because that is how mapper feedback works.

Cartographically arguments can be made for either differentiated rendering or uniform rendering. But in my eyes it is quite clear that for the mapper feedback goal a differentiation would be beneficial.

[kocio-pl]

My main problem is sharp line between the waters, which is a pure artifact of the used model. Solution for this might be different - not using different colors, soft gradients, maybe smaller difference between the colors (luminescence only without changing shade)... I currently research the gradient solution.

[imagico]

Since we have no other case in this style IIRC where a mapped geometry is deliberately blurred in rendering i am not sure if such thing is desirable. @jeisenbe looked at methods for highlighting the edges of water areas in rendering and this might also affect how the edge between different waterbody classes is rendered but in general for precise mapper feedback on accurate placement of geometries we don't want to deliberately disguise the position of geometries.

I am also not aware of any other maps that differentiate waterbody classes but render a kind of gradient between them.

[kocio-pl]

I start with an intuitive and readable map concept here. Water junctions are purely virtual feature most of the time. If we would insist on showing water borders, we should also do it on showing water dots and water lines on the river beds in a different color, because it's also technically more accurate, but counterintuitive in reality, because we don't have proper model for that. For me it would make map less understandable and more analytical, which belongs to editors and QA tools.

[imagico]

I strongly disagree with the notion that mapping and display of semantic differentiation of different types of waterbodies is non-intuitive or bad for map readability. You can find lots of examples of maps making such a differentiation - above and in https://github.com/gravitystorm/openstreetmap-carto/issues/1781#issuecomment-249149425. We have a proper model for modeling that in OSM and this is actually used with diligence in most cases.

Performing world view maintenance for all the data users of OSM data who think water is water and can and should only be rendered in one plain uniform color in maps is not our task here.

[kocio-pl]

OK, I already perfectly understand you disagree. But until now you did not answer any of my specific objections, so here they are:

• why not render water dots and water lines visibly different then?
• there are very small subset of maps that do it and until you came with tri-color water scheme I don't remember any map showing this, so this is not "a lot" for me
• nearly all the examples you both gave are printed (=fixed scale) maps, and the only exception I noticed is a Swiss map (which is not well known for waters estuaries), which suggests me that this is basically kind of "let's give some contrast boost, because nobody will mind small junctions on this scale"
• our goal is understandable map and introducing artifacts is not what I would call like this
• sharp lines for water is not what I could name a proper model for representing fuzzy borders - unless you want to claim that these exact lines are verifiable as such in the wild?

[imagico]

why not render water dots and water lines visibly different then?

I am sorry - what are water dots? I assume with water lines you mean waterway lines - those would obviously be rendered in river color (potentially further differentiated by natural/artificial and permanent/intermittent).

there are very small subset of maps that do it and until you came with tri-color water scheme I don't remember any map showing this, so this is not "a lot" for me

This issue is about differentiating ocean and inland water areas. Such differentiation is not rare at all in maps. But i don't really think this is a line of argument we want to follow - by that reasoning the >250 different point symbol types we render are absolutely exceptional and we therefore should remove most of them.

nearly all the examples you both gave are printed (=fixed scale) maps, and the only exception I noticed is a Swiss map (which is not well known for waters estuaries), which suggests me that this is basically kind of "let's give some contrast boost, because nobody will mind small junctions on this scale"

You seem to reject the idea that there is a reasonable distinction that can be made between different types of waterbodies in cartography (which is why i asked you if that is indeed the case - see below).

Semantically differentiated rendering of waterbodies is almost non-existent in OSM based maps because OSM-Carto does not do it and other map styles necessarily adjust to the smallest common denominator. Google and Here do not differentiate either because their data sources do not make such distinctions and it would be costly to change that. And since these map massively focus on human rather than physical geography they don't want to bother. In other words: It is not a cartographic decision, it is an economic decision.

our goal is understandable map and introducing artifacts is not what I would call like this

I think i already pointed out that i think differentiating rendering of 2/3 of the earth surfaces instead of blanket rendering in a uniform color does not negatively affect map readability when done in a way that works harmonically with the rest of the map.

sharp lines for water is not what I could name a proper model for representing fuzzy borders - unless you want to claim that these exact lines are verifiable as such in the wild?

I do - this is not a problem, at least not any more than differentiating between natural=wood and natural=scrub, landuse=residential and landuse=commercial or similar.

Note you have not answered my two questions above in https://github.com/gravitystorm/openstreetmap-carto/issues/3895#issuecomment-537531941.

[kocio-pl]

do you think the style should avoid showing this kind of differentiation because the mapping consistency in that regard is too low? I would disagree with that - the existence of a few prominent cases of this is no indication of an overall lack of mapping accuracy.

I don't understand what do you mean by mapping consistency?

do you think the differentiation between maritime, riverine and other water domains is insignificant and therefore this style should not provide feedback on mapping of those?

No. It is only about how to show them.

[imagico]

I don't understand what do you mean by mapping consistency?

I mean that you might think that mappers use the different taggings which we might want to use to differentiate rendering too arbitrarily for us to be able to provide productive feedback and create a useful map. The samples you posted seem to indicate you are dissatisfied with the data quality - some of them obviously show bad quality mapping - and i wonder if you might think this is representative for the data quality in general (which i don't think it is - but you might have a different impression).

No. It is only about how to show them.

Do you have any method of rendering (either in some other map or something you create yourself) that you would consider a suitable method of showing these differences?

[kocio-pl]

Maybe I should start from basics, because I have the impression that we start wasting time discussing things which we might already agree in general:

• the idea to differentiate water areas is OK for me, as long as we can find good visual representation for it
• discrete database is a weak tool for representing fuzzy shapes, and water objects are the most prominent example of them
• therefore any data showing internal water borders are highly arbitrary, no matter how hard one could try
• we cannot change the toolset, but we might show this avoiding sharp lines, to correct this fundamental weakness
• there can be different approaches how to do it, including two I am aware of: smooth color change (gradient still allows to find the border, it's just more fuzzy) or using white dots overlay for representing all the salt water (no lines or joinings at all, but the change is visible)

It's OK that some other maps use sharp water borders - from the examples it seems they have their own set of conditions which make it more acceptable, like fixed low/medium scale (joinings are small), area with no big estuaries (like Switzerland) or very limited color space (maybe budget printing solution or high contrast required), which is just not the case in OSM Carto.

Is there anything you agree on here, so we can skip discussing it?

[imagico]

I quite definitely do not want to discuss the best methods to represent the physical geography of the world in data form here. If we like how things are represented in the OSM database should not be an issue as long as things are mapped in a verifiable and consistent form (which as i explained i think is largely the case here).

I miss this in your considerations - you seem to mainly focus on how you would like to draw a map independent of how things are mapped in OSM.

So maybe consider the following question: If you think differentiated rendering of waterbodies is desirable to have (which seems to be the thing we agree on) how would you like to see them rendered considering the tagging and mapping practice in OSM and the goals of this project?

[kocio-pl]

OK, I already said it in the last bullet point I gave. I think the goals are essentialy the same as with sharp lines, it just adds something more, which is missing for me.

[imagico]

Well - if you have a specific idea for styling i would like to see it but as said before i kind of have the impression that disguising the exact location of a classification boundary as positioned by the mapper is a bit at odds with the goal of providing constructive feedback to mappers. I mentioned in a different context in https://github.com/gravitystorm/openstreetmap-carto/pull/2138#issuecomment-223326875 that rendering line/polygon geometries in a way that allows mapper to verify exact positioning of the geometries is important. This is in particular significant in cases like here where exact mapping, in particular without gaps, is of fundamental importance for most data users.

[imagico]

Regarding the idea of rendering salt water (including ocean) with a pattern - i don't think this would work well. Ocean covers by far the largest fraction of the map in total and showing a generic pattern on that would introduce a huge amount of visual noise. The idea of differentiated water rendering almost always is to use the less prominent styling for the more common water classes.

[jeisenbe]

Re: the problems shown in the comment above https://github.com/gravitystorm/openstreetmap-carto/issues/3895#issuecomment-537488876 - from the German fork.

Note that there are not problems like this in Germany, partially due to the feedback provided by the German alternative style.

The issues shown are all unreasonable locations for the coastline: near Kalingrad the coastline is a couple of kilometers west of the river mouth at an arbitrary location, as with the example near Archangelsk - hopefully these will be fixed by local mappers once the problem is visible.

At the Amazon river mouth, the coastline undulates and does not follow physical features. The Rio de la Plata is tagged as a river, instead of a sea, due to political issues and is a known problem. These two are also the 2 largest rivers in the world by certain metrics. I don't think we should optimize the rendering for these exceptions.

In general, looking around well-mapped areas with the German style, I find that the water color differences are usually subtle, and improve the rendering of rivers over darker landcover areas.

[kocio-pl]

Short references:

• "disguising" in many forms is a common cartographic practice, for example for stairs we show series of short lines going across with gaps between them (instead of a continuous line), and for roads on high zoom we show an area with two lines on the sides (while hiding the real line in the middle at the same time), because we try to express something about these objects, not make a "dump" of the database geometry
• for salt waters I'm waiting for the output of #3901, if the salt grains will have not too much contrast, they might look good enough to imitate lighter area on the first sight
• I believe in the most of the use cases people see inland waters as a common type, because vast majority of the ocean tiles will never be visited by human (the ones which are not close to the land)
• I see German style as a proof of concept deployment, which of course shows different problems, including high contrast between river and the ocean (tri-color sample does not show their border) or too pale ocean color (even current contrast is a bit too low for me on the map), which are independent from any possible tagging errors/disputes

There's also one more tool we could use - color progress, which I think might be most useful for rivers (they are dark because on low/mid-zoom they are thin). The higher zoom level, the less color difference.

[kocio-pl]

I don't think we should optimize the rendering for these exceptions.

I have shown only the most notable low zoom problems here. With midzoom (let alone high zoom!) you get a load (thousands? millions?) of these artifacts, like here:

or here:

[jeisenbe]

With midzoom ... you get a load ... of these artifacts

I think you are referring to sub-optimal mapping being revealed by the new rendering, not artifacts.

In rendering, usually the term "artifact" refers to something that is rendered that was not actually found in the original data.

However, the renderings above (from the openstreetmap.de style) do not show artifacts, but accurately represent the data in the Openstreetmap database.

By showing this, mappers will notice if there are problems.

For example, the coastline should not usually cut across tidal flats (as in the second example, from the Oste river mouth), because tidal flats are part of the marine environment, influenced by the tides. The coastline should be further upstream, based on the definition of natural=coastline as the high water line (at mean high water spring tide).

The first example shows the Klusowka river entering a lake from the est, and the line between the river and lake water is mapped too far into the lake. I suspect mappers will improve this, once the problem is visible.

[kocio-pl]

By showing this, mappers will notice if there are problems.

Of course, but since this is again the same misunderstanding - any proposed rendering change will make it visible, not only particular solution with sharp water borders, which I oppose.

Please, let's discuss the differences, not shared properties of these solutions.

I think you are referring to sub-optimal mapping being revealed by the new rendering, not artifacts.

From English Wikipedia:

Artifact (error), misleading or confusing alteration in data or observation, commonly in experimental science, resulting from flaws in technique or equipment

In OSM case, the flaws are in the data, there is no such lines in observable reality, our tools are just too raw to record this.

I am not discussing particular mappers decision, just the final look with any sharp water object borders. Moving them or transforming in any way will not make the artificial sharpness go away.

[jeisenbe]

• for salt waters I'm waiting for the output of #3901, if the salt grains will have not too much contrast, they might look good enough to imitate lighter area on the first sight

We want to add a pattern for salt lakes only, since these are rare in most places and just using the lighter color will not be very obvious, though it would still provide some mapper feedback.

• I believe in the most of the use cases people see inland waters as a common type, because vast majority of the ocean tiles will never be visited by human (the ones which are not close to the land)

At low zoom levels the oceans take up a large portion of the screen, including at z5 where visitors to openstreetmap.org first start.

There's also one more tool we could use - color progress, which I think might be most useful for rivers (they are dark because on low/mid-zoom they are thin). The higher zoom level, the less color difference.

Rivers are still thin when mapped as lines even at high zoom level, and the forest color is darker then, so the problem is still there. Also at higher zoom levels the need for mapper feedback is more important so we should be willing to have stronger contrast - that's why we render so many different icons in lots of different colors at z19.

[jeisenbe]

In OSM case, the flaws are in the data, there is no such lines in observable reality, our tools are just too raw to record this. I am not discussing particular mappers decision, just the final look with any sharp water object borders.

OK, I believe you are saying that the problem is not in the data (though they examples you have shown also have data problems due to imperfect mapping), but the main problem is with the openstreetmap database model or schema: it's a vector database, so all features are made of nodes and ways: straight lines and points.

This problem is not just for rivers. Transitions between woodland and scrubland or grassland are sharp lines in openstreetmap but are rather fuzzy in the real world. Perhaps we are just already accustomed to this with landcover?

It's certainly reasonable for database users to modify the OSM data to make it look more naturalistic. Many styles, like opentopomap and openscyclemap, have waterway=river features render as smoothly curving lines, for example, since rivers normally curve rather than having straight segments. However, this style has previously rejected such postprocessing of the data, because mappers use this style for feedback on their mapping. If we modify the geometry of river areas or lines to make them appear more natural, this will impair mapper feedback. We wouldn't use curving lines for woodlands, even though that wood be more realistic.

What we can do it use a 1, 2 or 4-pixel outline for the oceans, with 2 different colors, transitioning from water-color to ocean-color - I've shown how to do this in https://github.com/gravitystorm/openstreetmap-carto/issues/3695#issuecomment-479903108 and https://github.com/gravitystorm/openstreetmap-carto/issues/3695#issuecomment-526086657, also I mentioned how it can be done technically in issue #3854

This makes the effect a little more subtle but still makes it clear where the natural=coastline is located in the database. Since mapper feedback is one of our core goals, sometimes we have to compromise: we should not have the most beautiful, naturalistic rendering, because that's not how the data looks in the database.

[kocio-pl]

We want to add a pattern for salt lakes only

I know that. This is what I would like to test also on the oceans when ready. I don't know if this test will prove it good or bad.

At low zoom levels the oceans take up a large portion of the screen, including at z5 where visitors to openstreetmap.org first start.

Sure, but it does not change what water type is common when viewing the map.

Rivers are still thin when mapped as lines even at high zoom level, and the forest color is darker then, so the problem is still there.

I don't agree with that. The river is wide enough that I can say that the problem is gone there.

It's easy for me to distinguish special buildings from the others after they are progressively muted, exactly because bigger area amplifies the differences which are too small when showing smaller areas. Otherwise, why have you changed that?

[jeisenbe]

In https://github.com/gravitystorm/openstreetmap-carto/issues/3896#issuecomment-538815504 @kocio-pl says:

the ocean looks good only with 2-color water version, it's bad (too pale) when light and I even a current version looks weak in comparison.

That was comparing the proposed ocean color to the proposed slightly darker/more saturated water color and the darker/more saturated river color.

Please explain what it the technical problem with the color. Consensus-based decision making means that we don't make decisions based on our preferences, likes or dislikes, but based on specific issues and problems with the proposed solution to an issue.

See https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-534079926:

"Coming to consensus is when everyone (including the person making an objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste."

Note: the proposed @ocean-color: #b5d7e3 Lch(84,13,227) is only 2 points lighter and 2 points less chroma than the current @water-color: #aad3df Lch(82,15,224):

[kocio-pl]

This problem is not just for rivers. Transitions between woodland and scrubland or grassland are sharp lines in openstreetmap but are rather fuzzy in the real world. Perhaps we are just already accustomed to this with landcover?

I guess we are, but this is my after-thought. With water this is evident for me.

If we modify the geometry of river areas or lines to make them appear more natural, this will impair mapper feedback.

As I mentioned, we already heavily modify line with (for example) steps and roads on high zoom levels. In both cases the original line is completely invisible.

What we can do it use a 1, 2 or 4-pixel outline for the oceans, with 2 different colors, transitioning from water-color to ocean-color - I've shown how to do this

In your examples only the water/land difference is visible, with the exception of z6 Amazon 1px, which does not look like a transition for me.

[jeisenbe]

We changed major-buildings at z14 because at z14 there is no outline for buildings. At higher zoom levels the outline is the strongest difference.

Recall that I wanted to just make them lighter at all zoom levels originally, and I compromised by keeping the darker color at low zoom level based on your preference. I would have preferred to only have major-buildings darker at z14 only (where other buildings are darker, since there is no casing), not at z15. See #3695 - title is "Lighter major building fill and outline". However, I'm willing to compromise on minor things like this.

[kocio-pl]

I don't remember this, sorry. However the outcome is incredibly good for me, and really I had to check that - perceived color for special buildings looks to me as the same on all the zoom levels! That's because the area is different.

[jeisenbe]

we already heavily modify line with (for example) steps and roads on high zoom levels. In both cases the original line is completely invisible.

for stairs we show series of short lines going across with gaps between them (instead of a continuous line), and for roads on high zoom we show an area with two lines on the sides (while hiding the real line in the middle at the same time), because we try to express something about these objects

The center of the steps and the center of the road line precisely follows the location of the line in the database. At high zoom levels (eg. z19) this is obvious: you can see that road curves are made of straight vectors between nodes, unless mappers have used a very high number of nodes for the curve.

Similarly, it would be fine to add an outline to the coastline. For example, here this makes the transition from river to ocean less abrupt. But the geometry would still be clear, just like how a road still shows you where the nodes are located (at the centre).

I'm afraid that none of the previously ocean outline examples that I've shown has been very helpful for this. Since no one commented at the time, I had not been working on the gradient idea. I can show some examples if you'd like, but recall that using the gradient requires implementing the comp-op relayering in #3854 so it would happen after the change to the river/canal color and ocean color.

[kocio-pl]

The center of the steps and the center of the road line precisely follows the location of the line in the database.

Yet this center is what you have to imagine yourself - it's not there and there are more lines which are not in the database instead. Also when the road forks, it's hard to find exact location of this node just by looking.

I don't propose variable/random gradient or anything like that, they should imagine the middle line themselves too.

[jeisenbe]

Here are examples that show how subtle the change is between the current water-color and the proposed ocean-color:

z10 Riga, Latvia current

z10 lighter ocean-color only

z10 lighter ocean-color plus new water-color (1 point lighter, 2 points more saturated)

• water-color here is the same as test shown in #3896 - #a2d1e0 (Lch 81,17,227) - a slight change: a bit more saturated but a bit lighter

z10 with #3896 - three water colors

z13 Daugava river mouth before

z13 lighter ocean-color only

z13 lighter ocean, new water-color

z13 with 3 water colors (rivers darker and higher chroma too)

The most notable change is the darker, higher chroma (more saturated) rivers, which are necessary due to issue #3896 - the ocean color change is pretty subtle compared to the current color. It's the changes to rivers that make it noticeable.

[jeisenbe]

Following-up, here is another style that shows oceans differently than rivers/lakes, though in this case the oceans are more saturated and a little darker, oddly:

OPNV-karte (public transport) https://www.öpnvkarte.de/#25.3896;57.3317;7

That style also uses rather dark woodlands

[imagico]

Just as a reminder: The three water colors of the ac-style were designed for a somewhat different color environment in several aspects and i also tuned them after some time after getting rid of the blue transport symbol color - which previously formed one of the main constraints in color choice.

These colors are not necessarily the best choice here in the current color design situation. I would very much welcome any tests trying different colors. But i am also pretty sure this is much harder here now than it is in the ac-style because of the landcover color fading and other design choices creating a much more complex environment to adjust colors to.

One constraint of course always is that using different colors only makes sense if they are clearly discernible in rendering.

[kocio-pl]

Thanks for the reminder, @imagico. I was thinking to propose my set of colors, but @jeisenbe was fast as always and with https://github.com/gravitystorm/openstreetmap-carto/issues/3896#issuecomment-539999169 it looks much better for me. Of course on small area samples with no common borders they look more similar than in reality, when areas can be much bigger and there are multiple water junctions:

Together with 3 px ocean gradient outline it is the minimal set that would meet my needs. This is just a quick look and there can be some tuning, but at least it's very promising.

Referring transport map water rendering: it is distinctive and brave set of colors, but it reminds me Comic Sans font - it is also like this, but I would not use it for anything neutral, mainstream or standard.

[jeisenbe]

OK, I will submit a PR to just add @river-color: #8fcadd; // Lch(78,21,227) for now, and then we can discuss further how to improve the ocean and lake color to get enough contrast but not too much. And we will continue working on the new gradient / line for the coastline: then the next step is to try https://github.com/gravitystorm/openstreetmap-carto/issues/3854#issuecomment-525969407

[imagico]

Another note here: The color scheme chosen in the ac-style is based on a linear progression of colors with ocean and river having twice the difference as ocean and lakes/lakes and rivers. You could try to use an equidistant set of colors where all three colors are have approximately the same difference to each other. But that could be less intuitive overall.

[jeisenbe]

@kocio-pl wanted a reminder of the reasons for showing the sea differently than lakes and waterways - see comment in closed PR #3930

1) The location of the natural=coastline should be clearly visible to provide good mapper feedback

• This is the most basic feature of the map, especially at low zoom levels: all islands and countries which border the sea are defined by the shape of their coastline, in our mental maps.

2) There should be a visible difference between sea water and inland fresh water so that mappers will see the location of the coastline even when it is adjacent to natural=water or waterway=riverbank

• Right now it's not clear when someone moves the coastline a long way, as long as they replace it with natural=water areas. This can be a big problem at areas like mangroves or estuaries; see my sad experience of hours of work lost as described previously.

3) The color of the seas should be less intense than inland waters, since they take up a very large part of the rendering at lower zoom levels

• As mentioned in #3896 - waterways need to be dark so that you can see them over darker background like woodlands, scrub, golf courses, quarries, landfills, etc, and you have to be able to follow the thin line at lower zoom levels.
• But using a really dark color for the ocean is strange: then at low zoom levels the ocean is much more prominent than the land, since @land-color is light.
• By using a lighter, less saturated color for oceans and a darker color for rivers, we can get a good rendering for both features. This is very common on printed maps, as mentioned in examples previously.

Looking back at the comment above, I'm again confused how we lack consensus on this issuse; https://github.com/gravitystorm/openstreetmap-carto/issues/3895#issuecomment-540133740

"I was thinking to propose my set of colors, but @jeisenbe was fast as always and with #3896 (comment) it looks much better for me. ... This is just a quick look and there can be some tuning, but at least it's very promising."

That comment was why I submitted PR #3930. I don't understand what changed since then.