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

Re: [Orekit Users] HEE or GSE Frames?



Hi Luc,

thanks a lot! i'll try setting up an HEE transform from ICRF and GSE from GCRF. However, as of which release is the ICRF available? IMHO it is not available before 6.0-Snapshot, and there i do have building problems due to the missing commons-math 3.2 Snapshot. Afaik you're also involved in the commons-math development… Do i have to build the current commons-math Trunk as 3.2-Snapshot to get this working?
I could also derive my transformations from the SolarSystemBarycenters Frame, but I think this is (still?) EME2000 based?

Cheers,
Simon


From: MAISONOBE Luc <luc.maisonobe@c-s.fr>
Reply-To: <orekit-users@orekit.org>
Date: Wed, 27 Mar 2013 10:26:36 +0100
To: <orekit-users@orekit.org>
Subject: Re: [Orekit Users] HEE or GSE Frames?


Dear all,

Hi Simon,


I am developing a webbased visualization tool of in-situ data gathered by
various satellites. Now fyi i am not very proficient in astronometry or
astrophysics... Nevertheless I'd like to use orekit to consolidate  
coordinates
from different coordinate systems provided by the data sources which  
use mostly
HEE (Heliocentric Earth Ecliptic) or GSE (Geocentric Solar Ecliptic)
coordinates. Now i was wondering if there already are some helper classes or
predefined transforms that could be used for transformations to ICRF or GCRF
respectively from the aforementioned coordinate systems

Unfortunately, these coordinates systems are not supported (yet) by Orekit.

The only global solar system frame we have is ICRF, located at solar  
system barycenter, and I even think it's orientation is slightly wrong  
(the famous 18 mas offset between GCRF and EME2000 striked again ...).

By the way, could someone confirm me that GCRF and ICRF should be  
aligned? If so, I'll fix our ICRF.

Implementing a new frame is mainly a matter of implementing the  
TransformProvider interface which only declares one method:  
getTransform(AbsoluteDate date) between the new frame and one existing  
frame chosen as its parent. All the rest (inserting the frame in the  
tree, providing cache and thread safety, combining transforms) is  
already done by the rest of the framework.

Considering Heliocentric Earth Ecliptic, I would select ICRF as its  
parent frame so there are no translations (both centered at solar  
system barycenter). In order to compute the rotation, we need the  
Earth motion, which is already available in Orekit using JPL  
ephemerides (see the package bodies). So the first direction , from  
solar system barycenter to Earth is easy to get in ICRF. The second  
direction (normal to the ecliptic) can be computed at each time using  
the cross product of position and velocity, but this would provide an  
instantaneaous ecliptic. I don't know if the precise definition of  
this frame use an instantaneous value or some mean value. If a mean  
value is used, then there is probably a simple model for it, perhaps  
even a fixed direction.

Considering Geocentric Solar Ecliptic, it seems to me it could be  
defined either by a similar process as HEE but starting from GCRF  
instead of ICRF (and reversing the X direction, of course), or defined  
starting from HEE and performing a translation towards Earth and a 180  
degrees rotation.

hope this helps,
Luc



help is very appreciated!

cheers,
Simon





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.