map

Get Layer Mvt Tile

Changed on

Serve an MVT tile for a layer.

The tile is cached against the layer's own data_version, so a data change makes the prior tile unreachable rather than merely expired. The client still sends ?v=: the browser's HTTP cache needs a new URL on a bump, and validate_tile_access reads it as a staleness hint against its layer memo. filter_id references a server-side FilterSpec (POSTed via /filters); when present, the tile contains only matching rows. Favorites-only filtering pulls the user's favorite ids inline so the tile WHERE-clause includes them — without that, the tile would visually drop the favorites filter even though the table respects it. viz names a layer column to embed as a feature property at every zoom (below the include-all zoom only the core name/owner/address columns ship otherwise) so the client can drive a value-weighted visualization; unknown columns are dropped silently.

get/api/v1/map/{layer_id}/tiles/{z}/{x}/{y}.pbf

Request

  • Base URL
    https://api.maia-analytics.com (the document declares no server; this is the origin it was published from)
  • URL
    https://api.maia-analytics.com/api/v1/map/{layer_id}/tiles/{z}/{x}/{y}.pbf
  • Auth
    HTTP bearer

Path parameters

zinteger required
xinteger required
yinteger required
layer_idstring uuid required

Query parameters

filter_idstring uuid nullable
vizstring nullable
vstring

The layer's last-known data_version. Not the cache key — the server builds that from the layer itself — but keep sending it: it is how a client that has already seen a newer version tells the server its layer memo is stale.

mvstring

The layer's last-known metadata_version, the other half of the same staleness hint. Column visibility and provenance move this and not data_version, so a client that sends only v cannot tell the server its memo is behind on a metadata write.

Response

Successful Response

Changes