Optionally persist layers and sources across styles

[1ec5]

Annotations added to the map persist even after switching styles. This can be especially handy for an application that allows the user to switch back and forth between Streets and Satellite: any dropped pins, drawn shapes, or route lines remain on the map the whole time. The developer isn’t responsible for rebuilding the data on each style change.

Per #5626 (comment), for the runtime styling API to have parity with the annotation API, there would need to be some way for certain layers and sources to optionally persist after switching styles. I’m not sure whether the SDK would have to take full responsibility for persisting this data, or whether mbgl can keep track of some state.

/cc @jfirebaugh @incanus @frederoni

[jfirebaugh]

This is a well-recognized problem, but there appear to be few designs that don't introduce significant additional complexity of their own.

mapbox/DEPRECATED-mapbox-gl#25 has a proposal for one possible approach.

[boundsj]

For reference, here is a post that illustrates the kind of workaround that platform developers must do to manage runtime styling sources/layers on top of changing styles.

[nitrag]

@1ec5 , Would it be much work for the SDK to remove the source+layers from the mapview right before a style change, keep the references, and add them directly back when the style is ready?

I think asking the developers to do this isn't efficient and it's not clear in the docs that this WILL happen on style changes.

I would need to maintain a class level variable for MGLShapeSource to retain the shapes, right?

[boundsj]

@nitrag Would it be much work for the SDK to remove the source+layers from the mapview right before a style change, keep the references, and add them directly back when the style is ready?

Such an approach might be blocked by #7437

[nitrag]

I discovered a bug with the workaround in #7124 (comment). If you use a class level variable to hold a MGLShapeSource and even though you properly remove the source from the map before changing the style and adding it back to the new style you will get the following crash. Reproduced with aggressive zoom behavior and standard annotations on the map.

libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

updateUserLocationAnnotationView

I've resorted to wiping all the layers clean and starting fresh each time the style changes. Not perfect solution.
Also, this prevents the use case of being able to record users tracks on a map and being able to change the map style when doing so.

Please consider this a friendly bump in priority for this feature.

[1ec5]

If I’m not mistaken, yanking a source out from under a layer that uses it could result in undefined behavior. So to be safe, you’d have to remove the layers before removing the source that they use, the change the style, then add the sources and layers back, in that order. I recognize that isn’t a far cry from starting afresh.

[anandthakker]

Here's a broader tracking ticket for designing a style-spec level solution to this problem: mapbox/mapbox-gl-js#4225

[1ec5]

mapbox/mapbox-gl-js#4225 would only be a complete solution inasmuch as we plan to remove the ability to switch styles altogether, although it would eliminate one use case for switching styles.