Render ocean areas lighter, and river areas and lines darker

[jeisenbe]

Fixes #3896
Fixes #3895
Helps improve #1781
Required for #3926
Prerequisite for PR #3670

Changes proposed in this pull request:

• Create darker and more saturated river-color #8fcadd Lch(78,18,225) for river & canal areas, and ditch, drain, stream, canal & river lines
• Create ocean-color #b9d3dc Lch(83,10,227) for salt water areas including seas and salt_pond areas

Explanation:

• As mentioned in Rivers and canal lines and areas should be darker than other water areas #3896, rivers need to be darker so that they can be clearly seen at low zoom levels on darker backgrounds like forests. This makes it possible to merge PR Simplify low-zoom landcover rendering to 4 main colors (requires 3 water colors) #3670
• Oceans can be lighter and less saturated because they take up a larger area on the screen in most places and scales.
• Distinguishing rivers from lakes and oceans will help improve mapper feed-back about correct tagging of water areas
• Distinguishing salt and fresh water will also improve mapper feed-back about the location of the natural=coastline limit and tagging of salt water
• This would also make it possible to implement Restore linear coastline rendering #3926 if desired.

Test renderings##

Wales

• https://www.openstreetmap.org/#map=14/51.6192/-2.9391

z14 before

after

z13 before

after

z12 before - Newport

after

z12 before - Cardfiff

after

z10 before

after

[imagico]

The colors you chose are the original color set i also used initially for the three color scheme for water. See #2654 (comment).

However after i got rid of using blue for transport symbols and cycleway - which posed a significant constraint color wise - i moved to a different color set which is overall somewhat stronger and constant hue for all three colors. See imagico@0acdd0d

This is supplemented by using #199ec5/#24a6cc for water related symbols.

For comparison:

http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker#b9d3dc,aad3df,97c9d8,b5d7e3,a2d1df,8fcadd,24a6cc,199ec5

[jeisenbe]

Here's with the suggested, slightly higher chroma colors with hue matched at 227 (the ocean color is also a point lighter, and water-color is a point darker):

I do prefer this slightly higher chroma for the oceans, it looks a bit nicer.

[kocio-pl]

How this proposition solves the problem of connections between different water styles? The renderings above do not show that.

[jeisenbe]

Solving #3926 would be possible, but requires #3854 first - and that issue should be solved after this PR.

[imagico]

It would be highly valuable if we could get this change out. Lack of consensus and edit wars on coastline placement have strongly disturbed coastline data processing recently - see the various links provided in discussion here:

https://www.openstreetmap.org/user/JesseFW/diary/393709

Us providing precise and clearly readable visual feedback on the coastline positioning would help mappers tremendously in developing consensus on mapping and establishing a consistent coastline placement. Doing so is one of the core tasks of this style.

The colors proposed by this PR were my selection originally but i would not mind a different set of colors if that leads to consensus as long as the colors remain clearly differentiated towards each other and there is good contrast between in particular waterways and our landcover rendering.

[jeisenbe]

Ok, does anyone want to give this a positive or negative review?

[imagico]

As is ferry routes are not working - see:

A tongue-in-cheek fix for that is available in 753fb09 but there might be better options to fix this as part of #3854.

[imagico]

@jeisenbe - do you intend to fix the ferry routes? I think the approach i linked to is fine, we could look at it again in connection with #3854.

[kocio-pl]

It was not clear to me from the included images, but in the current state this change introduces artificial edges between river-type water objects (line based) and lake-like water objects (areas based). This is exactly the same problem as I talked before:

The fix could be to change the water color for all the water different than ocean (of course the gradient for borders between the ocean and the other water objects is needed, so the other patch should be merged in parallel).

[kocio-pl]

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

[jeisenbe]

I am happy to implement the solution for ferry lines suggest in 753fb09 but first we need consensus on whether or not rivers, lakes and seas should be rendered distinctly.

@kocio-pl has again mentioned that he does not like the way this looks and the fact that it emphasizes some existing problems and controversies in the database, like the proper location of the transition from river to lake or sea.

I would like the other maintainers and contributors to comment as well. My impression is that @kocio-pl is voicing an idiosyncratic view which is not the consensus. (Also see the previous discussion about this in issues #3896 and #3895 - plus in PR #3930 which previously implemented this same idea, and in #3670 which requires this PR as a prerequisite)

[jeisenbe]

ocean/river border looks even worse than river/lake border without the gradient line:

We discussed this before, where I pointed out that the same thing happens with areas of vegetation. Often there is a gradual transition from wood to scrub in the mountains, or grass to sand in a beach or desert, but of necessity we show these as an immediate change in the color, since the database objects are lines or areas modeled as a series of nodes connected by straight lines.

We do not attempt to smooth the shape of roads or rivers, even though these shapes are curves in the real world, because we want mappers to see the underlying data, which is a series of nodes.

Prior discussion: #3895 (comment)

[jeisenbe]

As a reminder, these are the reasons we should distiguish the seas (outside of the coastline) from rivers / lakes:

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 Rivers and canal lines and areas should be darker than other water areas #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.

4. If we have a color for seas, we can also use this color to help distinguish salt lakes and lagoons from fresh natural=water features; see discussion in Render water areas differently when tagged salt=yes #3893

Here are 3 main reasons to show rivers differently than lakes and other water bodies:

1. River and stream lines need to be more visible so that they can be seen at low zoom levels when over dark landcover like forests. Rivers and other waterways are long and narrow, which makes it harder to follow them than large water areas like lakes or the seas. For the same reason, river areas should be darker and the same color as river/stream lines

2. Areas of waterway=riverbank and water=river should be distinguished from lakes, reservoirs, ponds and other non-flowing water bodies.

• This makes the map more legible by clearly distinguishing waterways (like rivers, canals) from lakes and seas. Since waterways need to be darker/higher contrast with landcover, due to point 1 above, lakes can be a bit lighter and less chroma.

3. Mappers should get feedback about river areas that are missing water=* tags.
   In the past waterway=riverbank was the standard way to map all rivers, but now a number of editors are using natural=water, so water=river needs to be added. This can be easy to forget, so mappers need visual feedback from this style to make sure that the tag isn't missing from some segments of a river.

[georgek]

A far better solution to this is to leave the fill colours the same but render a dark line for the edges, ie. a river bank or coastline. This would solve the problem of river visibility at low zoom levels as well as provide the much-needed mean high water level in tidal areas.

For example:

[jeisenbe]

render a dark line for the edges, ie. a river bank

I previously lookind into this. Unfortunately it is not technically feasible to do that without pre-processing, except by significantly widening the size of the river area. While this would not be noticable at high zoom levels, the place it is needed is mostly at mid-zoom levels because of #1781 (rivers, fjords and narrow lakes are hard to see in dark landcovers like forest and woods).

If we add a 2 pixel wide outline, this would give the false impression that the water area is that much larger than it is in real life (perhaps 100m or even 1km at lower zoom levels), and this makes the feedback worse for mappers while impairing map usability. This will also increase the risk that the outline will overlap a road, railway or other feature is rendered later, thus hiding the outline.

If you want outlines for only the seas, this is possible, because we already have pre-processed polygons for those, but it requires changing the layering (as discussed in #3854 and shown in #3695 (comment) and following comments) But to add it for lakes and rivers, one would need to combine all adjacent polygons first, otherwise you will get lines across rivers where there is a split in the area - this commonly must be done to avoid creating unmanagably huge multipolygons for long rivers.

[georgek]

I looked into it too and, yes, due to the way OSM has been tagged using multiple adjoining polygons as "riverbanks" it is not possible. I have tried, and so far failed, to try to get people to map riverbanks instead of "river areas". With only a slight change in tagging, rendering the edges would be trivial (instead of rendering the edges of multipolygons, just render a line for the way tagged as the bank).

If we add a 2 pixel wide outline, this would give the false impression that the water area is that much larger than it is in real life (perhaps 100m or even 1km at lower zoom levels), and this makes the feedback worse for mappers while impairing map usability.

This is already the case for roads. Why are waterways second class citizens here? At low zoom levels it's not about knowing the exact width of a waterway but merely being able to see that one is present.

[imagico]

Please do not side step the discussion on this PR with the unrelated matter of outline rendering. If you want to suggest other improvements of waterbody rendering in this style i suggest to open an issue for that - though the matter of outline rendering of waterbodies has been both discussed and tried extensively (a summary can be found in #1781 (comment)) - without convincing results in the vast majority of cases - and all promising attempts are inherently incompatible with real time updating and the requirement of precise and intuitive mapper feedback.

As @jeisenbe says qualified opinions on the matter of this PR as well as suggestions for improvements would be highly welcome.

[georgek]

I'm not side stepping the discussion, I'm trying to contribute by suggesting an alternative rather than just posting something negative about this proposal. But since you asked for my opinion: this is obviously horrible due to introducing arbitrary, and ugly, boundaries between rivers and oceans (as pointed out by kocio-pl).

There is no such physical thing as a coastline that crosses a river mouth. It is something arbitrary that we do for practical purposes, but it doesn't exist. So why would we want to draw attention to it? There's no line where fresh water starts. There's no line where the tide stops.

Attention should instead be drawn to things that do really exist, which are:

• Areas where your feet will get wet (water). What makes river water different from ocean water? Well... many things, but there's no sharp line between them and the most important thing is: it gets your feet wet.
• The edges of the water (banks, mean high/low water level). This is what is missing in OSM right now. Nobody maps the edges, only the areas. But the edges are just as important. They can contain lots of important information, such as whether you can moor there, whether it's tidal etc.

You can't argue about things that actually exist.

Not only is this drawing attention to things that don't exist, the justifications are conflicting. On the one hand it's for being able to see rivers better at lower zoom levels ie. a cosmetic change for map viewers. But on the other hand it draws attention to the coastline for map editors, despite being ugly.

[imagico]

Thanks for the comment. Unfortunately this does not lead us any further because it essentially just reiterates a discussion we have had a long time ago (that is if cartography is allowed to use discrete classification systems) as well as delving into tagging discussion (i.e. if mappers should be allowed to use discrete classification systems and if we should support such endeavors).

@jeisenbe above in #4128 (comment) nicely summarized the current state of discussion. I suggest to take that as a starting point for anyone who wants to argue either for or against this change.

Suggestions for alternatives are welcome as well but they

• should be made in a separate issue and not in this PR
• should substantially address the problems this change tries to solve
• should be concrete, technically feasible suggestions - we have had vague promises for alternatives for more than a year (here and here) and nothing ever came out of them, they were just stalling.

[Bibi56]

Distinguishing salt and fresh water will also improve mapper feed-back about the location of the natural=coastline limit and tagging of salt water

One issue is that natural=coastline is used by some mappers as administrative border leading to edit wars issues (Rio de la Plata). Clarifying the status of natural=coastline would help for a more consensual tagging (whatever the result is). And indirectly give hints about this PR.

[imagico]

Looks fine now - except for the accidental partial revert of #4060.

[imagico]

Looks good now.

I would like us to actively anticipate reviewing and tuning the exact choice of colors made here in context of changes we might make in the future (in particular #3670 but also #3468, #3707/#3840/#3854, #3926). While i think the choice of colors is decent it is prudent to expect there to be room for improvement.

This change will make moving away from using blue color for cycleways and transportation symbols more pressing (see #1793 and #3631) because the stronger blue for rivers is closer to these colors.

[kocio-pl]

No changes has been made with main problem (introducing artificial water borders), so this code is still not ready for merging. I don't see a clear message how do you plan to address this? Especially after getting direct input from the OSM community, which is our target audience.

[imagico]

I would like to ask @pnorman, @matkoniecz and any other maintainer who feels like it to have a look at this change and give their opinion. Both @jeisenbe and me think this is an important change - cartographically as well as in terms of mapper feedback - @jeisenbe summarized this well above in #4128 (comment). Just as an additional data point:: We are talking here about the fundamental distinction between the world ocean covering two thirds of the planet as mapped with the coastline and inland waterbodies - which are among the most widely mapped features in OSM with >10M natural=water polygons and >20M waterways, exceeded only by buildings, addresses, roads and trees.

The only sustained argument against the change that is being made is that it shows allegedly artificial, arbitrary and ugly boundaries. Discrete classifications are however a fundamental component of mapping in OSM and cartography in general, we widely visualize discrete classifications that can be considered to be arbitrary with sharp boundaries in OSM-Carto (natural=wood vs. natural=scrub, landuse=commercial vs. landuse=industrial, natural=grassland vs. natural=heath just to name a few) and the classification we would start to visualize here is better defined and more consistently applied globally than any of the other classifications mentioned.

Any concrete and practically viable alternatives to the proposed change in terms of either solving the design issues this is trying to solve and in terms of differentiated mapper feedback for some of the most important and most widely mapped features in the OSM database would be highly welcome.

[imagico]

Reminder to @pnorman and @matkoniecz (as well as any other less active maintainer who wants to chime in and has not yet done so) about this. We are currently lacking consensus on the strategic direction of this style w.r.t. color design. #3670 and many other color decisions we make hinge on if we can establish consensus to do this change (or find a concrete viable alternative to address the issues this is meant to solve).

[pnorman]

It's on my to-do list, but will require a fairly extensive review.

[pnorman]

as well as any other less active maintainer who wants to chime in and has not yet done so) about this.

Non-maintainers are also welcome to review.

[pnorman]

So, this took awhile to get to and review. Most of my mapping takes place between Vancouver and Seattle, and I commonly encounter river/ocean intersections.

I can't agree with rendering the line between natural=coastline generated water polygons and waterway=riverbank/natural=water. My long-standing experience is this division is chosen for the convenience of mappers and should not be assigned great meaning.

There are places where I would like to draw greater attention to the location like Río de la Plata, but I’m not sure this is the way to do it, and if it were, I don’t believe it is worth the downsides.

I do like the new colour used for the rivers and would support using that universally, which would unblock #3670.

[imagico]

I do like the new colour used for the rivers and would support using that universally

I had looked into that before and i don't think this would be a good idea. As said before the color would be very heavy on larger areas and this way would create an overall imbalance and would make styling things to work both over land and over ocean or lakes fairly hard in the future.

[imagico]

Followup question to @pnorman - in your review you discuss exclusively the differentiation between ocean and inland waterbodies, i.e. #3895. Is your view the same on the differentiation between flowing and standing inland waterbodies?

The reason i am asking is that while the distinction between ocean and inland waterbodies is the ecologically and cartographically more meaningful one (and the one more frequently made in classical maps as well) it is the one where data users depend much less on OSM to provide data on. While this is not trivial it is perfectly manageable (and i have mentioned elsewhere that i meanwhile do so) to make this distinction using external data sources and heuristics independent of what is mapped in OSM. The flowing/standing water distinction OTOH is much harder to make for data users without OSM providing meaningful and consistent data on this difference. You could also argue that the lake/river distinction is much easier to verify on the ground and that mappers making this differentiation with diligence much more depends on us providing visual feedback because tagging does not require them to make this distinction (they can tag everything natural=water) while for the ocean it does (natural=coastline vs. natural=water).

[pnorman]

Followup question to @pnorman - in your review you discuss exclusively the differentiation between ocean and inland waterbodies, i.e. #3895. Is your view the same on the differentiation between flowing and standing inland waterbodies?

I think the distinction chosen by mappers is generally meaningful here, and would be okay with showing it. The edge, where a river meets a lake, would still need to look good.

[imagico]

I think we might be getting somewhere.

The edge, where a river meets a lake, would still need to look good.

Does this mean you think the proposal by @jeisenbe is lacking in that regard? Here for direct comparison the proposed design and how swisstopo 25k maps render this:

[pnorman]

I think it looks acceptable where rivers meet lakes, although not great.

[imagico]

As said before - any concrete practical ideas how this could be improved would be most welcome.

[pnorman]

As said before - any concrete practical ideas how this could be improved would be most welcome.

I don't think we can get beyond acceptable for the appearance, and that's not a barrier to merging.

My main concern was drawing emphasis to the natural=coastline boundary, not to any waterway=riverbank/natural=water+water=river vs natural=water water=lake ones.

[imagico]

@jeisenbe - would you be fine with and would you have the time for modifying this PR to limit its scope to the flowing/standing inland water distinction?

[imagico]

ping @jeisenbe.

[pitdicker]

The idea of a background line is that it covers the dashes that are in an different position from another ferry line. Using dashes for the background line defeats the purpose, it should just be solid.