Geojson tile pyramid source type (i.e. virtualized geojson)

[fr-an-k]

Motivation

Mapbox vector tiles degrade properties and (optionally) geometry, and are unnecessarily expensive when generated locally, and therefore don't serve our use case, but whole geojsons have the downsides that they are expensive to load and query.

A better way is to have a pure geojson tile pyramid source; perhaps with tile coordinates if that improves performance. The geojson tiles would be ideally be objects returned by addProtocol loadFn, rather than strings. The features should exists as one javascript object referenced by multiple tiles.

The current workaround is to add geojson sources per tile (bbox) at a specific zoom level, and load/unload them yourself based on the move(End) event.

Design

A geojson tile pyramid source type.

[HarelM]

I'm not sure I'm following, but in theory, you can create any format you want using addProtocol.

[fr-an-k]

The {x} {y} {z} in the url are not replaced by tile coordinates; it seems to only support a single geojson as source. The loadFn callback is not documented so I could be missing something.

[HarelM]

Geojson doesn't support tiles, if you use vector type source you'll get the x,y,z urls.
Can you please define the problem better? I'm leaning towards closing this issue or transferring it to be a discussion...

[tuukka]

I would also like to have this feature (support vector tiles in GeoJSON format without having to convert them to MVT at any point).

[wipfli]

Why don't you want to convert them? And why do you want to have a tiled source?

[wipfli]

I think it is a good idea to have a discussion here.

[wipfli]

@frank-unovica thanks for posting this idea. Can you describe your use case? How many features do you have in GeoJSON? How precise do locations have to be?

[fr-an-k]

What I mean is geojson virtualization; only load the visible features, but not degrade them into tiles or require use of the service worker for locally generated tiles.

I'm dealing with up to ~100 sources and throusands of styling layers, and high detail geojsons on city level of hundreds of MB. I do realize this is not necessarily supported by the current architecture, but it works fine, even with expensive React components on top.

The Chrome service worker doesn't implement/forward the cancel signal for offline tiles, causing request overload on IndexedDB (our persistent tile cache), leading to annoying stutter. It also complicates the application, and in our case we even have to load the visible geojsons twice, since the decoded tile features are too degraded to display properties in a (virtualized) table, or highlight the entire feature (it's broken up).

The internal geojson tile processing in maplibre doesn't offer optimization possibilities, such as dexie (IndexedDB) integration for caching, which would avoid the service worker.

Actually I think it might be better after all to listen to the move(End) event and calculate which tiles are visible, rather than the tile xyz load function, partially since there is no matching tile unload function (yet) and to avoid complexity from features that cross tiles. So the application would manage the features and update the geojson data source. So it is not a critical feature request, if this turns out to be performant enough.

An ability to dynamically adding/removing features instead of setData would theoretically solve unnecessary re-encoding and uploading to the GPU, IF that's where the encoding/uploading step can be localized within maplibre. A tile unload callback would have to be added to addProtocol, or a generic tile visible/hidden event instead.

Further optimization is possible: a geojson source with integer tile coordinates at a specific zoom level (array of x, y, u, v where u, v = internal tile coordinates). That would remove a lot of trigonometry.

So again, virtualized is a better way to describe it, but it can be done by mercator (viewport) or xyz (tile load/unload) coordinates for optimization.