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

[Linda Kladivová]

Hi Even,




you are completely right that having a SetFeature method would be nice, but 
it would require a much bigger intervention into the WriteFeature method. If
we were to do it properly, it shouldn’t be implemented as a simple Delete 
plus Create, but as a true update. That would mean checking which tiles the 
feature now intersects — part of it may fall into new tiles, part may still 
be on the same tiles, and some parts may no longer be on tiles it previously
occupied. For my use case, honestly, the ideal would be even an 
UpdateFeature method :-) because very often the geometry doesn’t change at 
all, but one or more descriptive attributes do. However, that would imply an
even more significant change, especially since a feature is currently 
treated as a single binary entity.




Just to your question Even - yes, I’d really like to get these changes 
upstream, so I have an official solution I can use for production delivery 
of Czech cadastral maps as vector tiles — and, I’ll admit, also for my own 
dissertation work as one of outputs. So for now, the first step is just to 
make it possible to open a dataset in GDAL_OF_UPDATE mode and prepare it for
updates right from the dataset creation. Regarding DeleteFeature method,  I 
like the first approach you suggested - reporting a domain-level identifier 
as OGR_FID - I think it is quite clear although it would require longer 
documentation why OGR_FID is not OGR_FID anymore :-). 




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.




Thanks a lot, and wishing you a happy new year!




Linda Karlovská




[0] https://docs.google.com/document/d/1KprkMH_YOGczrEWgXBsvubUpQWCu9_rXyG6
BQTv_RvM/edit?usp=sharing

---------- Původní e-mail ----------
Od: Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org>
Komu: gdal-dev at lists.osgeo.org
Datum: 23. 12. 2025 14:25:13
Předmět: Re: [gdal-dev] Decoding feature blobs and tracking FIDs in MVT 
datasets
" 
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

-- 
<a href='http://www.spatialys.com' class='-wm-moz-txt-link-freetext'>http://www.spatialys.com</a>
My software is free, but my time generally not.
_______________________________________________ 
gdal-dev mailing list 
gdal-dev at lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev 
"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260104/99bd0827/attachment.htm>