ConstExtracts the vectorTiles config block from a layer definition.
Supports both def.vectorTiles and def.data.vectorTiles.
Resolves the full tile URL template from the layer definition.
⚠️ The tilesDirectory fallback below is UNREACHABLE from the production flow,
and deliberately so. _createVectorTileLayer only calls this after
shouldUseVectorTiles() has returned true, and that guard requires an ABSOLUTE
tilesUrl — so by the time we get here, the first branch always wins. The
derived …/{z}/{x}/{y}.pbf path is therefore dead code in practice.
It is kept, not purged (R.33, backlog résiduel S5). Two reasons: it is covered by
13 assertions across __tests__/geojson/vector-tiles.test.js and
__tests__/config/s13-layer-data.test.js, several of them asserting the derived
path specifically; and it becomes live again the moment the absolute-URL guard is
relaxed, which is what "arming" a profile's vector tiles would mean. Removing it
would delete tested behaviour to fix a promise that was really a data problem —
the six tourism layers that declared enabled:true without a tilesUrl have
been disarmed in the profiles instead.
Creates a vector tile layer by delegating to the adapter, then binds
interactions and records shared state. The adapter builds one vector source
and up to 3 render layers (fill/line/circle) from the resolved spec.
Unique layer ID.
Display label.
Normalised layer definition (must include vectorTiles block).
Base options (unused in MapLibre mode).
Layer metadata.
Updates the style of an existing VT layer via the adapter.
Determines if a layer definition should use vector tiles. Returns true only when the VT config provides an absolute tile URL. Relative paths (auto-generated from profile structure) are not used because PBF files may not exist — the layer falls back to GeoJSON.