search

maplibre / maplibre-tile-spec

Next generation vector tiles format
Apache License 2.0
179 stars 14 forks source link

Consider making geometry optional #312

Open andrewharvey opened 2 months ago

andrewharvey commented 2 months 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 months 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.