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

Switch to ocean polygons #1982

Closed
pnorman opened this issue Nov 21, 2015 · 14 comments
Closed

Switch to ocean polygons #1982

pnorman opened this issue Nov 21, 2015 · 14 comments

Comments

@pnorman
Copy link
Collaborator

pnorman commented Nov 21, 2015

We should switch from preprocessed land polygons on a water colour background to preprocessed water polygons on a land colour background.

This would

  • Allow easier customization with hillshading
  • Be quicker in inland areas
  • Allow more water styling, including outlines of water
  • Allow rendering on top of maritime borders, making it possible to have them less prominent
  • Makes it easier to render inland areas with no coastline by substituting an empty shapefile

Cross-ref #621

Issues

  • There are no simplified water polygons

cc @joto @imagico

@matthijsmelissen
Copy link
Collaborator

Sounds reasonable. What did you have in mind with water styling / outlines of water?

@imagico
Copy link
Collaborator

imagico commented Nov 21, 2015

Other advantages would be:

Simplified water polygons have meanwhile been set up on openstreetmapdata.com - we were planning to roll this out together with some other improvements in coastline processing which are not quite finished yet but you can already get the simplified water polygons on

http://data.openstreetmapdata.com/simplified-water-polygons-complete-3857.zip

@pnorman
Copy link
Collaborator Author

pnorman commented Nov 21, 2015

Sounds reasonable. What did you have in mind with water styling / outlines of water?

I want to keep that separate, but a fairly common convention is a darker blue outline.

@donaldrnoble
Copy link

would doing this stop the issue of broken coastlines "flooding" the land? or could the reverse issue then happen, which areas of sea being shown as land?

@gravitystorm
Copy link
Owner

@donaldrnoble It makes no difference, "flooding" is still possible.

@matthijsmelissen
Copy link
Collaborator

I reverted the PR that fixed this, see #2101.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Feb 7, 2019

The benefits of this change still remain important, as listed above:

  • Allows easy customization with hillshading
  • Faster rendering in inland areas
  • Makes it possible to render inland areas with no coastline by substituting an empty shapefile
  • Improved water styling options
  • Allow rendering oceans on top of maritime borders, making it possible to have them less prominent
  • Allows consistent wetland rendering near / over water, e.g. mangroves, tidal flats, and salt marshes
  • Allows rendering landcovers differently over water and over land (like natural=beach, =shoal)
  • Possible to differentiate ocean from inland water, and rivers from other water bodies, in rendering

Makes it possible to solve these issues: #621, #788, #1547, #1781, #2013, #2025, #2609, #3273, and PR #3670

To summarize the current status, issue #2101 caused the reversion to using land-polygons when some users had problems with the simplified-water-polygons-complete-3857, which was used at z0 to z9 after PR #2066.

This problem was not easy to reproduce, so it is still not clear why this happened. We do not know if this problem would happen again with the current simplified-water-polygons-complete-3857 file and latest versions of Mapnik and associated software, but there is no reason to think the problem is fixed, either.

Options for moving forward:

1) Try the rendering from #2066 again:

  • Use simplified-water-polygons-complete-3857 at low-zoom, and see if problems still happen.
  • It may be possible to improve the simplified water polygons file in some way; however we are not yet sure of how to do this.

2) Use a different for low zoom water polygons

  • There are at least 3 currently-available data sources (a b and c below); we would continue using water-polygons-split-3857 till z9 or z7, instead of >= z10 only.
  • Rendering of metatiles along the coast will be slower at z7 to z9 than currently, though rendering of inland tiles should be faster, and tiles in the center of the ocean should be the nearly the same speed as with simplified polygons.

a) Raster mask for z0 to z6:
http://openstreetmapdata.com/data/water-reduced-raster

  • Very efficient file size: only 4 megabyte .zip file to download
  • Limits options for rendering; the fill color can be changed, but outlines and patterns cannot be used based on this data source.
  • Would be a little pixelated if exported or printed at higher resolution.
  • This could be improved by using the z6 mask at z5 or z4

b) Reduced polygons for z0 to z6:
http://openstreetmapdata.com/data/water-reduced-polygons

  • File is same size as the current simplified-land-polygons-complete-3857
  • Limits options for rendering. The fill color and pattern can be changed, but outlines cannot be used
  • I am not certain what happens when this is rendered or exported at 2x or 3x resolution
  • @pnorman was concerned about documentation and maintenance of the process used to produce these files Low zoom waterbody rendering and move to water polygons #2507 (comment)

