[QGIS-Developer] GPKG and FID -- can we fix this mess?

[Matthias Kuhn]

On Thu, Oct 15, 2020 at 7:23 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> On jeudi 15 octobre 2020 17:48:30 CEST Matthias Kuhn wrote:
> > If there is a managed database where there has been a conscious decision
> to
> > have an integer id column (postgres case) and workflows are built around
> > this: filling the id on insert, building foreign keys against it etc,
> that
> > works just fine.
> >
> > But if GeoPackage is used as a generic dataformat (typical Shapefile
> > replacement), requirements are different and workflows less managed. E.g.
> > The "simple" case of merging two datasets already poses the question what
> > to do with the two colliding fid attributes. Delete the original fid
> > columns and regenerate one. Or preserve both and generate a new one
> > (leading to fid, fid_1 and fid_2).
> >
> > If we look at the fid attribute as part of the data (where we have
> foreign
> > keys pointing two etc) we want it to be preserved.
> > If we look at it as a purely internal technical id (for RTree management
> > etc) we don't care for it and can just regenerate and forget about it.
> >
> > It looks as if we need to keep it as a technical id.
> > I like the idea to transparently generate it in addFeature.
> > I would also prefer to hide it away from the user and only leave it
> > available through $id. This would make it clear to users that it's for
> > internal use and no one would expect it to be preserved after a merge
> > operation. For backwards compatibility there could be a provider flag to
> > re-enable it.
> > I hope that makes sense.
>
> As I like playing devil's advocate :-), one issue I can think of is : how
> can
> you know when you open a GeoPackage, possibly created by another software,
> if
> the integer primary key column is a technical one (that could perhaps be
> hidden), or a "real" one part of the data and intended to be user visible
> ? So
> we would need some user feedback...


Correct, QGIS can't know. I as a user have better chances. I was trying to
propose to pass this as a parameter to the data provider (as an option in
the add layer dialog). This is not necessarily easy to implement.

Or maybe more simply, for pure QGIS
> workflows, we could decide for a new value for the fid column name when we
> create a GPKG table, like "hidden_fid", and when opening such GeoPackage,
> decide to not expose it as a field. That could solve issues for GPKG
> created
> from now by QGIS, while still providing some backward compatibility. And
> people wanting to still have a visible fid, and ready to deal with
> possible
> annoyances, could overload this "hidden_fid" value with another value.
>

This sounds like a simple while powerful solution.

Matthias


> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20201016/3d4c8932/attachment.html>