Don't filter riverbanks by size

[eigenwillig]

Has somebody already proposed some code to avoid unmanageable big riverbanks multipolygons (see imagico's post)?

If not what about:

  [natural = 'water']::natural,
  [landuse = 'reservoir']::landuse {
    [zoom >= 0][zoom < 1][way_pixels >= 4],
    [zoom >= 1][zoom < 2][way_pixels >= 16],
    [zoom >= 2][zoom < 8][way_pixels >= 32],
    [zoom >= 8] {
      [int_intermittent = 'no'] {
        polygon-fill: @water-color;
        [way_pixels >= 4] {
          polygon-gamma: 0.75;
        }
        [way_pixels >= 64] {
          polygon-gamma: 0.6;
        }
      }
      [int_intermittent = 'yes'] {
        polygon-pattern-file: url('symbols/intermittent_water.png');
        [way_pixels >= 4] {
          polygon-pattern-gamma: 0.75;
        }
        [way_pixels >= 64] {
          polygon-pattern-gamma: 0.6;
        }
      }
    }
  }
}

  [waterway = 'riverbank']::waterway {
    [zoom >= 0] {
      [int_intermittent = 'no'] {
        polygon-fill: @water-color;
        [way_pixels >= 4] {
          polygon-gamma: 0.75;
        }
        [way_pixels >= 64] {
          polygon-gamma: 0.6;
        }
      }
      [int_intermittent = 'yes'] {
        polygon-pattern-file: url('symbols/intermittent_water.png');
        [way_pixels >= 4] {
          polygon-pattern-gamma: 0.75;
        }
        [way_pixels >= 64] {
          polygon-pattern-gamma: 0.6;
        }
      }
    }
  }
}

[kocio-pl]

Please tell more about this change in simple words, the code alone doesn't speak for itself.

[eigenwillig]

@kocio-pl This is the code before:

  [natural = 'water']::natural,
  [landuse = 'reservoir']::landuse,
  [waterway = 'riverbank']::waterway {
    [zoom >= 0][zoom < 1][way_pixels >= 4],
    [zoom >= 1][zoom < 2][way_pixels >= 16],
    [zoom >= 2][zoom < 8][way_pixels >= 32],

[kocio-pl]

Please describe the changes. Code needs some comments so the changes are better understood and problems are found easier.

[eigenwillig]

Am I right, that the way_pixels filters out small waterbodies?

When copying over [waterway = 'riverbank'] to a new code block without these filters, riverbanks wouldn't become filtered.

[kocio-pl]

Please be more verbose, I still have a hard time finding what is the the exact code change and the consequences. It should be really clear, with main advantages and disadvantages shown.

[jragusa]

@eigenwillig you should post screenshots before/after to explain your modifications

[imagico]

I want to stay out of this matter since i consider the current approach to waterbody rendering here to be a dead end and therefore i can't really productively contribute to improving it. My ideas how to approach this subject in a broader sense can be found through the links in my diary entry linked to above.

But i wanted to give @eigenwillig as a first time contributor a bit of constructive feedback none the less: In theory your idea is valid but it will not work practically both for performance reasons and because it would look strange and ugly and be in conflict with the cartographic guidelines, specifically:

Being understandable and supportive for mappers - To serve as feedback for mappers and encourage correct mapping this style needs to render the data in a way that allows mappers to understand how the data produces a certain rendering result based on basic observation without in depth understanding how map rendering works or looking at the style implementation.

The current low zoom waterbody rendering is already in conflict with that IMO (see the diary) but your suggestion would put it even more in conflict because it would introduce additional difficult to understand filter rules based on a distinction (between river and non-river water areas) that is otherwise not shown in this style.

[kocio-pl]

Which solution would you like to work on then? It's perfectly possible to replace this once we have something better.

[eigenwillig]

@ragusa @kocio-pl Docker doesn't run on my PC, so I can't produce screenshots. I'm formulating this code without seeing any result.

[imagico]

@kocio-pl - i have written extensively about the subject of waterbody rendering, much of this as said is linked to from the diary entry and subsequent comments. Some of them are implemented in https://github.com/imagico/openstreetmap-carto/tree/alternative-colors. Most of this is technologically and design wise incompatible with the current approach here which is why i said i can't really productively contribute to improving waterbody rendering here. Almost any change i could propose has a lot of prerequisites many of which would amount to reverting other changes that have been made in the past.

If there is consensus among maintainers to re-visit past choices leading to the current situation that would be a different situation but given the inter-dependencies between many of the more recent changes that relate to waterbody rendering this would be a really big step.

Or it could of course be that there are options that i am missing - would be glad to learn something new.

[kocio-pl]

Almost any change i could propose has a lot of prerequisites many of which would amount to reverting other changes that have been made in the past.

I have nothing against reverting anything if the new approach works better. I just prefer solving problems where possible, not waiting until new approach is ready (because this might be "never" as well).

If there is consensus among maintainers to re-visit past choices leading to the current situation that would be a different situation but given the inter-dependencies between many of the more recent changes that relate to waterbody rendering this would be a really big step.

This is hard to tell - as I understand you, you want the guarantee that your time won't be wasted if you will invest in it. Unfortunately I believe nobody here has such guarantees. It's your decision how much are you ready to try.

[imagico]

@nehayya - i have already replied to you via email, if you prefer to use github you can also open an issue on https://github.com/imagico/openstreetmap-carto/issues - though d4fa63b probably already solves your problem.

@kocio-pl - there is nothing to try for me - i have already implemented those changes i want to implement in my own branch and continue to try new ideas building on that. But i see no point in trying to push them here when the underlying design goals are not shared by the other maintainers here and i need to expect the next change to completely mess with what i am trying to do. As i have said very clearly in the past i cannot really contribute actively in a cooperative design project without a shared vision and goals. If anyone else wants to port or re-implement ideas from me here i would be willing to support that with advise and answering questions of course - as i also try to do in other cases.

[kocio-pl]

I see. That seems so hard, that is unlikely to happen for me. There were big forks like lua+hstore, which lurked for many months, but that was very unusual.

However I believe in making smaller steps. If I understand well, #1982 is part of your solution, but that issue looks like dead, since nobody is investigating how to avoid "flooding".

[jeisenbe]

@imagico would you be in favor of removing the way_pixels filter for rivers and canals, if rivers and canals are rendered differently than other natural=water polygons? Eg

[natural = 'water'][water = 'river],
[natural = 'water'][water != 'canal'],
[waterway = 'riverbank'] {
  [zoom >= 6] {
    polygon-fill: @river-color;

I believe that the concerns about rendering 1 pixel or sub pixel water areas are mainly related to places with many small lakes, so may be able to reach consensus on changing the river water areas rendering?

[imagico]

@imagico would you be in favor of removing the way_pixels filter for rivers and canals, if rivers and canals are rendered differently than other natural=water polygons?

I am not in favour of a large and arbitrary way_area threshold in general and i find it relatively pointless to remove it selectively for some water features but not for others - even if they are rendered differently. It would also create a bad mapping incentive.

What you should be aware of is that there is no particular significance in a cutoff of 1.0 times the pixel size. This is not any more meaningful than a cutoff of 0.5 times the pixel size or whatever. The effect is completely gradual. The concept of dropping 'sub pixel size water areas' is without any physical or mathematical basis. The only threshold that was so far based on a solid consideration was the 0.01 pixel threshold. That does not mean this is the only valid choice but i would expect any other suggestion to be supported with solid arguments (and that the number 1.0 is somehow special isn't one).

[jeisenbe]

Examples of where this is a problem. Only parts of these large rivers are shown in Alaska and Canada at z4 to z6.

The small lakes are also missing, but this a less obvious problem.

z5 Alaska (Yukon River and tributaries)

z6 Alaska screenshot

z4 Canada - Mackenzie River

z5 Mackenzie River

[jeisenbe]

It happens in the tropics too, especially at z6 and z7:

z7 Mamberamo river
https://www.openstreetmap.org/#map=8/-2.647/138.647

z8 Mamberamo

z6 Amazon river
https://www.openstreetmap.org/#map=7/-2.778/-68.071

z7 Amazon