Consider making geometry optional

[andrewharvey]

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

maplibre-tile-spec/spec/README.md

Line 31 in 2b14c64

Each feature must have a geometry column, an optional id column, and optional property columns. The geometry column type is based on the OGC's Simple Feature Access Model (SFA) without the support for GeometryCollection types.

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.

2. 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]

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

maplibre/maplibre-gl-js#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.