[PROJ] Dealing with epoch and transformations

[Lesparre, Jochem]

Besides command line PROJ, I don't think there is much software that supports time-dependent transformations. Or does ArcGIS support this now? I heard they were working on it. It will probably take a long time and a lot of effort to raise awareness before time-dependent transformations become common practice in geo-information. So, we need a default epoch for such transformations.

The most practical default epoch would be in the middle of the expected lifetime of a realisation (for ITRF2014 this would be between the publication date of ITRF2014 and the publication date of ITRF2020). However, the publications of ITRS and WGS 84 realisations do not have a regular interval. So, there is no real way to predict the lifespan of a realisation. Ideally, IAG would choose a suitable default epoch by publishing ITRS realisations with a reference epoch in the future instead of in the past. Such extrapolation might feel a bit unscientific for IAG, so maybe some other organisation will have to come up with recommendations for more practical default epochs. I do not think PROJ should make this decision. So, I agree with you that using the reference epoch, like PROJ does, is the most reasonable thing to do for the moment.

I hope to discuss the need for a joint European strategy for dealing with the time-dependent ETRS89-ITRS transformation for geo-information at the upcoming EUREF-EuroSDR workshop in Tromsø, Norway. Is anyone else from this mailing list going there? Registration is still open...
https://www.eurosdr.net/workshops/joint-euref-and-eurosdr-workshop-how-increase-use-spatial-data-sharing-data-across-borders

Jochem


-----Original Message-----
From: Greg Troxel <gdt at lexort.com>
Sent: dinsdag 17 september 2024 23:50
To: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
Cc: PROJ at lists.osgeo.org
Subject: Re: [PROJ] Dealing with epoch and transformations

"Lesparre, Jochem" <Jochem.Lesparre at kadaster.nl> writes:

>> My somewhat hazy understanding is that ITRF2020 without a specified
>> epoch means 2015.0.
>
> I would say ITRF2020 without a specified epoch is undefined, but the
> reference epoch 2015.00 is sometimes also used as default epoch in
> software. Which is a poor choice for data that is current epoch,
> because ITRF2020 wasn't even published in 2015. So, a default epoch
> like 2025.00 would give more accurate results.

Is there any real support for picking some year not the reference epoch?
I can see treating ITRF2020 data without an epoch as either

  of the reference epoch, or

  an error, meaning an expecption is thrown and no results returned

This would be for to ITRF2020 or from.

And, if we pick the second option, we should do the same for each WGS84 realization (except maybe TRANSIT on the NA plate), and further reject data in the ensemble.

I therefore think the only reasonable plan is to treat it as being of the reference epoch, which is what I think proj is doing now.

I think it would take a very strong argument to pick a different default epoch.


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