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

Reorder layers to render ocean and water areas above water lines and landcover #3738

Merged
merged 2 commits into from Apr 15, 2019

Conversation

jeisenbe
Copy link
Collaborator

@jeisenbe jeisenbe commented Apr 6, 2019

Closes #426, Closes #1473, and Closes #2609. Also fixed #3253
Related to issues #1547, #1781, #2013, #2025, #2688, #3707 and PR #3670 as a necessary step in the solution.
Continuation of PR #3694
Partially reverts #3189

Changes proposed in this pull request:

  • Move ocean and water above landcover
  • Icesheet polygons are moved before water lines, which are now before water-areas, and ocean polygons are after these. Landcover is now first.
  • Also, springs are moved above water-barriers, marinas are moved below water-barriers, and necountries is moved to immediately before admin-low-zoom
  • Natural=mud is rendered in the landcover-area-symbols layer, above all the water bodies

Explanation

  • This PR is the first application of the switch to water (ocean/marine) polygons instead of land polygons. The layering changes follow the order used in the alternative-colors stylesheet by @imagico

  • By moving the ocean and water areas above the water lines, it is now possible to use different colors for linear water features (such as rivers and streams), seas, lakes and rivers.

  • The landcover fill color is now rendered below all types of water. This means that natural areas and areas with landuse and amenity which extend over water (such as golf courses, parks, schools etc) will be rendered properly. This solves natural=mud renders differently in rivers #1547, Render reedbed with a non-transparent color #2013 and Render beaches and rocks in the tidal range differently #3707 by not rendering the fill color for wetlands, rock, and beaches over the water, but the pattern will still show.

  • Marinas are moved before water barriers because the barriers should be shown over the area outline, as is done for tourism areas and protected areas on land.

  • Springs are moved up above water features so that they will render properly when under a stream or river. The icon is the same as that introduced in PR Refurbished spring icon (fix #325 using @imagico first tests) #3189 but the layering changes are reverted.

  • necountries, the z1 to z3 country borders, sourced from Natural Earth, are moved immediately before the admin-low-zoom layer. This makes sure that the borders are rendered over the water areas at all zoom levels.

  • The semi-transparent mud color fill is moved from the main landcover layer to landcover-area-symbols, which remains above all of the water areas, so that it will render properly over all water areas (If it were not changed, then all areas of mud over seas and water would render as they currently do over natural=water (only the wetland pattern would show); this is also a reasonable option)

In the future it will be possible to solve #2013 and #2025 by adding a fill color for wetland=reedbed and wetland=mangroves. These do not have a fill color currently, because they often grow over water areas. But after this PR the fill color can be rendered below the water, so it will only show on the land.

Test renderings with links to the example places:

Before

z10 Zeeland - current
https://openstreetmap.org/#map=10/51.5079/3.6996
(mud is over the sea in the south, but under the natural=water in the north)
z10-zeeland-current
z12 - current
z12-zeeland-before

z9 North Wales - current
https://openstreetmap.org/#map=9/53.2258/-3.6090
(the sand banks, covered at low tide, show up the same as beaches)
z9-north-wales-current
z13
z13-wales-salisbury-current

z14 Newborough forest - current
https://openstreetmap.org/#map=14/53.1682/-4.3945

  • the spring is under the stream, the marsh is over the sea
    z14-newborough-current

After

z10 Zeeland - after
(mud areas are the same over the sea and over natural=water)
z10-zeeland-after-mud-over
z12 - after
z12-zeeland-after-mud-over

z9 North Wales after
(sand banks are covered, but the pattern still shows the location)
z9-north-wales-after
z13 after
z13-north-wales-after-salisburybanks

z14 Newborough after - the spring is now over the stream, and the part of the marsh outside of the coastline is distinct
z14-newborough-after-spring-over-marsh-under

Icesheet polygons are moved before water lines, which are now before water-areas, and ocean polygons are after these. Landcover is now first.
Also, springs are moved after water-barriers, marinas are moved before the barriers, and necountries is moved to immediatley before admin-low-zoom
By moving the natural=mud background color to the landcover symbols layer, it will render over water of all types, and will display the same over ocean, rivers or lakes
@imagico
Copy link
Collaborator

imagico commented Apr 6, 2019

A few remarks here:

  • mud/tidalflat was already not rendered as intended originally before all other landcovers since the landcover color fading was introduced. This change does not significantly worsen the situation (and fixes natural=mud renders differently in rivers #1547) but it also does not solve the fundamental problem of the transparency leading to undesirable color mixing. This could be solved by rendering mud/tidalflat twice - once completely opaque before the water layers but above the landcover layers (or as last element of the landcover layer via attachment) and once after the water layers with transparency.
  • i don't like that natural=beach and natural=sand are shown identically when overlapping water. Removing the pattern from sand would solve that. natural=sand in general does not make much sense overlapping water - either natural=beach/shoal/reef or wetland=tidalflat with surface=sand would always be a more accurate mapping. This is not something this PR should solve but it is an issue this would open.
  • Render beaches and rocks in the tidal range differently #3707 is not fully fixed by this since natural=bare_rock is not rendered with an overlay pattern. But i am not so sure if it is actually desirable to change that for the same reason as with natural=sand, i.e. the possibility this could lead to abuse of natural=bare_rock for subsea mapping (i.e. natural=shoal/reef). This would need to be discussed separately.
  • there are some features from the landcover layer that would afterwards need to be considered how to suitably render over water, in particular things like amenity=grave_yard and leisure=pitch.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 6, 2019

I should also mention that one side-effect of this layering change is that landcover symbols are now above streams. It's a subtle difference, but can be noticed when streams are in wetlands, Eg:
z16 bogs before
z16-bog-before
after
z16-streams-bog-wales-after

z15 woods before
z15-pen-lan-wood-before
after
z15-Pen-lan-wood-after

And here's an example of how the marine relayering would work, in theory. (I haven't found any real examples of a marina outline that is crossed by a weir, dam or lock gate, so this is unlikely to occur)

Marina test area, before z17
(marina outline is below the pier and building, but above the dam, weir and lock gate)
z17-marina-test-before
after
z17-marina-test-after

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 6, 2019

mud/tidalflat was already not rendered as intended originally before all other landcovers since the landcover color fading was introduced. ... This could be solved by rendering mud/tidalflat twice...

I'm in favor of removing the low-zoom color fading in #3670, which should be possible to implement soon after this PR is merged, so I don't think we need to do the double rendering yet. Were #3670 to be rejected then I would submit another PR to fix the mud rendering.

... natural=beach and natural=sand are shown identically when overlapping water.

I believe this is true of natural=beach (and natural=shoal) with surface=sand. If the surface is not specified, then there is no pattern overlay. The coarser surfaces (eg pebbles, stones, shells) have a slightly different pattern. But as mentioned, there should be an issue opened about this problem. (Another possible solution would be to render a sand pattern in the landcover layer, so that it is not shown over water, similar to the rendering for natural=bare_rock:)

#3707 is not fully fixed by this since natural=bare_rock is not rendered with an overlay pattern.

Thank you, I hadn't realized this. I see now that the bare_rock, shingle and scree patterns are rendered in landcover, so they will not be shown over water. Perhaps there needs to be some tagging discussion first. I will change the PR description.

there are some features from the landcover layer that would afterwards need to be considered how to suitably render over water, in particular things like amenity=grave_yard and leisure=pitch.

I can imagine that leisure=pitch might be used for water sports. But I'm surprised to learn that there are partially-submerged graveyards?! Perhaps the pattern could be moved to the landcover-area-symbol. Should this be considered in this PR, or better left till later?

@imagico
Copy link
Collaborator

imagico commented Apr 6, 2019

I am sorry for not being clear - the mud rendering has nothing in substance to do with the fading, it is just that the introduction of fading broke the original rendering of mud before all other landcovers.

I believe this is true of natural=beach (and natural=shoal) with surface=sand.

Correct.

I can imagine that leisure=pitch might be used for water sports. But I'm surprised to learn that there are partially-submerged graveyards?! Perhaps the pattern could be moved to the landcover-area-symbol. Should this be considered in this PR, or better left till later?

That's for later. Just wanted to point out this being a thing to follow up on.

What i had in mind is for example dedicated sea burial sites like:

https://www.openstreetmap.org/way/48980133

@kocio-pl
Copy link
Collaborator

kocio-pl commented Apr 6, 2019

It's only the visual impression (I didn't look at the code), but I'm very happy to see all these changes. The sand pattern on the water with orange name looks a bit strange, but it makes sense if this is a sand covered with water.

Copy link
Collaborator

@imagico imagico left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works as expected.

As mentioned this calls for numerous other changes, in particular:

  • removing the pattern from natural=sand to not render it identical to natural=beach + surface=sand when overlapping water.
  • measures to avoid a lot of confusing mixed colors with the semi-transparent mud/tidalflat base color (not a new problem but becomes more definitive with this change).

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Apr 15, 2019 via email

@imagico
Copy link
Collaborator

imagico commented Apr 15, 2019

I don't see any gain from the sand pattern in its current form for the map (there is no information transported in it while it generates a lot of noise) but i would be open to any rendering of sand as long as it makes sure it is well distinguishable from beaches both with and without a surface tag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants