[PulseWaves] Issues with Optech GEMINI's LAS 1.3 FWF output
24 views
Skip to first unread message
Martin Isenburg
Jan 20, 2014, 9:35:44 PM1/20/14
to The LAS room - a friendly place to discuss specifications of the LAS format
Hello,
since this is a LAS 1.3/1.4 specification issue some of you may be
interested in this (read in reverse).
Martin
---------- Forwarded message ----------
From: Martin Isenburg <martin....@gmail.com>
Date: Tue, Jan 21, 2014 at 3:31 AM
Subject: Re: [PulseWaves] Issues with Optech GEMINI's LAS 1.3 FWF output
To: PulseWaves - no pulse left behind <pulse...@googlegroups.com>
Hello,
seems the issue is resolved. I received an off-line message explaining
the scaling of these direction vectors to me. Seems the LAS
specification is really vague on how to properly define these. In late
2011 I noticed that in RIEGL exports of LAS 1.3 FWF with RiPRECISION
vectors had inverted signs (when compared to Leica output) and now
Optech's LMS has both inverted signs and the wrong scaling. With the
software engineers of two leading hardware manufacturers both
miss-understanding this part of the LAS 1.3 specification - and
believe me these are smart folks (-: - I will suggest to the LAS
committee that we clarify the language of the spec.
Apparently in LMS the vector that gets stores in the wavepacket fields
X(t), Y(t), Z(t) corresponds to the difference between the coordinates
of the return and the coordinates of virtual point behind the scanning
mirror that can be thought of as the "optical origin". Hence, the
length of this vector equals to the range and LMS doesn’t normalize
it.
Simply dividing this vector of the wavepacket fields X(t), Y(t), Z(t)
by the negative wavepacket field "location" illustrates nicely that
the directions and distances seem to be all correct (see first pic) as
all beams converge on the optical origin. This code below changes the
current Optech vectors and the visuals are correct then (see second
pic).
// roundtrip distance in meters that the laser travels
// is one *picosecond* computed by the distance the
// laser travels in one nanoseconds divided by two
// and divided by 1000. used the speed of light, may
// need to be calibrated with system parameters
F64 round_trip_distance = 0.299792458 / 2 / 1000;
F64 x = -point.wavepacket.getXt();
F64 y = -point.wavepacket.getYt();
F64 z = -point.wavepacket.getZt();
F64 len = sqrt(x*x+y*y+z*z);
x = x / len * round_trip_distance ;
y = y / len * round_trip_distance ;
z = z / len * round_trip_distance ;
point.wavepacket.setXt((F32)x);
point.wavepacket.setYt((F32)y);
point.wavepacket.setZt((F32)z);
It also seems to make them more or less identical to Leica's in terms
of scale and direction as you can see below.
D:\lastools\bin>las2txt -i optech.las -parse W -stdout | more
WARNING: number of samples for wave packet descr 1 is with 479456700
unusually large
1 60 120 30013 6.21887e-005 -1.49608e-006 0.000136379
1 180 128 29979 6.28045e-005 -1.51842e-006 0.000136096
1 308 152 37185 6.31686e-005 -1.54842e-006 0.000135927
1 460 120 27013 6.38552e-005 -1.57271e-006 0.000135606
1 580 128 33044 6.41784e-005 -1.58418e-006 0.000135453
1 708 136 35929 5.7634e-005 -1.34903e-006 0.000138367
[...]
D:\lastools\bin>las2txt -i leica_4.las -parse W -stdout | more
1 60 68 22473 -3.63905e-005 2.41536e-005 0.000143351
1 128 61 22493.3 -3.57011e-005 2.40341e-005 0.000143545
1 189 70 23100.4 -3.54014e-005 2.3982e-005 0.000143628
1 259 57 23119.5 -3.49998e-005 2.39121e-005 0.000143738
1 316 69 23306.3 -3.4698e-005 2.38595e-005 0.000143819
1 385 65 22638.9 -3.4597e-005 2.38418e-005 0.000143847
1 450 65 23203.4 -3.44928e-005 2.38236e-005 0.000143875
[...]
Note that because the length of this vector in the wavepacket fields
X(t), Y(t), Z(t) equals to the unnormalize range, different returns of
the same pulse will have slightly different vectors. After running
them through the code above, however, you will find that they are now
(apart from slight floating point round-off errors) all identical:
D:\lastools\bin>las2txt -i optech.las -parse rnW -drop_single -stdout | more
WARNING: number of samples for wave packet descr 1 is with 479456700
unusually large
1 2 1 289660 208 44799 -3.17243e-005 4.49614e-006 0.000146432
2 2 1 289868 208 70076 -3.17241e-005 4.49606e-006 0.000146432
1 2 1 302684 208 47360 -4.72107e-005 5.20722e-006 0.000142172
2 2 1 302892 208 72635 -4.72108e-005 5.2073e-006 0.000142172
1 2 1 319508 200 37481 6.96286e-006 2.60026e-006 0.000149712
2 2 1 319708 200 53344 6.96273e-006 2.6003e-006 0.000149712
1 3 1 320964 200 36501 8.14494e-006 2.53891e-006 0.000149653
2 3 1 321164 200 64771 8.14507e-006 2.53888e-006 0.000149653
3 3 1 321364 200 75159 8.14489e-006 2.53907e-006 0.000149653
Regards,
Martin @rapidlasso
PS: In case people wonder why I consider Leica's output as the
ground-truth (1) I read up on the history of FWF in LAS 1.3. That part
of the spec was proposed (and I assume written) by Paul Galla of
Leica. (2) It seems that the Leica LAS 1.3 FWF is the only output that
is currently being used in a third vendor's commercial software
(Terrasolid) for some actual processing (extracting additional
returns).
--
http://rapidlasso.com - fast tools to fix your LiDARs
On Mon, Jan 20, 2014 at 11:57 AM, Martin Isenburg
<martin....@gmail.com> wrote:
> Hello from the Philippines,
>
> glad to report we managed to export a LAS 1.3 FWF file from the LMS but I
> have trouble understanding their output. The direction vector seems to have
> the wrong scaling and an inverted direction. A little more detail. Here is
> what the wavepacket descriptor contains (full lasinfo.exe report for Optech
> file is at the end):
>
> variable length header record 2 of 2:
> reserved 0
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description ''
> index 1 bits/sample 16 compression 0 samples 479456700 temporal 1000 gain
> 1, offset 0
>
> which - apart from a strange value for 'samples' - is quite similar to one
> by Leica that have historically proven to be correct (full lasinfo.exe
> report for the Leica file is also at the end). But when I look at the
> contents of the wavepackets stored per point i get confused. Some of the
> data is clearly wrong. Compared to the (correct) Leica output the direction
> vectors of the wavepackets seem completely wacko. They have a wrong scaling
> and obviously an inverted direction ... no wonder I cannot convert them to
> PulseWaves format.
>
> D:\lastools\bin>las2txt -i optech.las -parse W -stdout | more
> 1 60 120 30013 -229.222 5.51441 -502.68
> 1 180 128 29979 -231.992 5.60883 -502.721
> 1 308 152 37185 -233.598 5.72608 -502.661
> 1 460 120 27013 -236.703 5.82986 -502.674
> 1 580 128 33044 -238.199 5.87968 -502.735
> 1 708 136 35929 -209.547 4.90483 -503.078
> [...]
>
> D:\lastools\bin>las2txt -i leica_4.las -parse W -stdout | more
> 1 60 68 22473 -3.63905e-005 2.41536e-005 0.000143351
> 1 128 61 22493.3 -3.57011e-005 2.40341e-005 0.000143545
> 1 189 70 23100.4 -3.54014e-005 2.3982e-005 0.000143628
> 1 259 57 23119.5 -3.49998e-005 2.39121e-005 0.000143738
> 1 316 69 23306.3 -3.4698e-005 2.38595e-005 0.000143819
> 1 385 65 22638.9 -3.4597e-005 2.38418e-005 0.000143847
> 1 450 65 23203.4 -3.44928e-005 2.38236e-005 0.000143875
>
> Can anyone explain that? Wrong setting in the exporter? A screenshot with
> some interface settings is attached. Has anyone successfully used Optech LMS
> LAS 1.3 FWF exports from the Gemini? Next up ... Pegasus.
>
> Regards,
>
> Martin @rapidlasso
>
>>>>>>>> OPTECH LASINFO REPORT <<<<<<<<
>
> D:\lastools\bin>lasinfo L6-1-cgy_657g_lms-S1-C1_s_w.las
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 61
> global_encoding: 2
> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> version major.minor: 1.3
> system identifier: 'ALTM GEMINI'
> generating software: 'OptechLMS'
> file creation day/year: 20/2014
> header size: 235
> offset to point data: 409
> number var. length records: 2
> point data format: 4
> point data record length: 57
> number of point records: 4247880
> number of points by return: 3786591 342563 94427 20672 3627
> scale factor x y z: 0.01 0.01 0.01
> offset x y z: 349415.51000000001 1823317.5700000001 195.81
> min x y z: 349151.24 1821574.94 -263.41
> max x y z: 349677.65 1825211.92 520.15
> start of waveform data packet record: 242130944
> variable length header record 1 of 2:
> reserved 0
> user ID 'LASF_Projection'
> record ID 34735
> length after header 40
> description ''
> GeoKeyDirectoryTag version 1.1.0 number of keys 4
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 2 -
> GTRasterTypeGeoKey: RasterPixelIsPoint
> key 3072 tiff_tag_location 0 count 1 value_offset 32651 -
> ProjectedCSTypeGeoKey: PCS_WGS84_UTM_zone_51N
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> variable length header record 2 of 2:
> reserved 0
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description ''
> index 1 bits/sample 16 compression 0 samples 479456700 temporal 1000 gain
> 1, offset 0
> reporting minimum and maximum for all LAS point record entries ...
> X -26427 26214
> Y -174263 189435
> Z -45922 32434
> intensity 30 3931
> edge_of_flight_line 0 1
> scan_direction_flag 0 1
> number_of_returns_of_given_pulse 1 5
> return_number 1 5
> classification 0 0
> scan_angle_rank -25 28
> user_data 0 0
> point_source_ID 0 0
> gps_time 527887.540211 527942.380385
> Wavepacket Index 1 1
> Offset 60 958913292
> Size 96 448
> Location 11000 207500
> Xt -244.435 241.841
> Yt -24.8497 17.4707
> Zt -930.878 -141.063
> overview over number of returns of given pulse: 3444028 496272 221265 68180
> 18135 0 0
> histogram of classification of points:
> 4247880 Created, never classified (0)
>
>>>>>>>> LEICA LASINFO REPORT <<<<<<<<
>
> D:\lastools\bin>lasinfo LDR100301_120340_4.LAZ
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 0
> global_encoding: 4
> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> version major.minor: 1.3
> system identifier: 'ALSXX'
> generating software: 'ALSXX_PP V2.70 BUILD#15'
> file creation day/year: 60/2010
> header size: 235
> offset to point data: 5785
> number var. length records: 5
> point data format: 4
> point data record length: 57
> number of point records: 1642660
> number of points by return: 1642509 151 0 0 0
> scale factor x y z: 0.001 0.001 0.001
> offset x y z: 0 5000000 0
> min x y z: -235549.276 5799988.226 259.047
> max x y z: -234828.416 5800946.249 281.244
> start of waveform data packet record: 0
> variable length header record 1 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1001
> length after header 5120
> description 'Intensity Histogram'
> variable length header record 2 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1002
> length after header 22
> description 'MissionInfo'
> variable length header record 3 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1003
> length after header 54
> description 'UserInputs'
> variable length header record 4 of 5:
> reserved 43707
> user ID 'LASF_Projection'
> record ID 34735
> length after header 56
> description 'Projection Info'
> GeoKeyDirectoryTag version 1.1.0 number of keys 6
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 2 -
> GTRasterTypeGeoKey: RasterPixelIsPoint
> key 3076 tiff_tag_location 0 count 1 value_offset 32632 -
> ProjLinearUnitsGeoKey: look-up for 32632 not implemented
> key 2052 tiff_tag_location 0 count 1 value_offset 9001 -
> GeogLinearUnitsGeoKey: Linear_Meter
> key 4096 tiff_tag_location 0 count 1 value_offset 5030 -
> VerticalCSTypeGeoKey: VertCS_WGS_84_ellipsoid
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> variable length header record 5 of 5:
> reserved 43707
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description 'Waveform Data'
> index 1 bits/sample 8 compression 1 samples 256 temporal 1000 gain
> 0.0172906, offset 0
> the header is followed by 2 user-defined bytes
> LASzip compression (version 2.0r2 c2 50000): POINT10 2 GPSTIME11 2
> WAVEPACKET13 1
> reporting minimum and maximum for all LAS point record entries ...
> X -235549276 -234828416
> Y 799988226 800946249
> Z 259047 281244
> intensity 0 255
> edge_of_flight_line 0 1
> scan_direction_flag 0 1
> number_of_returns_of_given_pulse 1 2
> return_number 1 2
> classification 1 1
> scan_angle_rank -28 24
> user_data 0 0
> point_source_ID 400 414
> gps_time 129850.000003 129864.580506
> Wavepacket Index 1 1
> Offset 60 134528186
> Size 52 104
> Location 22435 64065.3
> Xt -5.67832e-005 5.98938e-005
> Yt -6.3084e-006 2.69603e-005
> Zt 0.000137158 0.000149669
> overview over number of returns of given pulse: 1642358 302 0 0 0 0 0
> histogram of classification of points:
> 1642660 Unclassified (1)
>
> --
> --
> Post to "PulseWaves" by email to pulse...@googlegroups.com
> Unsubscribe by email to pulsewaves+...@googlegroups.com
> Visit this group's message archives at http://pulsewaves.org
>
> ---
> You received this message because you are subscribed to the Google Groups
> "PulseWaves - no pulse left behind" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pulsewaves+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
since this is a LAS 1.3/1.4 specification issue some of you may be
interested in this (read in reverse).
Martin
---------- Forwarded message ----------
From: Martin Isenburg <martin....@gmail.com>
Date: Tue, Jan 21, 2014 at 3:31 AM
Subject: Re: [PulseWaves] Issues with Optech GEMINI's LAS 1.3 FWF output
To: PulseWaves - no pulse left behind <pulse...@googlegroups.com>
Hello,
seems the issue is resolved. I received an off-line message explaining
the scaling of these direction vectors to me. Seems the LAS
specification is really vague on how to properly define these. In late
2011 I noticed that in RIEGL exports of LAS 1.3 FWF with RiPRECISION
vectors had inverted signs (when compared to Leica output) and now
Optech's LMS has both inverted signs and the wrong scaling. With the
software engineers of two leading hardware manufacturers both
miss-understanding this part of the LAS 1.3 specification - and
believe me these are smart folks (-: - I will suggest to the LAS
committee that we clarify the language of the spec.
Apparently in LMS the vector that gets stores in the wavepacket fields
X(t), Y(t), Z(t) corresponds to the difference between the coordinates
of the return and the coordinates of virtual point behind the scanning
mirror that can be thought of as the "optical origin". Hence, the
length of this vector equals to the range and LMS doesn’t normalize
it.
Simply dividing this vector of the wavepacket fields X(t), Y(t), Z(t)
by the negative wavepacket field "location" illustrates nicely that
the directions and distances seem to be all correct (see first pic) as
all beams converge on the optical origin. This code below changes the
current Optech vectors and the visuals are correct then (see second
pic).
// roundtrip distance in meters that the laser travels
// is one *picosecond* computed by the distance the
// laser travels in one nanoseconds divided by two
// and divided by 1000. used the speed of light, may
// need to be calibrated with system parameters
F64 round_trip_distance = 0.299792458 / 2 / 1000;
F64 x = -point.wavepacket.getXt();
F64 y = -point.wavepacket.getYt();
F64 z = -point.wavepacket.getZt();
F64 len = sqrt(x*x+y*y+z*z);
x = x / len * round_trip_distance ;
y = y / len * round_trip_distance ;
z = z / len * round_trip_distance ;
point.wavepacket.setXt((F32)x);
point.wavepacket.setYt((F32)y);
point.wavepacket.setZt((F32)z);
It also seems to make them more or less identical to Leica's in terms
of scale and direction as you can see below.
D:\lastools\bin>las2txt -i optech.las -parse W -stdout | more
WARNING: number of samples for wave packet descr 1 is with 479456700
unusually large
1 60 120 30013 6.21887e-005 -1.49608e-006 0.000136379
1 180 128 29979 6.28045e-005 -1.51842e-006 0.000136096
1 308 152 37185 6.31686e-005 -1.54842e-006 0.000135927
1 460 120 27013 6.38552e-005 -1.57271e-006 0.000135606
1 580 128 33044 6.41784e-005 -1.58418e-006 0.000135453
1 708 136 35929 5.7634e-005 -1.34903e-006 0.000138367
[...]
D:\lastools\bin>las2txt -i leica_4.las -parse W -stdout | more
1 60 68 22473 -3.63905e-005 2.41536e-005 0.000143351
1 128 61 22493.3 -3.57011e-005 2.40341e-005 0.000143545
1 189 70 23100.4 -3.54014e-005 2.3982e-005 0.000143628
1 259 57 23119.5 -3.49998e-005 2.39121e-005 0.000143738
1 316 69 23306.3 -3.4698e-005 2.38595e-005 0.000143819
1 385 65 22638.9 -3.4597e-005 2.38418e-005 0.000143847
1 450 65 23203.4 -3.44928e-005 2.38236e-005 0.000143875
[...]
Note that because the length of this vector in the wavepacket fields
X(t), Y(t), Z(t) equals to the unnormalize range, different returns of
the same pulse will have slightly different vectors. After running
them through the code above, however, you will find that they are now
(apart from slight floating point round-off errors) all identical:
D:\lastools\bin>las2txt -i optech.las -parse rnW -drop_single -stdout | more
WARNING: number of samples for wave packet descr 1 is with 479456700
unusually large
1 2 1 289660 208 44799 -3.17243e-005 4.49614e-006 0.000146432
2 2 1 289868 208 70076 -3.17241e-005 4.49606e-006 0.000146432
1 2 1 302684 208 47360 -4.72107e-005 5.20722e-006 0.000142172
2 2 1 302892 208 72635 -4.72108e-005 5.2073e-006 0.000142172
1 2 1 319508 200 37481 6.96286e-006 2.60026e-006 0.000149712
2 2 1 319708 200 53344 6.96273e-006 2.6003e-006 0.000149712
1 3 1 320964 200 36501 8.14494e-006 2.53891e-006 0.000149653
2 3 1 321164 200 64771 8.14507e-006 2.53888e-006 0.000149653
3 3 1 321364 200 75159 8.14489e-006 2.53907e-006 0.000149653
Regards,
Martin @rapidlasso
PS: In case people wonder why I consider Leica's output as the
ground-truth (1) I read up on the history of FWF in LAS 1.3. That part
of the spec was proposed (and I assume written) by Paul Galla of
Leica. (2) It seems that the Leica LAS 1.3 FWF is the only output that
is currently being used in a third vendor's commercial software
(Terrasolid) for some actual processing (extracting additional
returns).
--
http://rapidlasso.com - fast tools to fix your LiDARs
On Mon, Jan 20, 2014 at 11:57 AM, Martin Isenburg
<martin....@gmail.com> wrote:
> Hello from the Philippines,
>
> glad to report we managed to export a LAS 1.3 FWF file from the LMS but I
> have trouble understanding their output. The direction vector seems to have
> the wrong scaling and an inverted direction. A little more detail. Here is
> what the wavepacket descriptor contains (full lasinfo.exe report for Optech
> file is at the end):
>
> variable length header record 2 of 2:
> reserved 0
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description ''
> index 1 bits/sample 16 compression 0 samples 479456700 temporal 1000 gain
> 1, offset 0
>
> which - apart from a strange value for 'samples' - is quite similar to one
> by Leica that have historically proven to be correct (full lasinfo.exe
> report for the Leica file is also at the end). But when I look at the
> contents of the wavepackets stored per point i get confused. Some of the
> data is clearly wrong. Compared to the (correct) Leica output the direction
> vectors of the wavepackets seem completely wacko. They have a wrong scaling
> and obviously an inverted direction ... no wonder I cannot convert them to
> PulseWaves format.
>
> D:\lastools\bin>las2txt -i optech.las -parse W -stdout | more
> 1 60 120 30013 -229.222 5.51441 -502.68
> 1 180 128 29979 -231.992 5.60883 -502.721
> 1 308 152 37185 -233.598 5.72608 -502.661
> 1 460 120 27013 -236.703 5.82986 -502.674
> 1 580 128 33044 -238.199 5.87968 -502.735
> 1 708 136 35929 -209.547 4.90483 -503.078
> [...]
>
> D:\lastools\bin>las2txt -i leica_4.las -parse W -stdout | more
> 1 60 68 22473 -3.63905e-005 2.41536e-005 0.000143351
> 1 128 61 22493.3 -3.57011e-005 2.40341e-005 0.000143545
> 1 189 70 23100.4 -3.54014e-005 2.3982e-005 0.000143628
> 1 259 57 23119.5 -3.49998e-005 2.39121e-005 0.000143738
> 1 316 69 23306.3 -3.4698e-005 2.38595e-005 0.000143819
> 1 385 65 22638.9 -3.4597e-005 2.38418e-005 0.000143847
> 1 450 65 23203.4 -3.44928e-005 2.38236e-005 0.000143875
>
> Can anyone explain that? Wrong setting in the exporter? A screenshot with
> some interface settings is attached. Has anyone successfully used Optech LMS
> LAS 1.3 FWF exports from the Gemini? Next up ... Pegasus.
>
> Regards,
>
> Martin @rapidlasso
>
>>>>>>>> OPTECH LASINFO REPORT <<<<<<<<
>
> D:\lastools\bin>lasinfo L6-1-cgy_657g_lms-S1-C1_s_w.las
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 61
> global_encoding: 2
> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> version major.minor: 1.3
> system identifier: 'ALTM GEMINI'
> generating software: 'OptechLMS'
> file creation day/year: 20/2014
> header size: 235
> offset to point data: 409
> number var. length records: 2
> point data format: 4
> point data record length: 57
> number of point records: 4247880
> number of points by return: 3786591 342563 94427 20672 3627
> scale factor x y z: 0.01 0.01 0.01
> offset x y z: 349415.51000000001 1823317.5700000001 195.81
> min x y z: 349151.24 1821574.94 -263.41
> max x y z: 349677.65 1825211.92 520.15
> start of waveform data packet record: 242130944
> variable length header record 1 of 2:
> reserved 0
> user ID 'LASF_Projection'
> record ID 34735
> length after header 40
> description ''
> GeoKeyDirectoryTag version 1.1.0 number of keys 4
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 2 -
> GTRasterTypeGeoKey: RasterPixelIsPoint
> key 3072 tiff_tag_location 0 count 1 value_offset 32651 -
> ProjectedCSTypeGeoKey: PCS_WGS84_UTM_zone_51N
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> variable length header record 2 of 2:
> reserved 0
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description ''
> index 1 bits/sample 16 compression 0 samples 479456700 temporal 1000 gain
> 1, offset 0
> reporting minimum and maximum for all LAS point record entries ...
> X -26427 26214
> Y -174263 189435
> Z -45922 32434
> intensity 30 3931
> edge_of_flight_line 0 1
> scan_direction_flag 0 1
> number_of_returns_of_given_pulse 1 5
> return_number 1 5
> classification 0 0
> scan_angle_rank -25 28
> user_data 0 0
> point_source_ID 0 0
> gps_time 527887.540211 527942.380385
> Wavepacket Index 1 1
> Offset 60 958913292
> Size 96 448
> Location 11000 207500
> Xt -244.435 241.841
> Yt -24.8497 17.4707
> Zt -930.878 -141.063
> overview over number of returns of given pulse: 3444028 496272 221265 68180
> 18135 0 0
> histogram of classification of points:
> 4247880 Created, never classified (0)
>
>>>>>>>> LEICA LASINFO REPORT <<<<<<<<
>
> D:\lastools\bin>lasinfo LDR100301_120340_4.LAZ
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 0
> global_encoding: 4
> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> version major.minor: 1.3
> system identifier: 'ALSXX'
> generating software: 'ALSXX_PP V2.70 BUILD#15'
> file creation day/year: 60/2010
> header size: 235
> offset to point data: 5785
> number var. length records: 5
> point data format: 4
> point data record length: 57
> number of point records: 1642660
> number of points by return: 1642509 151 0 0 0
> scale factor x y z: 0.001 0.001 0.001
> offset x y z: 0 5000000 0
> min x y z: -235549.276 5799988.226 259.047
> max x y z: -234828.416 5800946.249 281.244
> start of waveform data packet record: 0
> variable length header record 1 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1001
> length after header 5120
> description 'Intensity Histogram'
> variable length header record 2 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1002
> length after header 22
> description 'MissionInfo'
> variable length header record 3 of 5:
> reserved 43707
> user ID 'LeicaGeo'
> record ID 1003
> length after header 54
> description 'UserInputs'
> variable length header record 4 of 5:
> reserved 43707
> user ID 'LASF_Projection'
> record ID 34735
> length after header 56
> description 'Projection Info'
> GeoKeyDirectoryTag version 1.1.0 number of keys 6
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 2 -
> GTRasterTypeGeoKey: RasterPixelIsPoint
> key 3076 tiff_tag_location 0 count 1 value_offset 32632 -
> ProjLinearUnitsGeoKey: look-up for 32632 not implemented
> key 2052 tiff_tag_location 0 count 1 value_offset 9001 -
> GeogLinearUnitsGeoKey: Linear_Meter
> key 4096 tiff_tag_location 0 count 1 value_offset 5030 -
> VerticalCSTypeGeoKey: VertCS_WGS_84_ellipsoid
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> variable length header record 5 of 5:
> reserved 43707
> user ID 'LASF_Spec'
> record ID 100
> length after header 26
> description 'Waveform Data'
> index 1 bits/sample 8 compression 1 samples 256 temporal 1000 gain
> 0.0172906, offset 0
> the header is followed by 2 user-defined bytes
> LASzip compression (version 2.0r2 c2 50000): POINT10 2 GPSTIME11 2
> WAVEPACKET13 1
> reporting minimum and maximum for all LAS point record entries ...
> X -235549276 -234828416
> Y 799988226 800946249
> Z 259047 281244
> intensity 0 255
> edge_of_flight_line 0 1
> scan_direction_flag 0 1
> number_of_returns_of_given_pulse 1 2
> return_number 1 2
> classification 1 1
> scan_angle_rank -28 24
> user_data 0 0
> point_source_ID 400 414
> gps_time 129850.000003 129864.580506
> Wavepacket Index 1 1
> Offset 60 134528186
> Size 52 104
> Location 22435 64065.3
> Xt -5.67832e-005 5.98938e-005
> Yt -6.3084e-006 2.69603e-005
> Zt 0.000137158 0.000149669
> overview over number of returns of given pulse: 1642358 302 0 0 0 0 0
> histogram of classification of points:
> 1642660 Unclassified (1)
>
> --
> --
> Post to "PulseWaves" by email to pulse...@googlegroups.com
> Unsubscribe by email to pulsewaves+...@googlegroups.com
> Visit this group's message archives at http://pulsewaves.org
>
> ---
> You received this message because you are subscribed to the Google Groups
> "PulseWaves - no pulse left behind" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pulsewaves+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages