OSGeo
Transforming coordinates between two different epochs in the same reference frame (ex: [email protected] to ex: [email protected])
Hello,
I am a bit new to proj, And i have been currently struggling to find for multiple days to find how and if it is possible to do some things, so this ticket may also be a hint to ask for clearer documentation.
I am trying to perform a transformation from the same CRS in different epochs, such as from ITRF2014 @ 2000.0 to ITRF2014 @ 2020.0
As an example I can take a station from https://itrf.ign.fr/en/homepage in France that have around 1cm / year of motion in X,Y and Z coordinates
Looking at the documentation, the only option I found was to manually look for the nearest station to my coordinates, get their velocity and use an helmert transformation with only the velocity and epoch.
echo X Y Z 2000 | cct +proj=helmert +dx=-0.01 +dy=-0.2 +dz=-0.03 +t_epoch=2020 +convention=position_vector
So is this currently implemented in proj and if its the case, how can I perform the same operation without the hassle of looking for the velocity of each neighboring station by myself ?
Thanks
@Lakshitalearning I strongly suspect your above message has been generated with the use of AI/LLM, hasn't it ? In any case the examples you give don't work...
Please refrain from using AI/LLM at all especially when you want "accuracy"! That's tricky topics. They don't "understand" anything. That's a collective loss of time. I'm deleting your comments to avoid that further AI is trained on wrong answers. Sigh.
I'm not aware what the deleted comments were, but I think it is a valid question.
I can't seem to find clear answer whether proj is able to transform between epochs for the same dynamic coordinate system. The following doesn't seem to work on proj 9.6.2.
echo 40 -70 10 | cs2cs EPSG:7912 --s_epoch 2015 EPSG:7912 --t_epoch 2020 -f "%.10f"
40.0000000000 -70.0000000000 10.0000000000
While it does seem possible to transform from a dynamic (with epoch) to a static system. I don't understand why it wouldn't be possible to do the transformation within the same dynamic system. A silly workaround seems to be to transform to a static system and then back to the original dynamic system but with a different epoch.
I see that this ticket has been labeled 'feature request'. Can you explain what the current state is and what future plans there are regarding transformations between epochs within the same dynamic system?
I'm not aware what the deleted comments were, but I think it is a valid question.
The topic is definitely legit. I just removed some LLM-based "answers" full of AI hallucination, from someone else than the OP, that weren't helpful at all...
Can you explain what the current state is and what future plans there are regarding transformations between epochs within the same dynamic system?
I believe the only CRS where this works automatically currently is with the Candian NAD83(CSRS)v6 and v7 where there is a published velocity grid that got integrated in PROJ.
Currently for ITRF2014, you need to manually do something like "cct +init=ITRF2014:EURA" for Europe based coordinates with geocentric coordinates using the ITRF2014 plate motion model. See https://github.com/OSGeo/PROJ/blob/master/data/ITRF2014#L32 and below
We could possibly automate finding the appropriate transformations from that list. That would require adding somehow the geometry of the plate boundaries in PROJ db to test in which plate a point is located. That would need someone doing that actual implementation work or providing funding for it.
We could possibly automate finding the appropriate transformations from that list. That would require adding somehow the geometry of the plate boundaries in PROJ db to test in which plate a point is located. That would need someone doing that actual implementation work or providing funding for it.
Even if someone wanted to fund that I dont think that's the right way to go. I would rather prefer if a point motion operation for each tectonic plate in the plate motion model was added to the EPSG register. That way it could simply be referred to by its EPSG-code and we could treat it (mostly) like any other operation.
That way it could simply be referred to by its EPSG-code and we could treat it (mostly) like any other operation.
sure, that would definitely make things easier. We'd still have to improve the way we select transformations since our current bounding box based approach wouldn't work well for areas as big as tectonic plates
We'd still have to improve the way we select transformations since our current bounding box based approach wouldn't work well for areas as big as tectonic plates
Would be a nice addition but not a must as I see it. If your are concerned about point motion operations you probably aren't relying on cs2cs picking up the correct operation on your behalf. Well, probably some people would do just that but if you care about that sort of accuracy you should be more explicit.