Repository navigation
mbgl::style::GeoJSONSource should have GeoJSON getter #7376
Description
Activity
This would increase memory consumption, probably unreasonably so in some cases that the core API needs to support, such as embedded or otherwise memory constrained devices.
I've filed the inverse behavior as a bug in GL JS, and I would similarly argue that the native SDKs should choose the memory efficient route, and leave it up to the developer to keep the input data around in the case that they need it and are willing to accept the memory usage. But if this is a critical feature for iOS, and you are sure that the convenience of having the is worth the increased memory consumption in all cases, then you could implement it at the SDK level.
It is already implemented at the SDK level, but that inevitably leads to #7375. The only way I can imagine getting around both problems is for MGLStyle to have a canonical, one-to-one mapping of MGLSource objects to
mbgl::style::Sourceobjects, like it does for MGLOpenGLStyleLayers andmbgl::style::CustomLayers and like MGLMapView does for MGLAnnotations.leave it up to the developer to keep the input data around in the case that they need it and are willing to accept the memory usage
I wanted to do this in #7377 to address #7375, but I held off because
MGLShapeSource.shape’s getter and setter already appear to be the most popular part of the runtime styling API on iOS, and because it makes little sense for a property to be write-only: #7375 (comment).Peanut gallery here: I still think that if you had
appendfunctionality there would be less memory concern because I wouldn't need to use getting/setting of the shape/geojson source. If you are going to get 50 shapes, add 1, then set 51 shapes...that's inefficient in itself.This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.
mbgl::style::GeoJSONSourceshould have agetGeoJSON()method, which would be required for fixing #7375. Currently,setGeoJSON()tiles up the passed-inGeoJSONobject, but it doesn’t hang onto that object, nor does there appear to be a way to losslessly convert aGeoJSONTileback into the originalGeoJSON. If it wouldn’t increase memory consumption unreasonably, perhapsGeoJSONSourcewould hang onto theGeoJSONobject alongside the tiled data./cc @jfirebaugh @ivovandongen