Hi Linda, Happy New Year
I’ve put together a short document with the planned implementations [0]. Could you please take a look (or anyone else interested in this topic) and let me know if this seems okay to implement? Part of the work I have already done, but I’d like to make sure it follows GDAL conventions all the way through.
I've read your detailed document. Your plan looks solid. My main remark is that when a driver accepts to open a dataset in GDAL_OF_UPDATE mode, it is expected that read operations are still available. Failing to do that could cause issues for users/software that always open in update mode if possible, even if they end up not doing any change. By using OGRMVTWriterDataset which is write-only, you wouldn't be able to meet that expectation. It could be complicated to extend OGRMVTWriterDataset to have read capabilities (especially since the writing side generates several zoom levels at once, whereas the reading side has one dataset per zoom level), so I would suggest that the update mode you describe is triggered by both GDAL_OF_UPDATE and a specific open option like EDIT_ONLY=YES / UPDATE_ONLY=YES. Or maybe just the later.
If you plan to implement updates of existing features, implementing ISetFeature() only would be sufficient. IUpdateFeature() is reserved for drivers that can offer such capability naturally, typically drivers for a SQL database.
Even -- http://www.spatialys.com My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
