search

maplibre / maplibre-tile-spec

Next generation vector tiles format
Apache License 2.0
157 stars 13 forks source link

Consider making geometry optional #312

Open andrewharvey opened 2 weeks ago

andrewharvey commented 2 weeks ago

Per the current spec a geometry for each feature is required.

https://github.com/maplibre/maplibre-tile-spec/blob/2b14c64c10a1ae3926d7da9857cf8ddbb5917a24/spec/README.md?plain=1#L31

Have we considered loosening this to make geometry optional?

  1. Frequently updated attributes with infrequently updated geometries.

For example you might want to have the road network as MLTs with geometries that the browser can cache for longer, then a separate endpoint for MLTs without geometries but with live traffic attributes (using the id column to join the two together client side). This reduces the download size when updating a loaded map with fresh traffic data.

  1. Data with a large range of attributes.

For example you may have standardised census regions and possibly thousands of different attributes linked to those regions. In your application you could load the MLTs with the census regions, then based on the user selection within the app request geometryless MLTs just containing the attributes required to join to these regions client side.

cutephoton commented 2 weeks ago

I've been pondering how to solve this particular issue. Came up the other day in a discussion.

https://github.com/maplibre/maplibre-gl-js/discussions/4565

Geometry is fixed but data updates regularly and exists in the time domain. (I'm processing weather data that can be explored by the user.) The dataset is updated every 30 minutes. Using mbtiles and generating a new time slice for each hour/day is gigabytes of data. It will probably work, but it seems like the wrong way to approach this problem.