[pdal] NITRO NITF

[Howard Butler]

On Nov 14, 2013, at 8:52 PM, Murphy, Robert T. <ROBERT.T.MURPHY at leidos.com> wrote:
> 1. I am building PDAL under Fedora 19. I want to support NITF. Should only the NITRO NITF library from github ( /hobu/nitro ) be the one built to use with PDAL, or will it also work with the NITRO NITF repository from SourceForge.  I see you use NITRO NITF version 2.7, but diff'ing them show some source code changes.

The SourceForge version had a number of deficiencies, with the biggest being that it didn't support dynamic linking properly on Windows (a requirement of maintaining LGPL compliance). Additionally, the authors weren't interested in a CMake-based build system and were happy with WAF. I couldn't get WAF to work on *nix, let alone Windows, so I finally gave up, dropped it into github, and rolled a CMake-based build system that properly exported the symbols necessary to use Nitro on Windows dynamically linked. I left most of the repository alone, however, to ease merges back from the master tree. I hope some day the authors are interested in my contributions, but what exists now at http://github.com/hobu/nitro is sufficient for the LAS-in-NITF requirements I have.

> 2. Using the /hobu/nitro repository, the build instructions indicate to use WAF as is typical of NITRO NITF. When I ran WAF it threw an error ("build module not found"). However I saw cmake files and ran it and it built with no problem. Is CMAKE good to go to build the lib? It only produced dynamic linked libraries (libnitf-c.so and libnitf-cpp.so). I tested it and it was working.

Yes the CMake-based build system is good to go, and is very likely going to be the easiest to use. It doesn't have J2K detection and other things auxiliary library support yet, because I only needed to write LAS-in-NITF files to meet my obligations. LAS-in-NITF is the horrid turducken you imagine it to be, and PDAL's metadata support is limited to IDATETIM and a few other items. You'll have to read the source code of drivers.nitf.writer for more information. Sorry there isn't more yet.

drivers.nitf.reader is implemented using GDAL's NITF support. This is a little bit different than Nitro, and I'd like to someday rework the reader to use Nitro as well, both for a simple story and implicit compatibility. 

Hope this helps,

Howard