[gdal-dev] NITF DESDATA

[matt.nottingham at zen.co.uk]

Thanks for your quick & insightful reply.

I'll have a (re)look at getmetadata("tre") - but I seem to remember
that it didn't return anything, but I'll check again. I'll also look
into NITFDESAccess() / NITFDESDeaccess().

Thanks again,

Matt

Even Rouault writes:
 > 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