Should MapLibre support the GeoJSON spec fully?

[willtemperley]

Currently MapLibre effectively strips GeoJSON string feature ids (#1043), which are perfectly legal according to the spec:

"If a Feature has a commonly used identifier, that identifier SHOULD be included as a member of the Feature object with the name "id", and the value of this member is either a JSON string or number." [1]

It is straightforward to put the id in the properties of course, but the user needs to guarantee there will be no clash with other properties. We don't always have control over the properties - for example if I'd chosen "fid" there are 300k opportunities to overwrite an OSM tag [2]

This really feels like the library is imposing constraints on the data model.

[1] https://datatracker.ietf.org/doc/html/rfc7946#section-3.2
[2]https://taginfo.openstreetmap.org/keys/fid#overview

[HarelM]

I've written this is the past but I can't find it now for some reason... :-(
In any case, the reason behind this limitation is the following:
In order to use geojson in maplibre, maplibre uses geojson-vt so that it slices the geojson into tiles under the hood.
These tiles conform to MVT standard which doesn't allow setting the id as string (and other limitations that are due to how the format is defined and its ability to be sent fast).

We are looking into creating a new format that will power maplibre better, but it will take years I believe.
In the meantime, I'm not sure there's a good solution for this.
While I sympathize with the problem, your best bet would be to use a field in the properites or have the id be integer.

See this too: mapbox/vector-tile-spec#94 (version 3 was never released so the merged PR is not "helpful".

[willtemperley]

Thanks for the informative answer. It seems there would be strong support for string ids in a 3.0 spec if it ever comes.

FWIW I think I'll use the array index as an id and maintain an array of string ids in the JSON, which at least has some performance benefits during feature lookup.