[PROJ] Vertical CRS transformations and vertical grid shift

Daniele Romagnoli daniele.romagnoli at geo-solutions.it
Fri Apr 17 02:44:52 PDT 2020


Hi Even,
back to the topic I have an additional question. Please see below, inline.

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

I'm not sure to have fully understood how the bilinear interpolation is
being used in this process.
Could you please do an example?

Regards,
Daniele




> 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/20200417/b5a1916e/attachment.html>


More information about the PROJ mailing list