[Liblas-commits] libpc: first post!
liblas-commits at liblas.org
liblas-commits at liblas.org
Fri Feb 4 11:13:25 EST 2011
details: http://hg.liblas.orglibpc/rev/54af26d6a442
changeset: 0:54af26d6a442
user: Michael P. Gerlek <mpg at flaxen.com>
date: Thu Feb 03 15:06:15 2011 -0800
description:
first post!
Subject: libpc: rst fix
details: http://hg.liblas.orglibpc/rev/b909e7ef42a9
changeset: 1:b909e7ef42a9
user: Michael P. Gerlek <mpg at flaxen.com>
date: Thu Feb 03 15:37:07 2011 -0800
description:
rst fix
diffstat:
doc/notes/apps.txt | 58 +++++++++++++++++
doc/notes/future.txt | 7 ++
doc/notes/goals.txt | 30 +++++++++
doc/notes/intro.txt | 18 +++++
doc/notes/io.txt | 20 ++++++
doc/notes/misc.txt | 157 ++++++++++++++++++++++++++++++++++++++++++++++++
doc/notes/pipeline.txt | 139 ++++++++++++++++++++++++++++++++++++++++++
doc/notes/stages.txt | 67 ++++++++++++++++++++
doc/notes/use-cases.txt | 107 ++++++++++++++++++++++++++++++++
9 files changed, 603 insertions(+), 0 deletions(-)
diffs (truncated from 639 to 300 lines):
diff -r 000000000000 -r b909e7ef42a9 doc/notes/apps.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/apps.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,58 @@
+=========================
+libPC Project Notes: Apps
+=========================
+
+libPC will contain a number of command line applications that are built on
+top of the libPC libraries. This Note lists those apps.
+
+This should be fleshed out to list the (major) options for each of the apps.
+
+
+pc2pc
+=====
+
+Converts from one file format to another, optionally with some (relatively
+simple) filtering or processing.
+
+
+pcinfo
+======
+
+Dumps information about a point cloud file, such as:
+
+* basic properties (extents, number of points, point format)
+
+* coordinate reference system
+
+* additional metadata
+
+* summary statistics about the points
+
+The dump should go the stdout, but options should be provided to dump to
+XML or similar, where it makes sense to do so.
+
+
+pcview
+======
+
+A simple 3D viewer for point clouds. Strictly speaking, not a command-line
+app. Will be a Windows-only thing (WPF + DirectX), unless someone else
+wants to do something too.
+
+
+pcindex
+=======
+
+Creates a spatial index for a point cloud. (Could be moved into pc2pc.)
+
+
+pcmosaic
+========
+
+Merges multiple files together. (Could be moved into pc2pc.)
+
+
+pcdemosaic
+==========
+
+Chops one file up into multiple files. (Could be moved into pc2pc.)
diff -r 000000000000 -r b909e7ef42a9 doc/notes/future.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/future.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,7 @@
+===========================
+libPC Project Notes: Future
+===========================
+
+This Note is just a dumping ground for things that have yet to be discussed.
+
+* SSE?
diff -r 000000000000 -r b909e7ef42a9 doc/notes/goals.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/goals.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,30 @@
+==========================
+libPC Project Notes: Goals
+==========================
+
+
+Project Goals
+=============
+
+1. From a market perspective, libPC is "version 2" of libLAS. The actual
+ code base will be different, however, and the APIs will not be
+ compatible.
+
+2. It is a library which provides APIs for reading, writing, and processing
+ point cloud data of various formats. As GDAL is to 2D pixels, libPC is
+ to 3D points.
+
+3. It has high performance, yet remains flexible. We recognize that
+ these two goals will conflict at times and will weigh the tradeoffs
+ pragmatically.
+
+4. The library will be in C++, but will support SWIG bindings for Python and
+ C#. We will avoid things that will make SWIG's life difficult, such as
+ multiple inheritance.
+
+5. The overall architecture will be a pipeline of connected stages, each
+ stage being a data source (reader) or filter or writer.
+
+6. The project will be released under a BSD license.
+
+7. *others?*
diff -r 000000000000 -r b909e7ef42a9 doc/notes/intro.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/intro.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,18 @@
+==========================
+libPC Project Notes: Intro
+==========================
+
+The design, architecture, and implementation of libPC will be captured in a
+set of Notes. Each Note file will, in general, discuss a single topic, such
+as Use Cases, Pipeline Design, or Testing. Notes files are intended to
+capture all the decisions made on that topic, as well as keep track of
+points still to be decided.
+
+Better yet, these notes can serve as fodder for eventual public
+documentation for libPC developers and users.
+
+Notes files will be RST text files and will live in hg.
+
+Editorial comments, and points yet to be resolved, are noted in the text
+*like this*.
+
diff -r 000000000000 -r b909e7ef42a9 doc/notes/io.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/io.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,20 @@
+========================
+libPC Project Notes: I/O
+========================
+
+Given the sheer volume of data being processed by libPC apps, it is very
+important we pay attention to I/O speed.
+
+Questions:
+
+* Is C's unix-style I/O generally faster/slower/same-as C++'s stream-style
+ I/O?
+
+* Are boost's streams any faster than the native compiler's streams?
+
+* Is it worth providing our own simple unix-style binary stream interface,
+ which we use internally, and then letting the choice of underlying
+ implementation be made up at the app level? (LizardTech does this.
+ Maybe GDAL too sometimes?)
+
+* Do we want to spend some time investigating this issue up front?
diff -r 000000000000 -r b909e7ef42a9 doc/notes/misc.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/notes/misc.txt Thu Feb 03 15:37:07 2011 -0800
@@ -0,0 +1,157 @@
+=========================
+libPC Project Notes: Misc
+=========================
+
+This document contains several issues worth documenting but are not, or are
+not yet, substantive enough to merit their own separate files.
+
+
+Spelling
+========
+
+The proper spelling of the project name is libPC (uppercased P and C,
+like libLAS is spelled).
+
+
+Management
+==========
+
+We strive for consensus, but at the end of the day Howard is the benevolent
+dictator.
+
+
+libPC Package Contents
+======================
+
+libPC will, at some level, consist of the following parts:
+
+* a set of C++ libraries
+
+* a set of command line apps
+
+* a set of tests
+
+* a set of SWIG bindings
+
+* documentation
+
+
+Project Dependencies - 3rd Party Libs
+=====================================
+
+libPC will use these libraries:
+
+* GDAL - for spatial reference support (and rasterization)
+
+* Boost - for C++ library needs, such as streams or parsers
+
+* laszip - for compressed LAS support
+
+* MrSID - for LizardTech's MG4 lidar format
+
+* Oracle - ...?
+
+* *others?*
+
+Some of these libraries may be required (such as Boost); some may be
+configurable at build time, such as laszip.
+
+
+Project Dependencies - Builds/Infrastructure
+============================================
+
+To develop and build libPC, we'll be using these tools:
+
+* Sphinx and rst2pdf - for docs
+
+* CMake - for generating makefiles
+
+* Python - for miscellaneous scripting needs
+
+* *others?*
+
+
+Testing
+=======
+
+A unit test framework will be provided, with the goal that all (nontrivial)
+classes will have unit tests. At the very least, each new class should have
+a corresponding unit test file stubbed in, even if there aren't any tests
+yet.
+
+A test harness will also be provided to exercise each of the command line
+apps.
+
+A buildbot will eventually be set up to prevent builds from breaking and to
+keep the unit tests passing.
+
+*Performance testing is harder, but we should address this eventually too.
+mpg would like to see us put together a set of benchmark files, too.*
+
+
+Platforms
+=========
+
+We will support these platforms initially, corresponding to what the
+developers are using regularly:
+
+* Windows - VS2010 (32- and 64-bit)
+
+* Linux - *gcc x.y?*
+
+* Mac - *stuff*
+
+By virtue of CMake, other platforms may be supported such as VS 2008 or
+Solaris, but we aren't targeting those specifically.
+
+Note we will not be supporting big-endian (BE) platforms at this time. We
+recognize it would be good to do so, since endianness ports always seem to
+shake out twiddly little bugs, but we don't have ready access a BE
+development box.
+
+
+Source Format and Naming Conventions
+====================================
+
+To the extent possible and reasonable, we value consistency:
+
+* LF endings, not CRLF
+
+* spaces, not tabs; 2(?) char indents
+
+* upper or lower camel case?
+
+* filenames must match class name
+
+* *layout/organization of source tree?*
+
+* *use of namespaces?*
+
+
+libPC Position on (Non)conformance
+==================================
+
+libPC proudly and unabashedly supports formal standards/specifications for
+file formats. We recognize, however, that in some cases files will not
+follow a given standard precisely, due to an unclear spec or simply out of
+carelessness.
+
+When reading files that are not formatted correctly:
+
+* libPC may try to compensate for the error. This is typically done when as
+ a practical matter the market needs support for well-known or pervasive,
+ but nonetheless "broken", upstream implementations.
More information about the Liblas-commits
mailing list