<html><body><span style="font-size:16px"><span style="font-size:16px"><div>Hi Even,</div><div><br></div><div>you are completely right that having a <code>SetFeature</code> method would be nice, but it would require a much bigger intervention into the <code>WriteFeature</code>
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 <code>UpdateFeature</code>
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.</div><div><br></div><div>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_<code>OF_</code><code>UPDATE</code> 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 <code>OGR_FID - I think it is quite clear although it would require longer documentation why OGR_FID is not OGR_FID anymore :-).</code> </div><div><br></div><div>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.</div><div><br></div><div>Thanks a lot, and wishing you a happy new year!</div><div><br></div><div>Linda Karlovská</div><div><br></div><div>[0] https://docs.google.com/document/d/1KprkMH_YOGczrEWgXBsvubUpQWCu9_rXyG6BQTv_RvM/edit?usp=sharing</div></span></span><br><aside>---------- Původní e-mail ----------<br>Od: Even Rouault via gdal-dev <gdal-dev@lists.osgeo.org><br>Komu: gdal-dev@lists.osgeo.org<br>Datum: 23. 12. 2025 14:25:13<br>Předmět: Re: [gdal-dev] Decoding feature blobs and tracking FIDs in MVT
datasets</aside><br><blockquote data-email="gdal-dev@lists.osgeo.org">
<p>Hi Linda,</p>
<p>(Mailing lists have had issues lately)</p>
<blockquote>
<p>And internally I also have
the full update pipeline implemented - when the dataset is
opened in
<code class="-wm-western">GDAL_OF_UPDATE</code> mode, an
instance of
<code class="-wm-western">OGRMVTWriterDataset</code> is created,
which
allows me to call <code class="-wm-western">DeleteFeature</code>
(D) and
<code class="-wm-western">CreateFeature</code> (I), or a
combination of
both when an existing feature needs to be updated (U). </p>
</blockquote>
Updating an existing feature would normally be done through
SetFeature(), but Delete+Create may be OK for your use case
<blockquote><br>
<p>Given this, I started thinking about an alternative solution
based
on a stable, domain-level identifier such as <code class="-wm-western">domain_id</code>
(in practice, e.g., <code class="-wm-western">parcel_id</code>),
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 <code class="-wm-western">idx</code>, geometry,
and tile
coordinates). <code class="-wm-western">DeleteFeature</code>
could then
be implemented by removing all rows associated with that
domain-level
identifier (that would be an input parameter).</p>
</blockquote>
<p>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}"</p>
<p>Even</p>
<pre class="-wm-moz-signature">--
<a class="-wm-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
_______________________________________________
<br>gdal-dev mailing list
<br>gdal-dev@lists.osgeo.org
<br>https://lists.osgeo.org/mailman/listinfo/gdal-dev
<br></blockquote></body></html>