Open mikkohei13 opened 3 days ago
@olzraiti @aorin or @wkmor1 Can you evaluate how large task this would be? (Should we have labels for estimated task size, in addition to "quick"?) Are there possible complications in handling Geopackage fields?
FYI @AlpoTurunen Testing mention feature here also.
I don't think this is a huge task. Just adding a step to convert the Geopackage file to something importable. Lots of tools to do this e.g., https://gdal.org/en/latest/programs/ogr2ogr.html. GIS software has identifiers. Do think there is any guarantee they are persistent though. Don't think any software can guarentee that. It is a question of how the users are using the identifiers. That situation is the same for any file format so has to be managed same way we always do.
As someone having observations in a GIS system, I want to easily copy the data to Vihko without first converting it to a tabular format, so that the process is easy and quick for me.
Possible solution: Allow importing Geopackage documents using Vihko import feature (https://dev.laji.fi/vihko/tools/import) by converting them internally to a format accepted by the import system. Require the same data fields (i.e. attributes) as in tabular data imports, and allow the user to map the fields in similar way. Possible unnecessary fields in the Geopackage file can also be ignored this way.
Does GIS software and/or Geopackage files have persistent id's for data rows? if not, how users could create them?