Invert landmass
Open, NormalPublic


Currently we render a blue background and provide landmass polygons for non-water areas. This makes sense given the sea/landmass distribution on earth, but on second thought the inverted approach makes more sense: We will not provide sea tiles for medium / high level tiles, so the sea/landmass tile distribution is dominated by landmass. Furthermore rendering a white background by default will result in a better visual appearance when panning and new (land) vector tiles have not been loaded into memory yet.

To implement this, the background color in vectorosm.dgml has to be changed to white (or whatever landmass looks like), and the landmass tile creation part in vectorosm-tilecreator needs to be changed to subtract the clipped landmass tile from a full water tile, and change the tagging accordingly. For backwards compatibility we either have to provide both landmass and water background tiles for some time, or (likely better) drop landmass tiles directly and store tiles in dev/ or v2/.

nienhueser moved this task from Backlog to Server on the Marble board.
rahn added a subscriber: rahn.Dec 17 2016, 9:19 AM

I don't see the big advantage of this approach. Both approaches have their advantages and disadvantages: For the inverted approach you have flicker for coast- and sea areas (which looks equally bad and odd to me). Implementing the inverted approach will have a slight performance advantage if we don't manage the background color in a more sophisticated way. Implementing the inverted approach means on the other side that we have to develop a special dedicated plugin that will paint the pole caps blue - to avoid landmass-white circular polecaps beyond +/-85 degs latitude.

In the end we will need a more sophisticated approach for either solution:

  • The default background color should be chosen depending on whether most of the surrounding area is landmass or sea. This could be done using a coarse lookup pixmap. Depending on which background color would be chosen we would would leave out painting the background that is stored inside the tile.
  • For the zoom-level change we will also need dedicated treatment anyways: We should keep lower-zoom tiles around and render them while the target-zoom level loading progress hasn't reached at least 50%. During loading the new target-zoom level tiles should stay visible=false while the lowerzoom level tiles are shown instead.

Again I think that these tweaks will be absolutely necessary for both solutions to deliver a decent browsing experience. So implementing the invert landmass approach is imho redundant and just an extra roundtrip.

The vast majority of users will only look at landmass tiles. So we should optimize for that, and glitches in coast and sea areas can be easier tolerated than glitches at land areas.

The inverted approach does not only have an advantage in rendering time, but also an advantage in storage consumption (and likewise download time and RAM consumption goes down).

Handling pole caps can be easily added to GroundLayer::render().

The zoom level change has nothing to do with this.