c) Generalized coastlines & water polygons for z1 to z8:
http://openstreetmapdata.com/data/generalized-coastlines

  • Renders very quickly; blazing fast.
  • File size same as simplified-water-polygons-complete-3857
  • Works very well with an outline color for the coast, though an additional 30 megabyte file is needed.
  • Available all the way to z8, so only z9 would need to use water-polygons-split-3857 - and perhaps it's possible to request generalized coastlines for z9 as well?
  • Since the coastline is generalized, the map looks more similar to a printed atlas; this is a significant change from the current appearance. Also, while exporting and printing at higher resolution works fine, the generalization seems a little too much. This could be modified by using the files one zoom level sooner than intended (i.e. use generalized-water-polygons-z8 to render zoom 7, and continue using the full data at z8), though then a coastline outline will not look as good at standard resolution

3) Create a new data source for low-zoom coastline/ocean rendering

  • @imagico has suggested that he has a newer, better method for creation of reduced-size polygons, similar to http://openstreetmapdata.com/data/water-reduced-polygons but improved, which is used in the low-zoom landcover demonstration map: http://blog.imagico.de/on-basic-small-scale-landcover-rendering/.
    However, I don't think this data is currently available for testing, at least not in a form usable with this style?
  • We could also discuss updating one of the currently available data sources with additional zoom levels; eg the options in "2)" above could be extended to z9, with the z9 file designed to transition nicely between the full-data rendering at z10 and the simplified coastlines at z8.

Are there other options that I've missed?

@jeisenbe
Copy link
Collaborator

jeisenbe commented Feb 7, 2019

Ah, one more option:

4) Use ocean polygons at high zoom and land polygons at low zoom

  • That is, use simplified-land-polygons-complete-3857 at z0 to z7, and use water-polygons-split-3857 for high zoom
  • @pnorman mentioned this option, but didn't like it: Low-zoom ocean shapefile not rendered correctly on some setups #2101 (comment)
  • Increases the complexity of the style (the layering order would change between low zoom and mid/high zoom) and would not improve the rendering at low zoom levels.
  • Prevents fixing several of the issues above, if we want to continue rendering landcover to z5 and inland water bodies at low zoom.

@Adamant36
Copy link
Contributor

Are there any other issues with simplified-water-polygons-complete-3857 besides issue #2101? If not, it sounds like its clearly the best option. From reading through the issue it sounds like it was never clear what caused it and there's a good chance it was fixed in the last 3 years. Since it could really be anything.

This might be a good case for "implement and regress if needed" Like was done for rendering of surfaces on roads. I don't see how it can be tested to see if it was fixed or not otherwise. Especially if it was a server anomaly like was suggested.

@imagico
Copy link
Collaborator

imagico commented Feb 7, 2019

Note option 1, 2c and 4 are for the coastlines only while 2a and 2b are for all waterbodies.

The German style (https://github.com/giggls/openstreetmap-carto-de/) uses both the reduced water shapefiles and the simplified ocean polygons so any issues with those can be tested with that style.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Feb 7, 2019

Note option 1, 2c and 4 are for the coastlines only while 2a and 2b are for all waterbodies. ... The German style uses both the reduced water shapefiles and the simplified ocean polygons

@imagico, I had been focusing on the coastline/ocean, but it would be very helpful to have a separate data source for low-zoom lakes and rivers. I'm currently downloading the reduced ocean shapefiles for testing, to see how they work when rendered at 2x resolution (e.g. for "retina" tiles or printing).

But it would be great to have generalized rivers and lakes, to try with the generalized coastline. I believe your low-zoom demo shows an example of this?

Are those generalized lake and river files proprietary? Would it be possible to make generalized river and lake files available on openstreetmapdata.com to go with the generalized coastlines?

@imagico
Copy link
Collaborator

imagico commented Feb 7, 2019

No, that is a much more complicated process and would also be questionable in terms of mapper feedback. Keep in mind that our goals require that the 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. This is not the case if the data is processed with a complex, non-local algorithm.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Feb 8, 2019

Was that "No" a specific response to the last line: "Would it be possible to make generalized river and lake files available"?

Or are you also saying that the generalized coastlines are inappropriate to use at z1 to z6, due to mapper feedback?

Are simplified-water-polygons-complete-3857 and the simplified-land-polygons currently in use also created with a complex, non-local algorithm?

@imagico
Copy link
Collaborator

imagico commented Feb 8, 2019

Or are you also saying that the generalized coastlines are inappropriate to use at z1 to z6, due to mapper feedback?

I don't think it is any more problematic than the currently used line simplification (probably less because it is more consistent) but i think both are questionable for this style and its function.

If you follow comments of mappers regarding OSM-Carto rendering you can see that the simplified and outlined low zoom coastline rendering we have right now is quite frequently a source of confusion and misunderstandings.

Are simplified-water-polygons-complete-3857 and the simplified-land-polygons currently in use also created with a complex, non-local algorithm?

The simplified shapefiles are only used for performance reasons, they are not meant to introduce any visual difference in the results. If you look very closely you can detect a tiny difference at z9 but that is really insignificant.

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

No branches or pull requests

8 participants