Hi Linda,
(Mailing lists have had issues lately)
And internally I also have the full update pipeline implemented - when
the dataset is opened in |GDAL_OF_UPDATE| mode, an instance of
|OGRMVTWriterDataset| is created, which allows me to call
|DeleteFeature| (D) and |CreateFeature| (I), or a combination of both
when an existing feature needs to be updated (U).
Updating an existing feature would normally be done through
SetFeature(), but Delete+Create may be OK for your use case
Given this, I started thinking about an alternative solution based on
a stable, domain-level identifier such as |domain_id| (in practice,
e.g., |parcel_id|), which is already known at write time. This would
require storing such an identifier explicitly in the intermediate
SQLite table (in addition to the internal |idx|, geometry, and tile
coordinates). |DeleteFeature| could then be implemented by removing
all rows associated with that domain-level identifier (that would be
an input parameter).
I'm not clear if you intend to submit the changes you mention upstream,
but if so, using your domain-level identifier for DeleteFeature()
wouldn't be appropriate given that DeleteFeature() is supposed to take
the OGR FID as input parameter. So, either you would need to add logic
into the driver to report a domain-level identifier as the OGR FID (for
example through an open option that would take the name of an
attribute), or you would need to implement a pseudo-SQL command through
ExecuteSQL(), like "DELETE_FEATURE_BY_DOMAIN_ID {domain-level-identifier}"
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
