[OSM-dev] Migrating osm.org to vectors/Kartotherian

Stadin, Benjamin Benjamin.Stadin at heidelberg-mobil.com
Sat Jan 2 03:33:54 UTC 2016

Somewhat „ambitious" idea,  but why should it not be possible to store non-projected (WGS84 datum) data and do the projection in realtime when using vector "tiles". Vector data tiling is mainly about efficient disk storage and scalability (and versatility), and doesn’t necessarily refer to skewed data.

For example, why not distribute WGS84 vector data in a "MODIS grid" (http://modis-land.gsfc.nasa.gov/MODLAND_grid.html), and let a GL shader do the screen transformation to a Mercator or other projection (https://github.com/rjw57/proj4webgl/blob/master/proj/merc.glsl).

> First of all if you don't use the tiles as tiles but merge them into a
> full data set again there is no point in generating them in the first
> place of course.

Somewhat unrelated to the discussion, but this is indeed a real problem with vector tiles. You have to stitch polygons together again, or workaround several rendering challenges (e.g. draw an outline that’s been defined by style for a polygon which has been tiled). This is not really a completely solved problem, even less when you are in 3D  perspective and you have to stitch together geometry data of different LOD.

Von: Yuri Astrakhan <yastrakhan at wikimedia.org<mailto:yastrakhan at wikimedia.org>>
Datum: Samstag, 31. Oktober 2015 um 21:16
An: Christoph Hormann <chris_hormann at gmx.de<mailto:chris_hormann at gmx.de>>
Cc: dev <dev at openstreetmap.org<mailto:dev at openstreetmap.org>>
Betreff: Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

Christoph, thanks for the explanation! Yes, sounds like each projection would have to be generated and stored separatelly. Not that big of a deal from Kartotherian perspective because it handles each tile source independently, but it will require extra space and cpu. Also, it will require osm2pgsql or other db update tool to generate multiple invalidation tilesets in different projections.

On Sat, Oct 31, 2015 at 10:55 PM, Christoph Hormann <chris_hormann at gmx.de<mailto:chris_hormann at gmx.de>> wrote:
On Saturday 31 October 2015, Yuri Astrakhan wrote:
> Christoph, re multiple projections - if Mapnik implements vector tile
> merging, we could in theory dynamicaly recombine tiles and change
> projections, would't we? At a performance cost of course.

First of all if you don't use the tiles as tiles but merge them into a
full data set again there is no point in generating them in the first
place of course.

Apart from that regarding the abstract possibility: probably no for a
number of reasons:

- since mercator tiles don't include areas near the poles you will not
be able to handle any projections that include the poles although
better display of polar regions is of course one of the primary reasons
for using other projections.
- in general the tile edges in mercator will not be straight lines in
other projections.  You would have to specifically take this into
account when generating and processing the tiled data, otherwise you
can't reproject the tiles without generating artefacts or invalid
- you cannot map the zoom levels in one projection to those in another,
especially not with the strongly variable scale of the mercator
projection so unless your tiles are not zoom level specific you are

These points apply to all generic geometry data in the tiles, any data
specifically generated for rendering like label positions etc. is
normally projection specific anyway.

Christoph Hormann

dev mailing list
dev at openstreetmap.org<mailto:dev at openstreetmap.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20160102/e937d951/attachment.html>

More information about the dev mailing list