search

DOI-USGS / ale

Abstraction Layer for Ephemerides (ALE)
Other
13 stars 32 forks source link

Check if the input is as expected #451

Open oleg-alexandrov opened 2 years ago

oleg-alexandrov commented 2 years ago

For some sensors ALE expects a .cub file on input, such as for LRO NAC, and sometimes an IMG file is needed, such as for Dawn. When the wrong file type is provided the software goes through the motions, and after trying all drivers just fails. I spent some hours today debugging a good chunk of the ALE codebase before figuring out that this is where the issue with my data was.

There should be some logic on input, which, after figuring out the sensor based on what the .IMG or .cub file has in the metadata, errors out if the wrong file type is provided.

Also, after this check the correct driver should be called rather than just trying all of them by brute force.

acpaquette commented 1 year ago

@oleg-alexandrov I think as the number of drivers grows this could be useful but right now the brute force check all drivers works. In this particular case Dawn needs an IMG file because the only driver available for Dawn is the Pds3LabelNaifSpice driver. This driver needs Pds3 input (img/lbl file) to work given keywords and other things in the label.

I think there are ways to make this cleaner/more transparent to the user, potentially displaying drivers that are available to users and what files they work with.

oleg-alexandrov commented 1 year ago

OK, so no unified approach is possible either at the user level (sometimes need .cub, sometimes need .lbl/.img), nor internally. So, will have to live with it.

The MSL driver also needs .lbl, in addition to Dawn, btw.

Anyhow, in ASP I have all these modalities documented, in https://stereopipeline.readthedocs.io/en/latest/examples/csm.html.

Maybe at some point this can be rectified (by ensuring the .cub file has all the data one needs so need not go to .lbl), but that will likely not happen soon.