[gdal-dev] Improving NITF SICD support

Even Rouault even.rouault at spatialys.com
Wed Nov 25 07:04:58 PST 2020


On mardi 24 novembre 2020 16:32:14 CET Andrew Hardin wrote:
> Hi all,
> 
> I'd like to improve derived dataset support for SICD files. Here's one of
> the example files I'm working with:
> 
> https://six-library.s3.amazonaws.com/sicd_example_1_PFA_RE32F_IM32F_HH.nitf
> 
> This SICD file is a two-band NITF with an XML DES tacked onto the end. The
> two bands are {inphase, quadrature} and together they represent complex
> data. However, because they're in two separate bands, gdalinfo doesn't
> report any of the standard DERIVED_SUBDATASET functions for the complex
> data.
> 
> The desired end-state is to have standard DERIVED_SUBDATASET functions
> available for two-band complex data NITFs.  One implementation option(?)
> would be to write a new driver for SICD that's a specialized wrapper around
> a NITF dataset, but that feels heavy handed.
> 
> Any suggestions for how to go about this?

Too bad the producer doesn't use the native way of NITF to encode complex 
numbers (PVTYPE=C)

One way of solving this could be to use the "complex" pixel function of the 
VRT driver :
https://gdal.org/drivers/raster/vrt.html#default-pixel-functions

If SICD production is big enough to justify something more streamlined, you 
could as you suggest add at the end of the Open() method of the NITF driver 
some logic that would return a wrapping dataset that would do the assembly of 
the 2 components when a SICD product is detected, automating the on-the-fly 
creation of the above mentionned VRT.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list