Alsproc Development

Structure

Alsproc is built around the proprietary alspro.dll, forcing it to take the form of a winelib program, something which isn't quite native to either Windows or Linux. Some complications arise out of this, such as barring the use of gdb. A python program wraps around alsproc to handle broader more context-specific logic, doing things like reading in .cfg files and computing the correct arguments to pass.

Generally, the structure of the program is arranged by branches where alsproc.c is the root of the tree and branches are things like scn parsing, sup reading, navigation reading, etcetera. Output formats are modular, making them very easy to add and remove. Parameters passed to the program externally should be passed around internally using pointers to a config_struct structure, to help avoid dramatic changes in the API on a regular basis among other things, any developer should be sure to use it. The broadness of its use could be expanded at the time of writing.

Output modules can be added by defining 3 functions and a structure instance: functions for each of opening, writing, and closing; and a structure to hold pointers to those functions. Access to these should be exposed in a header file, while actual code should be contained in their own source file. out_txt is a good example of an output module, which outputs point data to a .txt file simply translating points to human readable text using fprintf, it can be copied and used as a template for any future modules. Once you have a module, edit output.c and add a clause for your module in open_output_stream which translates config->output_format to your structure holding pointers to your functions, and stores the result in out->fmt.

else if (strcmp(config->output_format, "netcdf")==0)
  out->fmt = &NETCDF_FORMAT;

SCN reading is arguably the most complex part of the program. It's best not to debug it directly in alsproc if at all possible, as this bars the use of gdb. Instead, consider using the scn_info program, which is compiled normally but still uses the same code for reading SCN records.

Subversion

Alsproc can be found in subversion under tools/alsproc. Obtain a copy with svn checkout.

svn checkout http://rsg.pml.ac.uk/intranet/svnroots/arsf-internal/trunk/tools/alsproc

You can make and manage your changes in this checkout. When you've tested it and you're happy, you may need to advance the version number. Edit the Makefile in src/, and find the line which says vers=x.x.x and advance it as you need.

# VERSION NUMBER
vers=0.0.9

When you're satisfied, commit the changes.

svn commit

And finally, tag the branch version if you advanced the version number.

svn cp http://rsg.pml.ac.uk/intranet/svnroots/arsf-internal/trunk/tools/alsproc http://rsg.pml.ac.uk/intranet/svnroots/arsf-internal/tags/alsproc-0.0.9 -m "tagging new version of alsproc"

Installation in ARSF

Current policy is to install in the home directory of the arsf user, as this asserts that all users across the department are using the same and current version of alsproc. Enter usr/opt/alsproc and check out the version you wish to build, check out the repository, compile it, and install it locally using the purpose-built Makefile rule: arsf_install.

cd ~arsf/usr/opt/alsproc
svn checkout http://rsg.pml.ac.uk/intranet/svnroots/arsf-internal/tags/alsproc-0.0.9
cd alsproc-0.0.9/src
make
make arsf_install

To Do

• Analysis and refinement of accuracy of individual points (ongoing)
• Geotagging las files (partially done)
• adding log and config files as VLRs to las files
• Better verification of proj4 strings
• Better verbose mode, current verbose mode is more like debug mode
• Better mechanism for passing values into alsproc, with checks for required arguments
• More reliable detection of test flightlines or verification of current methods
• scn_info is very slow for what it does, it should be able to skip unneeded data
• las12_las output module is very inter-dependant on the calling script, it should ideally be fixed or replaced