liblas-1.7.0+dfsg/ 0000755 0001750 0001750 00000000000 12257332573 013535 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/ 0000755 0001750 0001750 00000000000 11727124362 014276 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/api/ 0000755 0001750 0001750 00000000000 11727124362 015047 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/api/TracHeader.html 0000644 0001750 0001750 00000000106 11727124362 017734 0 ustar frankie frankie
liblas-1.7.0+dfsg/doc/api/doxygen.conf 0000644 0001750 0001750 00000145705 11727124362 017407 0 ustar frankie frankie # Doxyfile 1.5.4
#
# $Id$
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project
#
# All text after a hash (#) is considered a comment and will be ignored
# The format is:
# TAG = value [value, ...]
# For lists items can also be appended using:
# TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ")
#---------------------------------------------------------------------------
# Project related configuration options
#---------------------------------------------------------------------------
# This tag specifies the encoding used for all characters in the config file that
# follow. The default is UTF-8 which is also the encoding used for all text before
# the first occurrence of this tag. Doxygen uses libiconv (or the iconv built into
# libc) for the transcoding. See http://www.gnu.org/software/libiconv for the list of
# possible encodings.
DOXYFILE_ENCODING = UTF-8
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
# by quotes) that should identify the project.
PROJECT_NAME = "libLAS API Reference"
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.
PROJECT_NUMBER = (svn-trunk)
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.
OUTPUT_DIRECTORY = .
# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.
CREATE_SUBDIRS = NO
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian,
# Italian, Japanese, Japanese-en (Japanese with English messages), Korean,
# Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian,
# Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.
OUTPUT_LANGUAGE = English
# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
# Set to NO to disable this.
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
# the brief description of a member or function before the detailed description.
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
# brief descriptions will be completely suppressed.
REPEAT_BRIEF = YES
# This tag implements a quasi-intelligent brief description abbreviator
# that is used to form the text in various listings. Each string
# in this list, if found as the leading text of the brief description, will be
# stripped from the text and the result after processing the whole list, is
# used as the annotated text. Otherwise, the brief description is used as-is.
# If left blank, the following values are used ("$name" is automatically
# replaced with the name of the entity): "The $name class" "The $name widget"
# "The $name file" "is" "provides" "specifies" "contains"
# "represents" "a" "an" "the"
ABBREVIATE_BRIEF =
# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
# Doxygen will generate a detailed section even if there is only a brief
# description.
ALWAYS_DETAILED_SEC = NO
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
# members were ordinary class members. Constructors, destructors and assignment
# operators of the base classes will not be shown.
INLINE_INHERITED_MEMB = NO
# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
# path before files name in the file list and in the header files. If set
# to NO the shortest path that makes the file name unique will be used.
FULL_PATH_NAMES = NO
# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
# can be used to strip a user-defined part of the path. Stripping is
# only done if one of the specified strings matches the left-hand part of
# the path. The tag can be used to show relative paths in the file list.
# If left blank the directory from which doxygen is run is used as the
# path to strip.
STRIP_FROM_PATH =
# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
# the path mentioned in the documentation of a class, which tells
# the reader which header file to include in order to use a class.
# If left blank only the name of the header file containing the class
# definition is used. Otherwise one should specify the include paths that
# are normally passed to the compiler using the -I flag.
STRIP_FROM_INC_PATH =
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
# (but less readable) file names. This can be useful is your file systems
# doesn't support long names like on DOS, Mac, or CD-ROM.
SHORT_NAMES = NO
# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like the Qt-style comments (thus requiring an
# explicit @brief command for a brief description.
JAVADOC_AUTOBRIEF = YES
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
# comments) as a brief description. This used to be the default behaviour.
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = NO
# If the DETAILS_AT_TOP tag is set to YES then Doxygen
# will output the detailed description near the top, like JavaDoc.
# If set to NO, the detailed description appears after the member
# documentation.
DETAILS_AT_TOP = NO
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
# re-implements.
INHERIT_DOCS = YES
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
# a new page for each member. If set to NO, the documentation of a member will
# be part of the file/class/namespace that contains it.
SEPARATE_MEMBER_PAGES = NO
# The TAB_SIZE tag can be used to set the number of spaces in a tab.
# Doxygen uses this value to replace tabs by spaces in code fragments.
TAB_SIZE = 4
# This tag can be used to specify a number of aliases that acts
# as commands in the documentation. An alias has the form "name=value".
# For example adding "sideeffect=\par Side Effects:\n" will allow you to
# put the command \sideeffect (or @sideeffect) in the documentation, which
# will result in a user-defined paragraph with heading "Side Effects:".
# You can put \n's in the value part of an alias to insert newlines.
ALIASES =
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
# sources only. Doxygen will then generate output that is more tailored for C.
# For instance, some of the names that are used will be different. The list
# of all members will be omitted, etc.
OPTIMIZE_OUTPUT_FOR_C = NO
# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
# sources only. Doxygen will then generate output that is more tailored for Java.
# For instance, namespaces will be presented as packages, qualified scopes
# will look different, etc.
OPTIMIZE_OUTPUT_JAVA = NO
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
# include (a tag file for) the STL sources as input, then you should
# set this tag to YES in order to let doxygen match functions declarations and
# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
# func(std::string) {}). This also make the inheritance and collaboration
# diagrams that involve STL classes more complete and accurate.
BUILTIN_STL_SUPPORT = NO
# If you use Microsoft's C++/CLI language, you should set this option to YES to
# enable parsing support.
CPP_CLI_SUPPORT = NO
# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
# tag is set to YES, then doxygen will reuse the documentation of the first
# member in the group (if any) for the other members of the group. By default
# all members of a group must be documented explicitly.
DISTRIBUTE_GROUP_DOC = NO
# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
# the same type (for instance a group of public functions) to be put as a
# subgroup of that type (e.g. under the Public Functions section). Set it to
# NO to prevent subgrouping. Alternatively, this can be done per class using
# the \nosubgrouping command.
SUBGROUPING = YES
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
# documentation are documented, even if no documentation was available.
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = YES
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = NO
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = NO
# This flag is only useful for Objective-C code. When set to YES local
# methods, which are defined in the implementation section but not in
# the interface are included in the documentation.
# If set to NO (the default) only methods in the interface are included.
EXTRACT_LOCAL_METHODS = YES
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES = NO
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
HIDE_FRIEND_COMPOUNDS = NO
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
HIDE_IN_BODY_DOCS = NO
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
INTERNAL_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# and Mac users are advised to set this option to NO.
CASE_SENSE_NAMES = YES
# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
HIDE_SCOPE_NAMES = NO
# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
# will put a list of the files that are included by a file in the documentation
# of that file.
SHOW_INCLUDE_FILES = YES
# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
# is inserted in the documentation for inline members.
INLINE_INFO = YES
# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
# will sort the (detailed) documentation of file and class members
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
# brief documentation of file, namespace and class members alphabetically
# by member name. If set to NO (the default) the members will appear in
# declaration order.
SORT_BRIEF_DOCS = NO
# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
# sorted by fully-qualified names, including namespaces. If set to
# NO (the default), the class list will be sorted only by class name,
# not including the namespace part.
# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
# Note: This option applies only to the class list, not to the
# alphabetical list.
SORT_BY_SCOPE_NAME = NO
# The GENERATE_TODOLIST tag can be used to enable (YES) or
# disable (NO) the todo list. This list is created by putting \todo
# commands in the documentation.
GENERATE_TODOLIST = YES
# The GENERATE_TESTLIST tag can be used to enable (YES) or
# disable (NO) the test list. This list is created by putting \test
# commands in the documentation.
GENERATE_TESTLIST = YES
# The GENERATE_BUGLIST tag can be used to enable (YES) or
# disable (NO) the bug list. This list is created by putting \bug
# commands in the documentation.
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
ENABLED_SECTIONS =
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
# the initial value of a variable or define consists of for it to appear in
# the documentation. If the initializer consists of more lines than specified
# here it will be hidden. Use a value of 0 to hide initializers completely.
# The appearance of the initializer of individual variables and defines in the
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
SHOW_USED_FILES = YES
# If the sources in your project are distributed over multiple directories
# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
# in the documentation. The default is NO.
SHOW_DIRECTORIES = YES
# The FILE_VERSION_FILTER tag can be used to specify a program or script that
# doxygen should invoke to get the current version for each file (typically from the
# version control system). Doxygen will invoke the program by executing (via
# popen()) the command , where is the value of
# the FILE_VERSION_FILTER tag, and is the name of an input file
# provided by doxygen. Whatever the program writes to standard output
# is used as the file version. See the manual for examples.
FILE_VERSION_FILTER =
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
# The QUIET tag can be used to turn on/off the messages that are generated
# by doxygen. Possible values are YES and NO. If left blank NO is used.
QUIET = NO
# The WARNINGS tag can be used to turn on/off the warning messages that are
# generated by doxygen. Possible values are YES and NO. If left blank
# NO is used.
WARNINGS = YES
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some
# parameters in a documented function, or documenting parameters that
# don't exist or using markup commands wrongly.
WARN_IF_DOC_ERROR = YES
# This WARN_NO_PARAMDOC option can be abled to get warnings for
# functions that are documented, but have no documentation for their parameters
# or return value. If set to NO (the default) doxygen will only warn about
# wrong or incomplete parameter documentation, but not about the absence of
# documentation.
WARN_NO_PARAMDOC = NO
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# warning originated and the warning text. Optionally the format may contain
# $version, which will be replaced by the version of the file (if it could
# be obtained via FILE_VERSION_FILTER)
WARN_FORMAT = "$file:$line: $text"
# The WARN_LOGFILE tag can be used to specify a file to which warning
# and error messages should be written. If left blank the output is written
# to stderr.
WARN_LOGFILE =
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT = ../../include/liblas ../../include/liblas/capi
# This tag can be used to specify the character encoding of the source files that
# doxygen parses. Internally doxygen uses the UTF-8 encoding, which is also the default
# input encoding. Doxygen uses libiconv (or the iconv built into libc) for the transcoding.
# See http://www.gnu.org/software/libiconv for the list of possible encodings.
INPUT_ENCODING = UTF-8
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
FILE_PATTERNS = *.hpp *.cpp *.h *.c
# The RECURSIVE tag can be used to turn specify whether or not subdirectories
# should be searched for input files as well. Possible values are YES and NO.
# If left blank NO is used.
RECURSIVE = NO
# The EXCLUDE tag can be used to specify files and/or directories that should
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
EXCLUDE =
# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
# directories that are symbolic links (a Unix filesystem feature) are excluded
# from the input.
EXCLUDE_SYMLINKS = NO
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories. Note that the wildcards are matched
# against the file with absolute path, so to exclude all test directories
# for example use the pattern */test/*
EXCLUDE_PATTERNS = */.svn/*
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the output.
# The symbol name can be a fully qualified name, a word, or if the wildcard * is used,
# a substring. Examples: ANamespace, AClass, AClass::ANamespace, ANamespace::*Test
EXCLUDE_SYMBOLS =
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
# the \include command).
EXAMPLE_PATH =
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank all files are included.
EXAMPLE_PATTERNS =
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
# searched for input files to be used with the \include or \dontinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
EXAMPLE_RECURSIVE = NO
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
# the \image command).
IMAGE_PATH =
# The INPUT_FILTER tag can be used to specify a program that doxygen should
# invoke to filter for each input file. Doxygen will invoke the filter program
# by executing (via popen()) the command , where
# is the value of the INPUT_FILTER tag, and is the name of an
# input file. Doxygen will then use the output that the filter program writes
# to standard output. If FILTER_PATTERNS is specified, this tag will be
# ignored.
INPUT_FILTER =
# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
# basis. Doxygen will compare the file name with each pattern and apply the
# filter if there is a match. The filters are a list of the form:
# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
# is applied to all files.
FILTER_PATTERNS =
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER) will be used to filter the input files when producing source
# files to browse (i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_FILES = NO
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
# If the SOURCE_BROWSER tag is set to YES then a list of source files will
# be generated. Documented entities will be cross-referenced with these sources.
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = NO
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.
INLINE_SOURCES = NO
# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
# doxygen to hide any special comment blocks from generated source code
# fragments. Normal C and C++ comments will always remain visible.
STRIP_CODE_COMMENTS = YES
# If the REFERENCED_BY_RELATION tag is set to YES (the default)
# then for each documented function all documented
# functions referencing it will be listed.
REFERENCED_BY_RELATION = YES
# If the REFERENCES_RELATION tag is set to YES (the default)
# then for each documented function all documented entities
# called/used by that function will be listed.
REFERENCES_RELATION = YES
# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
# link to the source code. Otherwise they will link to the documentstion.
REFERENCES_LINK_SOURCE = YES
# If the USE_HTAGS tag is set to YES then the references to source code
# will point to the HTML generated by the htags(1) tool instead of doxygen
# built-in source browser. The htags tool is part of GNU's global source
# tagging system (see http://www.gnu.org/software/global/global.html). You
# will need version 4.8.6 or higher.
USE_HTAGS = NO
# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
# will generate a verbatim copy of the header file for each class for
# which an include is specified. Set to NO to disable this.
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
# of all compounds will be generated. Enable this if the project
# contains a lot of classes, structs, unions or interfaces.
ALPHABETICAL_INDEX = YES
# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
# in which this list will be split (can be a number in the range [1..20])
COLS_IN_ALPHA_INDEX = 3
# In case all classes in a project start with a common prefix, all
# classes will be put under the same header in the alphabetical index.
# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
# should be ignored while generating the index headers.
IGNORE_PREFIX =
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
# generate HTML output.
GENERATE_HTML = YES
# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `html' will be used as the default path.
HTML_OUTPUT = html
# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
# doxygen will generate files with .html extension.
HTML_FILE_EXTENSION = .html
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header.
#HTML_HEADER =
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
#HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet. Note that doxygen will try to copy
# the style sheet file to the HTML output directory, so don't put your own
# stylesheet in the HTML output directory as well, or it will be erased!
HTML_STYLESHEET = doxygen.css
# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
# files or namespaces will be aligned in HTML using tables. If set to
# NO a bullet list will be used.
HTML_ALIGN_MEMBERS = YES
# If the GENERATE_HTMLHELP tag is set to YES, additional index files
# will be generated that can be used as input for tools like the
# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
# of the generated HTML documentation.
GENERATE_HTMLHELP = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
# be used to specify the file name of the resulting .chm file. You
# can add a path in front of the file if the result should not be
# written to the html output directory.
CHM_FILE =
# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
# be used to specify the location (absolute path including file name) of
# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
# the HTML help compiler on the generated index.hhp.
HHC_LOCATION =
# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
# controls if a separate .chi index file is generated (YES) or that
# it should be included in the master .chm file (NO).
GENERATE_CHI = NO
# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
# controls whether a binary table of contents is generated (YES) or a
# normal table of contents (NO) in the .chm file.
BINARY_TOC = NO
# The TOC_EXPAND flag can be set to YES to add extra items for group members
# to the contents of the HTML help documentation and to the tree view.
TOC_EXPAND = NO
# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
# top of each HTML page. The value NO (the default) enables the index and
# the value YES disables it.
DISABLE_INDEX = NO
# This tag can be used to set the number of enum values (range [1..20])
# that doxygen will group on one line in the generated HTML documentation.
ENUM_VALUES_PER_LINE = 4
# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
# generated containing a tree-like index structure (just like the one that
# is generated for HTML Help). For this to work a browser that supports
# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
# probably better off using the HTML help feature.
GENERATE_TREEVIEW = YES
# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
# used to set the initial width (in pixels) of the frame in which the tree
# is shown.
TREEVIEW_WIDTH = 250
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
# generate Latex output.
GENERATE_LATEX = NO
# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `latex' will be used as the default path.
LATEX_OUTPUT = latex
# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
# invoked. If left blank `latex' will be used as the default command name.
LATEX_CMD_NAME = latex
# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
# generate index for LaTeX. If left blank `makeindex' will be used as the
# default command name.
MAKEINDEX_CMD_NAME = makeindex
# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
# LaTeX documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_LATEX = NO
# The PAPER_TYPE tag can be used to set the paper type that is used
# by the printer. Possible values are: a4, a4wide, letter, legal and
# executive. If left blank a4wide will be used.
PAPER_TYPE = a4wide
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
# packages that should be included in the LaTeX output.
EXTRA_PACKAGES =
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
# the generated latex document. The header should contain everything until
# the first chapter. If it is left blank doxygen will generate a
# standard header. Notice: only use this tag if you know what you are doing!
LATEX_HEADER =
# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
# is prepared for conversion to pdf (using ps2pdf). The pdf file will
# contain links (just like the HTML output) instead of page references
# This makes the output suitable for online browsing using a pdf viewer.
PDF_HYPERLINKS = NO
# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
# plain latex in the generated Makefile. Set this option to YES to get a
# higher quality PDF documentation.
USE_PDFLATEX = NO
# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
# command to the generated LaTeX files. This will instruct LaTeX to keep
# running if errors occur, instead of asking the user for help.
# This option is also used when generating formulas in HTML.
LATEX_BATCHMODE = NO
# If LATEX_HIDE_INDICES is set to YES then doxygen will not
# include the index chapters (such as File Index, Compound Index, etc.)
# in the output.
LATEX_HIDE_INDICES = NO
#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------
# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
# The RTF output is optimized for Word 97 and may not look very pretty with
# other RTF readers or editors.
GENERATE_RTF = NO
# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `rtf' will be used as the default path.
RTF_OUTPUT = rtf
# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
# RTF documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_RTF = NO
# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
# will contain hyperlink fields. The RTF file will
# contain links (just like the HTML output) instead of page references.
# This makes the output suitable for online browsing using WORD or other
# programs which support those fields.
# Note: wordpad (write) and others do not support links.
RTF_HYPERLINKS = NO
# Load stylesheet definitions from file. Syntax is similar to doxygen's
# config file, i.e. a series of assignments. You only have to provide
# replacements, missing definitions are set to their default value.
RTF_STYLESHEET_FILE =
# Set optional variables used in the generation of an rtf document.
# Syntax is similar to doxygen's config file.
RTF_EXTENSIONS_FILE =
#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------
# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
# generate man pages
GENERATE_MAN = NO
# The MAN_OUTPUT tag is used to specify where the man pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `man' will be used as the default path.
MAN_OUTPUT = man
# The MAN_EXTENSION tag determines the extension that is added to
# the generated man pages (default is the subroutine's section .3)
MAN_EXTENSION = .3
# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.
MAN_LINKS = NO
#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------
# If the GENERATE_XML tag is set to YES Doxygen will
# generate an XML file that captures the structure of
# the code including all documentation.
GENERATE_XML = YES
# The XML_OUTPUT tag is used to specify where the XML pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `xml' will be used as the default path.
XML_OUTPUT = xml
# The XML_SCHEMA tag can be used to specify an XML schema,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_SCHEMA =
# The XML_DTD tag can be used to specify an XML DTD,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_DTD =
# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
# dump the program listings (including syntax highlighting
# and cross-referencing information) to the XML output. Note that
# enabling this will significantly increase the size of the XML output.
XML_PROGRAMLISTING = YES
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
# generate an AutoGen Definitions (see autogen.sf.net) file
# that captures the structure of the code including all
# documentation. Note that this feature is still experimental
# and incomplete at the moment.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# configuration options related to the Perl module output
#---------------------------------------------------------------------------
# If the GENERATE_PERLMOD tag is set to YES Doxygen will
# generate a Perl module file that captures the structure of
# the code including all documentation. Note that this
# feature is still experimental and incomplete at the
# moment.
GENERATE_PERLMOD = NO
# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
# the necessary Makefile rules, Perl scripts and LaTeX code to be able
# to generate PDF and DVI output from the Perl module output.
PERLMOD_LATEX = NO
# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
# nicely formatted so it can be parsed by a human reader. This is useful
# if you want to understand what is going on. On the other hand, if this
# tag is set to NO the size of the Perl module output will be much smaller
# and Perl will parse it just the same.
PERLMOD_PRETTY = YES
# The names of the make variables in the generated doxyrules.make file
# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
# This is useful so different doxyrules.make files included by the same
# Makefile don't overwrite each other's variables.
PERLMOD_MAKEVAR_PREFIX =
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
# evaluate all C-preprocessor directives found in the sources and include
# files.
ENABLE_PREPROCESSING = YES
# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
# names in the source code. If set to NO (the default) only conditional
# compilation will be performed. Macro expansion can be done in a controlled
# way by setting EXPAND_ONLY_PREDEF to YES.
MACRO_EXPANSION = NO
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
# then the macro expansion is limited to the macros specified with the
# PREDEFINED and EXPAND_AS_DEFINED tags.
EXPAND_ONLY_PREDEF = NO
# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
# in the INCLUDE_PATH (see below) will be search if a #include is found.
SEARCH_INCLUDES = YES
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by
# the preprocessor.
INCLUDE_PATH =
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
# patterns (like *.h and *.hpp) to filter out the header-files in the
# directories. If left blank, the patterns specified with FILE_PATTERNS will
# be used.
INCLUDE_FILE_PATTERNS =
# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.
PREDEFINED =
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
# this tag can be used to specify a list of macro names that should be expanded.
# The macro definition that is found in the sources will be used.
# Use the PREDEFINED tag if you want to use a different macro definition.
EXPAND_AS_DEFINED =
# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
# doxygen's preprocessor will remove all function-like macros that are alone
# on a line, have an all uppercase name, and do not end with a semicolon. Such
# function macros are typically used for boiler-plate code, and will confuse
# the parser if not removed.
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration::additions related to external references
#---------------------------------------------------------------------------
# The TAGFILES option can be used to specify one or more tagfiles.
# Optionally an initial location of the external documentation
# can be added for each tagfile. The format of a tag file without
# this location is as follows:
# TAGFILES = file1 file2 ...
# Adding location for the tag files is done as follows:
# TAGFILES = file1=loc1 "file2 = loc2" ...
# where "loc1" and "loc2" can be relative or absolute paths or
# URLs. If a location is present for each tag, the installdox tool
# does not have to be run to correct the links.
# Note that each tag file must have a unique name
# (where the name does NOT include the path)
# If a tag file is not located in the directory in which doxygen
# is run, you must also specify the path to the tagfile here.
TAGFILES =
# When a file name is specified after GENERATE_TAGFILE, doxygen will create
# a tag file that is based on the input files it reads.
GENERATE_TAGFILE =
# If the ALLEXTERNALS tag is set to YES all external classes will be listed
# in the class index. If set to NO only the inherited external classes
# will be listed.
ALLEXTERNALS = NO
# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will
# be listed.
EXTERNAL_GROUPS = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of `which perl').
PERL_PATH = /usr/bin/perl
#---------------------------------------------------------------------------
# Configuration options related to the dot tool
#---------------------------------------------------------------------------
# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
# or super classes. Setting the tag to NO turns the diagrams off. Note that
# this option is superseded by the HAVE_DOT option below. This is only a
# fallback. It is recommended to install and use dot, since it yields more
# powerful graphs.
CLASS_DIAGRAMS = YES
# You can define message sequence charts within doxygen comments using the \msc
# command. Doxygen will then run the mscgen tool (see http://www.mcternan.me.uk/mscgen/) to
# produce the chart and insert it in the documentation. The MSCGEN_PATH tag allows you to
# specify the directory where the mscgen tool resides. If left empty the tool is assumed to
# be found in the default search path.
MSCGEN_PATH =
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz, a graph visualization
# toolkit from AT&T and Lucent Bell Labs. The other options in this section
# have no effect if this option is set to NO (the default)
HAVE_DOT = YES
# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect inheritance relations. Setting this tag to YES will force the
# the CLASS_DIAGRAMS tag to NO.
CLASS_GRAPH = YES
# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect implementation dependencies (inheritance, containment, and
# class references variables) of the class with other documented classes.
COLLABORATION_GRAPH = YES
# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for groups, showing the direct groups dependencies
GROUP_GRAPHS = YES
# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
# collaboration diagrams in a style similar to the OMG's Unified Modeling
# Language.
UML_LOOK = YES
# If set to YES, the inheritance and collaboration graphs will show the
# relations between templates and their instances.
TEMPLATE_RELATIONS = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
# tags are set to YES then doxygen will generate a graph for each documented
# file showing the direct and indirect include dependencies of the file with
# other documented files.
INCLUDE_GRAPH = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
# documented header file showing the documented files that directly or
# indirectly include this file.
INCLUDED_BY_GRAPH = YES
# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
# generate a call dependency graph for every global function or class method.
# Note that enabling this option will significantly increase the time of a run.
# So in most cases it will be better to enable call graphs for selected
# functions only using the \callgraph command.
CALL_GRAPH = YES
# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then doxygen will
# generate a caller dependency graph for every global function or class method.
# Note that enabling this option will significantly increase the time of a run.
# So in most cases it will be better to enable caller graphs for selected
# functions only using the \callergraph command.
CALLER_GRAPH = YES
# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
# will graphical hierarchy of all classes instead of a textual one.
GRAPHICAL_HIERARCHY = YES
# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
# then doxygen will show the dependencies a directory has on other directories
# in a graphical way. The dependency relations are determined by the #include
# relations between the files in the directories.
DIRECTORY_GRAPH = YES
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. Possible values are png, jpg, or gif
# If left blank png will be used.
DOT_IMAGE_FORMAT = png
# The tag DOT_PATH can be used to specify the path where the dot tool can be
# found. If left blank, it is assumed the dot tool can be found in the path.
DOT_PATH = "c:\Program Files\Graphviz2.16\bin"
# The DOTFILE_DIRS tag can be used to specify one or more directories that
# contain dot files that are included in the documentation (see the
# \dotfile command).
DOTFILE_DIRS =
# The MAX_DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
# nodes that will be shown in the graph. If the number of nodes in a graph
# becomes larger than this value, doxygen will truncate the graph, which is
# visualized by representing a node as a red box. Note that doxygen will always
# show the root nodes and its direct children regardless of this setting.
DOT_GRAPH_MAX_NODES = 50
# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, which results in a white background.
# Warning: Depending on the platform used, enabling this option may lead to
# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
# read).
DOT_TRANSPARENT = NO
# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10)
# support this, this feature is disabled by default.
DOT_MULTI_TARGETS = NO
# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
# generate a legend page explaining the meaning of the various boxes and
# arrows in the dot generated graphs.
GENERATE_LEGEND = YES
# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
# remove the intermediate dot files that are used to generate
# the various graphs.
DOT_CLEANUP = YES
#---------------------------------------------------------------------------
# Configuration::additions related to the search engine
#---------------------------------------------------------------------------
# The SEARCHENGINE tag specifies whether or not a search engine should be
# used. If set to NO the values of all tags below this one will be ignored.
SEARCHENGINE = NO
liblas-1.7.0+dfsg/doc/api/doxygen.css 0000644 0001750 0001750 00000020230 11727124362 017233 0 ustar frankie frankie /* override a few trac styles */
:link, :visited, :link:hover, :visited:hover {
border-bottom-style: none;
}
/* tabs */
div.tabs *
{
display: inline;
}
div.tabs ul
{
display: block;
margin: 0em;
padding: 0.5em 0em;
font-size: 10px;
list-style: none;
text-align: left;
}
div.tabs li
{
border-right: 1px solid #d7d7d7;
padding: 0em 0.75em;
white-space: nowrap;
margin: 3px;
}
div.tabs form
{
padding: 0em 0.75em;
white-space: nowrap;
margin: 3px;
}
div.tabs #current a, div.tabs a:hover {
background-color: #fdc; /* blue: #eef3f5 */
padding: 3px;
border-width: 1px;
border-style: solid;
border-color: #d00; /* blue: #dedeee */
-moz-border-radius: 8px 8px 8px 8px;
}
div.tabs a {
padding: 3px;
border-width: 1px;
border-style: dotted;
border-color: #ffffff;
-moz-border-radius: 8px 8px 8px 8px;
}
/*
div.tabs a:visited
{
color: #2A3798;
}
*/
h1 {
text-align: center;
font-size: 160%;
}
h2 {
font-size: 120%;
}
h3 {
font-size: 100%;
}
caption { font-weight: bold }
div.qindex {
width: 100%;
background-color: #e8eef2;
border: 1px solid #84b0c7;
text-align: center;
margin: 2px;
padding: 2px;
line-height: 140%;
}
a.qindex {
text-decoration: none;
font-weight: bold;
color: #1A419D;
}
a.qindex:visited {
text-decoration: none;
font-weight: bold;
color: #1A419D
}
a.qindex:hover {
text-decoration: none;
background-color: #ddddff;
}
a.qindexHL {
text-decoration: none;
font-weight: bold;
background-color: #6666cc;
color: #ffffff;
border: 1px double #9295C2;
}
a.qindexHL:hover {
text-decoration: none;
background-color: #6666cc;
color: #ffffff;
}
a.qindexHL:visited { text-decoration: none; background-color: #6666cc; color: #ffffff }
a.el { text-decoration: none; font-weight: bold }
a.elRef { font-weight: bold }
a.code:link { text-decoration: none; font-weight: normal; color: #0000FF}
a.code:visited { text-decoration: none; font-weight: normal; color: #0000FF}
a.codeRef:link { font-weight: normal; color: #0000FF}
a.codeRef:visited { font-weight: normal; color: #0000FF}
a:hover { text-decoration: none; background-color: #f2f2ff }
dl.el { margin-left: -1cm }
.fragment {
font-family: monospace, fixed;
font-size: 95%;
}
pre.fragment {
border: 1px solid #CCCCCC;
background-color: #f5f5f5;
margin-top: 4px;
margin-bottom: 4px;
margin-left: 2px;
margin-right: 8px;
padding-left: 6px;
padding-right: 6px;
padding-top: 4px;
padding-bottom: 4px;
}
div.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
div.groupHeader {
margin-left: 16px;
margin-top: 12px;
margin-bottom: 6px;
font-weight: bold;
}
div.groupText {
margin-left: 16px;
font-style: italic;
font-size: 90%
}
td.indexkey {
background-color: #e8eef2;
font-weight: bold;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px;
border: 1px solid #CCCCCC;
}
td.indexvalue {
background-color: #e8eef2;
font-style: italic;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px;
border: 1px solid #CCCCCC;
}
tr.memlist {
background-color: #f0f0f0;
}
p.formulaDsp { text-align: center; }
img.formulaDsp { }
img.formulaInl { vertical-align: middle; }
span.keyword { color: #008000 }
span.keywordtype { color: #604020 }
span.keywordflow { color: #e08000 }
span.comment { color: #800000 }
span.preprocessor { color: #806020 }
span.stringliteral { color: #002080 }
span.charliteral { color: #008080 }
.mdescLeft {
padding: 0px 8px 4px 8px;
font-size: 80%;
font-style: italic;
background-color: #FAFAFA;
border-top: 1px none #E0E0E0;
border-right: 1px none #E0E0E0;
border-bottom: 1px none #E0E0E0;
border-left: 1px none #E0E0E0;
margin: 0px;
}
.mdescRight {
padding: 0px 8px 4px 8px;
font-size: 80%;
font-style: italic;
background-color: #FAFAFA;
border-top: 1px none #E0E0E0;
border-right: 1px none #E0E0E0;
border-bottom: 1px none #E0E0E0;
border-left: 1px none #E0E0E0;
margin: 0px;
}
.memItemLeft {
padding: 1px 0px 0px 8px;
margin: 4px;
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-color: #E0E0E0;
border-right-color: #E0E0E0;
border-bottom-color: #E0E0E0;
border-left-color: #E0E0E0;
border-top-style: solid;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
background-color: #FAFAFA;
font-size: 80%;
}
.memItemRight {
padding: 1px 8px 0px 8px;
margin: 4px;
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-color: #E0E0E0;
border-right-color: #E0E0E0;
border-bottom-color: #E0E0E0;
border-left-color: #E0E0E0;
border-top-style: solid;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
background-color: #FAFAFA;
font-size: 80%;
}
.memTemplItemLeft {
padding: 1px 0px 0px 8px;
margin: 4px;
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-color: #E0E0E0;
border-right-color: #E0E0E0;
border-bottom-color: #E0E0E0;
border-left-color: #E0E0E0;
border-top-style: none;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
background-color: #FAFAFA;
font-size: 80%;
}
.memTemplItemRight {
padding: 1px 8px 0px 8px;
margin: 4px;
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-color: #E0E0E0;
border-right-color: #E0E0E0;
border-bottom-color: #E0E0E0;
border-left-color: #E0E0E0;
border-top-style: none;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
background-color: #FAFAFA;
font-size: 80%;
}
.memTemplParams {
padding: 1px 0px 0px 8px;
margin: 4px;
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-color: #E0E0E0;
border-right-color: #E0E0E0;
border-bottom-color: #E0E0E0;
border-left-color: #E0E0E0;
border-top-style: solid;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
color: #606060;
background-color: #FAFAFA;
font-size: 80%;
}
.search {
color: #003399;
font-weight: bold;
}
form.search {
font-size: 90%;
margin-bottom: 0px;
margin-top: 0px;
}
input.search {
/* font-size: 75%; */
color: #000080;
font-weight: normal;
background-color: #e8eef2;
}
td.tiny {
font-size: 75%;
}
.dirtab {
padding: 4px;
border-collapse: collapse;
border: 1px solid #84b0c7;
}
th.dirtab {
background: #e8eef2;
font-weight: bold;
}
hr {
height: 1px;
border: none;
border-top: 1px solid black;
}
/* Style for detailed member documentation */
.memtemplate {
font-size: 80%;
color: #606060;
font-weight: normal;
}
.memnav {
background-color: #e8eef2;
border: 1px solid #84b0c7;
text-align: center;
margin: 2px;
margin-right: 15px;
padding: 2px;
}
.memitem {
padding: 4px;
background-color: #eef3f5;
border-width: 1px;
border-style: solid;
border-color: #dedeee;
-moz-border-radius: 8px 8px 8px 8px;
}
.memname {
white-space: nowrap;
font-weight: bold;
}
.memdoc{
padding-left: 10px;
}
.memproto {
background-color: #d5e1e8;
width: 100%;
border-width: 1px;
border-style: solid;
border-color: #84b0c7;
font-weight: bold;
-moz-border-radius: 8px 8px 8px 8px;
}
.paramkey {
text-align: right;
}
.paramtype {
white-space: nowrap;
}
.paramname {
color: #602020;
font-style: italic;
}
/* End Styling for detailed member documentation */
/* for the tree view */
.ftvtree {
font-family: sans-serif;
margin:0.5em;
}
.directory { font-size: 9pt; font-weight: bold; }
.directory h3 { margin: 0px; margin-top: 1em; font-size: 11pt; }
.directory > h3 { margin-top: 0; }
.directory p { margin: 0px; white-space: nowrap; }
.directory div { display: none; margin: 0px; }
.directory img { vertical-align: -30%; }
liblas-1.7.0+dfsg/doc/api/TracFooter.html 0000644 0001750 0001750 00000000002 11727124362 017775 0 ustar frankie frankie
liblas-1.7.0+dfsg/doc/api/doxygen_dev.conf 0000644 0001750 0001750 00000150325 11727124362 020237 0 ustar frankie frankie # Doxyfile 1.5.4
#
# $Id$
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project
#
# All text after a hash (#) is considered a comment and will be ignored
# The format is:
# TAG = value [value, ...]
# For lists items can also be appended using:
# TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ")
#---------------------------------------------------------------------------
# Project related configuration options
#---------------------------------------------------------------------------
# This tag specifies the encoding used for all characters in the config file that
# follow. The default is UTF-8 which is also the encoding used for all text before
# the first occurrence of this tag. Doxygen uses libiconv (or the iconv built into
# libc) for the transcoding. See http://www.gnu.org/software/libiconv for the list of
# possible encodings.
DOXYFILE_ENCODING = UTF-8
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
# by quotes) that should identify the project.
PROJECT_NAME = "libLAS Developer's Reference"
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.
PROJECT_NUMBER = (svn-trunk)
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.
OUTPUT_DIRECTORY = .
# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.
CREATE_SUBDIRS = NO
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian,
# Italian, Japanese, Japanese-en (Japanese with English messages), Korean,
# Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian,
# Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.
OUTPUT_LANGUAGE = English
# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
# Set to NO to disable this.
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
# the brief description of a member or function before the detailed description.
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
# brief descriptions will be completely suppressed.
REPEAT_BRIEF = YES
# This tag implements a quasi-intelligent brief description abbreviator
# that is used to form the text in various listings. Each string
# in this list, if found as the leading text of the brief description, will be
# stripped from the text and the result after processing the whole list, is
# used as the annotated text. Otherwise, the brief description is used as-is.
# If left blank, the following values are used ("$name" is automatically
# replaced with the name of the entity): "The $name class" "The $name widget"
# "The $name file" "is" "provides" "specifies" "contains"
# "represents" "a" "an" "the"
ABBREVIATE_BRIEF =
# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
# Doxygen will generate a detailed section even if there is only a brief
# description.
ALWAYS_DETAILED_SEC = NO
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
# members were ordinary class members. Constructors, destructors and assignment
# operators of the base classes will not be shown.
INLINE_INHERITED_MEMB = NO
# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
# path before files name in the file list and in the header files. If set
# to NO the shortest path that makes the file name unique will be used.
FULL_PATH_NAMES = NO
# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
# can be used to strip a user-defined part of the path. Stripping is
# only done if one of the specified strings matches the left-hand part of
# the path. The tag can be used to show relative paths in the file list.
# If left blank the directory from which doxygen is run is used as the
# path to strip.
STRIP_FROM_PATH =
# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
# the path mentioned in the documentation of a class, which tells
# the reader which header file to include in order to use a class.
# If left blank only the name of the header file containing the class
# definition is used. Otherwise one should specify the include paths that
# are normally passed to the compiler using the -I flag.
STRIP_FROM_INC_PATH =
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
# (but less readable) file names. This can be useful is your file systems
# doesn't support long names like on DOS, Mac, or CD-ROM.
SHORT_NAMES = NO
# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like the Qt-style comments (thus requiring an
# explicit @brief command for a brief description.
JAVADOC_AUTOBRIEF = YES
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
# comments) as a brief description. This used to be the default behaviour.
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = NO
# If the DETAILS_AT_TOP tag is set to YES then Doxygen
# will output the detailed description near the top, like JavaDoc.
# If set to NO, the detailed description appears after the member
# documentation.
DETAILS_AT_TOP = NO
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
# re-implements.
INHERIT_DOCS = YES
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
# a new page for each member. If set to NO, the documentation of a member will
# be part of the file/class/namespace that contains it.
SEPARATE_MEMBER_PAGES = NO
# The TAB_SIZE tag can be used to set the number of spaces in a tab.
# Doxygen uses this value to replace tabs by spaces in code fragments.
TAB_SIZE = 4
# This tag can be used to specify a number of aliases that acts
# as commands in the documentation. An alias has the form "name=value".
# For example adding "sideeffect=\par Side Effects:\n" will allow you to
# put the command \sideeffect (or @sideeffect) in the documentation, which
# will result in a user-defined paragraph with heading "Side Effects:".
# You can put \n's in the value part of an alias to insert newlines.
ALIASES =
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
# sources only. Doxygen will then generate output that is more tailored for C.
# For instance, some of the names that are used will be different. The list
# of all members will be omitted, etc.
OPTIMIZE_OUTPUT_FOR_C = NO
# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
# sources only. Doxygen will then generate output that is more tailored for Java.
# For instance, namespaces will be presented as packages, qualified scopes
# will look different, etc.
OPTIMIZE_OUTPUT_JAVA = NO
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
# include (a tag file for) the STL sources as input, then you should
# set this tag to YES in order to let doxygen match functions declarations and
# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
# func(std::string) {}). This also make the inheritance and collaboration
# diagrams that involve STL classes more complete and accurate.
BUILTIN_STL_SUPPORT = YES
# If you use Microsoft's C++/CLI language, you should set this option to YES to
# enable parsing support.
CPP_CLI_SUPPORT = NO
# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
# tag is set to YES, then doxygen will reuse the documentation of the first
# member in the group (if any) for the other members of the group. By default
# all members of a group must be documented explicitly.
DISTRIBUTE_GROUP_DOC = NO
# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
# the same type (for instance a group of public functions) to be put as a
# subgroup of that type (e.g. under the Public Functions section). Set it to
# NO to prevent subgrouping. Alternatively, this can be done per class using
# the \nosubgrouping command.
SUBGROUPING = YES
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
# documentation are documented, even if no documentation was available.
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = YES
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = YES
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = YES
# This flag is only useful for Objective-C code. When set to YES local
# methods, which are defined in the implementation section but not in
# the interface are included in the documentation.
# If set to NO (the default) only methods in the interface are included.
EXTRACT_LOCAL_METHODS = YES
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES = NO
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
HIDE_FRIEND_COMPOUNDS = NO
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
HIDE_IN_BODY_DOCS = NO
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
INTERNAL_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# and Mac users are advised to set this option to NO.
CASE_SENSE_NAMES = YES
# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
HIDE_SCOPE_NAMES = NO
# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
# will put a list of the files that are included by a file in the documentation
# of that file.
SHOW_INCLUDE_FILES = YES
# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
# is inserted in the documentation for inline members.
INLINE_INFO = YES
# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
# will sort the (detailed) documentation of file and class members
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
# brief documentation of file, namespace and class members alphabetically
# by member name. If set to NO (the default) the members will appear in
# declaration order.
SORT_BRIEF_DOCS = NO
# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
# sorted by fully-qualified names, including namespaces. If set to
# NO (the default), the class list will be sorted only by class name,
# not including the namespace part.
# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
# Note: This option applies only to the class list, not to the
# alphabetical list.
SORT_BY_SCOPE_NAME = NO
# The GENERATE_TODOLIST tag can be used to enable (YES) or
# disable (NO) the todo list. This list is created by putting \todo
# commands in the documentation.
GENERATE_TODOLIST = YES
# The GENERATE_TESTLIST tag can be used to enable (YES) or
# disable (NO) the test list. This list is created by putting \test
# commands in the documentation.
GENERATE_TESTLIST = YES
# The GENERATE_BUGLIST tag can be used to enable (YES) or
# disable (NO) the bug list. This list is created by putting \bug
# commands in the documentation.
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
ENABLED_SECTIONS =
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
# the initial value of a variable or define consists of for it to appear in
# the documentation. If the initializer consists of more lines than specified
# here it will be hidden. Use a value of 0 to hide initializers completely.
# The appearance of the initializer of individual variables and defines in the
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
SHOW_USED_FILES = YES
# If the sources in your project are distributed over multiple directories
# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
# in the documentation. The default is NO.
SHOW_DIRECTORIES = YES
# The FILE_VERSION_FILTER tag can be used to specify a program or script that
# doxygen should invoke to get the current version for each file (typically from the
# version control system). Doxygen will invoke the program by executing (via
# popen()) the command , where is the value of
# the FILE_VERSION_FILTER tag, and is the name of an input file
# provided by doxygen. Whatever the program writes to standard output
# is used as the file version. See the manual for examples.
FILE_VERSION_FILTER =
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
# The QUIET tag can be used to turn on/off the messages that are generated
# by doxygen. Possible values are YES and NO. If left blank NO is used.
QUIET = NO
# The WARNINGS tag can be used to turn on/off the warning messages that are
# generated by doxygen. Possible values are YES and NO. If left blank
# NO is used.
WARNINGS = YES
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some
# parameters in a documented function, or documenting parameters that
# don't exist or using markup commands wrongly.
WARN_IF_DOC_ERROR = YES
# This WARN_NO_PARAMDOC option can be abled to get warnings for
# functions that are documented, but have no documentation for their parameters
# or return value. If set to NO (the default) doxygen will only warn about
# wrong or incomplete parameter documentation, but not about the absence of
# documentation.
WARN_NO_PARAMDOC = NO
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# warning originated and the warning text. Optionally the format may contain
# $version, which will be replaced by the version of the file (if it could
# be obtained via FILE_VERSION_FILTER)
WARN_FORMAT = "$file:$line: $text"
# The WARN_LOGFILE tag can be used to specify a file to which warning
# and error messages should be written. If left blank the output is written
# to stderr.
WARN_LOGFILE =
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT = ../../include ../../include/liblas ../../include/liblas/capi ../../src ../../apps
# This tag can be used to specify the character encoding of the source files that
# doxygen parses. Internally doxygen uses the UTF-8 encoding, which is also the default
# input encoding. Doxygen uses libiconv (or the iconv built into libc) for the transcoding.
# See http://www.gnu.org/software/libiconv for the list of possible encodings.
INPUT_ENCODING = UTF-8
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
FILE_PATTERNS = *.hpp *.cpp *.h *.c
# The RECURSIVE tag can be used to turn specify whether or not subdirectories
# should be searched for input files as well. Possible values are YES and NO.
# If left blank NO is used.
RECURSIVE = YES
# The EXCLUDE tag can be used to specify files and/or directories that should
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
EXCLUDE =
# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
# directories that are symbolic links (a Unix filesystem feature) are excluded
# from the input.
EXCLUDE_SYMLINKS = NO
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories. Note that the wildcards are matched
# against the file with absolute path, so to exclude all test directories
# for example use the pattern */test/*
EXCLUDE_PATTERNS = */.svn/*
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the output.
# The symbol name can be a fully qualified name, a word, or if the wildcard * is used,
# a substring. Examples: ANamespace, AClass, AClass::ANamespace, ANamespace::*Test
EXCLUDE_SYMBOLS =
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
# the \include command).
EXAMPLE_PATH =
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank all files are included.
EXAMPLE_PATTERNS =
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
# searched for input files to be used with the \include or \dontinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
EXAMPLE_RECURSIVE = NO
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
# the \image command).
IMAGE_PATH =
# The INPUT_FILTER tag can be used to specify a program that doxygen should
# invoke to filter for each input file. Doxygen will invoke the filter program
# by executing (via popen()) the command , where
# is the value of the INPUT_FILTER tag, and is the name of an
# input file. Doxygen will then use the output that the filter program writes
# to standard output. If FILTER_PATTERNS is specified, this tag will be
# ignored.
INPUT_FILTER =
# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
# basis. Doxygen will compare the file name with each pattern and apply the
# filter if there is a match. The filters are a list of the form:
# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
# is applied to all files.
FILTER_PATTERNS =
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER) will be used to filter the input files when producing source
# files to browse (i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_FILES = NO
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
# If the SOURCE_BROWSER tag is set to YES then a list of source files will
# be generated. Documented entities will be cross-referenced with these sources.
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = NO
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.
INLINE_SOURCES = NO
# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
# doxygen to hide any special comment blocks from generated source code
# fragments. Normal C and C++ comments will always remain visible.
STRIP_CODE_COMMENTS = YES
# If the REFERENCED_BY_RELATION tag is set to YES (the default)
# then for each documented function all documented
# functions referencing it will be listed.
REFERENCED_BY_RELATION = YES
# If the REFERENCES_RELATION tag is set to YES (the default)
# then for each documented function all documented entities
# called/used by that function will be listed.
REFERENCES_RELATION = YES
# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
# link to the source code. Otherwise they will link to the documentstion.
REFERENCES_LINK_SOURCE = YES
# If the USE_HTAGS tag is set to YES then the references to source code
# will point to the HTML generated by the htags(1) tool instead of doxygen
# built-in source browser. The htags tool is part of GNU's global source
# tagging system (see http://www.gnu.org/software/global/global.html). You
# will need version 4.8.6 or higher.
USE_HTAGS = NO
# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
# will generate a verbatim copy of the header file for each class for
# which an include is specified. Set to NO to disable this.
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
# of all compounds will be generated. Enable this if the project
# contains a lot of classes, structs, unions or interfaces.
ALPHABETICAL_INDEX = YES
# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
# in which this list will be split (can be a number in the range [1..20])
COLS_IN_ALPHA_INDEX = 3
# In case all classes in a project start with a common prefix, all
# classes will be put under the same header in the alphabetical index.
# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
# should be ignored while generating the index headers.
IGNORE_PREFIX =
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
# generate HTML output.
GENERATE_HTML = YES
# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `html' will be used as the default path.
HTML_OUTPUT = html_dev
# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
# doxygen will generate files with .html extension.
HTML_FILE_EXTENSION = .html
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header.
HTML_HEADER =
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet. Note that doxygen will try to copy
# the style sheet file to the HTML output directory, so don't put your own
# stylesheet in the HTML output directory as well, or it will be erased!
HTML_STYLESHEET =
# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
# files or namespaces will be aligned in HTML using tables. If set to
# NO a bullet list will be used.
HTML_ALIGN_MEMBERS = YES
# If the GENERATE_HTMLHELP tag is set to YES, additional index files
# will be generated that can be used as input for tools like the
# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
# of the generated HTML documentation.
GENERATE_HTMLHELP = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
# be used to specify the file name of the resulting .chm file. You
# can add a path in front of the file if the result should not be
# written to the html output directory.
CHM_FILE =
# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
# be used to specify the location (absolute path including file name) of
# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
# the HTML help compiler on the generated index.hhp.
HHC_LOCATION =
# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
# controls if a separate .chi index file is generated (YES) or that
# it should be included in the master .chm file (NO).
GENERATE_CHI = NO
# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
# controls whether a binary table of contents is generated (YES) or a
# normal table of contents (NO) in the .chm file.
BINARY_TOC = NO
# The TOC_EXPAND flag can be set to YES to add extra items for group members
# to the contents of the HTML help documentation and to the tree view.
TOC_EXPAND = NO
# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
# top of each HTML page. The value NO (the default) enables the index and
# the value YES disables it.
DISABLE_INDEX = NO
# This tag can be used to set the number of enum values (range [1..20])
# that doxygen will group on one line in the generated HTML documentation.
ENUM_VALUES_PER_LINE = 4
# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
# generated containing a tree-like index structure (just like the one that
# is generated for HTML Help). For this to work a browser that supports
# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
# probably better off using the HTML help feature.
GENERATE_TREEVIEW = YES
# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
# used to set the initial width (in pixels) of the frame in which the tree
# is shown.
TREEVIEW_WIDTH = 250
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
# generate Latex output.
GENERATE_LATEX = NO
# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `latex' will be used as the default path.
LATEX_OUTPUT = latex
# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
# invoked. If left blank `latex' will be used as the default command name.
LATEX_CMD_NAME = latex
# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
# generate index for LaTeX. If left blank `makeindex' will be used as the
# default command name.
MAKEINDEX_CMD_NAME = makeindex
# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
# LaTeX documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_LATEX = NO
# The PAPER_TYPE tag can be used to set the paper type that is used
# by the printer. Possible values are: a4, a4wide, letter, legal and
# executive. If left blank a4wide will be used.
PAPER_TYPE = a4wide
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
# packages that should be included in the LaTeX output.
EXTRA_PACKAGES =
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
# the generated latex document. The header should contain everything until
# the first chapter. If it is left blank doxygen will generate a
# standard header. Notice: only use this tag if you know what you are doing!
LATEX_HEADER =
# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
# is prepared for conversion to pdf (using ps2pdf). The pdf file will
# contain links (just like the HTML output) instead of page references
# This makes the output suitable for online browsing using a pdf viewer.
PDF_HYPERLINKS = NO
# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
# plain latex in the generated Makefile. Set this option to YES to get a
# higher quality PDF documentation.
USE_PDFLATEX = NO
# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
# command to the generated LaTeX files. This will instruct LaTeX to keep
# running if errors occur, instead of asking the user for help.
# This option is also used when generating formulas in HTML.
LATEX_BATCHMODE = NO
# If LATEX_HIDE_INDICES is set to YES then doxygen will not
# include the index chapters (such as File Index, Compound Index, etc.)
# in the output.
LATEX_HIDE_INDICES = NO
#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------
# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
# The RTF output is optimized for Word 97 and may not look very pretty with
# other RTF readers or editors.
GENERATE_RTF = NO
# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `rtf' will be used as the default path.
RTF_OUTPUT = rtf
# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
# RTF documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_RTF = NO
# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
# will contain hyperlink fields. The RTF file will
# contain links (just like the HTML output) instead of page references.
# This makes the output suitable for online browsing using WORD or other
# programs which support those fields.
# Note: wordpad (write) and others do not support links.
RTF_HYPERLINKS = NO
# Load stylesheet definitions from file. Syntax is similar to doxygen's
# config file, i.e. a series of assignments. You only have to provide
# replacements, missing definitions are set to their default value.
RTF_STYLESHEET_FILE =
# Set optional variables used in the generation of an rtf document.
# Syntax is similar to doxygen's config file.
RTF_EXTENSIONS_FILE =
#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------
# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
# generate man pages
GENERATE_MAN = NO
# The MAN_OUTPUT tag is used to specify where the man pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `man' will be used as the default path.
MAN_OUTPUT = man
# The MAN_EXTENSION tag determines the extension that is added to
# the generated man pages (default is the subroutine's section .3)
MAN_EXTENSION = .3
# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.
MAN_LINKS = NO
#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------
# If the GENERATE_XML tag is set to YES Doxygen will
# generate an XML file that captures the structure of
# the code including all documentation.
GENERATE_XML = NO
# The XML_OUTPUT tag is used to specify where the XML pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `xml' will be used as the default path.
XML_OUTPUT = xml
# The XML_SCHEMA tag can be used to specify an XML schema,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_SCHEMA =
# The XML_DTD tag can be used to specify an XML DTD,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_DTD =
# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
# dump the program listings (including syntax highlighting
# and cross-referencing information) to the XML output. Note that
# enabling this will significantly increase the size of the XML output.
XML_PROGRAMLISTING = YES
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
# generate an AutoGen Definitions (see autogen.sf.net) file
# that captures the structure of the code including all
# documentation. Note that this feature is still experimental
# and incomplete at the moment.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# configuration options related to the Perl module output
#---------------------------------------------------------------------------
# If the GENERATE_PERLMOD tag is set to YES Doxygen will
# generate a Perl module file that captures the structure of
# the code including all documentation. Note that this
# feature is still experimental and incomplete at the
# moment.
GENERATE_PERLMOD = NO
# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
# the necessary Makefile rules, Perl scripts and LaTeX code to be able
# to generate PDF and DVI output from the Perl module output.
PERLMOD_LATEX = NO
# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
# nicely formatted so it can be parsed by a human reader. This is useful
# if you want to understand what is going on. On the other hand, if this
# tag is set to NO the size of the Perl module output will be much smaller
# and Perl will parse it just the same.
PERLMOD_PRETTY = YES
# The names of the make variables in the generated doxyrules.make file
# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
# This is useful so different doxyrules.make files included by the same
# Makefile don't overwrite each other's variables.
PERLMOD_MAKEVAR_PREFIX =
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
# evaluate all C-preprocessor directives found in the sources and include
# files.
ENABLE_PREPROCESSING = YES
# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
# names in the source code. If set to NO (the default) only conditional
# compilation will be performed. Macro expansion can be done in a controlled
# way by setting EXPAND_ONLY_PREDEF to YES.
MACRO_EXPANSION = NO
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
# then the macro expansion is limited to the macros specified with the
# PREDEFINED and EXPAND_AS_DEFINED tags.
EXPAND_ONLY_PREDEF = NO
# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
# in the INCLUDE_PATH (see below) will be search if a #include is found.
SEARCH_INCLUDES = YES
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by
# the preprocessor.
INCLUDE_PATH =
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
# patterns (like *.h and *.hpp) to filter out the header-files in the
# directories. If left blank, the patterns specified with FILE_PATTERNS will
# be used.
INCLUDE_FILE_PATTERNS =
# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.
PREDEFINED =
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
# this tag can be used to specify a list of macro names that should be expanded.
# The macro definition that is found in the sources will be used.
# Use the PREDEFINED tag if you want to use a different macro definition.
EXPAND_AS_DEFINED =
# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
# doxygen's preprocessor will remove all function-like macros that are alone
# on a line, have an all uppercase name, and do not end with a semicolon. Such
# function macros are typically used for boiler-plate code, and will confuse
# the parser if not removed.
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration::additions related to external references
#---------------------------------------------------------------------------
# The TAGFILES option can be used to specify one or more tagfiles.
# Optionally an initial location of the external documentation
# can be added for each tagfile. The format of a tag file without
# this location is as follows:
# TAGFILES = file1 file2 ...
# Adding location for the tag files is done as follows:
# TAGFILES = file1=loc1 "file2 = loc2" ...
# where "loc1" and "loc2" can be relative or absolute paths or
# URLs. If a location is present for each tag, the installdox tool
# does not have to be run to correct the links.
# Note that each tag file must have a unique name
# (where the name does NOT include the path)
# If a tag file is not located in the directory in which doxygen
# is run, you must also specify the path to the tagfile here.
TAGFILES =
# When a file name is specified after GENERATE_TAGFILE, doxygen will create
# a tag file that is based on the input files it reads.
GENERATE_TAGFILE =
# If the ALLEXTERNALS tag is set to YES all external classes will be listed
# in the class index. If set to NO only the inherited external classes
# will be listed.
ALLEXTERNALS = NO
# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will
# be listed.
EXTERNAL_GROUPS = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of `which perl').
PERL_PATH = /usr/bin/perl
#---------------------------------------------------------------------------
# Configuration options related to the dot tool
#---------------------------------------------------------------------------
# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
# or super classes. Setting the tag to NO turns the diagrams off. Note that
# this option is superseded by the HAVE_DOT option below. This is only a
# fallback. It is recommended to install and use dot, since it yields more
# powerful graphs.
CLASS_DIAGRAMS = YES
# You can define message sequence charts within doxygen comments using the \msc
# command. Doxygen will then run the mscgen tool (see http://www.mcternan.me.uk/mscgen/) to
# produce the chart and insert it in the documentation. The MSCGEN_PATH tag allows you to
# specify the directory where the mscgen tool resides. If left empty the tool is assumed to
# be found in the default search path.
MSCGEN_PATH =
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz, a graph visualization
# toolkit from AT&T and Lucent Bell Labs. The other options in this section
# have no effect if this option is set to NO (the default)
HAVE_DOT = YES
# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect inheritance relations. Setting this tag to YES will force the
# the CLASS_DIAGRAMS tag to NO.
CLASS_GRAPH = YES
# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect implementation dependencies (inheritance, containment, and
# class references variables) of the class with other documented classes.
COLLABORATION_GRAPH = YES
# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for groups, showing the direct groups dependencies
GROUP_GRAPHS = YES
# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
# collaboration diagrams in a style similar to the OMG's Unified Modeling
# Language.
UML_LOOK = YES
# If set to YES, the inheritance and collaboration graphs will show the
# relations between templates and their instances.
TEMPLATE_RELATIONS = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
# tags are set to YES then doxygen will generate a graph for each documented
# file showing the direct and indirect include dependencies of the file with
# other documented files.
INCLUDE_GRAPH = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
# documented header file showing the documented files that directly or
# indirectly include this file.
INCLUDED_BY_GRAPH = YES
# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
# generate a call dependency graph for every global function or class method.
# Note that enabling this option will significantly increase the time of a run.
# So in most cases it will be better to enable call graphs for selected
# functions only using the \callgraph command.
CALL_GRAPH = YES
# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then doxygen will
# generate a caller dependency graph for every global function or class method.
# Note that enabling this option will significantly increase the time of a run.
# So in most cases it will be better to enable caller graphs for selected
# functions only using the \callergraph command.
CALLER_GRAPH = YES
# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
# will graphical hierarchy of all classes instead of a textual one.
GRAPHICAL_HIERARCHY = YES
# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
# then doxygen will show the dependencies a directory has on other directories
# in a graphical way. The dependency relations are determined by the #include
# relations between the files in the directories.
DIRECTORY_GRAPH = YES
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. Possible values are png, jpg, or gif
# If left blank png will be used.
DOT_IMAGE_FORMAT = png
# The tag DOT_PATH can be used to specify the path where the dot tool can be
# found. If left blank, it is assumed the dot tool can be found in the path.
DOT_PATH = "c:\Program Files\Graphviz2.16\bin"
# The DOTFILE_DIRS tag can be used to specify one or more directories that
# contain dot files that are included in the documentation (see the
# \dotfile command).
DOTFILE_DIRS =
# The MAX_DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
# nodes that will be shown in the graph. If the number of nodes in a graph
# becomes larger than this value, doxygen will truncate the graph, which is
# visualized by representing a node as a red box. Note that doxygen will always
# show the root nodes and its direct children regardless of this setting.
DOT_GRAPH_MAX_NODES = 50
# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, which results in a white background.
# Warning: Depending on the platform used, enabling this option may lead to
# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
# read).
DOT_TRANSPARENT = NO
# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10)
# support this, this feature is disabled by default.
DOT_MULTI_TARGETS = NO
# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
# generate a legend page explaining the meaning of the various boxes and
# arrows in the dot generated graphs.
GENERATE_LEGEND = YES
# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
# remove the intermediate dot files that are used to generate
# the various graphs.
DOT_CLEANUP = YES
#---------------------------------------------------------------------------
# Configuration::additions related to the search engine
#---------------------------------------------------------------------------
# The SEARCHENGINE tag specifies whether or not a search engine should be
# used. If set to NO the values of all tags below this one will be ignored.
SEARCHENGINE = NO
liblas-1.7.0+dfsg/doc/lastools.txt 0000644 0001750 0001750 00000005774 11727124362 016714 0 ustar frankie frankie
.. _lastools_liblas:
libLAS' Relationship to `LAStools`_
------------------------------------------------------------------------------
Licensing
..............................................................................
libLAS is available under the terms of the `BSD License`_. Many parts of `LAStools`_,
especially those that are similar to those provided by libLAS, are now
LGPL. See http://www.cs.unc.edu/~isenburg/lastools/download/LICENSE.txt for
specific details on which utilities and libraries are licensed as free software.
Utilities
..............................................................................
Because libLAS' focus is on being a software development library to enable
LAS processing, and not so much a processing library per se, libLAS *did*
re-implement many of the `LAStools`_ :ref:`command-line utilities `
to provide utility and test the functionality of the library. libLAS' port
of these utilities will always lag LAStools implementations, however, and if
you are looking for the latest and greatest in functionality, you should
look there. The port that libLAS contains of the LAStools has been blessed
by the Isenburg and Shewchuk as BSD-licensed.
Additionally, the libLAS version of the LAStools utilities are no longer
command-line compatible. So while they may have some common heritage, and
the two packages copy each other in terms of features and behaviors, they
are now quite divergent.
Which one to use for what
..............................................................................
Use libLAS for:
* Manipulating LAS files directly in C, C++, Python, .NET, and Ruby (caveats
apply)
* Embedding LAS read/write support in your own commercial software
* Plucking out first/last returns (:ref:`las2las` or do it yourself with
libLAS' programatic API)
* Reclassifying point data with your own algorithm(s)
* Decimating data (simple thinning by removing a given number of points)
* Converting data between formats (1.0 <-> 1.2, etc)
* Converting data to `OGR-writeable`_ formats
* Adding coordinate system info to an LAS file
* Reprojecting data from one coordinate system to another (vertical datum
transformation included soon!)
* Spatially indexing data for fast bounds lookup
* Working in a commercial setting
Use LAStools for:
* Creating DEMs from LAS data
* Creating TINs from LAS data
* Calculating convex or concave hulls from LAS data
* Generating contours from LAS data
* Advanced LAS command-line attribute processing (`las2las
`__)
* Plucking out first/last returns (:ref:`las2las` or yourself with a
programatic API)
* Decimating data (thinning by removing points within a grid or window)
* Converting data between formats (1.0 <-> 1.2, etc)
* Working in an academic or non-commercial setting
.. _`LAStools`: http://www.cs.unc.edu/~isenburg/lastools/
.. _`BSD license`: http://www.opensource.org/licenses/bsd-license.php
.. _`OGR-writeable`: http://gdal.org/ogr/ogr_formats.html liblas-1.7.0+dfsg/doc/_templates/ 0000755 0001750 0001750 00000000000 11727124362 016433 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/_templates/layout.html 0000644 0001750 0001750 00000003445 11727124362 020644 0 ustar frankie frankie {% extends "!layout.html" %}
{% block extrahead %}
{{ super() }}
{% endblock %}
{% block relbar1 %}
liblas-1.7.0+dfsg/doc/conf.py 0000644 0001750 0001750 00000016264 11727124362 015606 0 ustar frankie frankie # -*- coding: utf-8 -*-
#
# libLAS documentation build configuration file, created by
# sphinx-quickstart on Mon Mar 30 11:04:44 2009.
#
# This file is execfile()d with the current directory set to its containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys, os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
sys.path.append(os.path.abspath('../python'))
# -- General configuration -----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = [ 'sphinx.ext.autodoc',
'sphinx.ext.doctest',
'sphinx.ext.intersphinx',
'sphinx.ext.todo',
'sphinx.ext.ifconfig',
'rst2pdf.pdfbuilder',
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.txt'
# The encoding of source files.
#source_encoding = 'utf-8'
# The master toctree document.
master_doc = 'docs'
# General information about the project.
project = u'libLAS'
copyright = u'2010, Howard Butler, Mateusz Loskot and others'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
def read_version(filename):
# oh yes, this is brittle
data = open(filename).readlines()
major = 'LIBLAS_VERSION_MAJOR'
minor = 'LIBLAS_VERSION_MINOR'
patch = 'LIBLAS_VERSION_PATCH'
for line in data:
if str(major) in line:
line = line.replace('SET('+major+' ', '')
line = line.replace(')','')
line = line.replace('"','')
maj = line.strip()
if str(minor) in line:
line = line.replace('SET('+minor+' ', '')
line = line.replace(')','')
line = line.replace('"','')
min = line.strip()
if str(patch) in line:
line = line.replace('SET('+patch+' ', '')
line = line.replace(')','')
line = line.replace('"','')
pat = line.strip()
return '%s.%s.%s'%(maj, min, pat)
version = read_version('../CMakeLists.txt')
# The full version, including alpha/beta/rc tags.
release = version
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of documents that shouldn't be included in the build.
#unused_docs = []
# List of directories, relative to source directory, that shouldn't be searched
# for source files.
exclude_trees = ['build']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. Major themes that come with
# Sphinx are currently 'default' and 'sphinxdoc'.
html_theme = 'default'
html_style = 'sphinx.css'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {'rightsidebar':True}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# " v documentation".
html_title = 'liblas.org'
# A shorter title for the navigation bar. Default is the same as html_title.
html_short_title = 'Documentation'
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
html_sidebars = {
'**': ['globaltoc.html', 'sourcelink.html', 'searchbox.html'],
"index":["indexsidebar.html",'searchbox.html'],
"docs":['globaltoc.html',"indexsidebar.html",'searchbox.html']}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_use_modindex = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = ''
# Output file base name for HTML help builder.
htmlhelp_basename = 'libLASdoc'
breathe_projects = {
"liblas":"/Users/hobu/hg/liblas-cmake/doc/api/xml"
}
breathe_default_project = "liblas"
pdf_documents = [
('docs', u'libLAS', u'libLAS Documentation', u'The libLAS Team'),
]
# A comma-separated list of custom stylesheets. Example:
pdf_stylesheets = ['liblas']
pdf_language = "en_US"
pdf_fit_mode = "overflow"
pdf_use_toc = True
pdf_splittables = True
pdf_appendices = []
pdf_baseurl = 'http://liblas.org'
# Example configuration for intersphinx: refer to the Python standard library.
intersphinx_mapping = {'http://docs.python.org/': None}
liblas-1.7.0+dfsg/doc/Makefile 0000644 0001750 0001750 00000011456 11727124362 015745 0 ustar frankie frankie # Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext pdf
help:
@echo "Please use \`make ' where is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
clean:
-rm -rf $(BUILDDIR)/*
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/df.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/df.qhc"
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/df"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/df"
@echo "# devhelp"
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
make -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
man:
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
gettext:
$(SPHINXBUILD) -b gettext $(ALLSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
pdf:
$(SPHINXBUILD) -b pdf $(ALLSPHINXOPTS) build/pdf
@echo
@echo "Build finished; now you can process the PDF files." liblas-1.7.0+dfsg/doc/osgeo4w.txt 0000644 0001750 0001750 00000004444 11727124362 016434 0 ustar frankie frankie .. _osgeo4w_install:
******************************************************************************
Installing libLAS using OSGeo4W
******************************************************************************
:Author: Howard Butler
:Contact: hobu.inc at gmail dot com
:Date: 2/17/2011
This document describes how to install libLAS and its related :ref:`utilities `
using `OSGeo4W`_. `OSGeo4W`_ is a collection of Windows packages that uses the `Cygwin`_
installer to manage package dependencies. libLAS in its fully-featured form
requires a number of dependencies, and these are all available via the OSGeo4W installer.
1) Obtain the `OSGeo4W Installer`_. It is an executable that will run and
automatically download and install selected packages.
.. note::
OSGeo4W does not currently provide any options to install in any other
locations besides ``C:\osgeo4w``.
.. `OSGeo4W Installer`: http://download.osgeo.org/osgeo4w/osgeo4w-setup.exe
2) Choose "Advanced Install".
.. note::
libLAS is not part of any default package grouping, and it must be
installed individually.
.. figure:: ./images/osgeo4w-advanced-install.png
:alt: Choosing the "Advanced" OSGeo4W install
3) Select liblas from the "Commandline_Utilities" dropdown
.. figure:: ./images/osgeo4w-select-liblas.png
:alt: Selecting libLAS to install from the "Advanced" list tree
4) *Optional*: Select liblas-python from the "Libs" dropdown
5) Run the ``OSGeo4W Shell`` from Start-Programs-OSGeo4W
6) Execute the ``liblas`` command to set environment variables necessary to
support full libLAS operations.
.. note::
libLAS needs a number of environment variables set to do its business,
most notably the ones related to `GDAL`_ and `Proj.4`_ for
reprojection and coordinate system description.
.. figure:: ./images/osgeo4w-run-liblas-shell.png
:alt: Running the libLAS subshell from OSGeo4W
7) Test ``lasinfo`` with your own data
.. figure:: ./images/osgeo4w-lasinfo-output.png
:alt: Running lasinfo
.. _`OSGeo4W Installer`: http://download.osgeo.org/osgeo4w/osgeo4w-setup.exe
.. _`OSGeo4W`: http://trac.osgeo.org/osgeo4w/
.. _`Cygwin`: http://www.cygwin.com/
.. _`GDAL`: http://www.gdal.org
.. _`Proj.4`: http://trac.osgeo.org/proj/ liblas-1.7.0+dfsg/doc/faq.txt 0000644 0001750 0001750 00000007376 11727124362 015623 0 ustar frankie frankie .. _faq:
******************************************************************************
FAQ
******************************************************************************
This page is dedicated to `Frequently Asked Questions
`_ about libLAS library and ASPRS LAS Format
Standard.
What software is using libLAS?
--------------------------------------------------------------------------------
A number of commercial and open source softwares utilize libLAS for their LAS
reading and writing support. Additionally, a number of organizations also use
libLAS for a variety of tasks. See `here
`__ for more details.
What software supports ASPRS LAS Format?
--------------------------------------------------------------------------------
There is a number of geospatial software packages that support read/write of
ASPRS LAS Format. Popular software is listed on the `Software
`__ Wiki page.
How does ASPRS LAS Format handle endianness?
--------------------------------------------------------------------------------
According to the LAS Format Standard, all data is stored in `little-endian
`_ format. The implication is that on
little-endian architectures multi-byte data of LAS file can be read (or write)
directly and bytes reordering is not required. On big-endian machines,
however, bytes of multi-byte data must reordered between big-endian and
little-endian format.
Does libLAS support LAS 2.0?
--------------------------------------------------------------------------------
Not at this time. We hope to support as much of 2.0 when the specification
stabilizes and there are enough softwares and implementations out there to
base the work on. The LAS 2.0 specification is a whole-scale rewrite of the
LAS specification, and its implementation will be challenging within libLAS.
Does libLAS support LAS 1.3?
--------------------------------------------------------------------------------
Not at this time. Waveform data and software models to support waveform models
within libLAS have not yet been developed. libLAS 1.6 supports reading point
data from LAS 1.3 files, but waveform data is not supported.
How can I remove points classified as ground from LAS files?
--------------------------------------------------------------------------------
Use the :ref:`las2las ` utility to generate a new file with the
points removed::
las2las input.las output.las --drop-classes 2
How can I get past the linking error when building svn trunk on OS X 10.4?
--------------------------------------------------------------------------------
::
ld: multiple definitions of symbol ___divdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_divdi3.o) private external definition of ___divdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_divdi3_s.o) definition of ___divdi3
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_udivdi3.o) private external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_udivdi3_s.o) definition of ___udivdi3
ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3
/usr/bin/libtool: internal link edit command failed
OS X 10.4's XCode has an extremely old automake/autoconf/libtool stack, and without upgrading those,
you'll have to stick to building libLAS from releases.
liblas-1.7.0+dfsg/doc/compilation.txt 0000644 0001750 0001750 00000055465 11727124362 017374 0 ustar frankie frankie .. _compilation:
******************************************************************************
Compilation
******************************************************************************
.. contents::
:depth: 3
:backlinks: none
:Author: Mateusz Loskot
:Contact: mateusz at loskot dot net
:Author: Howard Butler
:Contact: hobu.inc at gmail dot com
.. warning::
This document is only for the 1.6 libLAS release. Unfortunately,
there is no documentation for building earlier libLAS releases at this time, though
it is a straightforward `Autoconf`_ setup for unix and nmake files for
windows.
As of libLAS 1.6, `CMake`_ 2.8.1+ is the prescribed tool for building
libLAS from source as well as running unit tests. `CMake`_ is a cross-platform
build system that provides a number of benefits, and its usage ensures a
single, up-to-date build system for all libLAS-supported operating systems
and compiler platforms.
Like a combination of autoconf/autotools, except that it actually works on
Windows (and works without eye-stabbing pain in general), `CMake`_ is somewhat
of a meta-building tool. It can be used to generate MSVC project files, GNU
Makefiles, NMake files for MSVC, XCode projects on Mac OS X, and Eclipse
projects (as well as many others). This functionality allows the libLAS project
to avoid maintaining these build options by hand and target a single configuration
and build platform.
This tutorial will describe how to build libLAS using CMake on both a
Unix platform and a Windows platform.
.. note::
The only supported build environment libLAS moving forward from the 1.6
release is `CMake`_. `Autoconf`_ configuration will be phased out and will
no longer be updated after the 1.6 release.
.. _prerequisites:
Prerequisites
..............................................................................
In addition to `CMake`_ 2.8.1+, you also need a C/C++ compiler. The
following compilers are known to work:
* MSVC 2003 (VC 7.1) (not all optional libraries work with 2003)
* MSVC 2005 (VC 8.0)
* MSVC 2008 (VC 9.0)
* MSVC 2010
* GCC 4.0
* GCC 4.2
* LLVM 4.8/Clang 2.8
`Boost`_
------------------------------------------------------------------------------
`Boost`_ is required to build libLAS 1.6. Set ``Boost_INCLUDE_DIR`` if
CMake cannot find it in a default location. Additionally, set ``Boost_LIBRARY_DIRS``
if it cannot find your libraries.
.. warning::
You need Boost version 1.38.0 or higher to build libLAS 1.6.
.. note::
If you are building on Windows, http://www.boostpro.com/download/ has an
excellent installer. The boost installer defaults are not enough, however,
and you will need to scroll down and select "Boost ProgramOptions", "Boost Thread", and
"Boost Serialization" components, and select static + multithreaded as the
types. If you want to link in a different way, you will have to change
your CMake cache variables ``Boost_USE_STATIC_LIBS`` and ``Boost_USE_MULTITHREADED``
accordingly.
.. figure:: ./images/boostpro-options.png
:alt: Selecting program_options with the Boostpro.com installer
.. _optional_libraries:
Optional libraries
..............................................................................
The base libLAS library can work without optional libraries to read and write
LAS files, but linking in libraries like `GDAL`_, and `libgeotiff`_ will
provide a boost in functionality to libLAS. libLAS linkage of GDAL and
libgeotiff enhances spatial coordinate system description and provides data
reprojection support. By linking `OCI`_ with the `Oracle Instant Client`_,
libLAS can be used to load LAS data into `Oracle Point Cloud`_ -enabled Oracle
tables.
Building these libraries is beyond the scope of this document, but all except
`OCI`_ can be built from source and installed at your leisure.
`GDAL`_
------------------------------------------------------------------------------
Obtain `GDAL`_ via whatever method is convenient. Linux platforms such as
`Debian`_ have `DebianGIS`_, Mac OS X has the `KyngChaos`_ software frameworks,
and Windows has the `OSGeo4W`_ platform.
* GDAL 1.7+ is required.
.. note::
If you are using `OSGeo4W`_ as your provider of GDAL, you must use the
``gdal-dev`` package, which is GDAL 1.8 as of 11/19/2010.
`libgeotiff`_
------------------------------------------------------------------------------
Obtain `libgeotiff`_ from the same place you got `GDAL`_.
* libgeotiff 1.3.0+ is required
.. note::
`GDAL` surreptitiously embeds a copy of `libgeotiff`_ in its library build
but there is no way for you to know this. In addition to embedding
libgeotiff, it also strips away the library symbols that libLAS needs,
meaning that libLAS can't simply link against `GDAL`_. If you are
building both of these libraries yourself, make sure you build GDAL
using the "External libgeotiff" option, which will prevent the
insanity that can ensue on some platforms. `OSGeo4W`_ users, including
those using that platform to link and build libLAS themselves, do
not need to worry about this issue.
`OCI`_
------------------------------------------------------------------------------
Obtain the `Oracle Instant Client`_ and install in a location on your system.
Be sure to install both the "Basic" and the "SDK" modules. Set your
``ORACLE_HOME`` environment variable system- or user-wide to point to this
location so the CMake configuration can find your install.
.. warning::
`OCI`_'s libraries are inconsistently named. You may need to create
symbolic links for some library names in order for the `CMake`_ to find
them::
cd $ORACLE_HOME
ln -s libocci.so.11.1 libocci.so
ln -s libclntsh.so.11.1 libclntsh.so
ln -s libociei.so.11.1 libociei.so
.. note::
MSVC should only require the oci.lib and oci.dll library and dlls.
* Oracle 11g is recommended, but OCI for 10g will work.
.. _`libgeotiff`: http://www.remotesensing.org/geotiff/geotiff.html
.. _`7/28/2008`: http://lists.maptools.org/pipermail/geotiff/2008-July/000501.html
.. _`proj.4`: http://proj.maptools.org/
.. _`GDAL`: http://www.gdal.org
.. _`Oracle Instant Client`: http://www.oracle.com/technology/tech/oci/instantclient/index.html
.. _`OCI`: http://www.oracle.com/technology/tech/oci/index.html
.. _`R-tree`: http://en.wikipedia.org/wiki/R-tree
.. _`Oracle Point Cloud`: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_pc_pkg_ref.htm
.. _`DebianGIS`: http://wiki.debian.org/DebianGis
.. _`Debian`: http://www.debian.org
.. _`KyngChaos`: http://www.kyngchaos.com/software/unixport
.. _`OSGeo4W`: http://trac.osgeo.org/osgeo4w/
.. _`libtiff`: http://remotesensing.org/libtiff/
Using "Unix Makefiles" on Linux
..............................................................................
Get the source code
------------------------------------------------------------------------------
See :ref:`source` for how to obtain the latest development version or visit
:ref:`download` to get the latest released version.
Prepare a build directory
------------------------------------------------------------------------------
CMake allows you to generate different builders for a project, and in this
example, we are going to generate a "Unix Makefiles" builder
for libLAS on Mac OS X.
::
$ cd liblas
$ mkdir makefiles
$ cd makefiles
Configure base library
------------------------------------------------------------------------------
Configure the basic core library for the "Unix Makefiles" target:
::
$ cmake -G "Unix Makefiles" ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Enable libLAS utilities to build - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/hobu/hg/liblas-cmake/makefiles
Issue the `make` command
------------------------------------------------------------------------------
This will build a base build of the library, with no extra libraries being
configured.
::
$ make
-- Enable libLAS utilities to build - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/hobu/hg/liblas-cmake/makefiles
Scanning dependencies of target las
[ 3%] Building CXX object src/CMakeFiles/las.dir/lasclassification.cpp.o
...
[ 60%] Building CXX object src/CMakeFiles/las.dir/detail/writer/writer.cpp.o
Linking CXX static library ../bin/Debug/liblas.a
[ 60%] Built target las
Scanning dependencies of target las_c
[ 63%] Building CXX object src/CMakeFiles/las_c.dir/las_c_api.cpp.o
Linking CXX shared library ../bin/Debug/liblas_c.dylib
[ 63%] Built target las_c
Scanning dependencies of target las2las
...
[100%] Built target txt2las
.. _make_install:
Run ``make install`` and test your installation with a :ref:`lasinfo` command
------------------------------------------------------------------------------
``make install`` will install the :ref:`utilities ` in the location
that was specified for 'CMAKE_INSTALL_PREFIX'. Once installed, ensure that
you can run lasinfo.
::
$ lasinfo ../test/data/TO_core_last_clip.las
---------------------------------------------------------
Header Summary
---------------------------------------------------------
File Name: ../test/data/TO_core_last_clip.las
Version: 1.0
Source ID: 0
Reserved: 0
Project ID/GUID: '00000000-0000-0000-0000-000000000000'
System Identifier: ''
Generating Software: 'TerraScan'
File Creation Day/Year: 0/0
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 213093
Number of Points by Return 128621 84472 0 0 0
Scale Factor X Y Z 0.01 0.01 0.01
Offset X Y Z -0.000000 -0.000000 -0.000000
Min X Y Z 630250.000000 4834500.000000 46.830000
Max X Y Z 630500.000000 4834750.000000 170.650000
Spatial Reference
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
End_Of_Tags.
Keyed_Information:
End_Of_Keys.
End_Of_Geotiff.
---------------------------------------------------------
Point Inspection Summary
---------------------------------------------------------
Header Point Count: 213093
Actual Point Count: 213093
Minimum and Maximum Attributes (min,max)
---------------------------------------------------------
Min X,Y,Z: 630250.000000,4834500.000000,46.830000
Max X,Y,Z: 630500.000000,4834750.000000,170.650000
Bounding Box: 630250.00,4834500.00,630500.00,4834750.00
Time: 413162.560400,414095.322000
Return Number: 1,2
Return Count: 1,2
Flightline Edge: 0,0
Intensity: 10,50200
Scan Direction Flag: 0,0
Scan Angle Rank: 0,0
Classification: 1,1
Point Source Id: 0,0
Minimum Color: 0 0 0
Maximum Color: 0 0 0
Number of Points by Return
---------------------------------------------------------
(0) 128621 (1) 84472 (2) 0 (3) 0 (4) 0
Total Points: 213093
Number of Returns by Pulse
---------------------------------------------------------
(1) 128621 (2) 84472 (3) 0 (4) 0 (5) 0 (6) 0 (7) 0
Total Pulses: 213093
Point Classifications
---------------------------------------------------------
213093 Unclassified (1)
.. _configure_optional_libraries:
Configure your `Optional Libraries`_.
------------------------------------------------------------------------------
By checking the "on" button for each, CMake may find your installations of
these libraries, but in case it does not, set the following variables,
substituting accordingly, to values that match your system layout.
.. csv-table::
"`GDAL`_","GDAL_CONFIG", "/usr/local/bin/gdal-config"
"","GDAL_INCLUDE_DIR", "/usr/local/include"
"","GDAL_LIBRARY", "/usr/local/lib/libgdal.so"
"`libgeotiff`_","GEOTIFF_INCLUDE_DIR","/usr/local/include"
"","GEOTIFF_LIBRARY","/usr/local/lib/libgeotiff.so"
"`OCI`_","ORACLE_INCLUDE_DIR","/home/oracle/sdk/include"
"","ORACLE_NNZ_LIBRARY","/home/oracle/libnnz10.so"
"","ORACLE_OCCI_LIBRARY","/home/oracle/libocci.so"
"","ORACLE_OCIEI_LIBRARY","/home/oracle/libociei.so"
"","ORACLE_OCI_LIBRARY","/home/oracle/libclntsh.so"
CCMake and cmake-gui
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While `CMake`_ can be run from the command-line, and this is the preferred
way for many individuals, it can be much easier to run CMake from a GUI.
Now that we have a basic library building, we will use CMake's GUIs to
help us configure the rest of the optional components of the library. Run
``ccmake ../`` for the `Curses`_ interface or ``cmake-gui ../`` for a GUI
version.
.. figure:: ./images/ccmake-osx-start.png
:alt: Running CCMake in OS X
Running the `Curses`_ `CMake`_ interface. This interface is available to
all unix-like operating systems.
.. note::
If your arrow keys are not working with in CCMake, use CTRL-N and
CTRL-P to move back and forth between the options.
.. figure:: ./images/cmake-gui-osx-start.png
:alt: Running cmake-gui in OS X
Running the cmake-gui `CMake`_ interface. This interface is available
on Linux, Windows, and Mac OS X.
Build and install
------------------------------------------------------------------------------
Once you have configured your additional libraries, you can install the
software. The main pieces that will be installed are:
* libLAS headers (typically in a location ./include/liblas/...)
* libLAS C++ (liblas.a or liblas.so) library
* libLAS C (liblas_c.a or liblas_c.so) library
* :ref:`Utility ` programs
::
make install
Using "XCode" on OS X
..............................................................................
Get the source code
------------------------------------------------------------------------------
See :ref:`source` for how to obtain the latest development version or visit
:ref:`download` to get the latest released version.
Prepare a build directory
------------------------------------------------------------------------------
CMake allows you to generate different builders for a project, and in this
example, we are going to generate an "Xcode" builder for libLAS on Mac OS X.
Additionally, we're going to use an alternative compiler -- `LLVM`_ -- which
under certain situations can produce much faster code on Mac OS X.
::
$ export CC=/usr/bin/llvm-gcc
$ export CXX=/usr/bin/llvm-g++
$ cd liblas
$ mkdir xcode
$ cd xcode/
Configure base library
------------------------------------------------------------------------------
Configure the basic core library for the Xcode build:
::
$ cmake -G "Xcode" ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Check for working C compiler: /usr/bin/llvm-gcc
-- Check for working C compiler: /usr/bin/llvm-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Check for working CXX compiler: /usr/bin/llvm-g++
-- Check for working CXX compiler: /usr/bin/llvm-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Enable libLAS utilities to build - done
-- Enable libLAS unit tests to build - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/hobu/hg/liblas-cmake/xcode
Alternatively, if you have `KyngChaos`_ frameworks for `GDAL`_ and `libgeotiff`_ installed, you can provide locations for those as part of your ``cmake`` invocation:
::
$ cmake -G "Xcode" \
-D GDAL_CONFIG=/Library/Frameworks/GDAL.framework/Programs/gdal-config \
-D GEOTIFF_INCLUDE_DIR=/Library/Frameworks/UnixImageIO.framework/unix/include \
-D GEOTIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib \
..
::
$ open libLAS.xcodeproj/
.. figure:: ./images/xcode-start.png
:alt: Building libLAS using the XCode project
Set default command for XCode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Set the default executable for the project to be ``lasinfo`` by opening the
"Executables" tree, choosing "lasinfo," and clicking the bubble next to
the "Executable name" in the right-hand panel.
.. figure:: ./images/xcode-set-default-executable.png
:alt: Setting the default executable
Set arguments for :ref:`lasinfo`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Set the arguments for :ref:`lasinfo` so it can be run from within XCode. We
use the ${PROJECT_DIR} environment variable to be able to tell lasinfo the
location of our test file. This is similar to the :ref:`same command
` above in the "Unix Makefiles" section.
.. figure:: ./images/xcode-lasinfo-arguments.png
:alt: Setting the arguments for lasinfo
Build and run the :ref:`lasinfo` command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Open the console by pressing CMD-SHIFT-R or by navigating to the Run-Console
menu and press the `Build and Run` button.
.. figure:: ./images/xcode-lasinfo-output.png
:alt: lasinfo output in XCode
Configure `Optional Libraries`_
------------------------------------------------------------------------------
As :ref:`before `, use ``ccmake ../`` or ``cmake-gui ../`` to
configure your :ref:`optional_libraries`.
.. figure:: ./images/cmake-gui-osx-configured.png
:alt: Configuring optional libraries with CMake GUI
Configuring `Optional Libraries`_ with CMake GUI
Using "Visual Studio 9 2008" on Windows
..............................................................................
Get the source code
------------------------------------------------------------------------------
See :ref:`source` for how to obtain the latest development version or visit
:ref:`download` to get the latest released version.
.. _msvc_prerequisites:
Prerequisites
------------------------------------------------------------------------------
* Ensure that you have `CMake 2.8.0+`_ installed on your system.
* Install `OSGeo4W`_ on your system to get `Optional Libraries`_ in
pre-compiled form. You can build these from source yourself, but it is
much more convenient to get them from OSGeo4W.
* gdal-dev
* libtiff
* libgeotiff
.. figure:: ./images/windows-osgeo4w-advanced-install.png
:alt: OSGeo4W installation
Choose the "Advanced install" to be able to pick the libraries
and their headers that you need.
.. figure:: ./images/windows-osgeo4w-choosing-packages.png
:alt: Choosing libraries
Open up the "Libs" tree and choose the libraries you need
Run ``cmake-gui.exe``
------------------------------------------------------------------------------
* Run ``cmake-gui.exe`` from a "Visual Studio 2008 Command Prompt"
::
cd d:\\liblas
cmake-gui .
.. figure:: ./images/windows-cmake-start.png
:alt: Starting CMake
Upon opening cmake-gui, nothing will be configured.
.. note::
The Visual Studio Prompt can be found by navigating through the start
bar to "Start" -- "Microsoft Visual Studio 2008" -- "Visual Studio
Tools " -- "Visual Studio 2008 Command Prompt". This command prompt
sets a number of environment variables necessary for Visual Studio to
run, and `CMake`_ must have these variables set in order for it to
work properly.
.. figure:: ./images/windows-command-prompt.png
:alt: Visual Studio Command prompt
.. figure:: ./images/windows-cmake-generator-visual-studio-9.png
:alt: Generating a project
* Click "Configure" and a window will pop up asking what type of build to
generate. Choose "Visual Studio 9 2008."
* Click "Generate" and a "libLAS.sln" file will be in ``d:\\liblas``
* Open and build the project
.. image:: ./images/windows-msvc-build.png
Configure your `Optional Libraries`_.
------------------------------------------------------------------------------
By checking the "on" button for each, CMake may find your installations of
these libraries, but in case it does not, set the following variables,
substituting accordingly, to values that match your system layout.
.. note::
If you are building using `OSGeo4W`_ libraries, you must use the "gdal-dev"
version, not the base `GDAL`_ build. libLAS requires GDAL 1.7+ to
operate, and this is provided by the "gdal-dev" `OSGeo4W`_ version.
.. note::
You will need to choose "Advanced View" and select the location of the
libTIFF library explicitly.
.. csv-table::
"`GDAL`_","GDAL_INCLUDE_DIR", "c:\\osgeo4w\\apps\\gdal-dev\\include"
"","GDAL_LIBRARY", "c:\\osgeo4w\\apps\\gdal-dev\\lib\\gdal_i.lib"
"`libgeotiff`_","GEOTIFF_INCLUDE_DIR","c:\\osgeo4w\\include"
"","GEOTIFF_LIBRARY","c:\\osgeo4w\\lib\\geotiff_i.lib"
"`libtiff`_","TIFF_INCLUDE_DIR","c:\\osgeo4w\\include"
"","TIFF_LIBRARY","c:\\osgeo4w\\lib\\libtiff_i.lib"
------------------------------------------------------------------------------
.. _`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
.. _`CDash`: http://www.cdash.org/
.. _`continuous integration`: http://en.wikipedia.org/wiki/Continuous_integration
.. _`libLAS CDash`: http://my.cdash.org/index.php?project=libLAS
.. _`Curses`: http://en.wikipedia.org/wiki/Curses_%28programming_library%29
.. _`Autoconf`: http://www.gnu.org/software/autoconf/
.. _`LLVM`: http://llvm.org/
.. _`OSGeo4W`: http://trac.osgeo.org/osgeo4w/
.. _`Boost`: http://www.boost.org/
liblas-1.7.0+dfsg/doc/make.bat 0000644 0001750 0001750 00000005570 11727124362 015712 0 ustar frankie frankie @ECHO OFF
REM Command file for Sphinx documentation
set SPHINXBUILD=sphinx-build
set ALLSPHINXOPTS=-d build/doctrees %SPHINXOPTS% .
if NOT "%PAPER%" == "" (
set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
)
if "%1" == "" goto help
if "%1" == "help" (
:help
echo.Please use `make ^` where ^ is one of
echo. html to make standalone HTML files
echo. dirhtml to make HTML files named index.html in directories
echo. pickle to make pickle files
echo. json to make JSON files
echo. htmlhelp to make HTML files and a HTML help project
echo. qthelp to make HTML files and a qthelp project
echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter
echo. changes to make an overview over all changed/added/deprecated items
echo. linkcheck to check all external links for integrity
echo. doctest to run all doctests embedded in the documentation if enabled
goto end
)
if "%1" == "clean" (
for /d %%i in (build\*) do rmdir /q /s %%i
del /q /s build\*
goto end
)
if "%1" == "html" (
%SPHINXBUILD% -b html %ALLSPHINXOPTS% build/html
echo.
echo.Build finished. The HTML pages are in build/html.
goto end
)
if "%1" == "dirhtml" (
%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% build/dirhtml
echo.
echo.Build finished. The HTML pages are in build/dirhtml.
goto end
)
if "%1" == "pickle" (
%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% build/pickle
echo.
echo.Build finished; now you can process the pickle files.
goto end
)
if "%1" == "json" (
%SPHINXBUILD% -b json %ALLSPHINXOPTS% build/json
echo.
echo.Build finished; now you can process the JSON files.
goto end
)
if "%1" == "htmlhelp" (
%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% build/htmlhelp
echo.
echo.Build finished; now you can run HTML Help Workshop with the ^
.hhp project file in build/htmlhelp.
goto end
)
if "%1" == "qthelp" (
%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% build/qthelp
echo.
echo.Build finished; now you can run "qcollectiongenerator" with the ^
.qhcp project file in build/qthelp, like this:
echo.^> qcollectiongenerator build\qthelp\libLAS.qhcp
echo.To view the help file:
echo.^> assistant -collectionFile build\qthelp\libLAS.ghc
goto end
)
if "%1" == "latex" (
%SPHINXBUILD% -b latex %ALLSPHINXOPTS% build/latex
echo.
echo.Build finished; the LaTeX files are in build/latex.
goto end
)
if "%1" == "changes" (
%SPHINXBUILD% -b changes %ALLSPHINXOPTS% build/changes
echo.
echo.The overview file is in build/changes.
goto end
)
if "%1" == "linkcheck" (
%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% build/linkcheck
echo.
echo.Link check complete; look for any errors in the above output ^
or in build/linkcheck/output.txt.
goto end
)
if "%1" == "doctest" (
%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% build/doctest
echo.
echo.Testing of doctests in the sources finished, look at the ^
results in build/doctest/output.txt.
goto end
)
:end
liblas-1.7.0+dfsg/doc/liblas.json 0000644 0001750 0001750 00000017437 11727124362 016453 0 ustar frankie frankie pageSetup:
firstTemplate: coverPage
margin-bottom: 8mm
margin-left: 12mm
margin-right: 12mm
margin-top: 8mm
styles:
admonition:
backColor: #EEFFCC
borderColor: #AACC99
borderPadding: 8
borderWidth: 0.5
commands: []
[VALIGN, [0, 0], [-1, -1], TOP]
spaceAfter: 6
spaceBefore: 12
admonition-heading:
backColor: null
borderColor: null
borderPadding: 0
borderWidth: 0
leftIndent: 0
parent: heading3
textColor: black
admonition-title:
backColor: null
borderColor: null
borderPadding: 0
borderWidth: 0
leftIndent: 0
parent: heading3
attribute: parent: bodytext
author:
alignment: TA_CENTER
fontName: stdSansBold
fontSize: 120%
parent: bodytext
centered:
alignment: TA_CENTER
fontName: stdBold
parent: bodytext
class: parent: bodytext
code:
allowOrphans: false
allowWidows: false
backColor: #EEFFCC
borderColor: #AACC99
borderPadding: [6, 0, 0, 4]
borderWidth: 0.3
spaceBefore: 0
confval: parent: bodytext
data: parent: bodytext
desc: {parent: bodytext, spaceBefore: 6}
descclassname: {fontName: stdMono, parent: literal}
descname: {fontName: stdMonoBold, parent: literal}
descparameter: {fontName: stdMono, parent: literal}
desctype: {fontName: stdMono, parent: literal}
directive: parent: bodytext
exception: parent: bodytext
heading:
backColor: #F2F2F2
borderColor: #CCCCCC
borderPadding: [6, 0, 0, 10]
borderWidth: 0.3
fontName: stdSansBold
fontSize: 10
leading: 10
leftIndent: 0
spaceBefore: 16
textColor: #20435C
heading1: fontSize: 200%
heading2: fontSize: 160%
heading3: fontSize: 140%
heading4: fontSize: 120%
heading5: fontSize: 110%
heading6: fontSize: 100%
hlist:
alignment: TA_CENTER
commands: []
[VALIGN, [0, 0], [-1, -1], TOP]
parent: normal
spaceAfter: 0
spaceBefore: 6
method: {fontName: stdSansBold, parent: bodytext}
note:
backColor: #EEEEEE
borderColor: #CCCCCC
parent: admonition
optional: {fontName: stdMonoBold, parent: literal}
pygments-bp: {parent: code, textColor: #007020}
pygments-c: {parent: code, textColor: #808080}
pygments-c1: {parent: code, textColor: #808080}
pygments-cm: {parent: code, textColor: #808080}
pygments-cp: {parent: code, textColor: #507090}
pygments-cs:
fontName: stdMonoBold
parent: code
textColor: #cc0000
pygments-err:
backColor: #F0A0A0
parent: code
textColor: #F00000
pygments-gd: {parent: code, textColor: #A00000}
pygments-ge: {fontName: stdMonoItalic, parent: code}
pygments-gh:
fontName: stdMonoBold
parent: code
textColor: #000080
pygments-gi: {parent: code, textColor: #00A000}
pygments-go: {parent: code, textColor: #808080}
pygments-gp:
fontName: stdMonoBold
parent: code
textColor: #c65d09
pygments-gr: {parent: code, textColor: #FF0000}
pygments-gs: {fontName: stdMonoBold, parent: code}
pygments-gt: {parent: code, textColor: #0040D0}
pygments-gu:
fontName: stdMonoBold
parent: code
textColor: #800080
pygments-hll: {backColor: #ffffcc, parent: code}
pygments-il:
fontName: stdMonoBold
parent: code
textColor: #0000D0
pygments-k:
fontName: stdMonoBold
parent: code
textColor: #008000
pygments-kc:
fontName: stdMonoBold
parent: code
textColor: #008000
pygments-kd:
fontName: stdMonoBold
parent: code
textColor: #008000
pygments-kn:
fontName: stdMonoBold
parent: code
textColor: #008000
pygments-kp:
fontName: stdMonoBold
parent: code
textColor: #003080
pygments-kr:
fontName: stdMonoBold
parent: code
textColor: #008000
pygments-kt:
fontName: stdMonoBold
parent: code
textColor: #303090
pygments-m:
fontName: stdMonoBold
parent: code
textColor: #6000E0
pygments-mf:
fontName: stdMonoBold
parent: code
textColor: #6000E0
pygments-mh:
fontName: stdMonoBold
parent: code
textColor: #005080
pygments-mi:
fontName: stdMonoBold
parent: code
textColor: #0000D0
pygments-mo:
fontName: stdMonoBold
parent: code
textColor: #4000E0
pygments-n-Identifier: parent: code
pygments-na: {parent: code, textColor: #0000C0}
pygments-nb: {parent: code, textColor: #007020}
pygments-nc:
fontName: stdMonoBold
parent: code
textColor: #B00060
pygments-nd:
fontName: stdMonoBold
parent: code
textColor: #505050
pygments-ne:
fontName: stdMonoBold
parent: code
textColor: #F00000
pygments-nf:
fontName: stdMonoBold
parent: code
textColor: #0060B0
pygments-ni:
fontName: stdMonoBold
parent: code
textColor: #800000
pygments-nl:
fontName: stdMonoBold
parent: code
textColor: #907000
pygments-nn:
fontName: stdMonoBold
parent: code
textColor: #0e84b5
pygments-no:
fontName: stdMonoBold
parent: code
textColor: #003060
pygments-nt: {parent: code, textColor: #007000}
pygments-nv: {parent: code, textColor: #906030}
pygments-o: {parent: code, textColor: #303030}
pygments-ow:
fontName: stdMonoBold
parent: code
textColor: #000000
pygments-s: {backColor: #fff0f0, parent: code}
pygments-s1: {backColor: #fff0f0, parent: code}
pygments-s2: {backColor: #fff0f0, parent: code}
pygments-sb: {backColor: #fff0f0, parent: code}
pygments-sc: {parent: code, textColor: #0040D0}
pygments-sd: {parent: code, textColor: #D04020}
pygments-se:
backColor: #fff0f0
fontName: stdMonoBold
parent: code
textColor: #606060
pygments-sh: {backColor: #fff0f0, parent: code}
pygments-si: {backColor: #e0e0e0, parent: code}
pygments-sr:
backColor: #fff0ff
parent: code
textColor: #000000
pygments-ss: {parent: code, textColor: #A06000}
pygments-sx:
backColor: #fff0f0
parent: code
textColor: #D02000
pygments-vc: {parent: code, textColor: #306090}
pygments-vg:
fontName: stdMonoBold
parent: code
textColor: #d07000
pygments-vi: {parent: code, textColor: #3030B0}
pygments-w: {parent: code, textColor: #bbbbbb}
returns: parent: bodytext
role: parent: bodytext
seealso:
backColor: #FFFFCC
borderColor: #FFFF66
parent: admonition
sidebar:
backColor: #EEFFCC
borderColor: #AACC99
borderPadding: 8
borderWidth: 0.5
spaceAfter: 6
spaceBefore: 12
sidebar-subtitle:
backColor: null
borderColor: null
borderPadding: 0
borderWidth: 0
leftIndent: 0
parent: heading4
spaceBefore: 0
sidebar-title:
backColor: null
borderColor: null
borderPadding: 0
borderWidth: 0
leftIndent: 0
parent: heading3
table-heading: {borderWidth: 0, parent: heading}
versionmodified: {fontName: stdItalic, parent: bodytext}
warning:
backColor: #FFE4E4
borderColor: #FF6666
parent: admonition
xref: {fontName: stdMonoBold, parent: code}
liblas-1.7.0+dfsg/doc/development/ 0000755 0001750 0001750 00000000000 11727124362 016620 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/development/rfc/ 0000755 0001750 0001750 00000000000 11727124362 017372 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/development/rfc/index.txt 0000644 0001750 0001750 00000001051 11727124362 021237 0 ustar frankie frankie .. _rfcs:
******************************************************************************
RFCs
******************************************************************************
..............................................................................
RFCs (Request For Comments) are documents describing a new feature or
procedure related to the project. They are used as a focus for discussion
of complex changes, and once agreed upon serve as a specification.
.. toctree::
:maxdepth: 1
rfc_1_verticalcs
rfc_2_spatialreference
liblas-1.7.0+dfsg/doc/development/rfc/rfc_1_verticalcs.txt 0000644 0001750 0001750 00000033647 11727124362 023361 0 ustar frankie frankie ******************************************************************************
libLAS RFC 1: Vertical Coordinate Systems
******************************************************************************
:Author: Frank Warmerdam
:Contact: warmerdam@pobox.com
:Date: 1/6/10
:Status: Implemented
:Version: libLAS 1.3
.. contents::
:depth: 2
This page holds resources to handling of vertical coordinate systems (datums
and units) in LAS files. Traditionally LAS files have not been rigorous with
regard to recording the vertical datum and vertical units. In actual use I
(Frank Warmerdam) have been unable to find any existing LAS files (January
2010) with vertical datum information set, though some do set vertical units
information.
With the support of !LizardTech, I have been asked to extend libLAS to support
reading and writing vertical coordinate system information in LAS files, and
to the extent practical to establish some reference information on "best
practices" with regard to describing vertical coordinate systems in LAS files.
Vertical CS in GeoTIFF
------------------------------------------------------------------------------
The planned approach is to store vertical coordinate system in GeoTIFF tags.
The GeoTIFF specification has always had vertical coordinate system support,
tied to the EPSG codes for vertical coordinate systems and datums. However,
traditionally, the vertical coordinate system support in GeoTIFF has also not
been widely used. So it is hoped that formalization of GeoTIFF tags for
vertical datums in LAS format would also apply for GeoTIFF in general and any
other geotiff oriented formats (GeoJP2 for instance). It is anticipated that
the GeoTIFF representation of a LAS file with a vertical datum set might look
something like this:
::
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_15N
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
VerticalCSTypeGeoKey (Short,1): Unknown-5701
VerticalCitationGeoKey (Ascii,7): "Newlyn"
VerticalDatumGeoKey (Short,1): Unknown-5101
VerticalUnitsGeoKey (Short,1): Linear_Meter
End_Of_Keys.
End_Of_Geotiff.
Note that VerticalCSTypeGeoKey 5701 is "ODN height", a vertical coordinate
system from the EPSG coordinate reference system table. The vertical
coordinate system 5701 is based on vertical datum 5101 (Ordnance Datum Newlyn)
from the EPSG datum table. The 5701 vertical coordinate system also specifies
use of meters as the vertical linear measure.
So there are four GeoTIFF tags related to vertical coordinate system information:
* VerticalCSTypeGeoKey: an EPSG coordinate system code of type vertical
(normally 5600-5799).
* VerticalCitationGeoKey: a description of the vertical coordinate system,
often the EPSG user name for the VerticalCS.
* VerticalDatumGeoKey: An EPSG vertical datum code (normally 5000 to 5299).
* VerticalUnitsGeoKey: An EPSG units code (normally 9000 to 9199, 9001=meter)
Interesting things to note:
* There does not appear to be a VerticalUnitSizeGeoKey allowing user defined
vertical units similarly to the ProjLinearSizeGeoKey, so it is not
appropriate to use KvUserDefined for VerticalUnitsGeoKey.
* The libgeotiff epsg_vertcs.inc file seems to imply that the vertical datum
codes in the range 5000 to 5299 should be considered vertical coordinate
systems which they are not in the EPSG data model. It is not clear whether
this is something that changed in the EPSG data model after the initiation
of the GeoTIFF specification, or if it was an error by the
GeoTIFF/libgeotiff authors. This mismatch is why Unknown-5101 above is not
reported as Newlyn directly. Spec issue reported at
http://trac.osgeo.org/geotiff/ticket/24
* The EPSG and OGC models include an EPSG code for a composite coordinate
system. The composite coordinate system is a collection of a horizontal
coordinate system (like PCS_WGS84_UTM_zone_15N) and a vertical coordinate
system (like 5701 - ODN height). An example is
[http://spatialreference.org/ref/epsg/7405/html EPSG:7405] - OSGB36 /
British National Grid + ODN. There is no way to represent this in a GeoTIFF
tag.
Vertical CS in OGC WKT
------------------------------------------------------------------------------
As noted above, EPSG and OGC have a concept of a compound coordinate system.
An example from the CT 1.0 specification (OGC 09-001) looks like this:
::
COMPD_CS["OSGB36 / British National Grid + ODN",
PROJCS["OSGB 1936 / British National Grid",
GEOGCS["OSGB 1936",
DATUM["OSGB_1936",
SPHEROID["Airy 1830",6377563.396,299.3249646,
AUTHORITY["EPSG","7001"]],
TOWGS84[375,-111,431,0,0,0,0],
AUTHORITY["EPSG","6277"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["DMSH",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AXIS["Lat",NORTH],
AXIS["Long",EAST],
AUTHORITY["EPSG","4277"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-2],
PARAMETER["scale_factor",0.999601272],
PARAMETER["false_easting",400000],
PARAMETER["false_northing",-100000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["E",EAST],
AXIS["N",NORTH],
AUTHORITY["EPSG","27700"]],
VERT_CS["Newlyn",
VERT_DATUM["Ordnance Datum Newlyn",2005,
AUTHORITY["EPSG","5101"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Up",UP],
AUTHORITY["EPSG","5701"]],
AUTHORITY["EPSG","7405"]]
The VERT_CS portion is analogous to the information we store in GeoTIFF file
about vertical coordinate systems, though we have no mechanism to hold the
overall name or authority code of the COMPD_CS wrapper.
Interesting things to note:
* The VERT_DATUM keyword includes a name and a datum type code (2005 in this
case). The set from the specification is specified in on page 58, section
12.3.8 which is roughly captured in [wiki:OGCVerticalDatumTypes OGC
Vertical Datum Types].
* For reference, the same compound coordinate system is handled similarly in
[http://spatialreference.org/ref/epsg/7405/html Geotools]
* GDAL/OGR, used to process libLAS OGC WKT does not currently have meaningful
support for vertical or compound coordinate systems.
Vertical CS in PROJ.4
------------------------------------------------------------------------------
PROJ.4 currently has no support for vertical coordinate systems, nor any way
of representing them.
Sample Data
------------------------------------------------------------------------------
A standard sample file has been prepared demonstrating good practice setting a
vertical cs. The geotiff tags look like:
::
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_17N
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
VerticalCSTypeGeoKey (Short,1): Unknown-5703
VerticalCitationGeoKey (Ascii,38): "North American Vertical Datum of 1988"
VerticalDatumGeoKey (Short,1): Unknown-5103
VerticalUnitsGeoKey (Short,1): Linear_Meter
End_Of_Keys.
End_Of_Geotiff.
The test file is available at:
http://hg.liblas.org/main/raw-file/tip/test/data/srs_vertcs.las
Proposed LASSpatialReference Interfaces
------------------------------------------------------------------------------
The LASSpatialReference class is used to manipulate the spatial references
which are considered to include the vertical coordinate system. It is proposed
to add the following interfaces.
LASSpatialReference::SetVerticalCS
..............................................................................
This is a fairly low level method to set the vertical coordinate system
information on the spatial reference (setting the appropriate geokeys), and
updating the VLR.
.. code-block:: cpp
/// Sets the vertical coordinate system using geotiff key values.
/// This operation should normally be done after setting the horizontal
/// portion of the coordinate system with something like SetWKT(),
/// SetProj4(), SetGTIF() or SetFromUserInput()
/// \param verticalCSType - An EPSG vertical coordinate system code,
/// normally in the range 5600 to 5799, or -1 if one is not available.
/// \param citation - a textual description of the vertical coordinate
/// system or an empty string if nothing is available.
/// \param verticalDatum - the EPSG vertical datum code, often in the
/// range 5100 to 5299 - implied by verticalCSType if that is provided, or
/// -1 if no value is available.
/// \param verticalUnits - the EPSG vertical units code, often 9001 for Metre.
void LASSpatialReference::SetVerticalCS( int verticalCSType,
std::string const& citation,
int verticalDatum,
int verticalUnits )
It is mainly intended for those wishing to extend coordinate system
information from another source (WKT, PROJ.4, an existing las file) with
vertical cs data in a convenient fashion. This will be used to implement
-a_vertcs in las2las.
LASSpatialReference::GetWKT()
..............................................................................
This method will be modified to support read with or without the compound
coordinate system.
.. code-block:: cpp
enum WKTModeFlag
{
eHorizontalOnly = 1,
eCompoundOK = 2
};
/// Returns the OGC WKT describing Spatial Reference System.
/// If GDAL is linked, it uses GDAL's operations and methods to determine
/// the WKT. If GDAL is not linked, no WKT is returned.
/// \param mode_flag May be eHorizontalOnly indicating the WKT will not
/// include vertical coordinate system info (the default), or
/// eCompoundOK indicating the the returned WKT may be a compound
/// coordinate system if there is vertical coordinate system info
/// available.
std::string GetWKT( WKTModeFlag mode_flag = eHorizontalOnly ) const;
Note, that while eHorizontalOnly is the default, this is just to avoid
compatibility problems. eCompoundOK is the general version of the function and
returns a COMPD_CS coordinate system with the vertical coordinate system if
there is vertical information available, otherwise is just returns the normal
horizontal coordinate system.
Internally this is implemented by improvements to GTIFGetOGISDefn() in GDAL.
LASSpatialReference::SetWKT()
..............................................................................
This existing method will be changed to support setting vertical CS
information if the passed in WKT is a compound coordinate system. The
interface would not change, just the breadth of functionality. The actual
implementation of this functionality is in GTIFSetFromOGISDefn() in GDAL.
Proposed Changes to las2las
------------------------------------------------------------------------------
It is proposed to add two new options to las2las
* -a_srs : This would override the coordinate system
information as part of the las2las conversion, but without actually doing
any geometric transformation - analygous to -a_srs in tools like
gdal_translate or ogr2ogr.
* -a_vertcs verticalCSType citation verticalDatum verticalUnits: This option
would allow overriding/setting the vertical coordinate system information
during las2las processing. Mostly this would be used to set vertical
coordinate system information when it was missing. The arguments are the
epsg code numbers except for citation which is a string (empty to not set a
citation).
The goal is to make las2las more useful as a "coordinate system fixing up"
tool, including a fairly convenient ability to set the vertical coordinate
system information on files that were missing it.
Changes in GDAL
------------------------------------------------------------------------------
The following changes have been made in GDAL to better support libLAS vertical
coordinate system handling:
* SetFromUserInput() was modified to recognise COMPD_CS as a valid root so a
compound coordinate system can be set this way. Mainly useful for las2las.
* GTIFGetOGISDefn() was extended to build a COMPD_CS coordinate system if
there is vertical coordinate system info.
* GTIFSetFromOGISDefn() was extended to write vertical cs tags if there is
vertical cs information in the WKT.
* OGRSpatialReference was extended with the StripVertical() method to remove
COMPD_CS wrappers from a compound coordinate system (used by GetWKT() to
strip off vertical stuff).
These changes will be in GDAL 1.7.
Changes in libgeotiff
------------------------------------------------------------------------------
The following changes have been made in libgeotiff to better support libLAS
vertical coordinate system handling:
* GTIFValueName() now knows how to translate !VerticalUnitsGeoKey.
* GTIFNew() now reads existing geotiff file tags in a way that support update
in place within the GTIF structure.
* libLASSortKeys() was rewritten to be less fragile in the face of malformed sets
of geokeys, such as those common in LAS files with several "0" keys at the
end.
These changes will be in libgeotiff 1.3.0. They are mostly useful for las2las.
liblas-1.7.0+dfsg/doc/development/rfc/rfc_2_spatialreference.txt 0000644 0001750 0001750 00000016311 11727124362 024524 0 ustar frankie frankie ******************************************************************************
libLAS RFC 2: SpatialReference Overhaul
******************************************************************************
:Author: Frank Warmerdam
:Contact: warmerdam@pobox.com
:Date: 11/19/10
:Status: Implemented
:Version: libLAS 1.6
.. contents::
:depth: 1
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 surprising 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 primarily 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 :ref:`las2las ` to perform
transformations between coordinate systems not representable in GeoTIFF
terms even if the source and destination are provided on the command-line 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
representing 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:
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.
.. note::
A liblas::SpatialReference instance that was read/generated from VLRs containing
only GeoTIFF keys will continue to only have GeoTIFF keys until you
issue a call to SetWKT(). You can simply do the following to WKT-enable
a liblas::SpatialReference in that case:
::
reference.SetWKT(reference.GetWKT());
.. warning::
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
"liblas" and with a RecordId of 2112 to
distinguish it from the GeoTIFF VLRs.
The data is the OGR WKT string with a terminating zero byte. An exception
is thrown if the size of the WKT is larger than a VLR record can hold.
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::
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.
liblas-1.7.0+dfsg/doc/development/specifications.txt 0000644 0001750 0001750 00000002447 11727124362 022373 0 ustar frankie frankie .. _specifications:
******************************************************************************
ASPRS Specifications
******************************************************************************
The LAS format standard is maintained by the `ASPRS Standards Committee`_.
LAS format standard documents are available from liblas.org for convenience
and archival purposes. Please check the APSRS website for the authoritative
source on the standards documents.
* `ASPRS LAS 1.3`_
* `ASPRS LAS 1.2`_
* `ASPRS LAS 1.1`_
* `ASPRS LAS 1.0`_
.. _liblas_vlr_key:
VLR Key
----------------
libLAS' VLR key is ``1209`` with keyname ``liblas``. See
http://www.asprs.org/society/committees/lidar/lidar_format_keylist.html for
the key list and Keys may be requested at
http://www.asprs.org/lasform/keyform.html to register your own keys.
.. _`ASPRS LAS 1.3`: http://liblas.org/_static/files/specifications/asprs_las_format_v13.pdf
.. _`ASPRS LAS 1.2`: http://liblas.org/_static/files/specifications/asprs_las_format_v12.pdf
.. _`ASPRS LAS 1.1`: http://liblas.org/_static/files/specifications/asprs_las_format_v11.pdf
.. _`ASPRS LAS 1.0`: http://liblas.org/_static/files/specifications/asprs_las_format_v10.pdf
.. _`ASPRS Standards Committee`: http://www.asprs.org/society/committees/standards/lidar_exchange_format.html liblas-1.7.0+dfsg/doc/development/annual_report_2010.txt 0000644 0001750 0001750 00000030335 11727124362 022700 0 ustar frankie frankie .. _annual_report_2010:
******************************************************************************
2010 Annual Report
******************************************************************************
:Author: Howard Butler
:Contact: hobu.inc@gmail.com
:Date: 12/21/2010
The following document is a synopsis of major development activities that have
taken place in the libLAS project (or related projects) in the 2010 calendar
year.
Vertical Datum Reprojection and Transformation
..............................................................................
Frank Warmerdam implemented vertical datum reprojection and transformation in the
entire open source GIS stack in the past year (`proj.4`_, `GDAL`_ and `libgeotiff`_). This work
makes it possible to make vertical datum transformations via command-line utilities
like :ref:`las2las ` in addition to providing the tools for software
developers to implement the features in their own software.
.. _`libgeotiff`: http://www.remotesensing.org/geotiff/geotiff.html
.. _`proj.4`: http://proj.maptools.org/
.. _`GDAL`: http://www.gdal.org
libLAS Processing Kernel
..............................................................................
libLAS gained something I call the "libLAS Processing Kernel" in the past year.
It's really just a set of common functions that all application-level software
can reuse to implement filtering and transformation on LAS data. The collation
of all of this functionality in a common place has meant the reuse of the
same operations in many of the libLAS utilities include :ref:`las2las `,
:ref:`lasinfo `, and :ref:`las2txt `. New features implemented
in the kernel include:
* Color fetching from GDAL raster data sources
* Data reprojection and vertical datum transformation
* Numerous filtering operations
* Header modification
These utilities are available to all software developers who wish to reuse them
in their own tools.
Re-engineering of :ref:`las2las ` :ref:`las2txt ` and :ref:`lasinfo `
...................................................................................................
:ref:`las2las ` :ref:`las2txt ` and :ref:`lasinfo `
were re-imagined in light of development of the `libLAS Processing Kernel`_ to
take advantage of new functionality and regularize command-line argument
handling and parsing. The previous versions of the utilities have been
preserved under the :ref:`las2las-old ` :ref:`las2txt-old
` and :ref:`lasinfo-old ` monikers in case people
have significant processing workflows developed with them. It would be
advantageous to upgrade to the new versions in many cases -- both for
significantly improved functionality and for a speed improvement that is
sometimes double that of the -old versions.
Some new features the utilities gained as part of this effort include:
* Setting color information from GDAL rasters
* Splitting files based on a point count or a file size in mb
* Chaining many filter operations together into a single call
* Modifying header information, including setting coordinate system info
* Summarizing data more fully and more flexibly (XML, per-point)
Chipper
..............................................................................
Andrew Bell developed a specialized point partitioning process called
:ref:`lasblock ` to bucketize point data.The process that aims to
optimize the fill capacity, shape, and speed of processing. More specifically,
it attempts to keep the blocks as full as possible and as square as possible
to augment querying characteristics for `Oracle Point Cloud`_. This
pre-processing is needed as precursor step in the processing chain that ends
with actually loading the data into Oracle via :ref:`las2oci`. :ref:`lasblock
` can also be used as a LAS tiling process, although it is not so
memory efficient.
Indexing
..............................................................................
Gary Huber developed an octree-based spatial index for libLAS to speed up random,
bounding-box-based queries to LAS files. It is released as part of libLAS 1.6,
but its full implementation within the library is not yet complete. The index
can store its data within VLRs (requires a file rewrite) in addition to
in a file alongside the .las file.
CMake
..............................................................................
libLAS was migrated to using `CMake`_ for its configuration system. CMake
allows easy generation of MSVC project files, XCode project files, and make
files under a common configuration. This effort eliminated three parallel
build system configurations (MSVC projects, GNU autoconf, MSVC makefiles) and
provided more flexibility for packaging, testing, and build types. In my
opinion, its use has been a boon to the project.
OSGeo4W
..............................................................................
For the first time ever, we have released fully-capable Windows libLAS
packages in the form of an OSGeo4W release. These releases contain the full
range of libLAS functionality including coordinate system support, Oracle
support, vertical datum transformation, and chipping. Head to
http://trac.osgeo.org/osgeo4w to obtain your copy and start testing libLAS
immediately.
New Website
..............................................................................
We rewrote the libLAS website and transformed it from a bunch of wiki pages
in Trac to a Sphinx-backed HTML website. We have added tons more documentation,
provided it in formats such as `PDF`_, and organized things significantly.
Generic LAS Schema Support
..............................................................................
Though it is specifically allowed by the standard but not widely implemented,
it is possible to store extra data attached to each point after the requisite
PointFormat data are stored. There is neither a regularized way to describe
these data nor a way to capture metadata about this. To this end, I have
proposed an XML schema document that could be stored in a VLR as well as
schema-aware reader and writer implementations that can utilize that VLR to
work with the data. See
for more details on the initial proposal of schema support.
libLAS now implements a class called liblas::Schema that is driven
by the Point Data Format ID of the header in addition to any extra dimensions
you wish to store with the point. This work is used for both the `Oracle Point Cloud`_
effort and upcoming LASzip compression integration.
Refactoring of liblas::Point class
..............................................................................
We significantly refactored the liblas::Point class the 1.6.0 release. The
first thing that was done was to make it "thinner" in the sense that it doesn't
store a union of all point-format-derived dimensions on it, and instead
stores a reference to a schema that informs the class about which dimensions
exist. Additionally, data are interpreted on-the-fly from the raw bytes
which compose the point, eliminating the fidelity issues.
libLAS 1.2.1 and below utilized a liblas::Point that was kind of fat. It
carried around interpreted data members for all of the dimensions on the point
-- x, y, z, intensity, etc -- and if you asked for one of these, it just
returned it to you directly. The interpretation of those data happened as the
data were read, and again as the data were written (back into raw bytes).
libLAS 1.6+ has changed liblas::Point in a number of important ways.
liblas::Point now only carries along the raw bytes for the point, and if you
ask for one of the dimensions, it interprets it on-the-fly. For example, a
GetX() call now requires going into the liblas::Point byte array, pulling the
first four bytes off of it, asking the point's header for scaling information,
and rescaling the integer data into double data. If you only call GetX() one
time, things are roughly equivalent to what we were doing before --
interpreting and caching interpreted data directly on the liblas::Point -- but
every one of your subsequent calls to GetX() have this interpretation
performance hit. You need to cache your calls to interpreted data if you are
reusing things. Alternatively, you can control when your data have scaling
applied by using GetRawX(), which was not possible before libLAS 1.6.
The rationale for moving to this approach was three-fold. First, the LAS
committee continually adds new dimensions onto the specification, and I wanted
an extendable way to add them to libLAS without causing a full re-engineering
of the liblas::Point class every time they do. Second, liblas::Point now has a
schema attached to it (based on the list of dimensions that a LAS file's point
format defines plus any custom dimensions you wish to add to the point
record). The schema allows you to extend the point format and add your own
dimensions and it provides generic descriptive information about what exists
in the file. You can see the description of these schemas in the new
:ref:`lasinfo ` output from libLAS. Lastly, previous versions of
libLAS did not allow you to work with raw data, and did not allow the user to
transform the data (coordinate data, especially) with perfect fidelity. The
new approach explicitly supports this out-of-the-box. Here's something that is
now possible with the new (C++) API that was not previously:
::
liblas::Point const& p = reader.GetPoint();
std::vector data = p.GetData();
... // do something with the raw data like stuff it into a database.
Refactoring of internal Reader and Writer code
..............................................................................
The previous (< libLAS 1.2) C++ reader and writer code of libLAS was a bit
inflexible, and contained significant duplication for each file format
version. Giant updates would be required to the code as the ASPRS LAS standard
committee added new specification versions with new required point formats.
Additionally, the old code's design was a bit rigid for adding things like
generic schema support.
Both the liblas::Reader and liblas::Writer have been significantly `refactored`_
The reduction in duplication means going to only one place to make changes to
the code. In addition to not repeating ourselves, it provides us more
flexibility to add new features and extensibility to allow the reader and
writers to be overridden by user code.
Generic interfaces
..............................................................................
A number of generic interfaces have been added to libLAS to support dynamic
polymorphism. See for the C++ interfaces. By implementing
these interfaces, you can add your own reader/writer implementations as well
as provide custom filtering and transformation capability.
Faster binary i/o
..............................................................................
Mateusz Loskot developed a more savvy implementation for its binary i/o which
provides some significant performance improvements.
Caching reader
..............................................................................
A reader implementation that provides data caching will be provided at
libLAS 1.6. If your data reading involves reading the data in multiple passes
through the file, you can utilize the cached reader to cache the points
(up to the size of the entire file) for faster repeated and random access.
Seek support
..............................................................................
It is now possible to seek to a specific point in the file and start reading
points. This can significantly speed up the "random sampling" access strategy
where one starts reading a run of points at a specific location in the file
and then moves to a different location.
Classification class
..............................................................................
A class is now provided to abstract the LAS classification value and help
interpret the bit fields that are present for synthetic, key point, and withheld
types.
.. _refactored: http://en.wikipedia.org/wiki/Code_refactoring
.. _`Oracle Point Cloud`: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_pc_pkg_ref.htm
.. _`PDF`: http://liblas.org/pdf/libLAS.pdf liblas-1.7.0+dfsg/doc/development/source.txt 0000644 0001750 0001750 00000000657 11727124362 020671 0 ustar frankie frankie .. _source:
******************************************************************************
libLAS Source Repository
******************************************************************************
The main repository for libLAS is located on github at https://github.com/libLAS/libLAS
You can obtain a copy of the active source code by issuing the following command::
git clone git://github.com/libLAS/libLAS.git liblas
liblas-1.7.0+dfsg/doc/development/format_elements.txt 0000644 0001750 0001750 00000023611 11727124362 022550 0 ustar frankie frankie .. _format_elements:
*******************
LAS Format Elements
*******************
:Author: Mateusz Loskot
:Contact: mateusz at loskot dot net
On this page, elements and attributes of LAS Format 1.0 and 1.1 are compared.
.. seealso::
The `LAS 1.0-1.3 Permuation matrix`_
contains a detailed description of LAS header and point discrepancies
between versions in addition to this (older) document.
==========
Data Types
==========
Both versions of LAS Format Standard define and use the same set of data types and their sizes:
* 1 byte
* char (int8_t)
* unsigned char (uint8_t)
* 2 bytes
* short (int16_t)
* unsigned short (uint16_t)
* 4 bytes
* long (int32_t)
* unsigned long (uint32_t)
* 8 bytes
* double - double precision floating-point number (64-bit) as defined in
`IEEE 754 `_
Standard
===================
Public Header Block
===================
+-----+-------------------------------------+--------------------+---------------------+
|**#**| **Element** | **LAS 1.0** | **LAS 1.1** |
+=====+=====================================+====================+=====================+
| 1 | File Signature ("LASF") | int8_t[4], *required* |
+-----+-------------------------------------+--------------------+---------------------+
| 2 | File Source ID | | uint16_t, *required*|
+-----+-------------------------------------+--------------------+---------------------+
| 3 | Reserved | uint32_t | uint16_t |
+-----+-------------------------------------+--------------------+---------------------+
| 4 | GUID data 1 (Project ID) | uint32_t |
+-----+-------------------------------------+--------------------+---------------------+
| 5 | GUID data 2 (Project ID) | uint16_t |
+-----+-------------------------------------+--------------------+---------------------+
| 6 | GUID data 3 (Project ID) | uint16_t |
+-----+-------------------------------------+--------------------+---------------------+
| 7 | GUID data 4 (Project ID) | uint8_t[8] |
+-----+-------------------------------------+--------------------+---------------------+
| 8 | Version Major | uint8_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
| 9 | Version Minor | uint8_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|10 | System identifier | int8_t[32], *required* |
+-----+-------------------------------------+--------------------+---------------------+
|11 | Generating software | int8_t[32], *required* |
+-----+-------------------------------------+--------------------+---------------------+
|12 | Flight date Julian / Day of Year | uint16_t |
+-----+-------------------------------------+--------------------+---------------------+
|13 | Year | uint16_t |
+-----+-------------------------------------+--------------------+---------------------+
|14 | Header size | uint16_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|15 | Offset to data | uint32_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|16 | Number of variable length records | uint32_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|17 | Point data format ID (0-99) | uint8_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|18 | Point data record length | uint16_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|19 | Number of point records | uint32_t, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|20 | Number of points by return | uint32_t[5], *required* |
+-----+-------------------------------------+--------------------+---------------------+
|21 | X scale factor | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|22 | Y scale factor | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|23 | Z scale factor | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|24 | X offset | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|25 | Y offset | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|26 | Z offset | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|27 | Max X | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|28 | Min X | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|29 | Max Y | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|30 | Min Y | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|31 | Max Z | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
|32 | Min Z | double, *required* |
+-----+-------------------------------------+--------------------+---------------------+
| Total number of bytes: | **227** | **227** |
+-----+-------------------------------------+--------------------+---------------------+
Type specifier of the form of **type[N]** where **N** is a number, represents
array of **N** elements of **type**.
==========
Point Data
==========
The table below is based on definition of **Point Data Record Format 0** and
it does not include what's specified *Point Data Record 1*.
+-----+-------------------------------------+---------------------+----------------------+
|**#**| **Element** | **LAS 1.0** | **LAS 1.1** |
+=====+=====================================+=====================+======================+
| 1 | X | int32_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 2 | Y | int32_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 3 | Z | int32_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 4 | Intensity | uint16_t |
+-----+-------------------------------------+---------------------+----------------------+
| 5 | Return number | 3 bits (0,1,2), *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 6 | Number of returns (given pulse) | 3 bits (3,4,5), *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 7 | Scan direction flag | 1 bit (6), *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 8 | Edge of flight line | 1 bit (7), *required* |
+-----+-------------------------------------+---------------------+----------------------+
| 9 | Classification | uint8_t | uint8_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
|10 | Scan angle rank (-90 to +90) | int8_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
|11 | File Marker / User Data (1) | uint8_t |
+-----+-------------------------------------+---------------------+----------------------+
|12 | User Bit Field / Point Source ID (2)| uint16_t | uint16_t, *required* |
+-----+-------------------------------------+---------------------+----------------------+
(1) FileMarker from 1.0 has been renamed to User Data in 1.1 and is available for any use.
(2) User Bit Field from 1.0 has been renamed to Point Source ID in 1.1 and marked as required.
.. _`LAS 1.0-1.3 Permuation matrix`: ../_static/LAS-1.0-1.3-feature-matrix.pdf liblas-1.7.0+dfsg/doc/development/index.txt 0000644 0001750 0001750 00000002276 11727124362 020477 0 ustar frankie frankie .. _development:
******************************************************************************
Development
******************************************************************************
Topics
..............................................................................
.. toctree::
:maxdepth: 0
buildbot
specifications
source
format_elements
Motivation
2010 Annual Report
RFCs
LAS 1.4 WKT Proposal
Authors
..............................................................................
The libLAS development team are:
* `Howard Butler`_
* `Mateusz Loskot`_
* `Phil Vachon`_
* Martin Vales
* `Frank Warmerdam`_
Special thanks to `Martin Isenburg and Jonathan Shewchuk`_ for their
:ref:`lastools_liblas` pioneering implementation of the ASPRS LAS standard that made
development of the libLAS library possible.
.. _`Howard Butler`: http://hobu.biz
.. _`Mateusz Loskot`: http://mateusz.loskot.net
.. _`Phil Vachon`: http://www.geoscan.info
.. _`Frank Warmerdam`: http://home.gdal.org/warmerda/
.. _`Martin Isenburg and Jonathan Shewchuk`: http://www.cs.unc.edu/~isenburg/lastools/
liblas-1.7.0+dfsg/doc/development/buildbot.txt 0000644 0001750 0001750 00000016560 11727124362 021175 0 ustar frankie frankie .. _buildbot:
******************************************************************************
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 `__ to perform
automated builds and continuous integration. Thanks to the
`OSGeo Foundation`_, a dedicated Buildbot instance is hosted on the `OSGeo Buildbot`_.
The libLAS Buildbot status is rendered on the `libLAS buildbot waterfall`_
which can be used to trigger new builds on request.
There is also #bbliblas bot present on `IRC`_ #liblas] IRC channel:
::
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
..............................................................................
Users are encourage to run libLAS unit tests and submit test results to
dedicated `CDash`_ - utility dashboard hosted by the http://cdash.org website:
* `libLAS CDash`_
The CDash is another tool liblAS uses to perform `continuous integration`_
during development process.
.. note::
In order to enable `CTest`_ support, `CMake 2.8.0+`_
version is required.
* Configure libLAS core library with unit tests and CTest enabled
::
$ cmake ../main -DWITH_TESTS=ON -DENABLE_CTEST=ON
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Enable libLAS utilities to build - done
-- Enable libLAS unit tests to build - done
-- Enable CTest to support submissions of results to CDash at http://cdash.org
-- Enable CTest to support submissions of results to CDash at http://cdash.org - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mloskot/dev/liblas/_hg/build
* Inspect available targets
::
$ make help
The following are some of the valid targets for this Makefile:
... all (the default if no target is provided)
... clean
... depend
... Continuous
... ContinuousBuild
... ContinuousConfigure
... ContinuousCoverage
... ContinuousMemCheck
... ContinuousStart
... ContinuousSubmit
... ContinuousTest
... ContinuousUpdate
... Experimental
... ExperimentalBuild
... ExperimentalConfigure
... ExperimentalCoverage
... ExperimentalMemCheck
... ExperimentalStart
... ExperimentalSubmit
... ExperimentalTest
... ExperimentalUpdate
... Nightly
... NightlyBuild
... NightlyConfigure
... NightlyCoverage
... NightlyMemCheck
... NightlyMemoryCheck
... NightlyStart
... NightlySubmit
... NightlyTest
... NightlyUpdate
... edit_cache
... install
... install/local
... install/strip
... list_install_components
... rebuild_cache
... test
... las
... las_c
... las2las
... las2txt
... lasinfo
... lasmerge
... txt2las
... liblas_test
* Run `Continuous` target
::
mloskot@dog:~/dev/liblas/_hg/build$ make Continuous
Site: dog
Build name: Linux-c++
Create new tag: 20091025-0003 - Continuous
Updating the repository
Updating the repository: /home/mloskot/dev/liblas/_hg/main
Use HG repository type
Old revision of repository is: aa303d670d1a
New revision of repository is: 690df0a6df0b
Gathering version information (one . per revision):
.
Found 1 updated files
Configure project
Each . represents 1024 bytes of output
. Size of output: 0K
Build project
Each symbol represents 1024 bytes of output.
'!' represents an error and '*' a warning.
......****.* Size of output: 11K
0 Compiler errors
7 Compiler warnings
Test project /home/mloskot/dev/liblas/_hg/build
Start 1: liblas_test
1/1 Test #1: liblas_test ...................... Passed 0.02 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.03 sec
Performing coverage
Cannot find any coverage files. Ignoring Coverage request.
Submit files (using http)
Using HTTP submit method
Drop site:http://my.cdash.org/submit.php?project=libLAS
Uploaded: /home/mloskot/dev/liblas/_hg/build/Testing/20091025-0003/Build.xml
Uploaded: /home/mloskot/dev/liblas/_hg/build/Testing/20091025-0003/Configure.xml
Uploaded: /home/mloskot/dev/liblas/_hg/build/Testing/20091025-0003/Test.xml
Uploaded: /home/mloskot/dev/liblas/_hg/build/Testing/20091025-0003/Update.xml
Submission successful
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
.. _`CDash`: http://www.cdash.org/
.. _`continuous integration`: http://en.wikipedia.org/wiki/Continuous_integration
.. _`libLAS CDash`: http://my.cdash.org/index.php?project=libLAS
.. _`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/
liblas-1.7.0+dfsg/doc/development/wkt.txt 0000644 0001750 0001750 00000017531 11727124362 020175 0 ustar frankie frankie .. _srs_wkt:
******************************************************************************
Georeferencing LAS files with LAS 1.4
******************************************************************************
:Author: Howard Butler
:Contact: hobu.inc at gmail dot com
:Date: 2/28/2011
Summary
------------------------------------------------------------------------------
This document proposes how to handle describing spatial reference systems
in `ASPRS LAS`_ 1.4. LAS 1.4 prescribes that software developers add and
prefer to use OGC WKT coordinate system description in the form of VLR
records in LAS files. Softwares can choose to continue to write GeoTIFF keys
to support older applications, but they should prefer the OGC WKT if it is
found in the file.
Rationale
------------------------------------------------------------------------------
LAS 1.3 and below have used `GeoTIFF`_ keys as described by the `GeoTIFF
specification`_, but use of the GeoTIFF keys within LAS has a number of
deficiencies:
* GeoTIFF is typically tied to the `EPSG database`_ and does not provide
simple mechanisms for extended definitions.
* Only a few softwares provide support for working with GeoTIFF keys directly.
* The GeoTIFF specification has no organization backing its continued
development.
* GeoTIFF does not offer a mechanism to represent transformations between
datums, while OGC WKT offers the TOWGS84[] mechanism
* GeoTIFF does not offer the possibility of fitted coordinate systems.
WKT
------------------------------------------------------------------------------
The `OpenGIS Coordinate Transformation Service Implementation Specification`_
provides the "Well-known Text Representation of Spatial Reference Systems"
(WKT) language in section seven. WKT is much more expressive than GeoTIFF keys,
has an organization providing institutional heft and progress behind it, and a
number of open source and commercial softwares are available to support
parsing and interpreting WKT output.
There are a few dialects of WKT of which to be aware. The most common dialect
is the "ESRI WKT" dialect, which does not include TOWGS84 and authority nodes,
but there are others including "GDAL", "CSMap", "Oracle 9", "Oracle 10", and
"GeoTools." While the basic form of WKT in these different dialects (other
than ESRI) is the same, the names used for different items, such as
``PARAMETER``, can often be spelled differently. It should be assumed that all
WKT provided in LAS files should be of a dialect that is not the "ESRI WKT"
dialect, which lacks some important features -- notably TOWGS84 and AUTHORITY
nodes.
.. _`OpenGIS Coordinate Transformation Service Implementation Specification`: http://www.opengeospatial.org/standards/ct
.. _`MetaCRS`: http://trac.osgeo.org/metacrs/
Implementation
------------------------------------------------------------------------------
WKT can be specified in two optional Variable Length Record (VLR) entries with the
``LASF_Projection`` User ID. The `Math Transform WKT`_ can be used to apply
transformations to the `Coordinate System WKT`_.
Math Transform WKT
..............................................................................
Math Transform WKT (section 7.1 of the `OGC Coordinate Transform Specification`_)
can also be specified to apply to a ``FITTED_CS``-style coordinate system.
OGC Math Transform WKT strings shall be provided in a VLR with the
following attributes:
* User ID: LASF_Projection
* Record ID: 2111
The following conditions should also apply:
* Because VLRs can only be 65536 bytes size, an OGC Math Transform WKT
string in a VLR data block is functionally limited to 64K in size.
* The OGC Math Transform WKT VLR data shall be a null-terminated string.
* The OGC Math Transform WKT VLR data shall be considered UTF-8.
* The OGC Math Transform WKT VLR data shall be considered ``C``
locale-based, and no localization of the numeric strings within the WKT
should be performed.
.. note::
Math Transform WKT's widespread use is not expected, but it is provided
for completeness and flexibility.
Coordinate System WKT
..............................................................................
OGC Coordinate System WKT strings shall be provided in a VLR with the
following attributes:
* User ID: LASF_Projection
* Record ID: 2112
The following conditions should also apply:
* Because VLRs can only be 65536 bytes size, an OGC Coordinate System WKT
string in a VLR data block is functionally limited to 64K in size.
* The OGC Coordinate System WKT VLR data shall be a null-terminated string.
* The OGC Coordinate System WKT VLR data shall be considered UTF-8.
* The OGC Coordinate System WKT VLR data shall be considered ``C``
locale-based, and no localization of the numeric strings within the WKT
should be performed.
.. note::
Though not specifically mentioned in previous LAS specifications,
coordinate system information (in GeoTIFF or WKT) applies to the final
coordinate data that are produced by transforming the raw coordinates by
the scale and offset specified in the header for the given dimension.
Transition
------------------------------------------------------------------------------
Older softwares may want to continue to use GeoTIFF keys, and it is not
desirable to have an abrupt discontinuity in the description of coordinate
systems for LAS data. Additionally, while many softwares may not need the
features of OGC WKT, its usage represents the strongest case for
interoperability with other software -- especially software in the GIS and CAD
domains that take advantage of the OGC WKT specification.
Softwares that currently write GeoTIFF VLR records into LAS files can continue
to do so in LAS 1.4. It is acceptable to write *only* GeoTIFF VLR records into
an LAS file, while softwares that choose to write OGC WKT VLRs must also
write GeoTIFF VLRs to promote backward compatibility. If a file is found to
have both OGC WKT and GeoTIFF VLRs, the OGC WKT description, which is more
expressive, should be preferred if possible.
Resources
------------------------------------------------------------------------------
The ASPRS LAS specification attempts to offload specification of coordinate
system description and transformation by standing on the shoulders of other
specifications in the ecosystem. To that end, there are options for both
software and support for an LAS developer to take advantage of. Those below
are provided for information purposes only, and are not expected to be
canonical. Use your favorite search engine for more details.
Software
..............................................................................
As mentioned previously, a number of open source and commercial softwares are
available to help an implementor of ASPRS LAS utilize Coordinate System and
Math Transform WKT in their software.
Some common open source softwares include:
* `GDAL`_'s `OSR`_
* `CS-Map`_
* `GeoTools`_/`Geotoolkit`_
Some commercial options include:
* `Blue Marble®`_
* `ArcGIS®`_
Questions
..............................................................................
If you have questions about how to produce WKT, please participate on
the `MetaCRS`_ mailing list. Examples of WKT may also be found on the
http://spatialreference.org website.
.. _`OSR`: http://www.gdal.org/ogr/osr_tutorial.html
.. _`ArcGIS®`: http://www.arcgis.com
.. _`Blue Marble®`: http://www.bluemarblegeo.com/
.. _`GDAL`: http://www.gdal.org
.. _`CS-Map`: http://trac.osgeo.org/csmap/
.. _`GeoTools`: http://www.geotools.org/
.. _`Geotoolkit`: http://www.geotoolkit.org/
.. _`OGC Coordinate Transform Specification`: http://www.opengeospatial.org/standards/ct
.. _`ASPRS LAS`: http://www.asprs.org/society/committees/standards/lidar_exchange_format.html
.. _`GeoTIFF specification`: ftp://ftp.remotesensing.org/pub/geotiff/spec/geotiff.rtf
.. _`GeoTIFF`: http://trac.osgeo.org/geotiff/
.. _`EPSG database`: http://www.epsg-registry.org/
liblas-1.7.0+dfsg/doc/_static/ 0000755 0001750 0001750 00000000000 11727124362 015724 5 ustar frankie frankie liblas-1.7.0+dfsg/doc/_static/liblas-color-pallette.css 0000644 0001750 0001750 00000000440 11727124362 022626 0 ustar frankie frankie .#6666AE {
color: #6666AE;
}
.#9168AD {
color: #9168AD;
}
.#D166A8 {
color: #D166A8;
}
.#DD5F6D {
color: #DD5F6D;
}
.#E18958 {
color: #E18958;
}
.#E1A858 {
color: #E1A858;
}
.#E0C358 {
color: #E0C358;
}
.#E2E05A {
color: #E2E05A;
}
liblas-1.7.0+dfsg/doc/_static/sphinx.css 0000644 0001750 0001750 00000007664 11727124362 017764 0 ustar frankie frankie /**
* Sphinx stylesheet -- default theme
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
@import url("basic.css");
/* -- page layout ----------------------------------------------------------- */
body {
font-family: Helvetica, Arial, sans-serif;
font-size: 100%;
background-color: #FFF;
color: #555;
margin: 0;
padding: 0;
}
div.documentwrapper {
float: left;
width: 100%;
}
div.bodywrapper {
margin: 0 0 0 230px;
}
hr{
border: 1px solid #B1B4B6;
}
div.document {
background-color: #eee;
}
div.body {
background-color: #ffffff;
color: #3E4349;
padding: 0 30px 30px 30px;
font-size: 0.8em;
}
div.footer {
color: #fff;
width: 100%;
padding: 13px 0;
text-align: center;
font-size: 75%;
background-color: #6666AE;
}
div.footer a {
color: #eee;
}
div.footer a.hover {
color: #eee;
text-decoration: underline;
}
div.related {
background-color: #6666AE;
line-height: 32px;
color: #fff;
font-size: 0.80em;
}
div.related a {
color: #fff;
}
div.sphinxsidebar {
font-size: 0.75em;
line-height: 1.5em;
z-index: 1000;
}
div.sphinxsidebarwrapper{
padding: 20px 0;
background-color: #E2E05A;
}
div.sphinxsidebar h3,
div.sphinxsidebar h4 {
font-family: Arial, sans-serif;
color: #222;
font-size: 1.2em;
font-weight: normal;
margin: 0;
padding: 5px 10px;
background-color: #E2E05A;
}
div.sphinxsidebar h4{
font-size: 1.1em;
}
div.sphinxsidebar h3 a {
color: #444;
}
div.sphinxsidebar p {
color: #888;
padding: 5px 20px;
}
div.sphinxsidebar p.topless {
}
div.sphinxsidebar ul {
margin: 10px 20px;
padding: 0;
color: #000;
}
div.sphinxsidebar a {
color: #444;
}
div.sphinxsidebar input {
border: 1px solid #ccc;
font-family: sans-serif;
font-size: 1em;
}
div.sphinxsidebar input[type=text]{
margin-left: 20px;
}
/* -- body styles ----------------------------------------------------------- */
a {
color: #1A1A56;
text-decoration: underline;
}
a:hover {
color: #A33333;
text-decoration: underline;
}
div.body h1,
div.body h2,
div.body h3,
div.body h4,
div.body h5,
div.body h6 {
font-family: Helvetica, Arial, sans-serif;
background-color: #ccc;
font-weight: normal;
color: #000;
margin: 30px 0px 10px 0px;
padding: 5px 0 5px 10px;
text-shadow: 0px 1px 0 white
}
div.body h1 { border-top: 20px solid white; margin-top: 0; font-size: 200%; }
div.body h2 { font-size: 150%; background-color: #ccc; }
div.body h3 { font-size: 120%; background-color: #ccc; }
div.body h4 { font-size: 110%; background-color: #ccc; }
div.body h5 { font-size: 100%; background-color: #ccc; }
div.body h6 { font-size: 100%; background-color: #ccc; }
h1 a,
h2 a,
h3 a,
h1 a:hover,
h2 a:hover,
h3 a:hover {
text-decoration: none;
}
a.headerlink {
color: #c60f0f;
font-size: 0.8em;
padding: 0 4px 0 4px;
text-decoration: none;
}
a.headerlink:hover {
background-color: #c60f0f;
color: white;
}
div.body p, div.body dd, div.body li {
line-height: 1.5em;
}
div.admonition p.admonition-title + p {
display: inline;
}
div.highlight{
background-color: white;
}
div.note {
background-color: #eee;
border: 1px solid #ccc;
}
div.seealso {
background-color: #E2E05A;
border: 1px solid #ff6;
}
div.topic {
background-color: #eee;
}
div.warning {
background-color: #ffe4e4;
border: 1px solid #f66;
}
p.admonition-title {
display: inline;
}
p.admonition-title:after {
content: ":";
}
pre {
padding: 10px;
background-color: #eee;
color: #222;
line-height: 1.2em;
border: 1px solid #C6C9CB;
font-size: 1.2em;
margin: 1.5em 0 1.5em 0;
-webkit-box-shadow: 1px 1px 1px #d8d8d8;
-moz-box-shadow: 1px 1px 1px #d8d8d8;
}
tt {
background-color: #ecf0f3;
color: #222;
padding: 1px 2px;
font-size: 1.2em;
font-family: monospace;
} liblas-1.7.0+dfsg/doc/_static/liblaslogo.png 0000644 0001750 0001750 00000013671 11727124362 020571 0 ustar frankie frankie ‰PNG
IHDR À < 0Œµe tEXtSoftware Adobe ImageReadyqÉe<