Enable a couple planetary raster formats

[thareUSGS]

Loving this idea to help users by simply supporting a browser-based GDAL tool.

I support planetary formats for NASA/ESA/... within GDAL and notice there are some limits to the allowable formats in the current tool. I will say while these are bespoke formats, but I would love to have them available for read and write.

As a start, I would love to understand if (1) "ISIS3" and (2) "PDS4" could be supported?

1. For reading ISIS3 cubes (-of ISIS3), I think support would be to allow for *.cub to be added into the interface. For writing, ISIS3 cubes are usually a single self-contained image with the output extension ".cub". As a simple "raw" format it should be built with GDAL by default. There are some odd format options, but those could mostly be ignored if not somehow already parsed.

2. The Planetary Data System v4 (PDS4) format could be harder. It is a detached header (XML-based) which can point to almost any file. Think of it like a "vrt". It can point to a "raw" binary, into an ISIS3 cubes, or GeoTiff for some examples. Thus reading would need have at least two files loaded into the interface (and the actual conversion would read the *.xml file).

• Writing to PDS4 can also be tricky since it will generate two files (unless the CREATE_LABEL_ONLY=YES is used). By default, it will create a .xml and .img. There are options (-co IMAGE_FORMAT=GEOTIFF) to actually create a .xml and .tif (GeoTIFF). By default, it will try to use an available PDS4 "template" file, called pds4_template.xml. This is the minimum template which still requires template variables to be assigned to make a valid PDS4 file. But even being able to run without any special options, or template variables defined, would still benefit our community. It will get one started with a PDS4 label (which we use for data archival). Lastly, PDS4 also has a vector side (within ogr2ogr), which can be currently ignored (it is much less used).

I understand if this is outside the scope for this project. This, if so, feel free to close this issue. But even having an idea if this was feasible, would let us know if this might be a viable future tool for us to support or host ourselves. Thanks again for staging this project.

[bugra9]

Hi @thareUSGS,

I'm so glad you love the project and the idea. I have enabled the PDS driver by releasing a new version. Could you please check for any issues?

Note: @rouault resolved the compiling issue with the PDS driver. #66 https://github.com/OSGeo/gdal/blob/v3.8.4/NEWS.md

[thareUSGS]

@bugra9 Amazing - thanks for the update. Glad the original PDS4 driver issue was already addressed by Even!

Easy update:

1. The current output extension for ISIS2/3 is "lbl" can that be updated to "cub"?

Harder (I imagine could be tricky).

2. As stated above in "2", PDS4 is consists of at least 2 files. The first is the .xml label (which loads in gdal3.js). Unfortunately, the second file which the XML points at could be a .img, .raw, .fits, .tif, .tiff, .cub, .vic, *.vicar (really almost extension). The only thing the different image extensions have in common is that the internal image must be stored as a raw binary in the file (no tiles or compression). Anyway, the gdal3.js interface would need to allow two files to be added to support PDS4. This likely breaks the loop over the files one at a time (and the attempt to lock-down loading known extensions). Can you think of a trick to maybe enable supporting 2 files for PDS4?

Export to PDS4 works great (two files generated and downloadable).

I actually checked a Shapefile and that does work with many files, so maybe there is hope to read PDS4...

thanks again!