natural=mud doesn't render in rivers

[chillly]

natural=mud now renders around the coastline, but not in rivers. The example below shows the join between coast and river and the cutoff is obvious.

Example: http://www.openstreetmap.org/#map=16/53.6995/-0.4381

[CloCkWeRX]

Is this simply because the riverbank is a closed polygon, and

      polygon-fill: @water-color;
      polygon-gamma: 0.75;

renders after/conflicts with

    polygon-pattern-file: url('symbols/mud.png');

?

Or is it just missing an appropriate comp-op: overlay as per https://www.mapbox.com/tilemill/docs/guides/comp-op/ ?

[gravitystorm]

Whatever the problem is, it's not a comp-op issue.

[mrwojo]

Move the glacier style from the top of #water-areas and it works as expected.

It's the order of symbolizers attachments, I suppose. The glacier style at the top makes ::natural before the ::waterway attachment of riverbanks. Mud is ::natural and is therefore drawn over by ::waterway.

[mrwojo]

I have the above fix for this in 26c9d4e. But I also have questions:

Should natural=glacier also render over riverbanks? The current behavior renders glaciers under riverbanks (like natural=mud; they're the same natural attachment).

Also, what about other water areas? Should mud/glacier always render over features like natural=water and landuse=reservoir? Or should it follow the usual polygon sorting patterns (z order then area)?

[dieterdreist]

2013/12/18 mrwojo notifications@github.com

Should natural=glacier also render over riverbanks? The current behavior
renders glaciers under riverbanks (like natural=mud; they're the same
natural attachment).

Also, what about other water areas? Should mud/glacier always render over
features like natural=water and landuse=reservoir? Or should it follow the
usual polygon sorting patterns (z order then area)?

natural=mud is a really dumb tag that doesn't quite fit into the system. +1
for not supporting it at all. "natural" describes geographic features, a
glacier is one, "mud" isn't. Better use landcover or surface as keys for
the mud value and use something like natural=wetland with the appropriate
subtag for "muddy areas".

[malcolmh]

I note that the Wiki page for natural=mud now redirects to the natural=wetland page, so I assume that this is the preferred tagging. However, it appears that the renderer does not differentiate between wetland=... cases, rendering the reed-like pattern for all. This is inappropriate for those cases where there is no vegetation, such as wetland=tidalflat. If that could be fixed, perhaps using the same rules as natural=sand/mud to render the same pattern for wetland=tidalflat + surface=sand/mud, then the need for the old natural=sand/mud goes away.

[dieterdreist]

Am 06/mar/2014 um 20:47 schrieb Malcolm Herring notifications@github.com:

then the need for the old natural=sand/mud goes away.

natural=sand / mud is quite a strange tag, fitting not really in the tagging system (it should be surface or landcover). We shouldn't encourage its use by rendering it

[Rovastar]

Feel free to contact the tagging mailing list where they can direct you to how do proposals and get the voting changed tags that you disagree with.

Never used natural=Mud (very onclear on the wiki what should be used - nothing on the wetlands page) but have used Natural=Sand is used a fair bit even if it was just for mapping golf courses.
I do not see the reason not to change this.

Regarding the wetland tag. We do not store this in our database so it is unlikely this will be changed anytime soon. (And for wetlands=mud only has 16 hits on taginfo....)

[malcolmh]

On 7 Mar 2014, at 17:12, Rovastar notifications@github.com wrote:

We do not store this in our database

Who is “we” and which database are you referring to?

[Rovastar]

The database we use which generates the rendering
"we" = this project.
See the project description:
https://github.com/gravitystorm/openstreetmap-carto

[dieterdreist]

Am 07/mar/2014 um 18:12 schrieb Rovastar notifications@github.com:

but have used Natural=Sand is used a fair bit even if it was just for mapping golf courses.
I do not see the reason not to change this.

this is a little bit OT here, but there are nice tagging details for golf courses in the wiki, suggesting golf=bunker for these, together with natural=sand and the latter explicitly for the renderer (that's also what it is IMHO: tftr)

[Rovastar]

:nod: Yeah After a discussion Harry Wood and I added those descriptions for golf course to the wiki a year or so ago. As previously people were mapping bunkers as beach. It obviously is sand. :-)

[mrwojo]

@Rovastar, your messages aren't showing up at GitHub, which makes this conversation a little hard to follow there.

Who is “we” and which database are you referring to?

The database used for rendering is defined by the openstreetmap-carto.style file. If a key isn't in there, then it can't be used (for now).

But it looks like we have everything we need to render based on wetland=* and/or surface=*. We're currently not using those keys but they should be there in the database.

[Rovastar]

Stupid github

[Rovastar]

Hopefully my messages appear now.

[malcolmh]

I have opened an issue to address the wetland=* rendering style: #387

[matthijsmelissen]

Is this the same issue as https://trac.openstreetmap.org/ticket/5020?

[malcolmh]

Yes it is.

[malcolmh]

If the waterway=riverbank tag is changed to natural=water, then the rendering is correct. These two tags ought to produce the same result, but don't.

[imagico]

I see no indication of areas tagged natural=water and waterway=riverbank being treated any differently - if they are please open a new issue and show an example. Note any special issues with natural=mud will be solved by #1497.

This problem here (different handling of coastline and water areas in relation to landcovers) is still unsolved - it will require use of water polygons for the ocean rendering.

[malcolmh]

Look here: http://www.openstreetmap.org/#map=14/53.7058/-0.5772. I changed one of the waterway=riverbank polygons to natural=water and the mud re-appeared.

[imagico]

#1497 is not yet rolled out - if there was any difference before it should be gone after this change.

By the way - if you change waterway=riverbank to natural=water please always add water=river.

[malcolmh]

OK, I will wait until roll-out to see if this issue is then cleared. Thanks!

[matthijsmelissen]

Closing this now, please let us know if there is still a problem after #1497 is rolled out.