Point cloud conversion in azgcorr

[mggr]

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.

[mggr]

Sent email to Bill in Iceland/Greenland.

[mggr]

Bill confirmed that this is a feature. Currently the UTM zone is stripped from the point data but isn't used - you still have specify the meridian manually. Suggested initialising the value to zero, kicking out an error or using the zone number.

Closing this ticket as wontfix for now, though hopefully it'll be fixed later.

[mggr]

In a new azgcorr release (4.8.4) Bill removed the -f x option, forcing one to specify a meridian. This makes explicit what was originally unclear. The reason the UTM zones in the LIDAR data aren't used is that we don't know what happens when a zone boundary is crossed - Bill needs to ask ULM.