/vector/{z}/{x}/{y}.pbf. Both should draw the
identical map — a difference is a bug in one of them. The same
goes across the two tabs above: four combinations, one map.
GEOSERVICES_DB_SCHEMA
z/x/y — same idea as the raster viewer's grid, drawn
from a small GeoJSON layer this page computes rather than either
engine's own built-in debug view: MapLibre's
showTileBoundaries bakes a byte-size figure into the
label with no way to turn it off, and OpenLayers'
TileDebug draws a differently sized label — and two
tabs that disagreed about a debug readout would be exactly the
confusion this page exists to prevent. Past the archive's own max
zoom the grid keeps showing that one deepest tile, since that's
the tile actually being reused while overzooming.
height the tiles carry: the real OSM
height tag first, building:levels next,
and only then a coarse per-type estimate. Which one fired is the
paler-vs-darker split you see, and the per-feature
height_src attribute; the "heights" row above says
whether the whole archive had real tags to draw from at all, or
was built against a schema imported before
app/osm2pgsql.style added those columns. Edit the
MapLibre style below to change any of it.
fill-extrusion, so the height the tiles
carry is not drawn here and there is no tilt button — but
height_src still is, as the paler-vs-darker split
(est is a coarse per-type estimate, the darker shade
a real height tag or building:levels).
The "heights" row above still applies: it describes the archive,
not the renderer. Everything else on this tab should match the
MapLibre tab — any other visible difference is a bug in one of
the two style files.
styles/demo/vector-style.json — see the hint at the
bottom of this panel for what "deploying" this means
styles.compile_themes() and
MapRegistry.load_theme(). In a real deployment this
editor wouldn't exist, so shipping a style change means either
committing an updated styles/demo/vector-style.json
(if this demo page itself is what should change), or — the normal
case — editing the MapLibre style inside whatever production
client app actually consumes /vector/tiles.json;
nothing on this server needs to change or restart for either.
app/devtools/static/vector/olstyle.js — OpenLayers
has no style document to POST, so changing them means editing
that file and reloading. The colours and width stops there are a
hand-kept copy of
styles/demo/vector-style.json;
tests/test_vector_demo_styles_match.py fails if the
two drift apart.