[PROJ] Vertical CRS transformations and vertical grid shift

Even Rouault even.rouault at spatialys.com
Thu Apr 16 07:13:03 PDT 2020


Daniele,

> so sorry in advance if I ask something obvious.

There's nothing is obvious in this area :-)

> Operation No. 2:
> EPSG:9275, GHA height to EVRF2000 Austria height (1), 0.05 m, Austria
> PROJ string:
> Error when exporting to PROJ string: Unimplemented
> 
> WKT2:2019 string:
> COORDINATEOPERATION[".... long WKT here...."]
> 
> What that PROJ Error means? Will it not be able to do the transform?

Yes, you need PROJ master (future 7.1.0) for that, as the mapping for Austrian vertical 
methods to PROJ, and the transformation of original files to GeoTIFF, has been done just 
recently.

> 
> Then, I tried combining 2DCRS + VerticalCRS:
> 
> projinfo -s "EPSG:31255+5778" -t "EPSG:3035+9274"
> 
> And I get again 2 candidate operations and long PROJ and WKT Strings.
> Now, when I try cs2cs to transform a coordinate I'm getting this:
> 
> cs2cs "EPSG:31255+5778" "EPSG:3035+9274"
> 88000 273000 600
> Results into:
> *            *        inf

Yes, failure to transform due to the above issue.

With PROJ master, I now get a result, but no change in vertical value. The reason is that the 
point is outside of the grid (it is 45d52'39.123"N	16d50'57.28"E, but the minimum 
latitude of the Austrian grids is ~ 46d20'), and thus a ballpark vertical (=null) transformation 
is applied

> 
> Not really sure what it means. :-(
> If I try a different vertical CRS
> 
> cs2cs "EPSG:31255+5778" "EPSG:3035+5621"
> 88000 273000 600
> Results into:
> 2553923.81 4852657.42 600.00
> 
> So, at least the 2D coordinates get properly transformed but the elevation
> seems unchanged, therefore I'm not sure how it works.

Same as above

> *pj_open_lib(at_bev_AT_GIS_GRID.tif): call
> fopen(/opt/conda/pkgs/proj-data-1.0-1/share/proj/at_bev_AT_GIS_GRID.tif) -
> succeededpj_open_lib(GV_HoehenGrid_V1.csv): call
> fopen(/opt/conda/pkgs/proj-data-1.0-1/share/proj/GV_HoehenGrid_V1.csv) -
> succeededpj_open_lib(GV_Hoehengrid_plus_Geoid_V3.csv): call
> fopen(/opt/conda/pkgs/proj-data-1.0-1/share/proj/GV_Hoehengrid_plus_Geoid_V3
> .csv) - succeededUnrecognized vertical grid formatvgridshift: could not find
> required grid(s).Pipeline: Bad step definition: inv (failed to load datum
> shift file)*

Yes, in PROJ 7.0, there's no mapping between the .csv files referenced by PROJ master and 
the converted GeoTIFF file.

> That being said, I git cloned the PROJ repo and I have a couple of
> questions:
> - how the vertical shift get actually computed when grid shift files are
> available?
> I mean, I suppose that when finding a grid_transformation entry in the EPSG
> DB and looking for the vertical_offset_file associated to a file, it will
> somehow load that file and use it for a kind of interpolation/pixel query
> but I didn't figure out where this happens in the code (checking a bit the
> vgridshift.cpp as well as coordinateoperation.cpp).

Addition/subtraction of the grid value, using bilinear interpolation. You spotted the right 
entry points. grids.cpp as well is relevant.

> - Does it support at the same time csv / tiffs / gtx? (If so, I didn't
> manage to find where it eventually loads them)

CSV files aren't directly supported. TIFF and GTX are supported, provided that there's a 
mapping between the original name found in EPSG and a PROJ supported file:
https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_alternatives.sql

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200416/6e450f98/attachment-0001.html>


More information about the PROJ mailing list