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

RE: [Orekit Developers] [Orekit Users] design of the DataProviders

Hello Evan,


I find it a bit counter-intuitive to cache data inside the factories. I would find it more logical to cache the data in the providers instead. This allows to clearly separate the data loading from the data use.

I guess that the data is cached in the factories because some factories transform the data before caching it ? If the transformation is computation-intensive, then the current design makes good sense.


My ideas are too messy to be written down right now. I am toying with the idea of Java Services, as described here :


I believe I have found something that would work for me, but I am still trying to make sure it could accommodate the other use cases. I think this is the kind of topic where a live brainstorming session, in person, would be much more efficient than mail. Which is one of the many reasons why I am looking forward to Orekit Day !



Kind regards




From: orekit-users-request@orekit.org [mailto:orekit-users-request@orekit.org] On Behalf Of Ward, Evan
Sent: Monday, November 13, 2017 3:30 PM
To: orekit-users@orekit.org
Cc: orekit-developers@orekit.org
Subject: Re: [Orekit Users] design of the DataProviders


Hi Yannick, Luc,


On Mon, 2017-11-13 at 12:16 +0100, MAISONOBE Luc wrote:

"JEANDROZ, Yannick [FR]" <yannick.jeandroz@airbus.com> a écrit :
I have started thinking about possible refactorings of the model data
management. I have a somewhat similar behaviour somewhere else in my  
and I have used a dependency inversion based on Java services to solve it. So
far, it seems to work quite well (but my software is not that big yet, so it
might be a bit early to tell). Maybe something like this could be implemented
for orekit data management ? I would gladly share a very basic draft  
of my ideas
if it can be of any help.
Sure! We can speak about this on the developers list (and also during
the Orekit day at the end of the month!).


Yannick, I'm interested in hearing your ideas. I've run in to the same issue when trying to use different EOP data sets within the same Orekit application. My thought is to:


1. Make the DataProviderManager (DPM) instaniable.

2. Make all the static factories (TimeScaleFactory, FramesFactory, etc.) instantiable and take a DPM in the constructor.

3. Ensure that for every contructor/method in Orekit that uses one of the static factories there is an equivalent method that receives the factory or the factory-created object as a parameter instead.


The existing static factory methods could be retained to make it easier for new users or simple applications.


Loaded data would still be cached in each of the factories, but the user application would now have more control over where the data is used. For example, application could use one TimeScaleFactory for the entire application to match the current behavior, or one TimeScaleFactory per thread to match Yannik's use case, or something more complex that makes sense for the specific application.


Here is an example of what the code would look like:


DataProviderManager dataSet1 = new DataProviderManager();
dataSet1.addProvider(new DirectoryCrawler("C:/dataset1"));
DataProviderManager dataSet2 = new DataProviderManager();
dataSet2.addProvider(new DirectoryCrawler("C:/dataset2"));
TimeScaleFactory tsf1 = new TimeScaleFactory(dataSet1);
TimeScaleFactory tsf2 = new TimeScaleFactory(dataSet2);
TimeScale utc = tsf1.getUTC();         // using original data set
TimeScale utcPlusHalf = tsf2.getUTC(); // using modified data set
Comments and criticisms welcome.
I agree with Luc that this would be a good topic to discuss at the Orekit Day.
Best Regards,
best regards,
Thank you for your time.
Yannick Jeandroz
Yannick Jeandroz
TESOA2 - Flight Dynamics
T    +33 (0)5 62 19 51 71
E    yannick.jeandroz@airbus.com
Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Airbus Defence and Space et les sociétés Airbus Group declinent toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space and Airbus Group companies disclaim any and all liability if this email transmission was virus corrupted, altered or falsified. 
Airbus Defence and Space SAS (393 341 516 RCS Toulouse) - Capital: 29.821.072 EUR - Siege social: 31 rue des Cosmonautes, ZI du Palays, 31402 Toulouse cedex 4, France