[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