> This makes me wonder when we could start using this in QGIS - I am > afraid we will have to wait for some time until it is all out in a > stable Proj release and adopted by major distributions, which may take > quite some time... (a year?)
Yes, likely. PROJ 6 is scheduled for February 2019. GDAL 2.4 for May > Pretty much. Looking at the grid support, I see that the OSTN15 > transformation is listed there in the grid_transformation table, but > we would also need an entry in grid_alternatives table for it + > include it in a future release of proj-datumgrid-europe package (that > particular grid is BSD licensed, so it should be fine). Yes, https://github.com/OSGeo/proj-datumgrid/issues/21 > > Regarding contents of proj.db table, will it be acceptable for apps > like QGIS to browse its contents or should it be considered as Proj > library's implementation detail and any queries to it should go > through Proj API? Well QGIS could do it, but there's the risk that the DB structure might change at some point. > I am thinking it would be nice to automatically > determine grid packages for missing grid files and to download them in > QGIS if the users wants. I've anticipated that need. In the PROJ API, there will be a function to list all potential transformations from CRS A to CRS B, independently of the availability of grids PJ_OPERATION_RESULT PROJ_DLL *proj_obj_create_operations( PJ_OBJ* source_crs, PJ_OBJ* target_crs, PJ_OPERATION_FACTORY_CONTEXT* operationContext); and then you can iterate over the potential operations returned, and ask for each operation, which grids are needed, and if they are available, and if not, where you can find them: int PROJ_DLL proj_coordoperation_get_grid_used_count(PJ_OBJ* coordoperation); int PROJ_DLL proj_coordoperation_get_grid_used(PJ_OBJ* coordoperation, int index, const char** pShortName, const char** pFullName, const char** pPackageName, const char** pPackageURL, int* pAvailable); > Another question is what to do with grids > with license that does not allow redistribution - should we have > entries with URL in grid_transformation table for such grid files as > well? (maybe with a flag that it is not direct link to a package, just > a web page about that grid) I guess grid_alternatives could receive additional columns, which would be used if package_name is NULL, perhaps something like: open_license BOOLEAN download_url TEXT direct_download BOOLEAN Putting that in my TODO list > > One final thought - how about customization of proj.db by ordinary > users? In QGIS users are allowed to define their custom CRS based on > Proj string - is something like that going to be supported? The issue is that a PROJ string is a rather low expressive way of defining a CRS, but yes that something I've in a corner of my mind, to allow defining custom CRS entries by PROJ strings or WKT strings, without going to the full relational structure. > E.g. to > have system proj.db and user proj.db with customizations? That's another issue. An easy solution would be to copy the system proj.db in a editable location and point PROJ_LIB to it Having both at the same time is more tricky. For example if you add custom transformations in the user proj.db between official CRS of the system proj.db, you'd have an issue with broken foreign keys, so the user proj.db shouldn't enforce foreign keys. and then PROJ could potentially create a in-memory database, that would ATTACH DATABASE the official and custom one, and for every table, create a temporary view that UNION ALL the tables of both dbs. Then that would be transparent for the rest of the code that does database queries. I might consider doing this, but this is not a top priority for now. Thanks for your valuable feedback on this ! Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ 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