[PROJ] Vertical CRS transformations and vertical grid shift

Thu Apr 16 07:57:54 PDT 2020

Hi Even,
thanks for your feedback, very appreciated.

On Thu, Apr 16, 2020 at 4:13 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>

Well, when providing that coordinate, I got them from a sample Dataset in
EPSG:31255 so they should be valid.

Weird thing:
cs2cs "EPSG:31255" "EPSG:4326"
88000 273000
>>>>
45d52'39.123"N 16d50'57.28"E 0.000 (as you said)

However:
gdaltransform -s_srs EPSG:31255 -t_srs EPSG:4326
88000 273000
>>>>
14.5025684938377 47.5898013589131 46.4711159374565

And same thing if I draw a point in QGIS: SRID=31255;POINT(88000 273000)
and I switch the map projection to 4326, that rendered point on the map has
the same coordinates reported by gdaltransform.

What do you think about it?

Regards,
Daniele

>
> >
>
> > 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
>

-- 
Regards,
Daniele Romagnoli
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200416/19ff0d6c/attachment.html>