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 <[email protected]>
Komu: [email protected]
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
"
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to