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?
It seems like it could be useful, though I don't have any use cases for it at the moment. It improves Orekit's flexibility so I think it would be worth including if the existing API can still be kept.