Feature request: Las2Las Datum Transformations
234 views
Skip to first unread message
Paul Magdon
Mar 15, 2018, 9:27:27 AM3/15/18
to LAStools - efficient tools for LiDAR processing
Hi Martin et al.,
we do a lot of processing with LasTools and we are quite happy with the functions and processing speed of the software. However, there is one limitation which is complicating our workflow quite often: the missing option to perform datum transformations in las2las. Obviously this is not only relevant to us as I found a couple of post related to this:
https://groups.google.com/d/msg/lastools/mGVFX1GYwHg/xj5OWrq4BgAJ
https://groups.google.com/d/msg/lastools/Tc7nv2H9Kko/Bw5OuLr8AwAJ
https://groups.google.com/d/msg/lastools/7lZ-DVtNgDE/tjvnsNPlDAAJ
Currently we tried different options to perform the datum transformation of las or laz files: i) using liblas las2las function ii) using pdal. The later is working but quite slow and memory intensive. The former is working only in some cases.
Any suggestions how we can create an efficient workflow including datum transformations?
Greetings
Paul
Martin Isenburg
Mar 15, 2018, 9:54:27 AM3/15/18
to LAStools - efficient command line tools for LIDAR processing
Hello,
I think you have tried your best options. Both
las2las from libLAS and PDAL - if I am not mistaken - are using the proj4 library to do the heavy lifting (i.e. the actual math that does the coordinate transformation). If I were to add a lasdatum tool it would be very similar to those approaches and merely hand over the coordinates to the proj4 do the math. So far I have avoided using the
proj4 library to keep the LAStools code more "light-weight" and without external dependencies, which is something appreciated by those who compile LASlib (the library behind LAStools) for their own purposes.
If the existing codes in proj4 are really that slow then I wonder who could possibly come up with a faster solution. I believe that the creation of proj4 is the result of many many years of engineering by really really clever people and I doubt that this is easily recreated in a faster version (or ported to a GPU). Are
processing speeds really limiting? Parallizing this operation on multiple cores would be relatively trivial.
I must admit that the mathematics behind datum transforms eludes me somewhat as I have never "properly" studied this. Maybe someone else who know a lot about datum transforms could enlighten us on how those are typically implemented ... ?
Regards from Costa Rica,
Martin @rapidlasso
--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe
Kirk Waters - NOAA Federal
Mar 15, 2018, 11:46:55 AM3/15/18
to LAStools - efficient command line tools for LIDAR processing
In general, I don't believe the datum transform should be particularly slow. It may depend a bit on how the transform is being done, for instance as something like a Helmert transform or by interpolating from a grid. The Helmert type transform should be pretty fast, at least not worse than doing a projection. Using a grid to transform can depend on how the code is written. For a few points, it could be more efficient to read from disk only the points you need to interpolate. For a lot of points, like lidar, that will really slow things down as you read the same points from disk over and over. In that case, you want to read the grid into memory (or at least a big part of it). I'm not sure which way proj4 does it. I'm not sure which datums you're transforming between, so it's hard to guess what you're faced with. If you're working with typical datums in the U.S., VDatum may do what you want.
Kirk Waters, PhD | NOAA Office for Coastal Management
Applied Sciences Program | 2234 South Hobson Ave
843-740-1227 | Charleston, SC 29405
843-740-1227 | Charleston, SC 29405
Terje Mathisen
Mar 15, 2018, 6:33:33 PM3/15/18
to last...@googlegroups.com, Kirk Waters - NOAA Federal
For any given LiDAR 1-to-1 datum
transform, i.e. laz input and laz output, it should be eminently
possible to do so at effectively max IO speed as long as you have
a reasonable accuracy requirement:
I am almost certain that for all the points within a typical tile a dead simple affine transform based on exact transformation of the tile corners and then a bilinear interpolation for all the points inside the tile will be accurate at the (sub-?)mm level. The processing for each point becomes a plain
x_out = x_in * xx_scale + y_in * xy_scale + x0;
y_out = x_in * yx_scale + y_in * yy_scale + y0;
(I'm assuming the vertical datum stays constant!)
This is two FMAC operations for each line of code, 4 in total, so total processing time will be less than 10 clock cycles, far less than the time to read and write each point.
(This is relevant for me since I intend to process all the LAZ data covering all of Norway in order to generate a 1:10K map, and those laz tiles are in 32N, 33N or 35N depending upon which part of Norway they cover.
I will need to convert everything to 33N to get a single flat (UTM) map covering the country. My current pipeline uses 256x256m tiles, making the errors across such a square insignificant.
Terje
I am almost certain that for all the points within a typical tile a dead simple affine transform based on exact transformation of the tile corners and then a bilinear interpolation for all the points inside the tile will be accurate at the (sub-?)mm level. The processing for each point becomes a plain
x_out = x_in * xx_scale + y_in * xy_scale + x0;
y_out = x_in * yx_scale + y_in * yy_scale + y0;
(I'm assuming the vertical datum stays constant!)
This is two FMAC operations for each line of code, 4 in total, so total processing time will be less than 10 clock cycles, far less than the time to read and write each point.
(This is relevant for me since I intend to process all the LAZ data covering all of Norway in order to generate a 1:10K map, and those laz tiles are in 32N, 33N or 35N depending upon which part of Norway they cover.
I will need to convert everything to 33N to get a single flat (UTM) map covering the country. My current pipeline uses 256x256m tiles, making the errors across such a square insignificant.
Terje
Kirk Waters - NOAA Federal wrote:
In general, I don't believe the datum transform should be particularly slow. It may depend a bit on how the transform is being done, for instance as something like a Helmert transform or by interpolating from a grid. The Helmert type transform should be pretty fast, at least not worse than doing a projection. Using a grid to transform can depend on how the code is written. For a few points, it could be more efficient to read from disk only the points you need to interpolate. For a lot of points, like lidar, that will really slow things down as you read the same points from disk over and over. In that case, you want to read the grid into memory (or at least a big part of it). I'm not sure which way proj4 does it. I'm not sure which datums you're transforming between, so it's hard to guess what you're faced with. If you're working with typical datums in the U.S., VDatum may do what you want.
Kirk Waters, PhD Â Â Â Â Â Â Â Â Â Â | NOAA Office for Coastal Management
Applied Sciences Program    | 2234 South Hobson Ave
843-740-1227 Â Â Â Â Â Â Â Â Â Â Â Â Â | Charleston, SC 29405 Â Â
On Thu, Mar 15, 2018 at 9:49 AM, Martin Isenburg <martin....@gmail.com> wrote:
Hello,
I think you have tried your best options. Both las2las  from libLAS and PDAL - if I am not mistaken - are using the proj4 library to do the heavy lifting (i.e. the actual math that does the coordinate transformation). If I were to add a lasdatum tool it would be very similar to those approaches and merely hand over the coordinates to the proj4 do the math. So far I have avoided using the proj4 library to keep the LAStools code more "light-weight" and without external dependencies, which is something appreciated by those who compile LASlib (the library behind LAStools) for their own purposes.
If the existing codes in proj4 are really that slow then I wonder who could possibly come up with a faster solution. I believe that the creation of proj4 is the result of many many years of engineering by really really clever people and I doubt that this is easily recreated in a faster version (or ported to a GPU). Are processing speeds really limiting? Parallizing this operation on multiple cores would be relatively trivial.
I must admit that the mathematics behind datum transforms eludes me somewhat as I have never "properly" studied this. Maybe someone else who know a lot about datum transforms could enlighten us on how those are typically implemented ... ?
Kirk Waters - NOAA Federal
Mar 15, 2018, 6:33:51 PM3/15/18
to Terje Mathisen, last...@googlegroups.com
Terje,
--
Sent from a mobile device subject to autocorrect errors.
The assumption that the vertical is not involved does not always hold true. But it should still be fast.
Kirk
--
Sent from a mobile device subject to autocorrect errors.
Terje Mathisen
Mar 16, 2018, 7:13:09 AM3/16/18
to last...@googlegroups.com, Kirk Waters - NOAA Federal
Kirk Waters - NOAA Federal wrote:
Terje,The assumption that the vertical is not involved does not always hold true. But it should still be fast.
Absolutely right: At that point it becomes a standard vector *
matrix -> vector multiplication which is such a common pattern
that most compilers will even be capable of auto-vectorizing it,
using SIMD (SSE/AVX etc) instructions.
I will reuse the exact corner transforms, so except for the final set of down and right tiles, this is a single top left corner transform for each tile, i.e. almost too fast to measure compared with the LAZ read time.
If Martin would add a generic matrix transform (i.e. a way to specify the 6 or 9 scaling parameters) we could add this as an input filter for any tile which is stored using the wrong datum and avoid an extra read/transform/write step in the pipeline:
-transform_points_xy xx,xy,x0,yx,yy,y0
or
-transform_points_xyz xx,xy,xz,x0,yx,yy,yz,y0,zx,zy,zz,z0
The nicest part here is that all the current transforms which shift/scale individual (x,y,z) coordinates can be converted internally to the general xyz transform so that a single code path can handle all of them. It is even possible to default this to (1,0,0,0, 0,1,0,0, 0,0,1,0) which is the identity transform and always run it since it only needs 3 FMAC operations per coodinate direction. Absolute worst case (no FMAC support) the total time will be about 20 clock cycles.
Terje
I will reuse the exact corner transforms, so except for the final set of down and right tiles, this is a single top left corner transform for each tile, i.e. almost too fast to measure compared with the LAZ read time.
If Martin would add a generic matrix transform (i.e. a way to specify the 6 or 9 scaling parameters) we could add this as an input filter for any tile which is stored using the wrong datum and avoid an extra read/transform/write step in the pipeline:
-transform_points_xy xx,xy,x0,yx,yy,y0
or
-transform_points_xyz xx,xy,xz,x0,yx,yy,yz,y0,zx,zy,zz,z0
The nicest part here is that all the current transforms which shift/scale individual (x,y,z) coordinates can be converted internally to the general xyz transform so that a single code path can handle all of them. It is even possible to default this to (1,0,0,0, 0,1,0,0, 0,0,1,0) which is the identity transform and always run it since it only needs 3 FMAC operations per coodinate direction. Absolute worst case (no FMAC support) the total time will be about 20 clock cycles.
Terje
Martin Isenburg
Mar 16, 2018, 10:05:59 AM3/16/18
to LAStools - efficient command line tools for LIDAR processing, Kirk Waters - NOAA Federal
Hello,
Paul is transforming coordinates from a local German system EPSG:31468
to UTM 32 N EPSG 32632 and the details are below. There are various ways to do the datum transform and I wonder which one Proj4 will usually do. Unless the correct grid is in place (would it be for this transform) I would think that a seven parameter transform is used which seem to be listed here with different accuracies:
https://epsg.io/31468-15869 (2m, TOWGS84[612.4,77,440.2,-0.054,0.057,-2.797,2.55])
https://epsg.io/31468-1673 (5m, TOWGS84[582,105,414,-1.04,-0.35,3.08,8.3])
https://epsg.io/31468-1777 (3m, TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7])
The TOWGS84
seven parameter transform could easily be added to LAStools. The grids - because of their size - would pose a challenge.
PROJCS["DHDN / Gauss-Kruger zone 4", GEOGCS["DHDN", DATUM["Deutsches_Hauptdreiecksnetz", SPHEROID["Bessel 1841",6377397.155,299.1528128, AUTHORITY["EPSG","7004"]], AUTHORITY["EPSG","6314"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4314"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",12], PARAMETER["scale_factor",1], PARAMETER["false_easting",4500000], PARAMETER["false_northing",0], AUTHORITY["EPSG","31468"], AXIS["Y",EAST], AXIS["X",NORTH]]
PROJCS["WGS 84 / UTM zone 32N", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], AUTHORITY["EPSG","32632"], AXIS["Easting",EAST], AXIS["Northing",NORTH]]
Regards,
Martin @rapidlasso
Kristian Evers
Mar 16, 2018, 11:10:09 AM3/16/18
to last...@googlegroups.com
The transformation in question goes from the Potsdam datum to WGS84. The recently released version 5 of PROJ handles this as a grid transformation [0]. PROJ versions previous to 5.0.0 does this transformation as a 7-parameter Helmert shift. The 7-parameter shift is not particularly accurate which is why the gridshift transformation is now recommended by the German authorities and therefore also used in PROJ.
/Kristian
Martin Isenburg
Mar 19, 2018, 10:48:19 PM3/19/18
to LAStools - efficient command line tools for LIDAR processing
Hello,
I've added (basic) support for the Helmert transform but it assumes you project your coordinates to ECEF (geocentric) coordinates first. This is just a basic hack to support Paul's particular need and does not make use of the great optimization potential described by Terje but performs the operation (including the round-trip to ECEF) for each point. Here the updated tool:
And here an example based on his data:
:: first convert to ECEF
E:\LAStools\bin>las2las -i 4390000_5524000.laz -epsg 31468 -target_ecef -odix _ecef -olaz
using target projection 'earth-centered earth-fixed'
:: apply helmert transform
E:\LAStools\bin>las2las -i 4390000_5524000_ecef.laz -transform_helmert 612.4,77,440.2,-0.054,0.057,-2.797,2.55 -odix _wgs84 -olaz
:: go to UTM. order of arguments is important here.
E:\LAStools\bin>las2las -i 4390000_5524000_ecef_wgs84.laz -ecef -wgs84 -target_epsg 32632 -odix _32632 -olaz
using projection 'earth-centered earth-fixed'
using datum 'WGS 84' with ellipsoid 'WGS-84'
:: create hillshade. aligns nicely.
E:\LAStools\bin>las2dem -i 4390000_5524000_ecef_wgs84_32632.laz -keep_class 2 -step 0.25 -hillshade -opng
Here are all the lasinfo reports:
E:\LAStools\bin>lasinfo -i 4390000_5524000.laz
lasinfo (180303) report for 4390000_5524000.laz
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 171231)'
file creation day/year: 116/2017
header size: 227
offset to point data: 229
number var. length records: 0
point data format: 1
point data record length: 28
number of point records: 3106229
number of points by return: 2523675 412595 138105 28138 3442
scale factor x y z: 0.001 0.001 0.001
offset x y z: 4000000 6000000 0
min x y z: 4390000.000 5524698.342 336.711
max x y z: 4390999.998 5524999.999 431.915
the header is followed by 2 user-defined bytes
LASzip compression (version 3.1r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 390000000 390999998
Y -475301658 -475000001
Z 336711 431915
intensity 1 406
return_number 1 7
number_of_returns 1 7
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 2 18
scan_angle_rank -36 35
user_data 17 255
point_source_ID 177 206
gps_time 383270.148433 384741.314249
number of first returns: 2523675
number of intermediate returns: 174057
number of last returns: 2515412
number of single returns: 2106915
WARNING: there are 264 points with return number 6
WARNING: there are 10 points with return number 7
overview over number of returns of given pulse: 2106915 546715 333562 101092 16274 1595 76
histogram of classification of points:
1964109 ground (2)
22555 low vegetation (3)
975678 medium vegetation (4)
143887 Reserved for ASPRS Definition (18)
E:\LAStools\bin>lasinfo -i 4390000_5524000_ecef.laz
lasinfo (180303) report for 4390000_5524000_ecef.laz
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 180303)'
file creation day/year: 116/2017
header size: 227
offset to point data: 307
number var. length records: 1
point data format: 1
point data record length: 28
number of point records: 3106229
number of points by return: 2523675 412595 138105 28138 3442
scale factor x y z: 0.01 0.01 0.01
offset x y z: 4000000 700000 4800000
min x y z: 4051350.44 748732.35 4851818.79
max x y z: 4051767.34 749737.80 4852056.57
variable length header record 1 of 1:
reserved 0
user ID 'LASF_Projection'
record ID 34735
length after header 24
description 'by LAStools of rapidlasso GmbH'
GeoKeyDirectoryTag version 1.1.0 number of keys 2
key 1024 tiff_tag_location 0 count 1 value_offset 3 - GTModelTypeGeoKey: ModelTypeGeocentric
key 2048 tiff_tag_location 0 count 1 value_offset 4004 - GeographicTypeGeoKey: GCSE_Bessel1841
the header is followed by 2 user-defined bytes
LASzip compression (version 3.2r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 5135044 5176734
Y 4873235 4973780
Z 5181879 5205657
intensity 1 406
return_number 1 7
number_of_returns 1 7
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 2 18
scan_angle_rank -36 35
user_data 17 255
point_source_ID 177 206
gps_time 383270.148433 384741.314249
number of first returns: 2523675
number of intermediate returns: 174057
number of last returns: 2515412
number of single returns: 2106915
WARNING: there are 264 points with return number 6
WARNING: there are 10 points with return number 7
overview over number of returns of given pulse: 2106915 546715 333562 101092 16274 1595 76
histogram of classification of points:
1964109 ground (2)
22555 low vegetation (3)
975678 medium vegetation (4)
143887 Reserved for ASPRS Definition (18)
E:\LAStools\bin>lasinfo -i 4390000_5524000_ecef_wgs84.laz
lasinfo (180303) report for 4390000_5524000_ecef_wgs84.laz
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 180303)'
file creation day/year: 116/2017
header size: 227
offset to point data: 307
number var. length records: 1
point data format: 1
point data record length: 28
number of point records: 3106229
number of points by return: 2523675 412595 138105 28138 3442
scale factor x y z: 0.01 0.01 0.01
offset x y z: 4000000 700000 4800000
min x y z: 4051984.68 748757.59 4852270.05
max x y z: 4052401.57 749763.04 4852507.83
variable length header record 1 of 1:
reserved 0
user ID 'LASF_Projection'
record ID 34735
length after header 24
description 'by LAStools of rapidlasso GmbH'
GeoKeyDirectoryTag version 1.1.0 number of keys 2
key 1024 tiff_tag_location 0 count 1 value_offset 3 - GTModelTypeGeoKey: ModelTypeGeocentric
key 2048 tiff_tag_location 0 count 1 value_offset 4004 - GeographicTypeGeoKey: GCSE_Bessel1841
the header is followed by 2 user-defined bytes
LASzip compression (version 3.2r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 5198468 5240157
Y 4875759 4976304
Z 5227005 5250783
intensity 1 406
return_number 1 7
number_of_returns 1 7
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 2 18
scan_angle_rank -36 35
user_data 17 255
point_source_ID 177 206
gps_time 383270.148433 384741.314249
number of first returns: 2523675
number of intermediate returns: 174057
number of last returns: 2515412
number of single returns: 2106915
WARNING: there are 264 points with return number 6
WARNING: there are 10 points with return number 7
overview over number of returns of given pulse: 2106915 546715 333562 101092 16274 1595 76
histogram of classification of points:
1964109 ground (2)
22555 low vegetation (3)
975678 medium vegetation (4)
143887 Reserved for ASPRS Definition (18)
E:\LAStools\bin>lasinfo -i 4390000_5524000_ecef_wgs84_32632.laz
lasinfo (180303) report for 4390000_5524000_ecef_wgs84_32632.laz
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 180303)'
file creation day/year: 116/2017
header size: 227
offset to point data: 323
number var. length records: 1
point data format: 1
point data record length: 28
number of point records: 3106229
number of points by return: 2523675 412595 138105 28138 3442
scale factor x y z: 0.01 0.01 0.01
offset x y z: 600000 5500000 0
min x y z: 605596.77 5522860.46 385.67
max x y z: 606601.00 5523184.27 480.88
variable length header record 1 of 1:
reserved 0
user ID 'LASF_Projection'
record ID 34735
length after header 40
description 'by LAStools of rapidlasso GmbH'
GeoKeyDirectoryTag version 1.1.0 number of keys 4
key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
key 3072 tiff_tag_location 0 count 1 value_offset 32632 - ProjectedCSTypeGeoKey: WGS 84 / UTM 32N
key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
the header is followed by 2 user-defined bytes
LASzip compression (version 3.2r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 559677 660100
Y 2286046 2318427
Z 38567 48088
intensity 1 406
return_number 1 7
number_of_returns 1 7
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 2 18
scan_angle_rank -36 35
user_data 17 255
point_source_ID 177 206
gps_time 383270.148433 384741.314249
number of first returns: 2523675
number of intermediate returns: 174057
number of last returns: 2515412
number of single returns: 2106915
WARNING: there are 264 points with return number 6
WARNING: there are 10 points with return number 7
overview over number of returns of given pulse: 2106915 546715 333562 101092 16274 1595 76
histogram of classification of points:
1964109 ground (2)
22555 low vegetation (3)
975678 medium vegetation (4)
143887 Reserved for ASPRS Definition (18)
Paul Magdon
Jun 7, 2019, 12:45:00 PM6/7/19
to LAStools - efficient tools for LiDAR processing
Hi Martin,
the modified las2las version was solving my issues with the datum transformation back at that time. Now I need to re-run some analysis with the las2las version you provided here. Unfortunately I lost the version of las2las when I moved to a new computer and the dropbox link is outdated. Could you pls provide this modified las2las version?
Thanks & Greetings from Göttingen
Paul
Kirk
"almost all programming can be viewed as an exercise in caching"
--
Sent from a mobile device subject to autocorrect errors.
--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe
Martin Isenburg
Jun 8, 2019, 3:44:27 AM6/8/19
to LAStools - efficient command line tools for LIDAR processing
Hello,
http://lastools.org/download/LAStools.zip
http://lascloud.com/download/LAStools.zip
http://lastools.github.io/download/LAStools.zip
http://lastools.org/download
http://lascloud.com/download
http://lastools.github.io/download
this feature has long been added to the release version of LAStools (like 190604) which you can download here:
http://lastools.org/download/LAStools.zip
http://lascloud.com/download/LAStools.zip
http://lastools.github.io/download/LAStools.zip
http://lastools.org/download
http://lascloud.com/download
http://lastools.github.io/download
You can always see what new features or tools are available and what bugs were fixed in the newest LAStools version at
[...]
28 March 2018 -- lasinfo: also report TOWGS84 Helmert transform stored in GeoTIFF key 2062 (GeogTOWGS84GeoKey)
27 March 2018 -- lasground, lasnoise, lasheight, lasthin, ... : also allow '-ignore_class 0' for classification 0
23 March 2018 -- LASlib, all LAStools: more checks for correct arguments for LAStransforms
25 March 2018 -- NEW: lasvoxel computes a number of different summarizing 3D voxelizations for high-density LiDAR
23 March 2018 -- lasvalidate: fixing bug introduced in LAStools release version 180322
22 March 2018 -- lascanopy, lasgrid, las2dem: fix for bug in writing TIF rasters that appeared in version 180303
21 March 2018 -- lasheight (and others): also allow '-ignore_class 2 5 0' to include classification 0
20 March 2018 -- LASlib: new '-transform_helmert 598.1,73.7,418.2,0.202,0.045,-2.455,6.7' for ECEF coordinates
15 March 2018 -- lasvalidate: validation of files compressed with "native LAS 1.4 extension" of LASzip possible
3 March 2018 -- LASlib, all LAStools: "allow '-odir' to just specify a drive such as '-odir f:' of '-odir f:\'
2 March 2018 -- lasboundary, lascanopy: use file name from output rollout of the GUI for meaningful modes
28 February 2018 -- LASlib, all LAStools: now '-set_RGB_of_class' also works for classifications > 31
24 February 2018 -- las2las: automatically move eligible EVLRs to VLR section when downgrading LAS 1.4
23 February 2018 -- las2las: bug fix when downgrading LAS 1.4 with new point types via '-set_version 1.3'
14 February 2018 -- lasview: expose possibility to visualize workings of "spike-free" algorithm via the GUI
27 March 2018 -- lasground, lasnoise, lasheight, lasthin, ... : also allow '-ignore_class 0' for classification 0
23 March 2018 -- LASlib, all LAStools: more checks for correct arguments for LAStransforms
25 March 2018 -- NEW: lasvoxel computes a number of different summarizing 3D voxelizations for high-density LiDAR
23 March 2018 -- lasvalidate: fixing bug introduced in LAStools release version 180322
22 March 2018 -- lascanopy, lasgrid, las2dem: fix for bug in writing TIF rasters that appeared in version 180303
21 March 2018 -- lasheight (and others): also allow '-ignore_class 2 5 0' to include classification 0
20 March 2018 -- LASlib: new '-transform_helmert 598.1,73.7,418.2,0.202,0.045,-2.455,6.7' for ECEF coordinates
15 March 2018 -- lasvalidate: validation of files compressed with "native LAS 1.4 extension" of LASzip possible
3 March 2018 -- LASlib, all LAStools: "allow '-odir' to just specify a drive such as '-odir f:' of '-odir f:\'
2 March 2018 -- lasboundary, lascanopy: use file name from output rollout of the GUI for meaningful modes
28 February 2018 -- LASlib, all LAStools: now '-set_RGB_of_class' also works for classifications > 31
24 February 2018 -- las2las: automatically move eligible EVLRs to VLR section when downgrading LAS 1.4
23 February 2018 -- las2las: bug fix when downgrading LAS 1.4 with new point types via '-set_version 1.3'
14 February 2018 -- lasview: expose possibility to visualize workings of "spike-free" algorithm via the GUI
[...]
Reply all
Reply to author
Forward
0 new messages