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,,