doi-usgs / ale Goto Github PK

Moving my comment from the closed PR:

The new library's name is currently set as usgsephem.

I'm sure this is intended as a preliminary name and I don't have any alternative suggestions, but,
if someone said to me "here is an ephemeris software library from the usgs" I would expect to be able to use it to look up the position of an astronomical body, given a time. To be more explicit, I would expect to be able to do something like usgsephem.getCoord('Mars', 2018-01-01:01:01:01, 'J2000') This is not how I currently understand the purpose of this software library. Are we planning to do this and provide default ephemerides to use (de430, etc) ?

This may be a bad idea

ISIS optionally allows light-time correction (adjustment for the time it takes the light to travel from the target to the detector) and more. (see abcorr under: ftp://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/cspice/spkez_c.html.) Does it make sense to support anything like this in Ale?

What should the License be for ale?

What is an appropriate number of ephemerides to have for line scanners? 5 - 10 lines between nodes? Update the base LS drivers with said number (instead of the hard coded 909 as a kwarg).

Currently: travis, coverage and docs

Numbers generated from the driver for spiceinit'd cubes are very large can creates what seems like overflow errors when running ImageToGround. I imagine a problem in the table reading code.

examples:

 'sensor_orientation': {'quaternions': [[-1.6566311061288426e+35,
    1.5014938937590877e+23,
    1.6845645495630183e+271,
    -1.1793123275974105e-66] ...

 'sensor_position': {'positions': array([[ 2.80625378e+213, -2.57356275e-206, -1.69599467e-083],
         [ 4.78956857e-187,  8.17356445e+174, -2.41488463e+254],
         [-7.12222820e+097,  3.92626094e-211,  2.23367021e-165]]),
  'velocities': array([[ 3.92381966e+261,  2.26516620e-218, -1.35303564e-225],
         [-2.22062154e+189, -6.77299474e-021,  3.20529426e+001],
         [ 4.20303359e-081, -2.55612308e+148, -1.15863475e+223]]),
  'unit': 'm'},

This issue is for discussion of the EAL Design Request For Comment document.

Any questions, comments, or proposed changes for the document should be made on this issue so that they can be discussed.

Need to be able to supply these the json blobs via the spice server online -- may need to be gzipped before being transferred if large enough file.

https://github.com/USGS-Astrogeology/ale/blob/master/ale/drivers/__init__.py#L61

This is very non-pythonic to have the library return a serialized string containing JSON. 99.9% of use cases are then going to immediately json.loads this so that further processing can occur or json.dumps it to a file. I am guessing that the latter use case is the one the linked file is seeking to accommodate, but this looks like strange behavior to a consumer (pfeffernusse in this case).

Out current setup only allows for natural cubic splines, we should add cubic hermite splines because we often have velocities which naturally lends itself towards cubic hermite splines.

Rename everything again

Adds basic files/classes/functions for the api

Do we have an example of a mission which uses these?

Stuart brought up that Naif deliberately uses binary for the accuracy. We need to test / check into whether or not we meaningfully lose precision or accuracy by using a non-binary json format.

Two options: Python C API, pybind

The serialization of the line_exposure_duration property in the base.py Driver can be np.nan. This is currently being serialized to NaN in the resulting JSON file which is invalid. This should serialize to null.

I have started a wiki page with user stories. I wonder if the best thing to do isn't to link this issue in there and work to keep these two in sync as we get new user stories submit by folks without write access to the wiki?

We are going to be called python functions from c++ and need to determine how we want to do this.

Should work with:
SPICE kernels and PDS Image file
In python

https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard

Docstrings for all python ale functions should be updated with numpy style docstrings

The focal length epsilon in the base driver fails because MRO does not have a focal_lengt_epsilon key. Since the focal length epsilon is pretty instrument specific, the solution is to push the key into the individual drivers.