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.notting...@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@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev