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

Change from land polygons to ocean polygons #3694

Merged
merged 2 commits into from Mar 25, 2019

Conversation

jeisenbe
Copy link
Collaborator

@jeisenbe jeisenbe commented Feb 24, 2019

Fixes #1982
Reverts #3065
See similar previous PR #2066 which was reverted due to #2101
Also see #2507
Related to solving several issues including #621, #1547, #1781, #2013, #2025, #2609, #2688, #3695, and PR #3670

Changes proposed in this pull request:

  • Change from rendering land polygons on an ocean-color background to rendering ocean polygons on a land-color background
  • Remove outline from low-zoom coastlines

Explanation

It is beneficial to render the oceans (that is, all water outside of the openstreetmap coastline) as polygons, rather than the present situation where the continents and islands are rendered as polygons. While this PR does not make any changes in the layering of land and water, with the introduction of water polygons it will become possible to move the oceans above water lines and landcover, which will be helpful in cases where these will show over the ocean. This will allow solving several issues related to mud flats, mangroves, wetlands and areas of parkland at the coast. It also makes it possible to use different colors for rivers and lakes, if desired. It also makes it easier to render maritime borders less prominently

Previously this same change was made in PR #2066 which had to be reverted due to an issue with the simplified water polygons that was seen on a few specific server setups. However, it appears that this issue may no longer be present with current software versions and the current simplified water polygons available from openstreetmapdata.com; see the discussion in issue #2101. Therefore we are attempting to implement ocean polygons using the current

Unfortunately it isn't possible to render a simplified coastline outline, as in PR #3065 and currently, from the simplified water polygons. This could be done by starting to use the generalized polygon files which are also available at openstreetmapdata.com, however this PR is attempting to make the smallest change possible. If the maintainers and contributors agree that a generalized outline is desirable at z0 to z7, I can easier add this feature now or in a separate PR by using the shapefiles at http://openstreetmapdata.com/data/generalized-coastlines

Test rendering:

Before:
z3-europe-land-polygons-master

After
z3-europe-ocean-polygons-after

Remove outline from low-zoom coastlines
@jeisenbe
Copy link
Collaborator Author

I've opened issue #3695 so that we can discuss whether the coastline outline and simplification or generalization is desireable at low zoom levels.

@kocio-pl
Copy link
Collaborator

Do you plan to ask affected users if they still have a problem with rendering ocean polygons?

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 26, 2019 via email

@jeisenbe
Copy link
Collaborator Author

I've now posted to the dev and talk mailing lists, and added a forum post. Are there any other places where we should mention this change to alert potentially affected users?

@kocio-pl
Copy link
Collaborator

Sounds to me like enough to reach interested persons.

@rrzefox
Copy link

rrzefox commented Mar 4, 2019

I've deployed this on my server. Not all tiles have been completely rerendered yet, but I've not seen any completely broken tiles yet (as I did when this was last attempted).
Apart from the difference due to the outline, I've seen differences here:
http://bl.ocks.org/matthijsmelissen/raw/af7a602c222dbf1ff1a2c0d84ed755b7/#9.00/66.7063/13.0012
I'm not sure if that is to be expected or even related to this PR (might just be the tiles on osm.org being too old).

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Mar 5, 2019

Thank you, @rrzefox for testing this again. It's very helpful to be able to see the whole planet for testing.
I didn't see any differences at the link which you shared above, other than the newly visible protected areas (due to PR #3661). But perhaps I'm not looking at the right place. Is it visible on z9 here? http://bl.ocks.org/matthijsmelissen/raw/af7a602c222dbf1ff1a2c0d84ed755b7/#9.00/66.7063/13.0012

@rrzefox
Copy link

rrzefox commented Mar 5, 2019

The protected areas were what I meant - I simply forgot that osm.org hasn't deployed 4.20 yet.

@pnorman
Copy link
Collaborator

pnorman commented Mar 10, 2019

I'm +1 to the change in principle, but haven't given this an in-depth review.

@imagico
Copy link
Collaborator

imagico commented Mar 10, 2019

Note it would be good to test this preemptively for the new version of the coastline process now available for evaluation on

https://osmdata.openstreetmap.de/

This should be backwards compatible but would none the less be good to test. Same applies if we decide to keep using land polygons. See

https://blog.jochentopf.com/2019-03-07-the-new-osmdata-service.html

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Mar 11, 2019 via email

@imagico
Copy link
Collaborator

imagico commented Mar 11, 2019

Note i did not mean we should change to source the coastline data from osmdata.openstreetmap.de right now in this PR. I meant we should check if it works this way. You changing the PR makes this easier for people to do of course. The eventual move to the new source should be done uniformly for all files and be coordinated with the OSMF sysadmins.

@pnorman
Copy link
Collaborator

pnorman commented Mar 11, 2019

Note i did not mean we should change to source the coastline data from osmdata.openstreetmap.de right now in this PR. I meant we should check if it works this way. You changing the PR makes this easier for people to do of course. The eventual move to the new source should be done uniformly for all files and be coordinated with the OSMF sysadmins.

+1 to doing it as part of a different PR, except the OSMF sysadmins have already moved

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.

Apart from the http URLs this looks fine. Depends on consensus on #3695. If we can achieve that i would approve this if you remove the URL change from here and create a separate PR with this and the same URL change for the icesheets.

scripts/get-shapefiles.py Outdated Show resolved Hide resolved
scripts/get-shapefiles.py Outdated Show resolved Hide resolved
shapefiles.mss Outdated Show resolved Hide resolved
@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Mar 12, 2019 via email

@jeisenbe
Copy link
Collaborator Author

I downloaded the new shapefiles from osmdata.openstreetmap.de and checked that the rendering is still correct. I will submit a new PR to suggest using this source, once this PR is merged.

I believe this PR is ready to merge now. Are there any concerns?

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.

Looks good now. This should be followed by a change of shapefile URLs to osmdata.openstreetmap.de for the same release so style users don't have to struggle with two different variants.

@imagico imagico merged commit b5938d6 into gravitystorm:master Mar 25, 2019
@imagico
Copy link
Collaborator

imagico commented Mar 25, 2019

I have merged this now so we can move forward with the various matters that depend on ocean polygons.

It seems we have consensus that reverting #3065 at least an acceptable side effect of this change - if not desirable on its own because of the problems discussed in #3695. If i misread anyone on this please say so.

As said we should move to osmdata.openstreetmap.de as shapefile data source with the same release as this change to avoid style users having to switch data source and deal with potential issues twice.

@matkoniecz
Copy link
Contributor

It seems we have consensus that reverting #3065 at least an acceptable side effect of this change

I agree now.

@kocio-pl
Copy link
Collaborator

Although I think it's better to have coastline simplification, this patch has higher priority for me, so I'm happy to see it merged - thanks.

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

Successfully merging this pull request may close these issues.

None yet

6 participants