[gdal-dev] Decoding feature blobs and tracking FIDs in MVT datasets

[Even Rouault]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251223/2226fbf8/attachment.htm>