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.

GTX Files

As ARSF often delivers data projected in the British National Grid, and Alsproc performs all projection operations using proj.4, performing the OSGM02 transformation specified by Ordnance Survey is essential to producing vertically accurate data. proj.4 can only perform grid-shift transformations vertically using .gtx files. For this purpose, a .gtx file had to be produced from the Ordnance Survey data from their website. You may need to produce or fine tune a .gtx file, so the tools used to generate them have been retained and are available in the svn repository under tools/gtx/.

You also require proj of at least version 4.8.0, the source code is available online, but be warned that as of the time of writing this doesn't compile out-of-the-box. It will compile, but requires minor adjustments to one source file and possibly the Makefile.

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"

Testing

Testing alsproc is easily possible without first installing it system-wide. All scripts should be able to run from the scripts/ directory. To test the processor itself you can build it as normal, and configure your .cfg file to point to this new executable file, rather than the official installed one, but note you will need to copy the .dll file into the src/ directory for any processing to work.

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

Common Problems

proj.i686

Q: What does this error mean.

wine: Bad EXE format for Z:\users\rsg\arsf\usr\opt\alsproc\alsproc.exe.so.

A: I don't know why it says that when you're missing dependencies, but on ARSF workstations this is probably going to be resolved by installing the proj.i686 package.

GDB

Q: Why doesn't gdb work on alsproc.exe? A: alsproc.exe is a winelib program, which means gdb annoyingly wont work with it. This is why alsproc needs better verbose and debugging modes. If you're really lucky you might be able to get winedbg to work.