Ownership of data for feature layers

[lennart]

Let's say I have a list of points, each with metadata, that I keep in my app state. I then want to both, pass this list to galileo as a feature layer to render the points as Map-Markers, and also pass them to a gui (e.g. egui). Both, galileo via event handlers, and egui via handlers on gui widgets, may mutate the metadata of each point, and also might add or remove points.

I am wondering if it is possible to retain ownership of data in my app state that I pass on to a FeatureLayer, or if it is intended that galileo takes ownership of both the collection of features and the features themselves.

Currently creating a FeatureLayer requires passing a Vec<Feature> which, as far as I understand, hands over this vec to galileo and it can only be manipulated via the features, features_mut getter (which exposes the underlying FeatureStore).

I looked at the with_egui example which facilitate the sharing of data between galileo and egui via passing (copies) of data on every frame. In the example this is read-only and, as far as I understood the current Galileo API, I would only be able to get (mutable) references of a feature out of a featurelayer (layer.features_mut(), and then feature_container.as_mut()). This does not seem to be what I would want to do.

Is the current state of the API intentional, i.e., galileo will need ownership of the list of items contained in every feature layer, or is this a stopgap? How would one allow manipulation of the collection of features and the features themselves from multiple places? (I started working towards using the (winit) event loop to pass UserEvent around to manipulate the data in a single place, but that place would eventually need to be through the galileo api)

Thanks in advance for any insights!

[Maximkaaa]

Hi, @lennart . Sorry, for the late reply. It's very good that you raised this question since I haven't give much though to ownership of data in Galileo structures. The current API is done as is just because this was what my previous take on mapping libraries did. (It was not in Rust, so there was no question about ownership at all...)

To tell the truth, I don't think that the current implementation of FeatureLayer is satisfactory. I tried to make it magically do everything at once: keep track of data changes, apply and control styling, reproject geometries into map CRS etc. And such approach rarely results in comprehensive and convenient API. So I am totally up for ideas on how to make it better.

As a way forward I would suggest you come up with a simple implementation of the Layer trait that takes some parts of FeatureLayer, and leaves out all unnecessary complexities. This should be straightforward to do. Just take features, pass them through symbols and send resulting bundles into the renderer. I'm not even sure that caching of bundles is necessary unless you work with large data sets (up to ~10k features should be fine to render directly at 60 FPS).

If such layer would prove to have convenient API, we can see how to modify FeatureLayer to reflect that, or just add that implementation as a separate layer type in the Galileo.

[lennart]

@Maximkaaa thanks for your reply! I will try out implementing the Layer trait myself as you describe and see how it works out and what a future FeatureLayer might look like. I'll mark this as the answer and would potentially open an issue with regard to changing/adding an alternative FeatureLayer.

Also good to know that up to 10k features caching of bundles might not be necessary, I will check since my current project will potentially not need more than that.