[PROJ] Vertical Transformations?

Even Rouault even.rouault at spatialys.com
Wed Feb 20 09:25:06 PST 2019


> In this case, my concern is that there is a consensus method to go
> between NGVD29 and NAVD88, that I think almost everyone would agree is
> the standard approach. 

You assume that PROJ has dedicated behaviour and knowledge for NGVD29, NADVD88 
and the "consensus method" to convert between them. The reality is that, and 
it is a feature, it has absolutely no clue about them, being (hopefully) fully 
generic and "computes" potential transformations from the information in its 
database, and the grids available.


> People who install proj but not optional
> gridfiles will silently get a much coarser approximation.
> 
> So I would like to see the transform from NGVD29/NAVD88 error out when
> the VERTCON grid file can't be opened, perhaps with some configuration
> to say that it should assume 0 instead.  I think it's better to fail
> during what I see as a misconfiguration than to fall back to a cruder
> approximation.

Note that this is complicated by the fact that there is not a single NGVD29-
>NAVD88 "optimal" transformation, but 3 since there are 3 grids, depending on 
the area of use. When using proj_create_crs_to_crs() with no specified area of 
use, there's a dynamic selection mechanism of the actual transformation, 
depending on the coordinate of the point to transform and comparing it with 
the area of use of the available transformations. So, if you are working in an 
area where all required grids are present, it is potentially fine to proceeed, 
even if in some other area a required grid would be needed.

> 
> Perhaps the evnironment variable "PROJ_NGVD29_COARSE" should be needed,
> and this hint can be returned as the error from attempting to use the
> gridfile.

That shouldn't be done like that. A more generic mechanism should be found. 
Nyall Dawson contacted me about a similar need, related to the possibility of 
tagging some GDA94->GDA2020 grid-based transformation as required, and hard 
fail if not.
We could enhance the PROJ database with a table/column to flag required 
transformation, but it is probably not trivial (area of use comes into the 
equation), and that would put the PROJ project in a position of being an 
"authority" to decide which transformation are required or not.

Even

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


More information about the PROJ mailing list