for a live index creation progress report.

Edit your map's style.json and replace the following:

with

You may note the "maxzoom":15,"overzoom":1 above, they allow to save some processing on the server side for any zoom above 15. The functions are written to present all data at zoom 15, and therefore higher-zoom tiles do not need to be generated if the client already has the z15.

This is called overzoom behaviour: the client keeps all z15 data and does not fetch anything more at zooms 16, 17, 18, 19, 20, 21 and 22 (the vector tile limit).

The server does not need to generate or cache any data for these z16+ levels as well.

The included script mktiles.py can generate lower-zoom tiles into a directory. Lower-zoom tiles contain data that changes rarely so they don't need to be rendered live.

These lower zoom tiles also need to query a lot of data and so take multiple seconds per tile to generate, this is not comfortable for viewing.

or

or

• python3 run.py -d 'dbname=... ' create --print will just print the compiled template and not run anything (Though it will connect to the database to read which columns exist or not)

• python3 run.py -d 'dbname=... ' index --print will compile the template and generate indexes on the database for speeding up lookup times during rendering. Re-running will skip exising indexes (use index_drop before to delete them). Info: this will use some space in the database.

Not the omt schema, but still a rich addition to any map: elevation, represented as same-elevation contour lines.

The contours-function.sql creates a pg_tileserv compatible sql function that returns data from a contours lines database (setup guide). See demo for implementation, with a stylesheet demo/styles/contours.json, adapted from the contours.xml in that guide. The contours layer alone is not that useful, instead to "append" contours over an already existing layer, see demo/main.js.

This is independent of the omt-schema.

Most guides to selfhost your own vectortiles recommend importing the database with imposm3. But I found nothing when data is already imported with osm2pgsql except for this set of SQL tables. But those are not written with realtime rendering in mind, nor with updateability of the data (with .osc files that osm2pgsql reads in).

These two tools produce a very different database table layout, and the main aim of this SQL script is to adapt the osm2pgsql produced tables for generating vectortiles, despite the omt-specification only considering data from the imposm3 schema.

Also, this "adapting" from one table layout to the other is difficult and will always be a moving target. This script is best-effort and I try do document differences. Changes requiring significant performance loss will probably not be considered.

The process of simplifying and removing geometric features when displaying them at low zooms: country polygons do not need to have multiple millions of points when displayed at z4 where they take up around 100 pixels. imposm3 does generalization by itself and stores multiple copies of the data at different generalization levels, but osm2pgsql does not. Here I attemt to craft generalization algorithms by hand in sql. This is not a scaleable approach and a future approach would be to make use of osm2pgsql's generalization features (though they are still in development as of 2023).

One advantage of doing generalization like this is that the database does not store multiple copies of geometries (a little disk space saved, but that's not worth too much).

This is a balance between tile serving speed and disk usage/efficiency.

Indexes only speed queries up by a little, but because they don't use that much space compared to data, I still recommend using them.

biggest_known_tiles is a list of at most one tile per zoom level that is the biggest. They should all be below 500KB, for client rendering perfomance and network latency.

I figured out the Referrer header is restricted for the maptiler API, but you can look at the map in OSM bright style here. Then setting map.showTileBoundaries=true; in the JS console shows the tilesize where you are looking at on the map.

Some of the biggest pgsql-omt-schema tiles:

Note : pgsql-omt-schema includes languages local(name), en, de, fr, ja, ar, ru in this benchmark, whereas omt officially has local(name), and adds only name_de and name_en for some layers.

• Which features should be hidden in which order when zooming out is somewhat unclear from the omt-schema specification. For now I go with what looks right.

• Aggregation: The layers transportation,landuse, and landcover are currently being aggregated on theirs geometries, and it shows to be an excellent way to reduce tilesize.

• Missing Feature: For the buildings layer as well: when zooming out, before all buildings disappear, they start to cluster into bigger chunks; but only when there are a lot of buildings around.

• ele_ft column is omitted

• The rank column is not clearly documented and I am just tweaking numbers untils it looks about right, for now. The OSM Bright style has some erratic behaviour on the poi layer with that, it's showing almost nothing right now.

• Some styles use "name:latin" and "name:nonlatin", which is not in the spec. Currently, name_en and name_de are not created, and only name is used. To create "name:latin", see template definition comments.

  • Another option to alias feature name data as "name:latin" data is to do so client-side: see provided demo/main.js, function set_name_property for a sample.