Custom Query (432 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (79 - 81 of 432)

Ticket Resolution Summary Owner Reporter
#109 fixed Output of ground coordinates in azgcorr mggr mggr
Description

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.
#110 fixed Azspec processed Hawk data has spectral spikes mggr benj
Description

Azspec-processed level 1b hawk data does not appear to be correct - it contains large anomalous spikes in some bands, seemingly correlated to very low data values. Eg from Nigg Bay line 3:

Hawk spectrum from azspec-processed level 1b file over water (8px average)

Compared to Caligeo spectrum from same pixel:

Hawk spectrum from caligeo-processed level 1b file over water (8px average), same place as azspec example

Could be underflowing, but would expect a much higher value for the spikes (~65k) in this case. Might still be underflowing and then changed by maths in azspec though.

Note extended from ticket #106, but separate to Hawk noise issue

#114 fixed Az* lever arm better with offsets mggr benj
Description

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.

Note: See TracQuery for help on using queries.