Custom Query (419 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (148 - 150 of 419)

Ticket Resolution Summary Owner Reporter
#127 fixed IPY07/08, flight day 214ef/2007, Langjökull mggr mggr
Description

Data location: ~arsf/arsf_data/in_progress/2007/flight_data/ipy/IPY07_08-2007_214ef_Langjokull

Data arrived from ARSF via SATA disk transfer in August, with post-processed GPS arriving in December following Kidlington visit.

Scientific details: (details of IPY applications not currently available at PML)

PI: I Willis

Langjökull anglicises to Langjokull - use this for filenames just in case of problems.

Sensors:

  • ATM (delivered 23/May/2008)
  • CASI (delivered 6/May/2008)

Quicklook

CASI

ATM

#128 fixed Support: 16/Apr/2008, Jon Atherton, (no project code) mggr benj
Description

Had a request for help from a user of existing CASI data (Jon Atherton) who was not an original PI but obtained some 2005 flight data from NEODC:

Hello,

I'm a complete novice at preprocessing CASI data. I have access to the NEODC online data sets, and I would like to use CASI data from Sitia, 2005 (http://neodc.nerc.ac.uk/cgi-infrastructure/data_browser/data_browser/neodc/arsf/2005/MC04_15).
I need about 15 bands worth centred at 685 nm (band 32 to 47) from images c130021b and c130041b.

Your colleague (Gary Llewellyn) kindly provided me with the FTP for AZGCORR. I had a go with the basic line of code (provided in the tutorial) which produced a blurred image on an angle, when compared with the three bands-worth of images already processed to level 3b which are available online. Any help on correcting the blurriness would be greatly appreciated.

The only code I used was (I don't have a DEM):

 "./azcor -bl 1 -1 -p 2.0 2.5 -1 c130021b.hdf -3 c130023a.hdf"


Best wishes,

Jon Atherton

PhD student
University of Edinburgh

Replied to the query (suggested he applied a correct projection, used square pixels and tried some different bands), which seems to have solved the problem.

What if any support level should we be providing to new users of existing data? On the one hand we don't want to leave ourselves open to potentially large open-ended support requests from non-PIs, on the other it's in our interests to have ARSF data as widely available and used as possible.

#130 fixed Support: 22/Apr/2008, Ricardo Díaz-Delgado, EUFAR07/01 mggr mggr
Description

Ricardo contacted us yesterday with:

  Recently you offered your help with any general Eagle/Hawk/CASI/ATM processing issues and we would like to consult about our Eagle/Hawk data processed with azgcorr. As you maybe are aware, Doñana (SW Spain) was overflown March last year and we have been using azgcorr to produce Level 3 geocorrected data, and able to apply atmospheric corrections with the great help of Andrew Wilson from CEH. However, to manage the huge files of the geocorrected Level 3 data at full spatial and radiometric resolution is still a pain because of file size, specially in cases in which we have lots of ground-thruth positions in different flight-lines (our main EUFARNet aim and goal is to map 2 allien plant species).

   That is why we are also trying to obtain IGM files for ENVI (X and Y coordinate files that help in overlying ground-truth areas, more info at http://www.ittvis.com/services/techtip.asp?ttid=3816), and this is why we are testing
the possibility to do it with PARGE since AZGCORR has not this option (although the calculations must be embedded somewhere in the code, during the geocorrection process, as Andrew Wilson indicated). This might simplify the process of overlaying ground-truth on flight-lines before applying any geocorrection to the final product (mostly classification maps). Would it be possible to incorporate such an option on AZGCORR processing?

As this is not the only project in which we are working, and we are not experienced hyperspectral data users, it is taking us longer than we would have liked to analyse the data.

The IGM files appear to be ENVI's method for specifying per pixel coordinates. This is the same issue as #109.

Replying to Ricardo with the info we have on this, and the current tentative plan for this to be implemented pending availability of development time. Raising the importance of that issue too.

Note: See TracQuery for help on using queries.