id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,processors 42,"Support: 20/July/2007, Chris Hecker, WM2006/06",mggr,mggr,"Contacted by Chris Hecker (also previously asked about azgcorr versions in #38). Full email below, but the key points are: 1. 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? 1. 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? 1. 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? 1. 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. }}} 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 }}}",support,closed,alpha 4 high,,Support,fixed,,sbg,