Opened 16 years ago
Closed 16 years ago
#194 closed bug (fixed)
Azgcorr ENVI header issues (Support: Karl Hennermann, GB08/20)
Reported by: | benj | Owned by: | benj |
---|---|---|---|
Priority: | immediate | Milestone: | 2008 data processing completion |
Component: | az* programs | Keywords: | |
Cc: | mggr, mark1 | Other processors: |
Description
Karl reports that if he geocorrects his data using azgcorr, any ENVI header file generated (either automatically because the file size went over the HDF limit, or manually using azexhdf -Be) reports the projection as UTM zone 30. I have duplicated the problem using one of the boresight flights, will contact Bill about it.
Change History (8)
comment:1 Changed 16 years ago by benj
comment:2 Changed 16 years ago by benj
Bill has confirmed that this is an issue with Azgcorr/Azexhdf - the original functionality to provide ENVI file headers was a "quick mod" and was only written for UTM projection (it works fine for UTM) - full documentation for loading an arbitrary-parameter TM projection (like BNG) into ENVI was unavailable at the time.
comment:3 Changed 16 years ago by mggr
Bill has fixes for this problem and a work order (wo2008007) has just been produced for them to be finalised and shipped.
Projections corrected will be all UK ones, all Traverse Mercator (inc. UTM), Lambert and Polar Stereographic. Other projections will need adjusting before use.
comment:4 Changed 16 years ago by mggr
Received azgcorr.495 and azexhdf.31111 to test. Handed to Ben.
Note that Irish regions will have an issue still - Bill comments:
For now ENVI headers will reflect the settings made in the azgcorr options. I still think there are problems due to the mess of documentation that has been publised. This is particularly difficult as the OSNI has been swallowed up into a land management admin swamp! When I have resolved in my own mind what the facts are I will put the option as correct as I can and issue a replacement version. In the meantime make sure anyone doing Irish (N or S) knows there is an issue.
comment:5 Changed 16 years ago by benj
azgcorr.495 has a couple of problems, have passed back to Bill
comment:6 Changed 16 years ago by benj
(Specifically for future reference/testing, it segfaults when producing BIL files and using the new -mUTMzs option to specify a spheroid for use with UTM seems to cause an overflow or divide by zero somewhere, because the output gives a lot of NaNs, infs, zeros and suspiciously round numbers and then falls over)
comment:7 Changed 16 years ago by benj
New one received on 14/11/08, passed as fine and put on FTP site, but turns out it generates BIL headers even when it's not generating a BIL file.
comment:8 Changed 16 years ago by benj
- Resolution set to fixed
- Status changed from new to closed
Most recent versions of azgcorr and azexhdf seem to have this working. Have notified Karl, closing.
Workaround is as follows:
Karl has confirmed that this workaround works.