Closed rdkgit closed 2 months ago
rdkgit
commented
2 months ago OK, more debugging. The library is correctly reading II for the byte order. But its bombing parsing the file elsewhere. I'll debug more and update this issue. Sorry for the confusion.
rdkgit
commented
2 months ago Here is what is happening when the maxar tif file is attempted to be read. tiff exception is java.lang.IllegalArgumentException: ERROR: GeoTIFF file is corrupted, this DEM is unusable! java.lang.IllegalArgumentException: ERROR: GeoTIFF file is corrupted, this DEM is unusable!
rdkgit
commented
2 months ago Closing this issue. Its not a bug with NGA tiff library. Sorry about that.
rdkgit
commented
2 months ago Please feel free to delete this issue to save me from more embarrassment!
Please fill out as much known and relevant information as possible.
Version Information:
Expected Results:
Should be able to parse the tiff file and return.
Observed Results:
Vricon DTM GeoTiff file; when first parsing, TiffReader spits out exception
tiff exception is mil.nga.tiff.util.TiffException: Invalid byte order: UH mil.nga.tiff.util.TiffException: Invalid byte order: UH at mil.nga.tiff.TiffReader.readTiff(TiffReader.java:153) at mil.nga.tiff.TiffReader.readTiff(TiffReader.java:109) at mil.nga.tiff.TiffReader.readTiff(TiffReader.java:52) at mil.nga.tiff.TiffReader.readTiff(TiffReader.java:35)
What happened instead? Exception.
How often does this occur? Every time.
Output:
tiff exception is mil.nga.tiff.util.TiffException: Invalid byte order: UH
Whats weird is the first bytes of the .tif file are:
0x49 0x49 0x00 0x2a which seem correct for tiff. II for byte order and 0x00 0x2a for 42 for version. I don't know where 'UH' is coming from. Unfortunately, I cannot provide this tif file as its a licenseable tiff provided by MAXAR.
Test Files:
I do not have permission to provide this file. I will see if I can find a similar file that generates same error.
Additional Information:
None yet.