On 5/8/20 3:13 PM, Tobias Wendorff wrote: > Am 08.05.2020 um 15:10 schrieb Andreas Neumann: >> To me, this is not a downside, but a big, big plus! Fewer mess on the >> file system. > My students and co-workers start to save each layer in a new GPKG, so I > don't have a benefit all ;) > >> And it is the whole point of a Geopackage, to package many data sets >> into one file, so it can be easily shared. > Just ZIP or TAR them ;)
Thanks for raising this Matthias! But I think we should not try to create a silver bullet here. One should use gpkg where it fit's (and that is apparently NOT in networked environment, that is where db's are a better fit?). About Tobias' flatgeobuf: instead of a shp/gpkg file alternative, would this not be a very good candidate to store our intermediate processing steps in (which was shp, not shure what it is now?)? May I second the above mentioned good thing about gpkg: that you can have more (related) sets of data in one file, that you can create joins in these to create views, that you can save styles and projects in it etc etc The fact at most people use some programs/formats to do things they equally can do with a txt/csv file does not make a more advanced format a bad format :-) Today I actually hit an issue in which selection first seem not to work: https://github.com/qgis/QGIS/issues/36291 from which my conclusion is: views are cool but be careful with primary keys! So in the case of gpkg we should probably have a dialog like we have for Postgis/Oracle in which you can define a Primary Key, etc etc? Which brings me to: we should handle gpkg as actual databases and not as simple files? Maybe we/ogc are actually trying to mixup concepts: databases vs simple files? Regards, Richard Duivenvoorde _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer