Updating and refactoring the vector tile pipeline

[Rub21]

While some tiles haven’t refreshed recently, the root cause in several cases was incomplete imports of relations and objects—likely due to resource constraints. I’ve noticed that after scaling down or restarting certain containers, all objects import correctly

The following actions were taken to improve the data import pipeline into the tiler database: OpenHistoricalMap/issues#1250 (comment)

• Updated the Imposm container to a newer software version.
• Update imposm config file for importing data to DB
• Removed generalized tables and replaced them with hierarchical materialized views.
• Ran the import on a dedicated server with minimal services—specifically, the ohmx service (which is resource-intensive) was stopped during the process

With these actions, all objects were successfully imported into the database.

On the other hand, I’ve refactored how views are created, improved object simplification logic, standardized handling of gaps in the tiles, and documentation zoom layers

Materiel views creation

Previously, we created materialized views from the generalized tables. While this approach was consistent—since each mview depended explicitly on a specific pre-simplified table—it limited flexibility.

Now, I’ve implemented hierarchical materialized views. For example, mv_landuse_areas_z16_20 is built directly from the raw osm_landuse_polygon table. This view takes about 3–4 minutes to create/refresh, depending on data volume, because it works with unsimplified geometries—but all other columns (like area, languages, and locale tags) are already processed and ready.

The new materialized views for lower zoom levels—such as mv_landuse_areas_z13_15 and mv_landuse_areas_z10_12—are now generated by simplifying mv_landuse_areas_z16_20. also centroids are derived directly from these materialized views. This ensures that polygons and their corresponding centroids always represent the exact same features, maintaining consistency across zoom levels.

Standardized gaps

Previously, our improvements were applied on a per-layer basis—sometimes to amenities, sometime to routes,, sometimes to transport_lines—and we sliced materialized views according to immediate needs. This led to inconsistent geometry handling across zoom levels and simplifications - OpenHistoricalMap/issues#1244

Now I’ve standardized zoom ranges across most layers using consistent intervals: 0–2, 3–5, 6–7, 8–9, 10–12, 13–15, and 16–20, each with its own simplification level.

### Large areas by zoom level
        - 0‑2: 5000
        - 3‑5: 1000
        - 6‑7: 200
        - 8‑9: 100
        - 10‑12: 20
        - 13‑15: 5
        - 16‑20: 0


### Transport lines / routes/ other lines
        - 0‑2: 5000
        - 3‑5: 1000
        - 6‑7: 200
        - 8‑9: 100
        - 10‑12: 20
        - 13‑15: 5
        - 16‑20: 0

This ensures a uniform approach and makes it transparent which simplification tolerance is being applied to features at each zoom group.

Documentation for layers.

I’ve added documentation that shows how each layer is structured. This could serve as a first step toward creating more consistent and reusable documentation. https://github.com/OpenHistoricalMap/ohm-deploy/blob/vtiles_admin/DOC-VTILES.md

This RP fixes: OpenHistoricalMap/issues#1250 and OpenHistoricalMap/issues#1244

cc. @1ec5