Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

natural=* covered by freshwater or oceans treated inconsistently? #1473

Closed
ghost opened this issue Apr 5, 2015 · 11 comments · Fixed by #3738
Closed

natural=* covered by freshwater or oceans treated inconsistently? #1473

ghost opened this issue Apr 5, 2015 · 11 comments · Fixed by #3738

Comments

@ghost
Copy link

ghost commented Apr 5, 2015

works nicely:
https://www.openstreetmap.org/way/336816028#map=17/46.18740/8.75470
there is bare rock on both sides of the rivers and also underwater. The rendering is fine.

The same does not appear to work for natural=bare_rock which is across natural=coastline
and partly underwater - the whole area is rendered as rock and water is not shown
in that place.

What is right? Should we use something like natural=underwater:bare_rock ? Could
the rendering be made consistent whether the water is natural=water or natural=coastline?

@matkoniecz
Copy link
Contributor

I would expect that rock areas under ocean/seas would not be tagged as natural=bare_rock, but http://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dbare_rock is not making it explicit.

Could the rendering be made consistent whether the water is natural=water or natural=coastline?

The problem is that ocean/seas are not rendered - at start everything is water, then land areas are painted over blue background. Then landcovers are rendered, with small water areas rendered on top.

It seems that this issue fits rather wiki/tagging mailing list - see my proposal on http://wiki.openstreetmap.org/wiki/Talk:Tag:natural%3Dbare_rock (please, continue discussion about how things should be tagged there, not on this bugtracker),

@matkoniecz matkoniecz added this to the Bugs and improvements milestone Apr 5, 2015
@ghost
Copy link
Author

ghost commented Apr 5, 2015

I have already asked the mailing list some time ago
http://permalink.gmane.org/gmane.comp.gis.openstreetmap.tagging/23465

Fact is, there is an inconsistency between oceans and lakes/rivers in carto. Can that
be fixed? Should that be documented as unfixable?

@matkoniecz
Copy link
Contributor

Should that be documented as unfixable?

I think #426 is good enough for that purpose.

@matkoniecz
Copy link
Contributor

See also #115 for very similar problem, but with reporter expecting opposite handling of natural=* key.

@ghost
Copy link
Author

ghost commented Apr 5, 2015

there is also natural=cliff which is rendered across rivers and ought to be, otherwise waterfall rendering would be pretty bad (nonexistent)..

Otoh for features like natural=wood, landuse=forest or natural=bare_rock it seems like a terrible fate to have to split them at every stream/riverbank.

So if needed for consistency it would be easier to add/honour a special tag for waterfall cliffs than dealing with forests being split at every creek.

@matkoniecz
Copy link
Contributor

Creeks are not a problem as these are mapped as lines, not as areas (water as lines is displayed after various areas).

@ghost
Copy link
Author

ghost commented Apr 5, 2015

The areas do not seem to be a problem either.. afaics it just works. It would be even stranger to differentiate between plain rivers (lines) and rivers with riverbanks (areas).

@ghost
Copy link
Author

ghost commented May 16, 2015

@jeisenbe
Copy link
Collaborator

jeisenbe commented Apr 9, 2019

This will be solved by #3738, I believe.

@jeisenbe
Copy link
Collaborator

The issue with bare_rock in particular is also solved by #3851

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 7, 2019

Since #3738 natural=water, waterway=riverbank and the oceans (areas outside of the coastline) are rendered together, above the landcover layer, so the original issue is fixed

@jeisenbe jeisenbe closed this as completed Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment