[PROJ] Vertical Transformations?

[Even Rouault]

> 1. Some transformations absolutely require a grid to work and should fail if
> the grid is not found.
> This behaviour is already in effect if grids are
> not prefixed by @’s in proj-strings. Determing which grids are optional can
> be difficult, but at least any grid that is used to change vertical datum
> from an ellipsoid to a local height system should fail (case in point, in
> Denmark that’s a ~40 m vertical offset)

The same could hold for the horizontal part where a missing grid might involve 
~ 100m horizontal error. The new coordinate operation "computation" module 
will return currently all potential coordinate operations, that is those using 
grids, Helmert transformation, constant offsets, etc. and also synthetic/dummy 
horizontal/vertical transformations. The sorting algorithm tries to sort first 
the more relevant ones given their accuracy and grid availability.

The concept of optional grid with @ is normally not emitted by the new 
computation module (except if you use the legacy nadgrids/geoidgrids terms by 
using a PROJ CRS string), as it considers coordinate operations using a grid 
or not as different coordinate operations

> 
> 2. For transformations with an optional grid usage, a warning should be
> issued stating
> “Grid xxx is missing, install proj-datumgrid-yyy package”.
> Grids not part of a proj-datumgrid package should be linked to if possible,
> otherwise give the user a friendly message saying that they are on their
> own.

The PROJ API has now a proj_coordoperation_is_instanciable(), 
proj_coordoperation_get_grid_used_count() and 
proj_coordoperation_get_grid_used() functions that can be used to know for a 
given coordinate operation which grids are needed and if they are currently 
available, and if not, where to download it when it is listed in the proj.db 
database as a known grid.

> 
> 3. When a transformation is performed without a grid the accuracy of the
> transformation should
> be lowered. Possibly, this is already be done (I
> can’t remember and am too lazy to check). 

Yes, coordinate operations with synthetized/dummy horizontal or vertical 
transformations will have a unknown accuracy.

e.g

$ src/projinfo -s EPSG:7406 -t EPSG:4979
Candidate operations found: 3
Note: using '--spatial-test intersects' would bring more results (64)
-------------------------------------
Operation n°1:

unknown id, NAD27 to WGS 84 (79) + Transformation from NGVD29 height (ftUS) to 
WGS 84 (approximate transformation, without ellipsoid height to vertical 
height correction), unknown accuracy, USA - CONUS including EEZ

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert 
+xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=conus +step 
+proj=unitconvert +xy_in=rad +z_in=us-ft +xy_out=deg +z_out=m +step 
+proj=axisswap +order=2,1


> I have a dream that one day we will replace the datumgrid packages with a
> download service
> where as many grids as possible can be served from. PROJ
> should have the ability to either download grids when the need arises (or
> at least make it easy for users to do so themselves). At this point it is
> just a vision and I am not particularly keen on taking on this task myself
> but I would be very happy to see this happen within the next couple of
> years. 

That would add a libcurl dependency. And/or add a callback mechanism to do the 
download on behalf of PROJ. But as mentionned above, applications built on top 
of PROJ have now what is needed to implement that.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com