[gdal-dev] NITF DESDATA

[Even Rouault]

Le dimanche 07 octobre 2012 10:57:05, matt.nottingham at zen.co.uk a écrit :
> Hi,
> 
> I'm trying to access the DESDATA segment of a nitf file. Nothing
> appears to happen in the default build - i.e. getmetadata("DES") (or
> getmetadata("NITF_DES")) doesn't return anything. Looking at the NITF
> driver I can see it has all of the code necessary to read the DES part
> of nitf files, but its all protected by a #ifdef ESRI_BUILD. If I
> bodge the fmts/nitf/gnumakefile (I'm on FC16) to have a -DESRI_BUILD
> in the CFLAG variable then it all works as expected. So my questions
> are:
> 
> 1) Have I missed something stupid and desdata can be read by a default
> build? (I'm using gdal 1.9.0)

Reading DES with GDAL API is certainly an advanced capability, so nothing 
"stupid" missed here.

> 
> 2) Why doesn't the default build of gdal read desdata? (It seems odd
> to have all the code then not use it - there must be a good reason for
> that).

In fact, you can read the TREs that are in a DE segment by using the 
GetMetadata("TRE") or GetMetadata("xml:TRE"). But if you are interested in the 
raw segment information, you'll have to use the NITF C API, which is semi 
public (isn't guaranteed to be as stable as the GDAL C API). See 
NITFDESAccess() / NITFDESDeaccess()  in frmts/nitf/nitflib.h

> 
> 3) What is the ESRI_BUILD flag? I can't find any docs on it - its not
> clear which option(s) set it.

ESRI_BUILD protects code paths that are specific (or deemed as specific) to ESRI 
needs. They have their own branch of GDAL with some tweaks that haven't been 
vetted as general purpose (or whose rationale has not been clearly understood 
to enable them by default).

In the case of NITF, there are sometimes overlaps between what they have done 
and what exists in standard GDAL. They have also selected Base64 escaping 
whereas the rest of the NITF driver traditionnaly used a "backslash quoting" 
escaping. So the merging isn't easy, and in that case of DESDATA, we haven't 
yet figured out how to do it (see NITF_DES_XML_DATA_CONTENT_DESDATA )

> 
> Sadly Google has failed me on the above - I can see people *are*
> reading it (http://trac.osgeo.org/gdal/ticket/4803), so why can't I!

The reporter of the ticket uses NITFDESAccess() directly in its application.

> 
> 
> Thanks very much,
> 
> Matt
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev