Re: [Orekit Developers] User-provided filtering of input data

[Hank Grabowski <hank@applieddefense.com>]

I'm with Evan on this.  Increasing the flexibility of the library is always good in theory but if there aren't resources to do that then I think your work around is more than reasonable.  I definitely do not want to require massive dependencies for an edge case...

On Tue, Apr 25, 2017 at 5:29 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

Hi all,

I have been asked by one of our CS engineers (Maxime Journot, who already contributed
turn-around measurements recently) about uncompressing input data.

He is working on reading Klobuchar coefficients provided as compressed .Z files. This
compression scheme is an old unix method and not directly supported by the standard
Java API. Reading .Z files could be done using Apache Commons Compress, but this
would introduce a dependency on Orekit for a small feature. As Apache Commons
components are widespread, there would be a high risk of jar hell for higher level
applications, so I am very reluctant to this.

One way to circumvent this problem is to let users fetch and uncompress the .Z
files by themselves before putting them in their orekit-data (or equivalent)
data folders.

Another way would be to let users hook their own filtering layer somewhere
in the DataProvidersManager singleton, so they could for example insert
.Z decompression themselves if their application can depend on their chosen
version of Apache Commons Compress or anything like that. This would be
in the same spirit as how .gz compression is handled (we rely on the file
name ending in ".gz" to insert the decompression), but with a user control.
It would also allow other types of filtering to be introduced (other compression
methods, deciphering, monitoring data reads...).

Does this feature seem worth introducing into Orekit?

best regards,
Luc