Support: 5/Nov/2008, Li Zhang, no code (old data)

[mggr]

Contacted by Dr Li (Lily) Zhang re: some CASI data from '97 and various issues:

• azgcorr version
• use of azgcorr parameters
• necessity of DEM with low altitude differences (20-30m, max 70m)
• ENVI + HDF loading, finding the geolocation
• Using GCPs?

Also attempting to fix remaining timing errors in the dataset Lily's using (GB97/14).

[mggr]

Ben handled all of the initial problems, but also noticed that the data had timing errors.

He attempted to acquire raw data from NEODC (on exabyte tape) but apparently the formatting is non-standard. NEODC do not have resources to deal with this at this time.

Bill showed us we could still correct the nav using aznav on a L1B file, but there were some bugs (ticket no?). These have been corrected.

[mggr]

Lily asked for a timeline on fixes - going to attempt the nav timing fixes this week and will ask NEODC for raw data in case of other problems.

[mggr]

Dataset in question is GB97/14 (1) Kenfig Burrows (c121XX1b.hdf). Lily also mentioned Whiteford Burrows.

There was also a question on ground data - we passed her the address of the PI as these data aren't collected centrally at this time (#202).

[mggr]

Retrieved boresight and lever arm offsets from NVacor HDF vector:

lev1/originals/c121011b.hdf = NVacor       [6]  0.02803095 -9.39848e-05 1.19215 1.25737 -3.07019e+00 3.93420
lev1/originals/c121021b.hdf = NVacor       [6]  0.02803095 -9.39848e-05 1.19215 1.25737 -3.07019e+00 3.93420
lev1/originals/c121031b.hdf = NVacor       [6]  0.02803095 -9.39848e-05 1.19215 1.25737 -3.07019e+00 3.93420
lev1/originals/c121041b.hdf = NVacor       [6]  0.02803095 -9.39848e-05 1.19215 1.25737 -3.07019e+00 3.93420
lev1/originals/c121051b.hdf = NVacor       [6]  0.02803095 -9.39848e-05 1.19215 1.25737 -3.07019e+00 3.93420

This is an aznav parameter of -acv 0.02803095 -0.0000939848 1.19215 1.25737 -3.07019 3.93420.

[mggr]

Note from Bill: in 1997 the, nav both position and attitude was only 1Hz and latterly 2Hz. So the "timing" will never be great''

Attempting a variety of timing tweaks on the offchance anyway, but not looking too hopeful so far.

[mggr]

Snapshot of wobbly bit on line 2, no correction attempted

[mggr]

Line 2, no correction:

[mggr]

No improvements noted on a scan of times from -4.0s to +4.0s @ 0.1s resolution, testing +/-14s @ 1s.

[mggr]

+/-14 showed no particular improvements, testing +15 -> +20 to cover any remaining parts of the navigation.

[mggr]

No improvement noted for +15-20.

Conclusion: timing is as good as it'll get for that navigation data :\ Not much chance of getting a better nav solution at this point either (Ashtech nav, no idea how to process that).

[mggr]

Emailed Lily with the conclusions and some suggestions for how to proceed if the accuracy is insufficient.

[mggr]

Lily is going to work with the positioning parameters then use GCPs. Suggested digimap might be helpful too.

Closing ticket.