[Liblas-commits] hg: 2 new changesets
liblas-commits at liblas.org
liblas-commits at liblas.org
Tue Dec 14 16:10:30 EST 2010
changeset 2826c28d85b3 in /Volumes/Data/www/liblas.org/hg
details: http://hg.liblas.orghg?cmd=changeset;node=2826c28d85b3
summary: move liblas::Writer transforms and filters down into the pimpl
changeset 4ddf274a6814 in /Volumes/Data/www/liblas.org/hg
details: http://hg.liblas.orghg?cmd=changeset;node=4ddf274a6814
summary: merge
diffstat:
doc/development/buildbot.txt | 55 +++++++-
doc/development/rfc/index.txt | 1 +
doc/development/rfc/rfc_2_spatialreference.txt | 174 +++++++++++++++++++++++++
include/liblas/capi/liblas.h | 13 +-
include/liblas/detail/fwd.hpp | 2 +
include/liblas/detail/writer/base.hpp | 5 +-
include/liblas/detail/writer/writer.hpp | 8 +-
include/liblas/lasspatialreference.hpp | 65 ++++-----
include/liblas/lastransform.hpp | 1 +
include/liblas/lasversion.hpp | 58 +-------
include/liblas/laswriter.hpp | 10 +-
include/liblas/liblas.hpp | 4 +
src/CMakeLists.txt | 3 +-
src/detail/writer/base.cpp | 1 +
src/detail/writer/writer.cpp | 10 +
src/las_c_api.cpp | 18 ++-
src/lasindex.cpp | 2 +-
src/lasspatialreference.cpp | 174 +++++++++++++++++++++++-
src/lasversion.cpp | 113 ++++++++++++++++
src/laswriter.cpp | 65 +-------
test/unit/lasspatialreference_test.cpp | 149 +++++++++++++++++++-
21 files changed, 735 insertions(+), 196 deletions(-)
diffs (truncated from 1395 to 300 lines):
diff -r e2f2b287bc6e -r 4ddf274a6814 doc/development/buildbot.txt
--- a/doc/development/buildbot.txt Mon Dec 13 09:10:50 2010 -0600
+++ b/doc/development/buildbot.txt Tue Dec 14 15:09:52 2010 -0600
@@ -1,9 +1,46 @@
.. _buildbot:
******************************************************************************
-Continuous Integration
+Test Suite
******************************************************************************
+Liblas includes a test suite written in C++ that can be fairly easily run
+to ensure that the library is working properly.
+
+
+make test
+..............................................................................
+
+The test suite can be run in the liblas main directory with::
+
+ make test
+
+If the liblas_test binary does not exist it may be necessary to do::
+
+ make liblas_test test
+
+This should produce a brief report indicating the number of tests that failed,
+if any. A detailed report will be generated in
+liblas/Testing/Temporary/LastTest.log. Failure reports may look something
+like::
+
+ ---> group: liblas::SpatialReference, test: test<6>
+ problem: assertion failed
+ failed assertion: `VLR count: expected `3` actual `4``
+
+Tests failures diagnosis may require inspecting the test code in the
+liblas/test/unit directory. In the above case searching for "test<6>" in
+the file liblas/test/unit/lasspatialreference_test.cpp would be appropriate.
+
+The tests can also be run directly in the liblas/test/unit directory by
+running the liblas/bin/liblas_test executable. In this case the report is
+written to stderr. Be careful to write it in the right directory or some
+tests will fail for reasons that are not clear.
+
+
+Continuous Integration - buildbot
+..............................................................................
+
The libLAS project uses `Buildbot <http://buildbot.net/trac>`__ to perform
automated builds and continuous integration. Thanks to the
@@ -19,6 +56,10 @@
<mloskot> bbliblas: force build telascience-full "Routine check"
+.. warning::
+ Currently the buildbot instance is not operational. This section will
+ be updated when an analygous service is available again.
+
Building libLAS and running unit tests using CMake on Unix
..............................................................................
@@ -159,6 +200,16 @@
Built target Continuous
+Ammending and Extending the Test Suite
+..............................................................................
+
+The tests for the test suite are implemented as a set of C++ files in the
+liblas/test/unit directory. New tests for existing classes can be added
+based on the existing examples. New files can be introduced for additional
+classes or categories of testing, but the source filename(s) will also need
+to be added in liblas/test/unit/CMakeLists.txt.
+
+
.. _`CMake`: http://www.cmake.org/
.. _`CTest`: http://cmake.org/cmake/help/ctest-2-8-docs.html
.. _`CMake 2.8.0+`: http://www.cmake.org/cmake/help/cmake-2-8-docs.html
@@ -169,4 +220,4 @@
.. _`IRC`: http://irc.freenode.net/
.. _`OSGeo Buildbot`: http://buildbot.osgeo.org/
.. _`libLAS buildbot waterfall`: http://buildbot.osgeo.org:8507/waterfall
-.. _`OSGeo Foundation`: http://osgeo.org/
\ No newline at end of file
+.. _`OSGeo Foundation`: http://osgeo.org/
diff -r e2f2b287bc6e -r 4ddf274a6814 doc/development/rfc/index.txt
--- a/doc/development/rfc/index.txt Mon Dec 13 09:10:50 2010 -0600
+++ b/doc/development/rfc/index.txt Tue Dec 14 15:09:52 2010 -0600
@@ -15,6 +15,7 @@
:maxdepth: 1
rfc_1_verticalcs
+ rfc_2_spatialreference
diff -r e2f2b287bc6e -r 4ddf274a6814 doc/development/rfc/rfc_2_spatialreference.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/development/rfc/rfc_2_spatialreference.txt Tue Dec 14 15:09:52 2010 -0600
@@ -0,0 +1,174 @@
+******************************************************************************
+ libLAS RFC 2: SpatialReference Overhaul
+******************************************************************************
+
+:Author: Frank Warmerdam
+:Contact: warmerdam at pobox.com
+:Date: 11/19/10
+:Status: Proposed
+:Version: libLAS 1.6
+
+.. contents::
+ :depth: 1
+
+.. sectnum::
+
+This RFC addresses several areas of change to the liblas::SpatialReference
+class and associated services. The objectives are:
+
+ * Minimize the default exposure of liblas applications to definitions
+ from the GeoTIFF library.
+ * Minimize the default exposure of liblas applications to definitions
+ from the GDAL library.
+ * Provide a mechanism to capture coordinate system definitions in a LAS
+ file that cannot be represented via GeoTIFF tags via a liblas
+ vendor proprietary WKT VLR.
+ * Ensure that the liblas::SpatialReference class can hold such a non
+ GeoTIFF definition.
+
+
+Justification for Minimized GeoTIFF / GDAL Include Flow Through
+------------------------------------------------------------------------------
+
+Currently the lasspatialreference.hpp and a few other include files
+pull in libgeotiff, and GDAL include files somewhat gratuitously if
+these sublibraries are enabled in the build.
+
+This introduces a lot of cruft into the global namespace. Also due to the
+"C" style includes of these sublibraries, it introduces a lot of junk that
+might interfere in suprising ways and in contrast to how the rest of
+liblas in very careful to put things into namespaces and otherwise be
+somewhat sparing of includes.
+
+The cleanup should help avoid conflicts and namespace pollution for
+applications primariliy linking against liblas and not wanting to use
+libgeotiff or GDAL services directly. It should also make building somewhat
+less fragile in some cases.
+
+
+Justification for WKT Coordinate System Representation
+------------------------------------------------------------------------------
+
+There are a significant number of coordinate systems, and options that
+cannot be represented in GeoTIFF tags. This includes TOWGS84 parameters,
+options to use particular horizontal and vertical grid shift files, and
+support for projection methods that don't have CT_ definitions for
+GeoTIFF.
+
+Currently the liblas::SpatialReference class converts passed in WKT
+coordinate system definitions into a GeoTIFF VLR and future requests for
+the WKT are created by converting the GeoTIFF VLR back into WKT. This
+makes it essentially impossible currently for las2las to perform
+transformations between coordinate systems not representable in GeoTIFF
+terms even if the source and destination are provided on the commandline in
+WKT format.
+
+Also, it seems with future versions of LAS format some variation of OGC
+WKT in a VLR will become a supported, or even the preferred way of
+repesenting coordinate systems.
+
+Given these points it seems reasonable to make liblas::SpatialReference
+less GeoTIFF VLR oriented now.
+
+
+Include File Overhaul
+------------------------------------------------------------------------------
+
+The basic plan is to remove includes of all GeoTIFF include files from
+any public liblas include files. For objects, like liblas::SpatialReference,
+that depend on GeoTIFF definitions like GTIF, ST_TIFF or GTIFDefn we will
+substitute dummy types if the corresponding GeoTIFF include files have
+not already been included in advance by the application. This looks something
+like::
+
+ // Fake out the compiler if we don't have libgeotiff includes already
+ #if !defined(__geotiff_h_)
+ typedef struct GTIFS *GTIF;
+ #endif
+ #if !defined(__geo_simpletags_h_)
+ typedef struct ST_TIFFS *ST_TIFF;
+ #endif
+
+Thus liblas library code, and application code that wants "proper"
+GTIF and ST_TIFF types will need to include the corresponding libgeotiff
+include files *before* including lasspatialreference.hpp. Any attempt to
+include these libgeotiff include files *after* including lasspatialreference.hpp
+will cause conflicts. Yes, this is somewhat unfortunate and will be an
+unobvious requirement to new folks. Some existing application code will
+likely need a bit of include reordering before it will work.
+
+It is intended that similar approach might be used for GDAL and OGR
+dependencies. The primary place where this is a concern seems to be
+lastransform.hpp.
+
+It is also planned to move the lasversion.hpp function implementations into a
+.cpp file to avoid having to include libgeotiff and GDAL include files right
+in lasversion.hpp. This should have the added benefit of not making what
+lasversion.hpp returns depend on what extra macros (like HAVE_GDAL) are defined
+when it is included vs. when liblas itself is compiled and linked.
+
+
+SpatialReference WKT Updates
+------------------------------------------------------------------------------
+
+Additions to SpatialReference Class::
+
+ public
+ enum GeoVLRType
+ {
+ eGeoTIFF = 1,
+ eOGRWKT = 2
+ };
+
+ void ClearVLRs( GeoVLRType eType );
+
+ private:
+ mutable std::string m_wkt;
+
+The GeoVLRType enumeration is currently used just to define what information
+should be wiped in a call to ClearVLRs() but in the future it might also
+be used for other purposes.
+
+The ClearVLRs() method clears either the WKT VLR + m_vlr, or the GeoTIFF
+VLRs and the associated m_gtiff, m_tiff objects.
+
+The m_wkt is used internally to cache the current WKT string associated
+with the spatial reference.
+
+The SpatialReference class is updated to:
+
+ * Generated both GeoTIFF and WKT VLRs in the ResetVLRs() method.
+
+ * GetWKT() now just returns the WKT definition if it is available, otherwise
+ it computes the WKT from the GeoTIFF definition.
+
+ * SetWKT() now caches the WKT as well as creating the GeoTIFF definition
+ from it. Then the WKT and GeoTIFF VLRs are generated.
+
+Now, if you want *only* GeoTIFF VLRs you should normally generate the
+SpatialReference and then call "ClearVLRs(eOGRWKT);" before setting the
+SpatialReference on the header being written. If you want *only* a WKT
+VLR then you should call "ClearVLRs(eGeotIFF);" at the same point.
+
+
+
+WKT VLR
+------------------------------------------------------------------------------
+
+
+Currently the OGR WKT VLR is currently being written with a UserId of
+"LASF_Projection" like the GeoTIFF VLRs, and with a RecordId of 2112 to
+distingish it from the GeoTIFF VLRs.
+
+The data is the OGR WKT string with a terminating zero byte.
+
+Is there any scheme to assign RecordIds? Perhaps we should pick a value
+outside the normal legal range for TIFF tags? Or perhaps we should be
+using a different UserId?
+
+Note that it is anticipated at some point in the future there will be a
+WKT VLR definition as part of the LAS specification and that it's contents
+may be more accurately defined as OGC WKT rather than OGR WKT which can
+contain a variety of extensions to the specification.
+
+
diff -r e2f2b287bc6e -r 4ddf274a6814 include/liblas/capi/liblas.h
--- a/include/liblas/capi/liblas.h Mon Dec 13 09:10:50 2010 -0600
+++ b/include/liblas/capi/liblas.h Tue Dec 14 15:09:52 2010 -0600
@@ -59,15 +59,6 @@
typedef struct LASSchemaHS *LASSchemaH;
-/* Fake out the compiler if we don't have libgeotiff */
-#ifndef HAVE_LIBGEOTIFF
- typedef struct GTIFS * GTIF;
- typedef struct TIFFS * TIFF;
-#else
-#include <geotiff.h>
-#endif
-
-
LAS_C_START
@@ -1132,8 +1123,8 @@
*/
LAS_DLL LASSRSH LASSRS_Create(void);
-
-LAS_DLL const GTIF* LASSRS_GetGTIF(LASSRSH hSRS);
More information about the Liblas-commits
mailing list