Runtime Styling API - mutable GeoJsonSource

[sddamico]

This is really a feature request for two methods:

1. MapboxMap#getSource(String sourceId)
2. GeoJsonSource#setData(String rawJson) or, better, #setData(Object jsonObject) so that the caller doesn't need to serialize to String every time.

Intended use here is the ability to dynamically update GeoJson sources. Specifically, this includes things like adding/removing Features from FeatureCollections, etc. and, also, being able to modify the data in sources that are pre-defined in the map style.

Currently, I'm needing to removeSource() and then addSource() when I want to update source data.

[sddamico]

Tangentially, adding a first-party GeoJson implementation might be useful. I've started adapting https://github.com/filosganga/geogson by removing the guava dependency in my own project, but I can see others finding use for it.

[ivovandongen]

@sddamico Thanks for the report.

The api around sources is immutable on purpose ATM as the underlying resources are immutable. Adding a getter + setData() would still need to do add and remove the source.

Concerning the gson support. Currently we're bringing in GSon specifically for GeoJson in #5869 from https://github.com/mapbox/mapbox-java. I like your idea and I added a ticket for it: #5941

[sddamico]

Great! Thanks @ivovandongen.

Interesting choice on the immutable sources, I was observing the js api and the geojson source there has a setData(). What was the reasoning there?

Somehow I missed the GeoJSON implementation in mapbox-java, I'll be moving my project over to that shortly.

[ivovandongen]

@sddamico Digging further into this, I see now that it should be possible to add a getter for the source and setters for the data/url. Seems like I missed that in the initial implementation.

Somehow I missed the GeoJSON implementation in mapbox-java, I'll be moving my project over to that shortly.

The dependency on mapbox-java is new since #6012 .

[sddamico]

Awesome, thanks!

[1ec5]

Tracking the iOS/macOS equivalent in #6159.

[ivovandongen]

We need to wait on #5701 #6264 for this as the changes in the source are not reflected on the map at this time.

[jfirebaugh]

#setData(Object jsonObject)

Agreed that this signature would be ideal; it requires #5623.

[ivovandongen]

@jfirebaugh For java, Object parameters make less sense. I've added a setter for GeoJson types to accomplish the same thing here.

Besides untyped parameters not being common in java, it would require some nasty reflection from jni as there is no way to access an Object as a map like in some other languages.

[jfirebaugh]

Sorry, I should have been more clear. My point was, ideally neither the API nor implementation require a round trip through stringified JSON. The function signature you linked to looks good, but I want to avoid the features.toJson() in the implementation.

[tobrun]

Core integration has landed with 7df9a21