[Liblas-commits] hg: more getting started doc
liblas-commits at liblas.org
liblas-commits at liblas.org
Thu Nov 4 12:56:55 EDT 2010
changeset 9bc112c8701c in /Volumes/Data/www/liblas.org/hg
details: http://hg.liblas.orghg?cmd=changeset;node=9bc112c8701c
summary: more getting started doc
diffstat:
doc/start.txt | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 121 insertions(+), 3 deletions(-)
diffs (148 lines):
diff -r 04d40d3a1304 -r 9bc112c8701c doc/start.txt
--- a/doc/start.txt Thu Nov 04 11:56:14 2010 -0500
+++ b/doc/start.txt Thu Nov 04 11:56:51 2010 -0500
@@ -60,7 +60,7 @@
you might want to do on LAS data, and the utilities and approaches to
take to complete those tasks.
-Reproject a LAS file
+Reprojecting an LAS file
..............................................................................
All LAS data are in some sort of coordinate system, even if that coordinate
@@ -75,8 +75,122 @@
LAS file, or you may override the coordinate system description (or supply
one if none was specified).
+We're going to use an example file at http://liblas.org/samples/srs.las which
+contains only 10 points and has a coordinate system defined. Please
+download this file if you want to follow along.
+
:ref:`las2las <las2las>` is very similar in behavior to another data
-translation utility for raster data -- `gdal_translate`_.
+translation utility for raster data -- `gdal_translate`_. To reproject data,
+we must have a description of both the coordinate system we are starting with
+and a description of the coordinate system we are going to. To find out what
+you are starting with, issue a :ref:`lasinfo <lasinfo>` command:
+
+::
+
+ lasinfo --no-check srs.las
+
+.. note::
+
+ The --no-check option tells lasinfo to only print the header information
+ for the file and to not scan through all of the points. For a 10 point file,
+ this of course isn't much of a concern, but with a 50 or 500 million point
+ file, it isn't worth waiting for a full scan of the data if all you
+ want is header information.
+
+Our :ref:`lasinfo <lasinfo>` invocation tells us that the ``srs.las`` file
+is in a UTM North Zone 17 coordinate system:
+
+::
+
+ PROJCS["WGS 84 / UTM zone 17N",
+ GEOGCS["WGS 84",
+ DATUM["WGS_1984",
+ SPHEROID["WGS 84",6378137,298.257223563,
+ AUTHORITY["EPSG","7030"]],
+ AUTHORITY["EPSG","6326"]],
+ PRIMEM["Greenwich",0],
+ UNIT["degree",0.0174532925199433],
+ AUTHORITY["EPSG","4326"]],
+ PROJECTION["Transverse_Mercator"],
+ PARAMETER["latitude_of_origin",0],
+ PARAMETER["central_meridian",-81],
+ PARAMETER["scale_factor",0.9996],
+ PARAMETER["false_easting",500000],
+ PARAMETER["false_northing",0],
+ UNIT["metre",1,
+ AUTHORITY["EPSG","9001"]],
+ AUTHORITY["EPSG","32617"]]
+
+Now that we know our input coordinate system, we can make a decision about
+what to reproject the data to. In our first example, we're going to use
+the venerable plate carrée non-coordinate system, `EPSG:4326`_.
+
+::
+
+ las2las srs.las --t_srs EPSG:4326
+
+Our process succeeds, but after a quick inspection of the data with
+``lasinfo output.las`` we see a problem:
+
+::
+
+ ...
+ Scale Factor X Y Z: 0.01 0.01 0.01
+ Offset X Y Z: -0.00 -0.00 -0.00
+ ...
+ Min X, Y, Z: -83.43, 39.01, 170.58,
+ Max X, Y, Z: -83.43, 39.01, 170.76,
+
+The ``srs.las`` file had a scale of 0.01, or two decimal places of precision
+for its X, Y, and Z coordinates. For UTM data, this is ok, because it implies
+an implicit precision of 1 cm. For decimal degree data of the unprojected plate carrée
+coordinate system, it causes us to lose a bunch of precision. We need to
+set our scale values to something that can hold more precision in our case:
+
+::
+
+ las2las --t_srs EPSG:4326 srs.las --scale 0.000001 0.000001 0.01
+
+Another quick inspection with :ref:`lasinfo <lasinfo>` gives us something
+we're more comfortable with:
+
+::
+
+ ...
+ Scale Factor X Y Z: 0.000001 0.000001 0.01
+ Offset X Y Z: -0.000000 -0.000000 -0.00
+ ...
+ Min X, Y, Z: -83.427598, 39.012599, 170.58
+ Max X, Y, Z: -83.427548, 39.012618, 170.76
+
+Vertical datum transformation of an LAS file
+..............................................................................
+
+We're going to continue what we were doing in `Reprojecting an LAS file`_ but
+add a twist -- we want to change the vertical datum on the data from WGS84
+to NAVD88.
+
+.. warning::
+
+ A number of requirements are needed before you can do vertical datum transformations
+ with libLAS. The most important is GDAL, of course, but you also need a
+ very current (possibly even unreleased) version of `Proj.4`_ and the vertical
+ datum .gtx transformation files. If you're using :ref:`osgeo4w_install`, you
+ already have all of this installed when you installed libLAS. For Linux
+ or other Unix platforms, you should be aware of these requirements.
+
+Assuming you have all of the prerequisites in place, we can do the vertical
+datum transformation quite simply (again, worrying about precision as well):
+
+
+::
+
+ las2las srs.las --t_srs EPSG:4326+5703 --scale 0.000001 0.000001 0.01
+
+The key point there is adding `+5703` to the coordinate system description
+tells the GDAL/Proj.4 machinery to do a vertical transformation. There are
+other ways to have these operations happen using `WKT`_ and even GeoTIFF
+keys, but this is the most simple way to do things via command line.
.. _`CMake`: http://www.cmake.org/
.. _`CTest`: http://cmake.org/cmake/help/ctest-2-8-docs.html
@@ -90,4 +204,8 @@
.. _`OSGeo4W`: http://trac.osgeo.org/osgeo4w/
.. _`Boost`: http://www.boost.org/
.. _`DebianGIS`: http://wiki.debian.org/DebianGis
-.. _`gdal_translate`: http://www.gdal.org/gdal_translate.html
\ No newline at end of file
+.. _`gdal_translate`: http://www.gdal.org/gdal_translate.html
+.. _`EPSG`: http://www.epsg-registry.org/
+.. _`EPSG:4326`: http://spatialreference.org/ref/epsg/4326/
+.. _`Proj.4`: http://trac.osgeo.org/proj/
+.. _`WKT`: http://en.wikipedia.org/wiki/Well-known_text#Spatial_reference_systems
\ No newline at end of file
More information about the Liblas-commits
mailing list