Custom Query (419 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (13 - 15 of 419)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
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.

#43 wontfix Point cloud conversion in azgcorr mggr mggr
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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Note: See TracQuery for help on using queries.