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