Custom Query (432 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 432)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#40 wontfix IPY2007/01 gaew mggr
Description

Part of IPY (International Polar Year) campaign. Gary to fill in later.

#41 wontfix IPY2007/04 part A gaew mggr
Description

This is part of the IPY campaign (multi-part project).

Flight is north of Skutulsforour, Iceland.

#42 fixed Support: 20/July/2007, Chris Hecker, WM2006/06 mggr mggr
Description

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?
  2. 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?
  3. 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?
  4. 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.