[PROJ] transformations with epoch

Even Rouault even.rouault at spatialys.com
Tue Mar 24 06:55:53 PDT 2026 

Le 24/03/2026 à 14:09, Lesparre, Jochem via PROJ a écrit :
>
> Hi
>
> Unfortunately, no one reacted to this question. I would be interested 
> in an answer too, because I don’t understand the cs2cs behaviour either.
>
Not much to answer but filing tickets for detected inconsistencies and 
express the wished behavior

>  Even worse: I don’t understand how there can be a different epoch for 
> source and target CRS without specifying a velocity vector for the 
> point of interest (like 
> https://www.epncb.oma.be/_productsservices/coord_trans/) or a 
> deformation grid model.
>
PROJ general philosophy when inferring transformation pipelines is to be 
lax, and do its best, and ignore stuff that it can't make sense, unless 
instructed otherwise (also we'd probably need a flag to make it error 
out when time info not being used).

For CRS like Canadian NAD83(CSRS), doing NAD83(CSRS v7)@XXXX to 
NAD83(CSRS v7)@YYYY will definitely use their velocity model. PROJ has 
no concept of velocity vector per input point.

Even

> Jochem
>
> *From:*PROJ <proj-bounces at lists.osgeo.org> *On Behalf Of *Javier 
> Jimenez Shaw via PROJ
> *Sent:* zaterdag 14 maart 2026 23:53
> *To:* proj <PROJ at lists.osgeo.org>
> *Subject:* [PROJ] transformations with epoch
>
> Hi
>
> I have been playing with epochs today. Maybe I am understanding 
> something wrongly, but the outputs are very strange.
>
> My deductions are:
>
> - the 4th dimension (v_4) from the input is just copied into the 
> output of cs2cs. Independently of epoch flags.
>
> - if --s_epoch or --t_epoch are set, the input v_4 is ignored (but 
> still printed in the output)
>
> - if only --s_epoch or --t_epoch is set, v_4 is set before and after 
> the transformation to that value
>
> - if both are set, v_4 is set to s_epoch before transforming, and to 
> t_epoch after. So in this case t_epoch only works to tag the output 
> time,... but it is not displayed in cs2cs (it is in the C function)
>
> Is that correct? Why is t_epoch overwriting the input time/epoch? Why 
> is s_epoch setting the output time/epoch?
>
> In addition, cs2cs is apparently not printing the modified output 
> epoch. This is not what C function does.
>
> Here are some transformations using the input epoch in the coordinates 
> and the --s_epoch and --t_epoch
>
> echo 40 0 0 | ./cs2cs ITRF90 ITRF2014  -d 9
> 40.000000788 -0.000000207 0.009684166
>
> echo 40 0 0 foo bar | ./cs2cs ITRF90 ITRF2014  -d 9
> 40.000000788 -0.000000207 0.009684166 foo bar
>
> echo 40 0 0 2010 | ./cs2cs ITRF90 ITRF2014  -d 9
> 40.000000788 -0.000000207 0.009684166 2010
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9
> 40.000000087 -0.000000216 -0.028724159 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --s_epoch 2000
> 40.000000555 -0.000000210 -0.003118609 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --s_epoch 2010
> 40.000000788 -0.000000207 0.009684166 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --s_epoch 2010 
> --t_epoch 2030
> 40.000000788 -0.000000207 0.009684166 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --s_epoch 2000 
> --t_epoch 2030
> 40.000000555 -0.000000210 -0.003118609 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --t_epoch 2010
> 40.000000788 -0.000000207 0.009684166 1980
>
> echo 40 0 0 1980 | ./cs2cs ITRF90 ITRF2014  -d 9 --t_epoch 2030
> 40.000001256 -0.000000201 0.035289716 1980
>
> The pipelines for some cases are
>
> without setting --s_epoch or --t_epoch
>
> +proj=pipeline
>   +step +proj=axisswap +order=2,1
>   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
>   +step +proj=cart +ellps=GRS80
>   +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 
> +rz=-0.00026
>         +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 
> +drz=-2e-05
>         +ds=-0.00012 +t_epoch=2010 +convention=position_vector
>   +step +inv +proj=cart +ellps=GRS80
>   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
>   +step +proj=axisswap +order=2,1
>
> setting --s_epoch to 2000
>
> +proj=pipeline
>   +step +proj=set +v_4=2000
>   +step +proj=axisswap +order=2,1
>   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
>   +step +proj=cart +ellps=GRS80
>   +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 
> +rz=-0.00026
>         +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 
> +drz=-2e-05
>         +ds=-0.00012 +t_epoch=2010 +convention=position_vector
>   +step +inv +proj=cart +ellps=GRS80
>   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
>   +step +proj=axisswap +order=2,1
>   +step +proj=set +v_4=2000
>
> setting --t_epoch to 2030
>
> +proj=pipeline
>   +step +proj=set +v_4=2030
>   +step +proj=axisswap +order=2,1
>   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
>   +step +proj=cart +ellps=GRS80
>   +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 
> +rz=-0.00026
>         +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 
> +drz=-2e-05
>         +ds=-0.00012 +t_epoch=2010 +convention=position_vector
>   +step +inv +proj=cart +ellps=GRS80
>   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
>   +step +proj=axisswap +order=2,1
>   +step +proj=set +v_4=2030
>
> setting --s_epoch to 2000 and --t_epoch to 2030
>
> +proj=pipeline
>   +step +proj=set +v_4=2000
>   +step +proj=axisswap +order=2,1
>   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
>   +step +proj=cart +ellps=GRS80
>   +step +proj=helmert +x=-0.0254 +y=-0.0115 +z=0.0928 +rx=0 +ry=0 
> +rz=-0.00026
>         +s=-0.00479 +dx=-0.0001 +dy=0.0005 +dz=0.0033 +drx=0 +dry=0 
> +drz=-2e-05
>         +ds=-0.00012 +t_epoch=2010 +convention=position_vector
>   +step +inv +proj=cart +ellps=GRS80
>   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
>   +step +proj=axisswap +order=2,1
>   +step +proj=set +v_4=2030
>
> PS https://jjimenezshaw.github.io/wasm-proj/transform.html is in this 
> case probably showing better the output of the C function.
>
>
>
> 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
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260324/37c2d39b/attachment-0001.htm>

More information about the PROJ mailing list