It would be useful if azgcorr could output some extra information on the mapping of points.

Peter Land was interested in level 1 ground coordinates per pixel.

Chris Hecker (#108) has requested per-pixel geocoordinates or per pixel view vector info for feeding into ATCOR, also presumably at level 1. He said ATCOR needed, as an input parameters for the atmospheric correction model, the viewing geometry and distance between plane and each pixel. This can be supplied either as:

• a geo lookup table (GLT) that defines a map coordinate of each pixel while still in image coordinates
• a scan angle file with the viewing vector for each pixel (azimuth angle, zenith, angle, height of plane).

Peter contacted Bill about it, who replied (1/May/2007) with:

The option to 3D output pixel coordinates, solar and sensor view
vector details and time are on the cards for Andrew's group to use
with Modtran, so in the not too distant future will be available.

The use of -l in azspec produces a blank image if anything than a start line of 0 is used. The end line number does seem to produce the correct effect however.

Same problem also occurs in azatm (causes errors saying "scan jump from: 0 to 191119 scan : 191119 rejected"). Same option in azcas2 seems to work correctly.

NEODC has some old ATM data from Andrew Wilson's archive and would like to process it to the modern HDF standard. This data does not include navigation, so the requirements are just creation of the HDF structure (azsite) and conversion/calibration of the data (old utilities).

Bill's comments:

I have now had a chance to look at the original ATM post processing.
This consists of two programs:

atmcct0 that read the file of a cct tape and creates a level-0 HDF
file and atm_1 that radiometrically corrected the level-0 file and
output a second level-1 HDF file

The programs were started late 1994 and the last updates were on the
20/07/1998. I cannot now remember why I did it as two programs as it
would be relatively easy to join them together.

I have copied the last source to a linux dev dir, updated library
paths, corrected 2 items to comply with the latest C and libc and
recompiled/linked;  program runs OK to give usage.

So to provide a working version as it was in 1994, I will need some
test data from the ATM for the period 1994 to 1998; this has to be
files from the original 9 track tapes.

The work needed for a version to create latest metadata HDF1a files
is:

1. change byte swap option (original program was for a sun)
2. check edit/insert missing metadata items
3. check compatibility with latest azsite
3. test with 1994-1996 data
4. test with pre 1994 data

This will take up to 4 days depending if there are any problems with
pre 1994 data as I do not recall if Andrew ever used the program on
early data as we had no navigation. It may be possible to merge the
two programs in the same time, I would have to see when I get started'
this would then avoid 2 HDF files.

This new versions [ azatmcct0.200 and azatmcct1.200 ]  will then run,
on linux, in a standard processing sequence, but of course it only
needs  azsite as there is no navigation.

This version of the program does not read cct tapes directly so if any
tapes needing processing they must be first copied to a file using dd
[raw binary with no translation etc].

Bill later revised his estimate to 5 days in light of potential issues while testing.

NEODC will provide test files. They believe they have calibration files too.

Deliverable from Bill will be tested and working copies of the relevant programs.

NEODC will then do the processing and communicate with Bill on any problems, keeping PML in the loop.

PML will offer advice on processing as required.

As title - if aznav processes a line that starts or ends on a grid reference where one component starts with 0 (eg NZ 0429 9739 - Harwood line 6 end), on display it omits the initial zero and displays a three-digit number instead of a four-digit number (eg NZ 429 9739). This can be confusing, though it appears to process correctly.

Peter Land suggested altering azgcorr to allow L1 files to be opened read-only. Currently they are opened read-write, which causes problems if they are on / were copied from read-only media.

Current TIFF formats are limited to 2GB, which is an issue with the Eagle & Hawk - large numbers of bands can easily exceed this limit.

Bill says that ERDAS 9.2 supports BigTIFF (and perhaps big geotiffs as a result?). It'd be good to find out the extent of the support and perhaps implement BigTIFF support in azexhdf.

This ticket is to track the issue for now. At some point we may want to take action on it.

The az* lever arm format is currently gam/del/dst (two angles and a distance) for legacy reasons. These reasons are now irrelevant, so for clarity and ease of calculation it would be better if az* used x/y/z offsets (three distances) instead.

Incorporate EGM96 geoid code into azgcorr, eliminating the need for geoid-spheroid separation files (Bill estimates ~3 days effort)