Custom Query (432 matches)
Results (130 - 132 of 432)
| Ticket |
|---|
| #42 |
| Description |
Contacted by Chris Hecker (also previously asked about azgcorr versions in #38). Full email below, but the key points are:
Full email: Hi Mike; I started to work myself through the various manuals and LINUX version help file of azgcorr. I have some questions regarding the processing. Maybe you can help me out with this. I am sure they (i.e. the first three) are pretty straight forward for you. A) I want to use the ARSF/NERC LIDAR data that was recorded simultaneously with the hyperspectral data to improved geocorrection results. The data I want to correct are Eagle/Hawk data strips. The LIDAR data comes as point clouds in files like "Str_287.all". Can these point clouds be read directly into azgcorr (as what is referred to as an "external file") or do I need to use another software (e.g. SCOP++) to make regular gridded altitude data first? B) For the LIDAR data, I presume that I wont need any geoid - ellipsoid correction parameter, since aircraft navigation data as well as airborne LIDAR are both based on DGPS heights above WGS84 ellipsoid. Is that correct? C) I saw that there are a lot of special CASI options mentioned in the manual. Are there any for the SPECIM sensor in this version already and where would I find a list of these options? D) Now here comes the tricky one: In the help file there is the option -E which allows the preprocessing of the LIDAR data cloud to new coordinates. Since all our basemaps are in European datum 1950, I wanted to pre-process the LIDAR cloud to this datum as well. Currently the data is in the standard format (UTM zone 30, WGS84) with xcoodrinate including the UTMzone as a prefix. The output datum is again UTM zone 30 with International ellipsoid and the following datum parameters dx=-87 dy=-98 dz=-121. no rotational parameters are known to me. So I tried the following AZGcorr statement: azgcorr -ELpt f1 x -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.all Which to my knowledge should have given me a properly refernced data cloud for my UTM / ED50 system. I can see from the coordinates that are displayed during the processing that it is not going OK. The conversion of the x coordinate to the longitude value is already going wrong. I also noticed that the central meridian (in this case -0.0396 but changing with each time azgcorr is run ) doesnt make any sense. Am I doing something wrong or is this a bug? I am running azgcorr v. 4.8.3 on a 486pc-linux system. Below I copy a screendump. Thanks for the help, Chris His dump: hecker@x7:~/in$ azgcorr -ELpt f1 x -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.all ----------------------------------------------------------------------- azgcorr -- ver: 4.8.3-lin Jun 12 2007 (C) Azimuth Systems UK 1996, 2007 DEM pre processing... Initialised transform for point cloud to WGS84 geogs... Projection and datum shift details initialised.... Spheroid name: WGS84 semi-major: 6378137.00000 semi-minor: 6356752.31425 e^2: 0.006694380 1/f: 29 8.257223563 Projection name: UTM origin lat: 0.0000 long (central meridian) : -0.0396 grid coords at origin easting: 500000.00 northing: 0.00 scale factor: 0.99960000 hemisphere: north Datum shift name: none Initialised transform for point cloud WGS84 geogs to local datum and projection. .. Projection and datum shift details initialised.... Spheroid name: INTERN semi-major: 6378388.00000 semi-minor: 6356911.94613 e^2: 0.006722670 1/f: 29 7.000000000 Projection name: UTM origin lat: 0.0000 long (central meridian) : -3.0000 grid coords at origin easting: 500000.00 northing: 0.00 scale factor: 0.99960000 hemisphere: north Datum shift name: SING old spheroid name: INTERN semi-major: 6378388.00000 semi-minor: 6356911.94613 e^2: 0.006722670 1/f: 29 7.000000000 dx: -87.0000 dy: -98.0000 dz: -121.0000 metres sc: 0.000000 ppm rx: 0.0000 ry: 0.0000 rz: 0.0000 secs old x: 593792.77 y: 4095708.38 z: 131.270 lat: 37.0028547 lng: 1.0145276 new x: 857185.96 y: 4102748.87 z: -12.407 old x: 593792.77 y: 4095708.39 z: 131.310 lat: 37.0028548 lng: 1.0145276 new x: 857185.96 y: 4102748.88 z: -12.367 old x: 593792.79 y: 4095707.83 z: 131.270 lat: 37.0028497 lng: 1.0145278 new x: 857186.00 y: 4102748.32 z: -12.407 old x: 593792.79 y: 4095707.84 z: 131.290 lat: 37.0028498 lng: 1.0145278 new x: 857186.00 y: 4102748.33 z: -12.387 old x: 593792.82 y: 4095707.10 z: 131.300 lat: 37.0028432 lng: 1.0145280 new x: 857186.05 y: 4102747.59 z: -12.377 old x: 593792.82 y: 4095707.12 z: 131.340 lat: 37.0028433 lng: 1.0145280 new x: 857186.05 y: 4102747.61 z: -12.337 old x: 593792.91 y: 4095706.78 z: 131.310 lat: 37.0028403 lng: 1.0145290 new x: 857186.15 y: 4102747.27 z: -12.367 old x: 593792.90 y: 4095706.80 z: 131.370 lat: 37.0028404 lng: 1.0145289 new x: 857186.14 y: 4102747.29 z: -12.307 file: Str_287.all converted points: 3910381 End of DEM run |
| #43 |
| Description |
azgcorr's point cloud conversion function appears to have a problem with correctly detecting the UTM zone from a ULM LIDAR point cloud. Specifically, with a file like: 472077.149175 30593792.77 4095708.38 131.27 87 30593792.77 4095708.39 131.31 87
472077.149205 30593792.79 4095707.83 131.27 81 30593792.79 4095707.84 131.29 81
472077.149235 30593792.82 4095707.10 131.30 100 30593792.82 4095707.12 131.34 100
472077.150285 30593792.91 4095706.78 131.31 105 30593792.90 4095706.80 131.37 105
472077.150315 30593792.89 4095707.31 131.26 84 30593792.89 4095707.33 131.30 84
472077.150345 30593792.86 4095708.07 131.31 84 30593792.86 4095708.07 131.30 84
472077.150375 30593792.82 4095708.87 131.46 89 30593792.82 4095708.87 131.47 89
easting northing height easting northing height (last pulse)
UTM zone 30 appended to easting coords
...
and running azgcorr -ELpt f1 x -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.first1000, you get: azgcorr -- ver: 4.8.3-lin Jun 12 2007 (C) Azimuth Systems UK 1996, 2007 DEM pre processing... Initialised transform for point cloud to WGS84 geogs... Projection and datum shift details initialised.... Spheroid name: WGS84 semi-major: 6378137.00000 semi-minor: 6356752.31425 e^2: 0.006694380 1/f: 298.257223563 Projection name: UTM origin lat: 0.0000 long (central meridian) : -0.0288 grid coords at origin easting: 500000.00 northing: 0.00 scale factor: 0.99960000 hemisphere: north Datum shift name: none Initialised transform for point cloud WGS84 geogs to local datum and projection... Projection and datum shift details initialised.... Spheroid name: INTERN semi-major: 6378388.00000 semi-minor: 6356911.94613 e^2: 0.006722670 1/f: 297.000000000 Projection name: UTM origin lat: 0.0000 long (central meridian) : -3.0000 grid coords at origin easting: 500000.00 northing: 0.00 scale factor: 0.99960000 hemisphere: north Datum shift name: SING old spheroid name: INTERN semi-major: 6378388.00000 semi-minor: 6356911.94613 e^2: 0.006722670 1/f: 297.000000000 dx: -87.0000 dy: -98.0000 dz: -121.0000 metres sc: 0.000000 ppm rx: 0.0000 ry: 0.0000 rz: 0.0000 secs old x: 593792.77 y: 4095708.38 z: 131.270 lat: 37.0028547 lng: 1.0253605 new x: 858150.51 y: 4102789.67 z: -12.422 old x: 593792.77 y: 4095708.39 z: 131.310 lat: 37.0028548 lng: 1.0253605 new x: 858150.51 y: 4102789.68 z: -12.382 old x: 593792.79 y: 4095707.83 z: 131.270 lat: 37.0028497 lng: 1.0253606 The first time the central meridian appears in the output, it is -0.0288 (should be -3). On subsequent runs, this number changes at random. Specifying the meridian manually (e.g. azgcorr -ELpt f1 W003 -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.first1000-nozone) appears to work. Rather oddly, it doesn't appear to matter if the UTM zone is stripped from the coordinates or not - the output is identical. Contacting Bill to see if this is a bug or a misunderstanding on our part. |
| #45 |
| Description |
Create tickets for flight data collection or processing as appropriate (follow Procedures/NewDataArrival for processing tickets, collection ticket templates tbd). Update status pages as needed. Here's the info Gary sent me: PROJECT PI SITE STATUS GB07/07 Tim Malthus Inverclyde (spring) Data collected 102a GB04/19 Sandra Winterbottom Nigg Bay Data collected 102b GB07/05 Andrew Tyler Loch Leven (spring) Data collected 103abc GB05/02 Alejandro Souza Dee Estuary Data collected 109a GB07/05 Andrew Tyler Estwaithe W (spring) Data collected 116a GB07/05 Andrew Tyler Windemere (spring) Data collected 116a BGS07/02 Stuart Marsh Keyworth Data collected 172 GB07/07 Tim Malthus Inverclyde (early summer) Data collected 191a GB07/06 Doreen Boyd Dorchester Data collected 192a GB07/06 Doreen Boyd New Forest Data collected 192b CEH07/06 Andrew Wilson Worcestershire Data collected 192c GB07/05 Andrew Wilson Wytham Wood Data collected 73 GB05/07 Paul Bates Upper Severn Data collection current GB05/07 Paul Bates Lower Severn Data collection current GB06/07 Tim Malthus Silver Flowe (spring) Missed due to poor weather GB06/07 Tim Malthus Munsary Peatlands (spring) Missed due to poor weather GB07/05 Andrew Tyler Loch Leven (early summer) Missed due to poor weather GB07/05 Andrew Tyler Estwaithe W (early summer) Missed due to poor weather GB07/05 Andrew Tyler Windemere (early summer) Missed due to poor weather HY05/07 Julia McMorrow Longdenda Reflight pending CEH07/01 Andrew Wilson Hillesdon CEH07/02 Andrew Wilson Stanlow CEH07/03 Andrew Wilson Sailsbury Plain CEH07/04 Andrew Wilson Morehouse/Ribblehead/Hellifield GB01/12 Anthony Cooper Ripon GB01/12 Anthony Cooper Ripon GB03/01 Jim Williams Fiskerton-Barlings GB04/07 David Gilvear River Tummel GB05/03 Mat Disney Harwood Forest (1) GB05/03 Mat Disney Harwood Forest (2) GB05/07 Paul Bates Upper Thames GB05/07 Paul Bates Stour GB05/13 Peter Land Plymouth Sound GB06/02 Tom Spencer Freiston Shore GB06/05 Tim Malthus Clocaenog F GB06/05 Tim Malthus Glasfynydd F GB06/07 Tim Malthus Silver Flowe (summer) GB06/07 Tim Malthus Munsary Peatlands (summer) GB06/07 Tim Malthus Silver Flowe (autumn) GB06/07 Tim Malthus Munsary Peatlands (autumn) GB06/08 Claire Flemming Weardale GB07/03 Gemma Bell Multi-Wales 1-4 GB07/04 Peter Halkon Hayton GB07/05 Andrew Tyler Loch Leven (late summer) GB07/05 Andrew Tyler Estwaithe W (late summer) GB07/05 Andrew Tyler Windemere (late summer) GB07/05 Andrew Tyler Loch Leven (autumn) GB07/05 Andrew Tyler Estwaithe W (autumn) GB07/05 Andrew Tyler Windemere (autumn) GB07/05 Andrew Wilson Wytham Wood (1) GB07/05 Andrew Wilson Wytham Wood (2) GB07/05 Wilson Wytham Wood (3) GB07/07 Tim Malthus Inverclyde (late summer) GB07/12 Wilson Peak District HY05/02 Graham Ferrier (Flemming) East Ayrshire HY05/04 Wilson Pitsea/Thameshaven HY05/06 Mark Culter Glenogil These two will have to be better identified before they are included HY05/09 GB04/27 This job uses the AIMMS-20 atmospheric suite of instuments GB07/01 Geraint Vaughhan Caple Dewy (1) GB07/01 Geraint Vaughhan Caple Dewy (2) |
Note: See TracQuery
for help on using queries.