Output of ground coordinates in azgcorr

[mggr]

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.

[mggr]

This is something we should consider asking Bill to look at as an enhancement.

[mggr]

Apparently Matt Disney has built some tools to do this for CASI. Chris Hecker is going to look at them to see how much adaptation they need for Eagle.

[mggr]

Ricardo Diaz-Delgado has also requested this (#130). Raising importance - this should probably be one of the first features we ask Bill to implement as soon as time is available.

[mggr]

Some notes from Bill on the implementation (with reference to atmospheric correction #200):

...the items that are easy to do are:
pixel position:  either geocentric xyz, geodetic lat,long, spheroid height, or grid east/north/hgt;  I suspect the first items are most use
pixel time:  this would be the UTC time of viewing the pixel
pixel view vector:  the azimuth and zenith of the view either from the pixel to the sensor or the reverse

it would also be feasible to provide the pixel tilt if that is any use.

Pixel coords would be on the DEM surface; so they may need to be transformed to WGS84 if the DEM is local.

These would be the level-1 input pixel postions.

Also for UK data there is the issue about ETR89 to WGS84.....

 I remember talking to Dale about this, and his view was that although Modtran takes a lot of atmo physics into account the needed pixel accuracy was low!

[snip]

Because of the volume of data, it would be a separate binary file with a header and all items per pixel together, identified by level-1 1 row and pixel and be implemented as a separate output option to azgcorr, because that is where all this calc is done. 

[mggr]

Also needed by Hassan Khavarian Nehazk (name order possibly wrong though first name is correct :/).

[mggr]

Detail on output:

As I have mentioned a few times I have been specing out this update to avoid missing anything and can now give a definitive say on what is available as items for atmospheric correction parameters from azgcorr.

It would be a good idea to circulate this and get comments.

Available items
---------------

1. per scan/data frame:  time (year, day of year, UTC seconds of day), sensor (lat, long, spheroid height),
2. per pixel: time (UTC), lat, long, spheroid height on DEM, azimuth to sensor, zenith to sensor, distance to sensor;
pixel (dem surface) slope and slope azimuth
3. per pixel solar items: solar time ( correct julian day - units: decimal days), solar azimuth, solar zenith

Units: distances/heights: metres; angles: decimal degrees; time: decimal seconds of day

Use of the solar algorithm
--------------------------

The alg. I have found is complete, ie no solar ephemeris are required as mentioned below, but needs some paras beyond those available in arsf processing HDF-1.

These are:  delta_t, average pressure (millibars), av. temperature, atmospheric refraction at sunset/sunrise

I have not investigated how these effect the results, but I suspect for atmos_corr use could be defaulted to 1000, 15 and 0.5667.
Delta_t  is to convert between earth rotation time and terrestrial time and is published by a US site on a regular basis bot as exact after the event values or predicted ones. This has to be supplied as it is a key part of the calculation and is best supplied by processing group...

Options
-------

1. Output can be either binary or ascii; the later is useful for testing and usable for small data sets.
2. it would be possible to give grid coordinates as well as or instead of lat/longs

Limitations
-----------

As you know there is a percentage of flight lines that have turns or other large aircraft attitude events. This causes the pixel view vectors to disappear to the horizon. In georef use this doesn't matter because thes epixels are just ignored if they fall outside the image area. In the atco file I will just have to check for thes and put in some "no data" flag.

Running azgcorr to get the atco items
-------------------------------------

Any georef run can be re-run to output an atco file by just adding the parameters:

-pv filepath    to provide a atco output file
-pvi  to supply the solar algorithm values     .... apart from delta-t this may become optional

no other changes are required to thr run, although any subsequent use of azexhdf will not be needed


Check list
----------

The following need to be looked into by whoever is going to use this outoput and/or do the interface programs to the various possible atco programs.

1. Any other item needed or versions of the above ones.
2. These available items are from LEVEL-1 image navigation NOT geo corrected. So for programs that try to atco level-3 images they will not be suitable; so these programs need to be looked into - eg. ATCOR4

-------------------------------

I am happy that the update to output the available items above can be done in my original estimate of 5 wd; anything further will need more time.


Please let me have any comments that turn up and tell me if and when you want this available.

[mggr]

actual output info from Bill's test run:

view vector file item details:
  secs     : UTC seconds of day
  acx, acy : sensor position in WGS84 TM grid coordinates, Units: m
  acla, acln : sensor position lat/long on WGS84 spheroid, Units: dec degs
  ach      : sensor height above WGS84 spheroid, Units: m
  px, py   : pixel position in WGS84 TM grid coordinates, Units: m
  pla, pln : pixel position lat/long on WGS84 spheroid, Units: dec degs
  ph       : pixel height above WGS84 spheroid, Units: m
  va, vz   : view vector azimuth and zenith pixel to sensor, Units: dec degs
  di       : distance pixel to sensor, Units: m
  sa, sz   : solar illumination vector azimuth and zenith, Units: dec degs

  azimuths are clockwise 0-360 from true north
  zeniths are 0-90 from the horizontal

[mggr]

Remaining points (as of 13/Feb, may be done now)

1. pixel slope and aspect from the DEM - I have adopted to provide 3 optional standard methods: Zevenbergen and Thorne's, Horn's and ERDAS; apart from implementation, they also need testing. (see: doc from Macaulay Institute for details).

2. after talking to Peter, I need to allow for no DEM use, ie for marine; but still to allow for geoid - spheroid correction

3. talking to Andrew, it appears that solar incidence on the illuminated pixel is required

4. I need to allow for view vectors that cannot be calculated either for aircraft attitude or missing DEM nodes.

5. It may be of value to allow for user's to select what items they require on the output file

6. There are still some loose ends to do with providing (or not) for the special CASI modes?


I need to have the time to do and adequately test all this, so the time needs to be put up to 8 working days on the work order. 

[mggr]

Work order wo2009001 sent to Bill.

[mggr]

Version in testing at present.

When we have a working version, please also notify:

• Javier Bustamante
• Khavarian Nehzak H. (Hassan)

[peland]

Just took a look at Oxford Parks flightline 1. The L3 has pixel [0,0] at the bottom left, map pixel [35,369], while pixel [952,0] is at the top left, map pixel [7,45]. That puts the scan direction at atan(-28/324)=-5deg. This is confirmed by the aircraft heading=86deg. The aircraft is normally 'nose up' and this is confirmed by pitch=2deg. That will decrease azimuth at [0,*], make it about 265 at [512,*] and increase it at [952,*]. Roll is negligible.
Eagle parameters from the HDF: CAoaxis=512, CAfov=35, CAfovport=16 (hence fovstarboard=19).
At [0,*] we expect view zenith=fovstarboard=19, azimuth -5=355-.
At [512,*] we expect zenith 2, azimuth 265.
At [952,*] we expect zenith=fovport=16, azimuth=180-5=175+.

The aircraft is normally 'nose up' and this is confirmed by pitch=2deg. That will decrease azimuth at [0,*], make it about 265 at [512,*] and increase it at [952,*]. Roll is negligible.

At x[0,*] we get zenith=73=90-17, azimuth=350.
At [512,*] we get zenith=87=90-3, azimuth=220.
At [952,*] we get zenith=72=90-18, azimuth=182.

Flightline 2 is perpendicular, hence an ideal complement to line 1. Ignoring the dodgy bit at the beginning, we have fairly even flight for the rest of the image. [0,x] is at the bottom right of the even section, map pixel [552,1127], while [952,x] is at the bottom left, [217,1143].
This gives a scan direction of atan(-335,-16)=267deg, consistent with heading=356. Pitch is 1, roll is negligible.

At [0,*] we expect zenith=19, azimuth=267-.
At [512,*] we expect zenith=1, azimuth=177.
At [952,*] we expect zenith=16, azimuth=87+.

At [0,*] we get zenith=73=90-17, azimuth=89.
At [512,*] we get zenith=88=90-2, azimuth=150 to 230.
At [952,*] we get zenith=73=90-17, azimuth=265.

The obvious discrepancies are zenith->90-zenith and E-W azimuths appear to be transposed. The azimuth discrepancy could just be semantics - Bill describes it as 'pixel to sensor', but is that the 'from' azimuth (like winds) or as I've assumed, the 'to' azimuth (like vectors)? Apart from that it seems to be working fine. When we have decent Esthwaite data I'll try that too.

[peland]

One other thing - there's one less line in the vecfile than in the original image. Noting that sample numbers start from 0 but line/frame numbers start from 1, it's not hard to guess what's happened.

[mggr]

Could be a missing frame - just checking with Bill on that for another purpose.

[mggr]

Bill confirmed there was a missing frame issue, dependent on the direction of flight, and is fixing that. New version due soon.

[mggr]

All working fine :)