On Fri, Mar 20, 2020 at 6:04 PM matteo wrote:
>
> +1000 from an user perspective the fid is really confusing. The user
> seems to be able to delete/edit the column but (of course) touching it
> will throw an error when saving.
>
> Moreover, it happens that during format conversion in the
Hi,
> I personally HATE HATE HATE these columns, and would rather I never
> saw them ever again. Does anyone else feel the same? If so, could we
> potentially just permanently hide these columns from QGIS and avoid
> all these dangerous issues for users?
+1000 from an user perspective the fid is
I used to frequently get errors when copying and pasting features across
geopackage files.
So now, before saving the edited file, I select all features and set the
fid to NULL, which avoid errors most of the times.
On Fri, Mar 20, 2020 at 5:07 AM Alexis R.L. wrote:
> Greetings,
>
> Personnally
Greetings,
Personnally when splitting layers and when there are FID conflits, I try to
solve it manually. Sometimes it tells me that the fid of feature x cannot
be change, which are not indistinguishable.
And the next time you open the geopackage there is a change that the fid
column will now be
I agree too - I also dont like that we get an FID column when we import another
table that already has an id column….all sorts of chaos ensues….
https://github.com/qgis/QGIS/issues/30697
Regards
Tim
> On 19 Mar 2020, at 17:00, René-Luc Dhont wrote:
>
> I agree, so in my algorithms working
I agree, so in my algorithms working with geopackage I always redefined
FID with
options = QgsVectorFileWriter.SaveVectorOptions()
options.layerOptions = ['FID=id']
For me it is like a primary key in PostGIS, I need to manage it.
Other point, Feature ID in QGIS is still a short integer.
+1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived and
allowed business logic primary keys.
Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow a écrit :
> I agree.
>
> If there is an ID that is used internally as a unique primary key it
> should never be shown to the user. It
I agree.
If there is an ID that is used internally as a unique primary key it should
never be shown to the user. It should not be expected to be edited outside
of the provider's control or be stable between edits.
If you need a stable ID for reference you should make your own {{insert
rant about
Hi Nyall,
Similar thoughts here.
Not sure what a format wins from forcing people into using an integer
based primary key column.
I think ultimately it is the data producer's responsibility to assign
unique and sensible identifiers with meaningful names (aka primary keys)
to data.
All the
Hi list,
Just wondering what everyone's thoughts are about geopackage FID
columns. Personally, I find them an absolute nightmare to deal with,
resulting in annoying (and dangerous) issues when trying to save
geopackage edits, such as
- field type issues: converting certain formats to geopackage
10 matches
Mail list logo
