You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: