PROJ
PROJ copied to clipboard
OSGeo
grid_alternatives and deformation_model
Currently we have no entry in grid_alternatives table for the nz_linz_nzgd2000-20180701.json deformation model used for PROJ:NZGD2000-20180701 . It would be easy to add one, but the .json file itself depends on several .tif files . We have no mechanism to express such dependencies and inform downstream users of those additional files to download (for those not using PROJ-data). Something to consider perhaps
As I recall at one point we discussed bundling everything up in a zip-file that would be unpacked by PROJ on the fly. That would have been useful here I guess.
The additional files can be discovered from the JSON file. Would it be too expensive to look that up when a JSON file is encountered in the grid_alternatives table? If the file is available on disk it should be a problem but what about fetching it from the CDN? A sensible fallback message like "additional resources may be needed" should be provided when a JSON file is neither available locally or from the internet (builds without curl).
As yet this is not in EPSG but when it is added I was thinking that the transformation method would have two parameters, say json_master_file and grid_files. The grid files parameter would be a text delimited list of the grid files required for the version of the deformation model. Would that help in this case. Obviously it would require some processing to manage. And it would only be useful if definition was coming from EPSG rather than a user entering a json file name as a parameter.
(It is not entered into EPSG yet because it would require multiple NZGD2000 definitions and multiple coordinate systems and projections associated with each and there is a concern that could be confusing for users. However the most recent definition could go in there without creating an issue)
ay json_master_file and grid_files. The grid files parameter would be a text delimited list of the grid files required for the version of the deformation model. Would that help in this case
Yes, I guess we could certainly make sense of that so that the proj_coordoperation_get_grid_used_count() / proj_coordoperation_get_grid_used() functions list the JSON and TIFF files needed by an operation (the naming 'grid' should then be understood as 'resources')