[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] [Orekit Users] Fwd: IERS Message No. 353: Anticipated change to the IERS Bulletin A solution


[switching to the developers list]

"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :


--
Evan Ward
Aerospace Engineer, Naval Center for Space Technology
U.S. Naval Research Laboratory
T 202.279.4365
www.nrl.navy.mil

On Thu, 2018-03-29 at 14:12 +0200, Luc Maisonobe wrote:

Le 29/03/2018 à 13:58, Ward, Evan a écrit :


Hi Luc,

On Thu, 2018-03-29 at 09:52 +0200, Luc Maisonobe wrote:


Hi all,

Here is a message from IERS specifying that Bulletin A will
switch soon to ITRF2014.

Orekit already supports IERS 2014 and when you build an ITRF frame
using FramesFactory.getITRF(IERSConvention, flag), you basically get
the ITRF that corresponds to the EOP you load. This means that up
to now, if you used BulletinA, you got ITRF 2008 and now you will
get ITRF 2014. The conversion from ITRF 2008 to ITRF 2014 was also
available using:

HelmertTransformation.Predefined.ITRF_2014_TO_ITRF_2008.
   createTransformedITRF(itrf2008, "ITRF-2008");

If you were using EOP 14 C04 files to retrieve EOP, you were already
using an ITRF 2014.



Should we update how the ITRF frames are handled for CCSDS files?
CCSDSFrame currently assumes that FramesFactory.getITRF(...) returns
ITRF2008. As you mention it will only make a small difference. Perhaps
updating the JavaDoc would be sufficient.



You are right, I did not think about CCSDS files.
We should add a ITRF2014 entry in the CCSDSFrame enumerate and
probably go with the assumption FramesFactory will now return ITF2014
by default as more EOP files do that.

The best would be to be able to detect by ourselves what EOP we load,
but that seems difficult. If we read EOP XX C04, thats easy as the
file name includes the 08 or 14 part. For Bulletin A we could rely
on the file production date, but I'm not sure they will not at some
time reprocess the files. For Bulletin B I asked months ago if the
underlying EOP were for ITRF 08 or 14 and never received an answer
from IERS. Also IERS has a tendency to change file content without
changing the name. I therefore don't know how we can handle this
in the general case.


Sounds reasonable to default to the ITRF2014 frame.
For the high accuracy cases perhaps let the user provide the ITRF frame and specify which one it corresponds to (2008 or 2014). Something like: 

ODMParser parser;
parser.withItrf2008(itrf2008);
// or
parser.withFrame(itrf2008, CCSDSFrame.ITRF2008);


The problem I see with this solution is that it assumes the
developer of the application and the person who will manage
the data update are aware of this configuration and that it
does not crosses EOP change dates.

Do you think we could add an indicator in each EOPEntry showing
what kind of ITRF it defines (2005, 2008, 2014, ...)? This
entry would be set up by the EOPHistoryLoarder according to
their own logic. EOP XX C04 would rely on the file name,
Bulletin A and Bulletin B would rely on the file production
date which should probably be set in a configuration file rather
than hard-coded in Orekit, so users stuck with one version of
Orekit can still get the correct switch.

We could consider that FramesFactory.getITRF() is kept as is
and continue to provide an ITRF with the current EOP without
any tranform applied (let's call it raw ITRF). Users really
concerned with accuracy could ask for a specific ITRF that
would be based on a new TransformProvider. If for example they
want ITRF-2014, the new TransformProvider would keep a reference
to the raw ITRF and for each date inspect the EOPEntry used by
the raw ITRF for this date and either return the same Transform
as the raw ITRF would if the type is correct, or apply the
required HelmertTransform if it happens that for this date
the available EOPEntry is for example an ITRF-2008 entry.

This would be more transparent for users. I don't see any
backward incompatibility, it can cross changes in IERS
products as the change we experience this week, and it can
be updated when further changes arrive, even for users stuck
with one version of Orekit: they would simply have to update
the EOP loader configuration file to tell it how to flag the
EOPEntry according to date.

best regards,
Luc



Best Regards,
Evan



The difference is small, at a few millimeters level, but we are
going in the direction of very high accuracy, so we should deal
with this, even if only a few users are concerned.

best regards,
Luc




Best Regards,
Evan




In any case, this is only important if you need a very high accuracy.

best regards,
Luc

-------- Message transféré --------
Sujet : IERS Message No. 353: Anticipated change to the IERS Bulletin A

solution
Date : Wed, 28 Mar 2018 18:32:27 +0200 (CEST)
De : central_bureau@iers.org<mailto:central_bureau@iers.org> <mailto:central_bureau@iers.org> 
Pour : messages@iers.org<mailto:messages@iers.org> <mailto:messages@iers.org>

***********************************************************************
*
IERS Message No. 353                                      March 28,
2018
***********************************************************************
*


Anticipated change to the IERS Bulletin A solution


Dear IERS users,

As of Bulletin A Vol XXXI, No. 013, on 29 March, 2018, the IERS Rapid
Service/Prediction Center will transition the EOP solution to be
consistent with the 14 C04 for polar motion, UT1-UTC, and celestial
pole
offsets. This change will result in a jump of less than 0.1 mas in
polar
motion and 10 us in UT1-UTC. Small adjustments will be made to the
celestial pole offsets from approximately March 2017 to present in
order
to be more consistent with the 14 C04 solution. The only users who need

to be concerned with this change are those who need EOP accuracy to be
better than 0.1 mas (~0.3 cm at the Earth's surface, ~1.2 cm at GPS
orbit.)

A final notice of the anticipated change will be contained near the top

of the IERS Bulletin A Vol XXXI, No. 013, on 29 March 2018, where notes

to users are placed. Users are strongly encouraged to review this
message to confirm the change or to note if the change was not
implemented due to technical problems.

Kind regards,
Nick Stamatakos
IERS Rapid Service Prediction Centre:
Production director and lead project scientist


***********************************************************************
*
IERS Messages are edited and distributed by the IERS Central Bureau.
If not stated otherwise, the IERS is only the distributor of the
message
and is not responsible for its content.
To submit texts for distribution and to subscribe or unsubscribe,
please write to <central_bureau@iers.org<mailto:central_bureau@iers.org> <mailto:central_bureau@iers.org>>. 
Archives: http://www.iers.org/Messages/
***********************************************************************
*