[feature request] more control over `GeoJSONVectorTileDataSource`

[farfromrefug]

It would be nice to able to add/remove/update items in GeoJSONVectorTileDataSource. This would avoid the need to always have to transform the whole feature collection from String (if working with string geojson). Internally it seems possible as it is already possible in MBVTTileBuilder. The only issue i see is that you force the feature id with ++_featureIdCounter instead of using the passed feature id (which per specs is either a string or a number). If it was changed to feature.id = feature.id || ++_featureIdCounter; then you could imagine something like

delete(featureId: string | number);

Update or replace is a nice to have not a requirement i think.

EDIT: actually the feature.id override is a bug. If i pass a geoJSON with a specified id, then in the vector tile click event i wont get the same id back (it will be the one from feature.id = ++_featureIdCounter

[mtehver]

Right, it would make sense to use the 'id' property for id by default and auto-generated id as a fallback. MBVT does not support string ids though, so I guess a hash of the string id could be used in that case. Tagging this as enhancement, will implement this probably for 4.4.2.

[mtehver]

@farfromrefug SDK 4.4.2 RC1 now includes the changes to id generation. I have not added the delete method you suggested, but instead optimized setLayerFeatureCollection method (it does not use serializing/de-serializing steps anymore).

[farfromrefug]

@mtehver ok i actually stopped using setLayerFeatureCollection because it was doing the serializing/de-serializing. So i use setLayerGeoJSON with a variant. It is much more efficient. I would still really like to be able to add / remove / update single features. Would make the GeoJSONVectorTileDataSource a true replacement for LocalVectorDataSource with the bonus of using carto css. Would you prefer me to open another issue?

[mtehver]

@farfromrefug Better and more fine-grained API for GeoJSONVectorTileDataSource makes a lot of sense. I am not 100% sure what is the best approach regarding API, though. Will look into this post 4.4.2 release.