Conversation
| ``` | ||
| The GeoTIFFs can then be used as input like cubes to other applications, just remember to add the `+GTiff` to any output if that output should be formated as a GeoTIFF. | ||
|
|
||
| One can also combine supported output attributes with the `+GTiff` attribute. The `GTiff` attribute will work with all ISIS [pixel type attributes](../../concepts/isis-fundamentals/command-line-usage.md#pixel-type) and [label format attributes](../../concepts/isis-fundamentals/command-line-usage.md#label-format). [Pixel storage order](../../concepts/isis-fundamentals/command-line-usage.md#pixel-storage-order) does not work and will not perform any alterations to the byte ordering. |
There was a problem hiding this comment.
When using +GTiff in ISIS, the current defaults will automatically set a DEFLATE compression with PREDICTOR=2. This type of compression is lossless and supports all bit types. Overviews are not automatically created by ISIS, but they can be added to any TIFF using the GDAL routine gdaladdo.
Technically, a fully realized GeoTIFF is only enabled when the data is map projected. For images that are not yet map projected, the underlying TIFF format will still be used, but there will be no geospatial map projection in the ISIS or TIFF label. For more information on the Open Geospatial Consortium GeoTIFF specification please see.
There was a problem hiding this comment.
Question: When in a map projection does the ISIS metadata contain the map projection AND the GeoTIFF also have a version of the map projection too? I could see that being hard to maintain both.
There was a problem hiding this comment.
Currently, we do not write the GDAL mapping data. We likely should. I will explore adding it
| } | ||
| ``` | ||
| ### Working with GDAL Products Outside of ISIS | ||
| GDAL also provides a suite of applications that work on either GeoTIFFs or cubes. The programs that can be run on ISIS produced images can be found [here](https://gdal.org/en/stable/programs/index.html) |
There was a problem hiding this comment.
While there are plans to update the GeoTiff Driver in GDAL to support and maintain this ISIS JSON metadata, if an external application is used, the ISIS metadata within the GeoTIFF will likely not be recognized or lost during conversion. For example, during a conversion of an ISIS-created GeoTIFF using gdal_translate, the output file will not contain the JSON metadata.
There was a problem hiding this comment.
So if this is true (what I listed above), we will likely need an override to the default settings if we want to host these ISIS GeoTIFFs as COGs. I assume to create a cloud-optimized file, say a Base data DEM, using gdal_translate -of COG ..., we will want to maintain that ISIS metadata in the output COG. This could mean eventually adding a to=S3file.tif+COG as a variant in ISIS.
There was a problem hiding this comment.
Another good potential test. In theory since COGs are just tiffs under the hood, the metadata might just propagate. I can give it a test and see. I would rather not add a +COG in ISIS as we cannot directly create them
There was a problem hiding this comment.
The data is not transferred. It seems like Tiffs and COGs do not transfer all metadata domains in gdal_translate
There was a problem hiding this comment.
Until the map projection and geotransformed is saved into the output GeoTIFF, we don't need to support an additional ISIS flag to=file.tif+COG. The workaround would be to head back to a *.cub, and then use gdal_translate -of COG... to make a COG (but losing the ISIS JSON for now, until the GDAL driver is updated).
| "Data":"4cffffffd401ffffffe62effffffd3ffffffa8ffffffc11d03ffffffffffffff8525495dffffffc157fffffffb03ffffff89ffffff800c404114ffffffd1ffffffa7ffffffb6ffffffecffffffe7ffffffcaffffffbfffffffc6fffffffa48ffffffd7ffffffe1ffffffe637ffffffc0246fffffff93ffffffae39ffffffea25ffffffc074ffffffd83dfffffffa36ffffffb5ffffffb141fffffff6ffffffc264fffffff92effffffd3ffffffa8ffffffc1503cffffffb32a394a5dffffffc1fffffff5fffffff746ffffffceffffff830b4041ffffffc6066d1b4fffffffe3ffffffcaffffffbf6c4f1dffffff80ffffffe1ffffffe637ffffffc03fffffffb246ffffffde39ffffffea25ffffffc0ffffff8fffffffe85e2837ffffffb5ffffffb141" | ||
| }' | ||
| } | ||
| ``` |
There was a problem hiding this comment.
At any time, one can still use catlab to extract the label information from the ISIS-created GeoTIFF.
Is that true? Are there limitations like using editlab?
There was a problem hiding this comment.
I did my best to make sure any label reading or modifying apps worked with the new tiffs. Good things to test once we get a dev build with the changes
acpaquette
force-pushed
the
geotiff_updates
branch
from
6826567 to
7c2cf40
Compare
Kelvinrr
left a comment
Kelvinrr
left a comment
There was a problem hiding this comment.
I think this is good. Also reviewed DOI-USGS/ISIS3#5737 (review)
* Added initial Gdal GeoTIFF processing docs * Added sections on ISIS specific data and working with gdal applications * Added section on overview uses * Addressed PR feedback * Fixed spelling * Fix gdal_support link in command-line-usage * Corrected file name for mkdocs
3 participants
Licensing
This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words: