Vector map

[der-stefan]

With Mapbox GL, e.g. inspired by OpenMapTiles.

[tomass]

Note that (as far as I know) Mapbox GL cannot nicely render non abstract polygon patterns. Example of wetland rendering with: a) zoom not at integer position (f.e. zoom 13.9) b) rotated map Problems: 1) wetland labels are scaled 2) symbols are not horizontal.

Wetland and meadow:

[der-stefan]

You can see the style by visiting http://editor.openmaptiles.org and loading the style from URL https://raw.githubusercontent.com/der-stefan/OpenTopoMap/master/mapbox-gl/opentopomap.json

[der-stefan]

Here is an informative blog post about two different ways how to generate vector tiles: https://carto.com/blog/inside/MVT-mapnik-vs-postgis/ For us, mapnik-vecor-tile should be preferred, as the whole select logic is in our mapnik xml file (and our preprocessing scripts).

edit: Ok, it seems to be no problem to render MVT tiles from Mapnik. The main question is: Which tile server should be used? Can tirex be used for both png and mvt tiles at the same time??

[henrythasler]

I have recently started to play around with vector tiles. You should have a look at tegola.io For details see: https://www.thasler.com/blog/blog/VectorMaps-serving-tiles

In general I'm not sure what the benefit of rendering MVTs with mapnik would be, as this seems rather slow. Maybe I miss some information...

[tomass]

MVT with Mapnik (raster tiles) is useful if you want to render more than one style. In such scenario you would query the database once and then generate all styles from the same MVT results - thus saving a lot of queries/time. If only one raster style is created, there is no benefit in vector tiles. Doing smooth migration from raster tile queries to vector tiles queries is not possible (in my view), as for vector tiles for vector map you will need to do additional (and sometimes serious) generalisation (more than simplify, and preferably more than imposm's "generalisation") in order to get good results. Unless I miss some information...

[mboeringa]

Doing smooth migration from raster tile queries to vector tiles queries is not possible (in my view), as for vector tiles for vector map you will need to do additional (and sometimes serious) generalisation (more than simplify, and preferably more than imposm's "generalisation") in order to get good results.

As far as I understood it, generalization for vector tiles is usually only done upon the actual vector tile generation, a kind of "on-the-fly" generalization during the process of creating the tiles for the different zoom levels, so the database itself doesn't have to generalized, which would also pose a major issue, since most data models for OpenStreetMap in databases only employ a "flat" and simple database model with only three tables for Polygon, Line and Point features, and no dedicated tables that could be generalized for small scale display.

[tomass]

@mboeringa in my practice - the other way round. The problem is that if you have a geometry with too many vertexes and generate raster png file - it will be slightly larger but nothing extraordinary. If you create a vector tile from such a detailed geometry - standard dp simplify (which is the "on-the-fly" generalisation you mention) will only slightly decrease number of points and thus create a huge vector tiles. For example I: was playing with government data (very detailed), so without generalisation on database side (without MSDB) vector tiles at zoom 11 were reaching 1,8M with all expected results from that (speed of download, crashing older browsers etc.). Simple conservative (almost no visual difference) polygon generalisation on database side decreased tile size by up to 50%.

By "generalisation" I mean:

• road/railway simplification (collapsing parallel ways into one for speed as well as visual result)
• polygon (landuse, water) amalgamation/simplification
• building amalgamation/simplification and typification
• other simple ones. This allows decreasing tile size a lot (exact numbers depend on initial data and quality/speed requirements).

Note: you can only pick two from a triangle of:

• tile size
• preparation/generation speed/time
• visual quality

As for "flat" model, if you do not need multi-scale db - adding indexes, materialised views will solve your problems of "flat" model.

[henrythasler]

Has anyone actually created MVTs with mapnik? I can't seem to find any usable examples. Just some vague hints and a lot of unanswered stackoverflow-threads...

[henrythasler]

I just wanted to give you an update of my results with vector-tiles so far. As @tomass mentioned, the most important part is the db-structure, import and generalization. You can have a look at https://www.thasler.com/mvt/#18/49.599279/11.006322

A lot of stuff is still missing (e.g. low zoom levels, water labels) but the overall stack works really nice. Refer to https://github.com/henrythasler/vectortiles for inspiration.

[henrythasler]

I tried another approach to create and serve vectortiles. This time cloud-based with a Lambda-function on top of postgis: https://github.com/henrythasler/cloud-tileserver