id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 6285,Possible bug in NITF TRE parser engine,bradh,warmerdam,"I'm working on adding support for the ENGRDA TRE for NITF. The XML is relatively straight forward: {{{ + + + + + + + + + + + + + + + + }}} Unfortunately it doesn't work right in GDAL (it does work OK in my Java parser). I see: {{{ }}} Note that the ENGLBL in the second block is truncated and some of it ends up being parsed as ENGMTXC and ENGMTXR. So I would expect to see: {{{ }}} (in both cases I've removed the other 21 groups - this is already long enough) I think the problem is that the parser is using the ENGLN value from the first group when parsing the second group (and every other group after that). I have a suggestion that fixes this: {{{ diff --git a/gdal/frmts/nitf/nitffile.c b/gdal/frmts/nitf/nitffile.c index 9bda6d7..68cae38 100644 --- a/gdal/frmts/nitf/nitffile.c +++ b/gdal/frmts/nitf/nitffile.c @@ -2145,7 +2145,6 @@ static char** NITFGenericMetadataReadTREInternal(char **papszMD, if (pszEqual != NULL) { nLength = atoi(pszEqual + 1); - break; } } papszMDIter ++; }}} However I'm not confident that I understand the code well enough. So happy to propose a pull request (or attach a patch), but not sure its right, or what the other consequences are. I do have redistributable files that demonstrates this, the smallest one is attached.",defect,closed,normal,1.11.4,GDAL_Raster,svn-trunk,minor,fixed,,