Best practice to store a feature in a GeoJSON with accurate geometry

[BenOnTrack]

Hi Maplibre team,

I've been struggling over the past few months on a recurrent issue, regarding geometry of VectorTile features stored and then displayed as a GeoJSON, having discrepancies with the "original" vectorTile feature (white on the picture) versus the "stored" one (purple on the picture), at high zoom level.

I've found a few similar topics, where people are wondering what's best between using queryRenderedFeatures or querySourceFeatures. I believe this topic is to make sure I understand correctly what's happening and that there might be no solution to my issue.

Objective

The User clicks on a feature rendered on the Map.
The App stores that feature, update a reactive GeoJSON source Rune (svelte5), that is displayed on the map.

Small comment on the rationale of using an additional GeoJSON:
Initially I only stored the id of the feature "clicked", had a duplicate of my feature VectorLayer, and had a reactive filter on those ids. It worked "OK", but :

• there is no cluster on VectorTile (at least not yet) -> having cluster for "stored" features is more than ideal
• the zoom of the features saved is the same as the one available in the VectorTile -> ideally, it's convenient to see your "saved" features at lower zoom level

For those reasons I've switched to GeoJSON.

The Issue

When doing so, I have discrepancies between my GeoJSON feature and my "original" VectorTile feature. Why ? My understanding (and this is where I'd love to make sure I'm understanding it properly) is:

• GeoJSON source are rendered with their unique geometry (the one stored)
• VectorTile source are rendered with a "more accurate" geometry to take into account the projection (?) hence having different geometries at different zoom level.

Hence, since today I perform a queryRenderedFeatures on my "original" feature, I actually store "a" geometry of my feature. Geometry that would be rendered differently at different zoom levels hence explaining the discrepancy between both the "original" data and the "stored geojson" data.

The Question

Is there actually a solution to this problem ? If not, what would be the best workaround ?

Thank so much for taking the time and for your feedbacks.

[HarelM]

I would recommend getting the geometry from a backend server instead of relying on the rendered geometry as it is meant for rendering of the base map and not for rendering a "place".
This is what I'm doing in my app at least, with overpass API.
When I get the original geometry with good precision, I set it to a geojson source.

[BenOnTrack]

Wouldn't that be the same as performing a querySourceFeature on the feature clicked ?

So basically :

• User clicks on Feature
• perform a queryRenderedFeature to get the feature id
• perform a querySourceFeature based on this id to get the geometry
• store the geometry

?

[HarelM]

No, it's not the same as query source feature is zoom specific and if you have tiles that were "simplified" for lower zoom levels you would get a feature that is not accurate, this is why querying a backend would result in accurate results that are not zoom dependent.

[BenOnTrack]

Thanks for the feedback - Let me try and come back to you if that solved my issue

[BenOnTrack]

It works better, but the main drawback is that it requires a backend with a dataset containing all the data already available in the tile, which results in duplicating information. However, I understand it's the only way.

My current workaround is to filter out the initial feature, where ids is the array of stored IDs.

["!", ["in", ["get", "id"], ["literal", [ids]]]]

Hence, removing the duplicate from the map. It's not pretty, but it works. However, I'm unsure about the performance with large arrays.