queryRenderedFeatures should returns original feature geometry

[JinIgarashi]

maplibre-gl-js version:

browser: Google Chrome

Steps to Trigger Behavior

1. add polygon or line layer to maplibre
2. features = map.queryRenderedFeatures(undefined, { layers:{polygon layer name added in No.1 step} });
3. console.log(features) to check features outputted from queryRenderedFeatures

Link to Demonstration

There is my working branch and preview here (watergis/svelte-maplibre-components#283).

1. open https://deploy-preview-283--svelte-maplibre.netlify.app/components/attribute-table
2. Click plugin button on the map to open attribute table
3. select village layer.

4. Click download button. also check console.log for features returned from queryRenderedFeatures
5. add GeoJSON to QGIS

The geometries from queryRenderedFeatures are split by tiles as shown in the below screenshot. and it returns 41 features since there are only 28 unique features in village layer.

Expected Behavior

It would be better if queryRenderedFeatures returns original geometry of features.

Actual Behavior

queryRenderedFeatures returns duplicated features split by multiple tiles

References

There are same issues reported for mapbox-gl-js.

• Return original geometry for GeoJSON features in queryRenderedFeatures mapbox/mapbox-gl-js#11591
• QueryRenderedFeatures returning duplicated features mapbox/mapbox-gl-js#12346

[HarelM]

Repeating my reply from slack:
queryRenderFeatures does what it should - query the rendered features, for that same reason it will not return features that were not rendered (hidden etc).
You can use querySourceFeatures to get the original geometry, I think, not sure though.
You can also retrieve the ID of a feature from the render results and query the backend/cache/local storage.
This is basically as intended, the bottom line is that the same will happen if you load this geojson on a tile server.

[JinIgarashi]

@HarelM Thank you for feedbacks. I understand queryRenderFeatures maybe is designed to return actual rendered features split by tiles as you said.
I just confirmed querySourceFeatures. This bug still presents even in querySourceFeatures funciton (maybe it is not bug as you said).

But as a developer of Mapbox/Maplibre, this behaviour of queryRendered/SourceFeatures return different geometry from original is very inconvenient. I believe many developers expect original geometry to be returned rather than actual rendered geometry

[HarelM]

This library is about rendering the data, not about storing it for you.
It might not be convenient or intuitive, but it is by design.
The documentation of query render features function is long and descriptive, I hope you spent the time reading it, if not, well, you have some homework...
Geojson source will take the original geojson and split it into tile to allow all other functionalities to work the same way they work for tiles - this isn't well documented, I agree, you are welcome to add anything that might help future developers.

[JinIgarashi]

@HarelM ok. I agree this is not bug. I saw this is well documented on the website (https://maplibre.org/maplibre-gl-js/docs/API/classes/maplibregl.Map/#queryrenderedfeatures). I am sorry for this.

Maybe you can consider this issue as a feature request.

By the way, what may confuse developers is the definition of feature. When Maplibre render features on map canvas, it considers split geometry with the same properties in the same layer as a unique feature geometry (Mapbox/Maplibre will never render tile boundaries of geometry split by tiles). queryRenderedFeatures is actually returning geometry rendered and split by tiles in the current map extent by querying mouse point or layer ID. This difference between the definition of feature in maplibre's map rendering and queryRenderedFeatures / querySourceFeatures is quite confusing. It is the same word, but it has two meanings.

[1ec5]

For what it’s worth, the original Mapbox GL team did want to support this use case: mapbox/mapbox-gl-js#5639. It isn’t quite the case that GL JS can’t be used as geometry storage; after all, it is typically the only storage of vector tile data in the application.

Storing both the tiled and untiled data in memory adds some overhead that may not always be desirable. The iOS does store the original, untiled data as a property of the source. However, this doesn’t affect feature querying; developers still need to filter that data manually.

[JinIgarashi]

Let me close this issue now since it’s not a bug. I understood the purpose of both methods is not for getting geometry of features. It can be used for getting just attributes.