[QGIS-Developer] Dealing with datum shift grids in QGIS

[Even Rouault]

> 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