Create darker river-color for river & canal areas and ditch, drain, stream, canal & river lines #3930
Conversation
The color of river, canal, ditch and drain lines is changed to #8fcadd to be more visible over forest and other dark landcovers The color of river and canal areas is changed to match. This also improves mapper feedback about tagging of water areas
|
Årdalstangen, Norway
z14 before z14 after Førde, Norway z13 after z15 before z15 after |
|
Bremerhaven
z14 before z14 after |
|
Note this significantly interferes with implementing #3854 so we should make a choice of either first implementing water color differentiations or first implementing #3854. Mixing the two things would complicate making changes. I am open to either variant. I have not tested it yet but do i read the code right that you differentiate rivers and non-rivers but only if they are non-intermittent? That might be a bit confusing for the map user. |
Only the areas are not yet distinguished, the linear renderings all use the new I was too lazy to make and test a new file for intermittent river areas so I just kept |
I'd be happy to do either order, but #3854 is more work, while this PR seems to have a good chance of being accepted soon. Also I thought it would be easier to settle on the new water colors before trying to adjust the rendering of intertidal features. |
Yes, i understand. But then we should afterwards come to a consensus on the other water colors (ocean/lakes) before going to implement #3854 because otherwise we would first need to implement #3854 with a two color scheme for water and then possibly upgrade it to a three color scheme which is a lot more work. |
|
In reference to #3926 (comment) - in case you are not aware, this is how your above samples look like to me in the browser: |
|
Crazy, that's quite different that what I'm seeing. The ocean color is #A8D3DE in both the original images according to the color picker in Terminal. Perhaps this happed because the "before" pictures are screenshots from a 1.0 opacity overlay of the current rendering, and the "after" are exports from Kosmtik? I'll avoid doing this in the future (I'll lose this nice fiberoptic connection in a few days anyway, so it's back to rendering everything instead of downloading tiles) |
|
We could still do part of #3854: the re-layering and use of Then there could be a second PR to adjust the rendering of all the features over water and remove the mud transparence once the new colors are settled. |
|
The fundamental problem I have with this solution is still the same - the inner water borders are sharp. The rendering color shift is what I get when using Chromium/Chrome, it is known issue with this browser. That's why I also tried to export from Kosmtik. |
I'm happy to fix this for the ocean/river border with #3926, but that's only possible after we start using the darker river color. Recall that in the past we only had the outline for land polygons from z0 to z7 because at mid and high zoom levels there was a strong line across the river/coastline transit. To avoid that, we have to change the river color first. |
|
I have to recall this when I have a bigger bit of conciousness, at the moment I don't remember this problem. But this means that I'm looking for gradient border on inland waters first. Since riverbeds are usually constructed with multiple polygons it does not seem reasonable to use border around them, but for the rest of the inland water it sounds OK for me. Of course any other idea might work too. |
As you mention, this isn't feasible for rivers since they are always made of multiple polygons. It would also show rendering artifacts with lakes which are mapped as more than one polygon. That practice is still somewhat common, especially in areas with many interconnected lakes, so I do not believe it is a good idea. The plan is that there will be only half as much contrast between rivers and lakes as between oceans and rivers, so I don't see a problem here: z14 after this PR z15 with 3 water colors (first tests)
z15 lower contrast 3 colors
|
|
Try z19, please, and without bridge near the junction, this would be much more reliable test of this effect. |
|
Good testing places (even without reaching z19): |
|
I've already done a couple tests on z17 (just in the higher-contrast 3 color style): z17 Afon rhythallt river-lake transition before
z17 high-contrast 3-color z17 Sure river-lake border before
z17 after (high-contrast 3-color) |
|
https://www.openstreetmap.org/#map=19/53.04425/8.87248 Higher contrast 3 colors |
|
It's difficult to find places without a bridge, dam, weir or lock: https://www.openstreetmap.org/#map=19/53.03678/8.87313 Higher contrast |
Mapped badly: the river-lake transition is a few hundred meter out in the lake. We should not use poor data for testing
Incomplete: the wide part of lake is tagged like a river, but the narrow part is tagged like natural=water only, so it looks backwards currently (screenshot from openstreetmap.de):
|
|
I have general question regarding water data in general, since you were making these comments in different cases lately - how do you know it's really badly mapped? And the second one - if we use different colors for water, aren't you afraid people will start moving inner water borders so they look nicer (real mapping for rendering), especially to make the border small and unintrusive? This does not mean I would be against lower contrast with gradient, I just like to be sure we know what we're choosing and what are the downsides of the choice. |
Re: lake-river transition: a river has flowing water, a lake doesn't. The boundary between this two should not be out in the middle of the lake. This is how the riverbank in first example is currently mapped: https://www.openstreetmap.org/relation/1348576#map=14/12.5875/104.4208 The line goes around a peninsula and along the edge of the marshes. I suspect this was mapped coarsely originally, and has now been improved somewhat but still needs more work. This way still goes around the entire 100km long river: https://www.openstreetmap.org/way/378290382#map=12/12.5671/104.5050
In some cases they will need to be moved because the current data is not accurate, and often that will improve the rendering. But most of the current data is quite good. It's the less accurate examples that stand out. |
|
Thanks for the answer, but this is not exactly what really interests me. Maybe I will rephrase it: what is the source of your knowledge about water borders? Is it because they look bad or something else? It is also a question for @imagico: do you believe these borders need to be fixed and why? How do you know where is their (exact, I guess?) location? |
|
The taggings the different colors depict indicate different ecological and physical waterbody types. In this case riverine systems where gravity induced water flow is the dominating water movement and standing waterbodies with usually some form of stratification and/or free circulation induced by wind. These are typically locally observable properties (you can see the water flow) and the incentive for mappers to obtain an optically pleasant map rendering will usually align with what is physically accurate - in other words: The physically correct delineation of the flowing and standing water domains tends to also be the most agreeable and intuitive in map display. As said before this is essentially no different than other classifications that are being made in OSM - like natural=wood vs. natural=scrub or landuse=industrial vs. landuse=commercial. (i kind of thought we had already settled this since you agreed that in principle the differentiation of different waterbody classes is something you support in #3895 (comment)) |
|
You're right, I don't withdraw my agreement in any way. I just wanted to ask about your take about some examples illustrating real life problems, which can be interesting to extrapolate on many others similar cases, like this:
When talking about moving/standing water border it seems that this is more correct in most of the cases, since I suspect water still moves there:
|
|
Your questions are mostly related to tagging and mapping, not to rendering so i am reluctant to start a discussion about these here. The idea of differentiated water rendering is based on what is currently tagged and mapped - which as i mentioned before i think is done quite consistently. Same as for natural=wood and natural=scrub or landuse=industrial and landuse=commercial.
Apart from as indicated this not being about water speed but about the ecological and physical characteristics of the waterbody - No. Mappers as explained do differentiate the different waterbody classes and globally seen they do it quite well (in case of the ocean/coastline i would even say extremely well). There is IMO no reason to assume they'd stop doing that because OSM-Carto starts acknowledging their work in rendering. It is not that the colors suggested are so different that mappers are likely to have strong preferences and for example think: This color is not suited for a lake so i am going to re-tag it as waterway=riverbank. If a mapper tags a lake For mappers who don't care and just tag any waterbody with some tag to make it blue the best we can hope for is that the differentiated rendering encourages them to inform themselves on accurate tagging and encourages them to use it. |
|
OK, thanks for responding anyway, I'm not too much into discussing it, rather asking about your position on (inevitable, as always in the real world) problems. My impression is that you don't worry, whatever mappers will do with it, you trust them when it comes to position of water borders. It is essentially on a par with my general laissez-faire attitude, so I don't complain, I'm just surprised that you don't see any potential data problems as usual. Nothing to discuss, though. I just confirmed that you're comfortable with all the consequences and the given example does not bother you. I'd like to ask something else (if you're interested in explaining a bit more) - I'm just curious, they are "consistent" with what and "excellent" measured how exactly? I mean, how do you personally evaluate the quality of water borders? What benchmarks do you use, not being able to see the water yourself in most of the cases? Are satellite images of special use here, for example, when the definition you gave is so complex? @jeisenbe, I'd like to hear your position on the data errors and possibility that people might start relocating borders just to make them small and what is your reference to say if data are bad (sorry for repeating the question, I'm just still interested in hearing that)? |
|
Consistent means consistent use of tags by mappers as it has been discussed in a lot of cases in case of feature additions in this style. If different mappers use the same tag in the same way according to the same understanding what it means and the same view of the geographic reality that is consistent use. The ocean/coastline mapping being quite excellent in its consistency is owed to the fact that there are a lot of people performing routine quality checks on coastline mapping and because the coastline data is one of the few feature types in OSM that is routinely processed on a global level. You can see that by comparing it to other data sources. That there are a few cases world wide with really blatant inconsistencies does not diminish that significantly. My view of the likely effects of differentiated rendering of different waterbody classes is not a laissez-faire attitude, it is based on what can be expected from the experiences we made with various other cases of providing visual feedback to mappers. And the idea of providing positive feedback on mapping consistently performed by mappers already to a large extent is part of the primary goals of this style. Should this expectation be disappointed and the data quality degrade as a result of our rendering decision we could and should of course revisit that decision. |
|
@jeisenbe I'm puzzled, why have you merged this code? I thought I made it crystal clear that it's not ready quite early with #3930 (comment):
and they still are. |
|
It would be helpful in the future to formally request specific changes if there are objections to a PR. The linked comment was made 15 days ago. I responded to it #3930 (comment) - "I'm happy to fix this for the ocean/river border with #3926, but that's only possible after we start using the darker river color. Recall that in the past we only had the outline for land polygons from z0 to z7 because at mid and high zoom levels there was a strong line across the river/coastline transit. To avoid that, we have to change the river color first." (emphasis added) It's not possible to make the coastline linear gradient unless we first change the river-color. Since it is recommended to make small PRs, I could not include that change in this PR, since major layering changes are required. 4 days ago, I commented #3930 (comment) "Both @kocio-pl and @imagico have commented on this PR in generally positive ways, but it's not yet approved. Any chance of a formal review this week?" - which described my understanding of the situation. There was no response requesting any changes except for imagico's request to change the intermittent water pattern, so I thought that meant there was consensus. |
|
Sorry, I try to make formal requests most of the time, but I don't want to make more tension when discussing then necessary. And I thought in this case you know what I accept and what I don't, which appears was not true. I don't understand where did you find me commenting this in a positive way? In my opinion this was a critical review all the time. The only positive thing I remember was in response to "since you agreed that in principle the differentiation of different waterbody classes" - and yes, I still support this principle (you're right, we got the consensus here), but not this implementation, you have probably mixed these things. My approval is conditional and relies on the soft border rendering. This condition is roughly OK for ocean and seas, so I approved that, but for inland waters the border is still sharp, so I'm still against. OK, back to the current point. My concerns about people moving lines to just look smaller are further amplified by your responses - Christoph gave no clear rules and only rejected one (speed of the water), and you mentioned only high water level, which is about water/land, not how deep river goes into the lake for example and what shape does it make, so you gave no easy tools for people willing to verify borders, which is bad. So it becomes more important that people don't see artificial strong lines if they decide the line should be long. They should be not pushed by visual solution which is suitable only for small borders (and even then it's inferior). I propose to revert this code and make a new release (4.24.1 or 4.25.0), which could be deployed any time, so we could get back to the work with inland waters implementation. The possible solutions I see are:
The first one is technically more complex, but it allows making soft borders and is vector friendly (it does not rely on any special, innovative rendering features) and is fallback friendly too (if it breaks, we simply get the hard borders). The second one needs some more testing around the world and does not have to stay forever, once we have the proper solution. |
|
Thank you for suggesting specific changes, this is helpful
In the past the use of preprocessed data has been rejected by @pnorman and others, because it increases the complexity of maintaining, using and adapting this style. (However, this is only really necessary to show an outline around river areas, not for the ocean or lakes.)
This is certainly possible as an intermediate step, but I don't understand which problem it will solve?
The implementation is simple: water=river, water=canal and waterway=riverbank areas as well as waterway=* lines are changed to The objection appears to be to releasing v4.24.0 before other PRs were made and accepted? I has been said that it is better if a PR changes one thing at a time, rather than changing many features all at once - I have made this mistake before, and am trying to improve. It would be hard to continue development if a large number of changes have to be accepted all in the span of one release. Many of the maintainers do not have time to review multiple PRs. In the past we have usually made incremental changes over several releases, even when the individual changes do not make an improvement. For example, the ST_PointOnSurface PRs have resulted in worse label placement in some cases, but they will eventually allow vector tiles so we have been willing to accept this. |
It will allow us to show ocean/inland border the way we have agreed, exactly.
Of course, the objection has been raised exactly about the fact that it's too simple, not to any part of this change. It's just lacking an important part. Please, let's focus on it.
My objection is that this change is not agreed upon, it has nothing to do with other PRs.
I appreciate that and I'm happy with how do you handle such things now - thank you, Joseph. Oceans PR just depends on this code and that's fine, it's better than one big chunk.
But we have fully agreed on that and such decisions are made on a case by case basis. not as a general rule. My reason was that vector tiles is a big, long and complicated goal, which has the potential to resolve many of our disputes (what color should it be? how many icons we can show? from what zoom level?) and fix some serious problems (rendering names in different languages). It was worth to make such compromise, even if I don't like the current rendering of labels. But if they would go outside the boundaries, like it was before, I would be against instant changes and would concentrate on fixing rendering first. With this change it's much simpler and I don't fear it will take years to resolve, like the vector case, so I think it is not worth pushing such raw changes on a fast path. Why do you think we need to hurry up with this? |
I don't understand. If you mean that we should add the gradient line around the coastline, it's not necessary to change the color of lakes to do that. (It might actually be possible to do a gradient line for lakes right now, though I'm concerned it may cause problems at some rare places where 2 lakes are connected without a river in between)
I don't understand this part. Do you mean the PR to render oceans in a slightly lighter color, which I've previously suggested? Or the relayering in #3854? Or the coastline gradient? I would like to know what you are requesting as a next step. |
I'm also very concerned about this. That's the only reason why I don't want to merge ocean PR right now.
I mean missing a gradient on the water borders. In a case of this PR, only internal waters.
I have proposed how to resolve the problem of sharp water borders - if you don't like to involve preprocessing, then making all the internal waters dark is what can be done, so I would go with that. |
|
So you are saying that you are more concerned about where lakes meet rivers, rather than at the coastline? I did not get that from the previous discussion. So far there has only been 2 examples shown where the transition between a lake and a river would look unusually: that was the large lake in Cambodia where the river area had been mapped coarsely with a single, large outline originally, and then later was made into a multipolygon, but the transition between the lake and river wasn't fixed when the rest of the area of updated (probably with better aerial imagery). There was also an areas where the lake and river were not tagged properly yet - see #3930 (comment) - There are going to be some examples of missing tags which are shown by this change, as with any time that we render a new feature. I do not believe there is a valid issue with showing a difference between the colors of lakes and rivers, and more than in showing a difference between heath and scrub areas. This style should represent accurately the geometries in the database. Adding a gradient around the coastline is something that could help distinguish the location of the coastline, but it's not necessary around lakes, and even for the coastline it's a "nice to have" feature. |
|
Do you think this PR should be reverted? |
|
My view here is that I think @jeisenbe did nothing wrong in his principal approach and that both me and @jeisenbe have to some extent misunderstood the comments by @kocio-pl - which was probably at least partly because they were somewhat unclear and contradicting (at least from my point of view) @kocio-pl - the way i read your comments now it seems you kind of say you support differentiating different classes of waterbodies but you don't want this difference to actually be explicitly visible. This seems a contradiction to me. What i think would make the situation much clearer is if you either
Either of these would give a positive perspective on how to move forward. As far as reverting the change is concerned - i am probably not the right person to decide this. But i am kind of with @jeisenbe here that this change is the logical first step for any design strategy towards differentiating different classes of waterbodies - you cannot differentiate without differentiating after all. In other words: Reverting this change would not actually solve the problem of us needing to come to an agreement on the actual design decision. |
Yes, nothing new from #3930 (comment). I see no reason for the rest of the code to not be deployed soon, while we keep discussing inland waters.
I think you're oversimplifying the problem. Real geometry of the database is sometimes hidden - deliberately, I suppose. For example we hide waterways under water areas (the intermittent case is an exception here). Also when I suggested outline for the lakes, we would see the actual geometry of all the parts used there, but this was exactly why you rejected this idea.
I think you're getting me right, but where do you see the contradiction in these claims? It's similar to "I like this color, but not so strong (explicit)".
I don't understand what do you miss from my propositions. In my opinion the code from this PR does the good job with showing different classes of waterbodies, but it also does the bad job of suggesting the solid difference, which is just an artifact. What I want is to keep the good things while not introducing bad things.
Making all the inland water darker fulfills this requirement and this is what I proposed lately as an alternative take, which also fulfills my requirements.
For me adding a gradient for the coastline is a minimal solution that made me accept this code, as long as there is no hard water border, which is my primary concern. The fact that it tunes the coastline rendering back to the previous state is a nice to have feature for me. I hoped you all understand that and I wont have to repeat what is the fundamental problem in every comment, but it looks like I have to repeat it. So please make a very simple test - just check if any given solution shows the soft water borders or not, and you instantly know whether this moves the proposition forward (or not). |
Reverts PR gravitystorm#3930 which changed river color to #8fcadd for waterways and river, canal areas
|
I've opened #3955 which would revert this PR. |
We can not show everything in the database. When there are 2 features in the same place, we can only shown one of them at a time. With waterway line in water areas, the mapper feedback would be best if we put the line on top, but this would violate map users expectations, and would encourage mappers to incorrectly delete the water lines after mapping water areas to get a "proper" rendering.
I think this is a misunderstanding of the history. I mentioned the outline to try to compromise and meet the request to not have a "sharp" meeting between river-color and lake areas, but I mentioned that sometimes it might show a line between two adjacent lakes, and this was rejected: "@jeisebe: It might actually be possible to do a gradient line for lakes right now, though I'm concerned it may cause problems at some rare places where 2 lakes are connected without a river in between." It would be ok to show a line between lakes in theory: since we render a text label for each lake mappers already have an incentive to map lakes as one polygon or closed way. I don't think they would remap them due to our adding an outline. But I did not mention this option before because I do not think it is necessary to show an outline for lakes. We should not show a line between different river polygons, because rivers are properly mapped as a large number of separate areas. A single huge polygon, extending for 1000's of kilometers in the case of the Danube or Mekong, would be hard to maintain and hard to use, so mappers rightly have chosen to map rivers areas as many smaller segments (just as the waterway is broken up in 10 to 20 kilometer pieces). The proper expectation of mappers is that this will be rendered as one continuous feature.
I find the frequent request to use visually weaker colors is a frequent problem in reviews here. See the issue #3647 for examples of many times when contrast has been reduced, sometimes so that two different colors cannot be clearly distinguished. Features should be shown clearly. It should not be required to have "fuzzy" borders between two areas. If we accept this for water bodies, doesn't that mean that we should also make fuzzy boundaries between all natural vegetation areas, like grass, heath, scrub, woodland? This actually look "fuzzy" on aerial imagery. We don't do this, because we are representing information in a vector database, which stores everything as straight lines between nodes. Similarly, it would be more realistic to represent rivers and streams as curving lines, like on opentopomap and other styles. But we do not do this, because mappers should be able to see the actual geometry as clearly as possible.
That would be rejecting @river-color, and only changing the ocean-color. While that is better than nothing, it would not help improve mapping of rivers, and it would make the lakes darker than necessary. This is based on rejecting a release which shows a pixel of water-color next to a pixel of ocean-color or river-color. I don't believe this is a valid argument. From what I can see, there has not been an argument presented to explain why it would cause problems for map users or mappers (the openstreetmap.de style is already using a similar rendering without problems). I think this objection is probably based on a subjective, cultural-determined or perhaps individual view of how things should look. Please take a look at #3951 - consensus-based decision making will not work if our decisions are based on tastes or preferences. It will also not work if maintainers veto changes which are not exactly what they prefer. |
As i said elsewhere i think attempts to create a compromise between showing something and not showing something will always result in bad map design. Since you - even on specific inquiry - do not make any suggestion how you think different classes of waterbodies can be differentiated without the difference being visible (think of the example i gave for comparison: You want to differentiate natural=wood and natural=scrub but don't want the difference to be visible) i can at this point interpret your answer only that you don't see a way to differentiate in a way that you would find acceptable. Postulating the existence of some hypothetical possibility to differentiate without actually showing the difference does not change that - what you postulate seems physically impossible, at least doing it in a way that is compatible to our documented goals of creating a well readable map and providing constructive mapper feedback. If you disagree please show us how you think this can be done. And as @jeisenbe said - so far your rejection of a visible differentiation seems based exclusively on a subjective dislike for it - you have so far not presented any arguments and reasoning why you think this would be problematic w.r.t. any of the goals of this style. |
|
Well, I think we could simplify a problem then for a start: please provide an objective proof for 3-color water solution - not 2 and not any other number of classes. It seems to be missing in the initial proposition and it looks to me like a very subjective choice. |
|
You seem to be taking a very destructive approach to this now, we have discussed the reasoning for this change at length and you (at least seemed to) have agreed that differentiating different classes of waterbodies is a good idea. @jeisenbe has - largely based on your request - split this into small step-by-step changes and now you are demanding proof for something (not sure for what but apparently not for anything specifically about this change). If you want to question and argue with the reasons for differentiating different types of waterbodies or for this change here in isolation that is fine with me. But i would ask you to read about the arguments that have been made for this in the past discussion and start from there instead of re-iterating the discussion yet again from the beginning. @jeisenbe has showed and explained in detail the advantages of using different colors, we also have patiently answered a lot of questions raised by you so far. I think it is a reasonable request for you now to present a constructive approach making specific suggestions how to proceed from here and how to address the various issues this change tries to address if you disagree with the approach taken. |
|
I have proposed 3 different solutions and 2 of them preserve original 3-color proposition, I think this is quite a lot of constructive feedback. Rejecting them does not seem like a constructive step. Consensus means all the sides trying to reach it - so now it's your turn, I guess. I agree with the general differentiation and this can be easily done with 2 colors (ocean and inland waters). I think any number of colors and any other choice by definition is subjective and I don't know why you treat objectivity as a new rule, but if you can prove me wrong and show me that 3 is not the subjective number, that would make finding a technical solution easier. |
Would it be possible to explain the steps that would be part of each of those solutions? I'm a little confused about the next step to take, and how many steps need to be included in 1 PR. (Please, let's discuss at #3895 or #3896 - not in this closed PR where the comments will get hidden) |
|
Sure, I will do it soon there. |
Fixes #3896
Related to #3895 and #1781
Required for #3926
Changes proposed in this pull request:
#8fcadd(Lch78,21,227) to be more visible over forest and other dark polygon fills.Explanation:
-Narrow river areas and lines are difficult to see on woodland areas and some other dark landcovers currently. This is particularly visible at mid and lower zoom levels.
waterway=riverbankandwater=riverareas also provides feedback when rivers are not properly tagged, or when the transition from river to lake or sea is at the wrong location.Test renderings
Skjolden, Norway
https://www.openstreetmap.org/#map=13/61.5033/7.6847
Before z13
After
Sogndal, Norway
https://www.openstreetmap.org/#map=15/61.2285/7.1051
Before z15
After
