[PROJ] Make push and pop FIFO?

[Lesparre, Jochem]

Hi Thomas,

Using an axisswap between height and time is indeed one of the possible temporary solutions that I tested. However, we will introduce a time-dependent transformation as soon as the time-series of the GNSS reference station is long enough. So publishing a PROJ pipeline that uses the time for storing a height value now might be confusing for users. I have another temporary solution (applying the same geoid twice) which we could use, but I think that PROJ should have a more elegant solution for this rather common case.

Regards, Jochem


From: Thomas Knudsen <knudsen.thomas at gmail.com>
Sent: donderdag 14 december 2023 19:15
To: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
Cc: PROJ at lists.osgeo.org
Subject: Re: [PROJ] Make push and pop FIFO?

If your input data does not need time stamps, you may be able to work around this using +omit_fwd/+omit_inv selectors and a set of axisswap order=1,2,4,3 steps?

Den tors. 14. dec. 2023 kl. 14.13 skrev Lesparre, Jochem via PROJ <proj at lists.osgeo.org<mailto:proj at lists.osgeo.org>>:
Hi list members,

The PROJ operations +proj=push and +proj=pop use "last in, first out" (LIFO) to store and retrieve coordinate values in a stack. It seems that I need "first in, first out" (FIFO) or other new functionality in PROJ.

Problem
The Dutch Caribbean islands use TM-projections based on old datums. We have an exact Helmert transformation per island that transforms the horizontal coordinates to an ITRS realisation at a specific epoch. For some islands we need a geoid (EGM2008 sampled at 45” is the best we have at the moment) for the height transformation from local levelling heights to ITRS. That works fine for a forward transformation with this PROJ pipeline:

cct +proj=pipeline
+step +proj=push +v_3
+step +proj=tmerc +inv +lat_0=12.180658675 +lon_0=-68.251802281 +k_0=1 +x_0=23209.5600 +y_0=21423.9900 +ellps=intl
+step +proj=cart +ellps=intl
+step +proj=helmert +x=-366.1939 +y=-115.0688 +z=-776.7039 +rx=20.963080 +ry=16.462749 +rz=-14.276379 +s=-12.80900 +convention=coordinate_frame +exact
+step +proj=cart +inv +ellps=GRS80
+step +proj=pop +v_3
+step +proj=vgridshift +grids=egm2008_0_45.tif +inv

However, I do not get exactly the same results for the inverse transformation with -I, since I apply the geoid on the ITRS coordinates, but then the physical height is used for the Helmert transformation instead of the correct ellipsoidal height. This gives a small error in the horizontal coordinates in this case, but can easily reach more than 50 metres for other CRSs.

Solution
The most elegant solution seems to me to use FIFO for operations +proj=push and +proj=pop, so I can use this pipeline:

cct +proj=pipeline
+step +proj=push +v_3
+step +proj=tmerc +inv +lat_0=12.180658675 +lon_0=-68.251802281 +k_0=1 +x_0=23209.5600 +y_0=21423.9900 +ellps=intl
+step +proj=cart +ellps=intl
+step +proj=helmert +x=-366.1939 +y=-115.0688 +z=-776.7039 +rx=20.963080 +ry=16.462749 +rz=-14.276379 +s=-12.80900 +convention=coordinate_frame +exact
+step +proj=cart +inv +ellps=GRS80
+step +proj=push +v_3
+step +proj=pop +v_3
+step +proj=vgridshift +grids=egm2008_0_45.tif +inv
+step +proj=pop +v_3 +omit_fwd

Alternative
Another possible solution is a new PROJ operation e.g. +proj=flip to make the values of a coordinate value and the value stored in the stack switch places.

cct -I +proj=pipeline
+step +proj=push +v_3
+step +proj=utm +zone=19 +inv +ellps=intl
+step +proj=cart +ellps=intl
+step +proj=helmert +x=-366.1939 +y=-115.0688 +z=-776.7039 +rx=20.963080 +ry=16.462749 +rz=-14.276379 +s=-12.80900 +convention=coordinate_frame +exact
+step +proj=cart +inv +ellps=GRS80
+step +proj=flip +v_3
+step +proj=vgridshift +grids=egm96_15.tif +inv
+step +proj=pop +v_3 +omit_fwd

Regards, Jochem



Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].

Disclaimer:
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products and services
[https://www.kadaster.com/general-terms-and-conditions].
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj


Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].

Disclaimer:
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products and services
[https://www.kadaster.com/general-terms-and-conditions].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20231214/af8d923b/attachment-0001.htm>