Laravel Vector Tiles Laravel Package

Product Decisions This Supports

• Location-intelligent features without a tile vendor: vector-tiles:doctor and vector-tiles:benchmark turn "can we serve maps from our own PostGIS?" from an unbounded research spike into a measurable spike — run the doctor against staging, get a read-only pass/fail per layer, and benchmark render time and tile size per zoom before committing roadmap scope.
• Build vs. buy for maps: this package moves the buy-side comparison from "Mapbox/MapTiler subscription" to "managed service vs. self-hosted on infra we already run." The new tooling produces the actual numbers (tile bytes, render latency per zoom) needed to price that trade-off rather than argue it abstractly.
• Zoom-tiered product tiers: filterByZoom() lets a single layer definition back different zoom behaviour per plan or map mode, so gating detail by customer tier becomes configuration instead of a fork of the tile pipeline.
• Perceived performance and payload budgets: simplify() with a pixel tolerance under maxZoom is a direct lever on tile weight at low zooms — the kind of change that shows up as faster first paint on mobile without touching source data fidelity at high zoom.
• Access control for gated geodata: the TileJSON middleware fix means protected layers can now be trusted to hide their metadata, which unblocks shipping customer-restricted layers (parcels, assets, coverage footprints) behind existing Laravel auth rather than a bespoke proxy.
• Caching strategy decisions: TileCache::remember() and PostgisTileDriver::tileQuery() open the door to pre-warming, custom invalidation, and per-layer cache policy — relevant when deciding whether map freshness is a product promise ("live asset positions") or a nice-to-have.

When to Consider This Package

Consider it when:

• Your geospatial source of truth is already PostGIS and you want tiles to reflect database state without a separate ETL or export pipeline.
• You are on Laravel and want tile serving to inherit your existing auth, middleware, config, queue, and deployment conventions rather than standing up and operating a separate Go/Rust tile server.
• You need self-hosting or data residency — geodata that cannot leave your infrastructure or a specific region.
• Your scale is moderate and CDN-frontable: cached vector tiles, per-layer zoom ceilings, and read-heavy traffic. The benchmark command exists precisely to tell you whether your layer design fits that profile.
• You need layer-level access control and predictable TileJSON/GeoJSON surface area for a frontend team (MapLibre/Mapbox GL consuming TileJSON).
• You want a low-commitment evaluation: the doctor command is read-only and safe to run against production replicas.

Look elsewhere when:

• You need a global basemap at street level with worldwide coverage — that is a data and CDN problem, not a package problem.
• You require very high write-frequency or real-time tiles (live vehicle fleets at sub-second freshness) — tile caching and rendering latency will fight you.
• Your data is not in PostGIS (Shapefile/GeoPackage/cloud object storage only) or the team has no spatial-database skills.
• You need raster tiles, 3D terrain, or complex cartographic styling handled server-side — a dedicated tile server (Martin, Tegola, pg_tileserv) or a managed platform is a better fit.
• You are pre-1.0 averse: at v0.3.0 the API can still move. Pin versions and budget for upgrade work each minor release.

How to Pitch It (Stakeholders)

For executives: We can serve interactive maps directly from the spatial data we already hold in PostGIS, inside our own Laravel application — no per-tile vendor fees, no geodata leaving our infrastructure, no new platform to procure. This release adds the missing operational confidence: a read-only health check that verifies each map layer end to end, and a benchmark that reports render time and tile size per zoom so we can forecast cost and performance before we commit. It also fixes a real security gap where protected layers could leak their metadata, which is why upgrading is worth doing promptly even though the package is still pre-1.0.

For engineering: Adoption is a bounded spike, not a migration. vector-tiles:doctor validates PostGIS, source, geometry column, SRID, properties, and spatial index usage per layer without writing anything — run it against a replica and you know in an afternoon whether our schema is viable. vector-tiles:benchmark then gives per-zoom render time and tile size, which is the input to capacity planning and to deciding where simplify() and filterByZoom() should sit. Access control now composes with our existing middleware, so gated layers reuse Laravel auth instead of a proxy. Two caveats to plan around: the API is pre-1.0, so pin the version and treat minor bumps as reviewable changes; and the cache-version race fix means the upgrade closes a staleness window we would otherwise have had to work around.