Looking through the code, I noticed the SWIG interface language. Going from
that, I began looking into SWIG and what it can do. In the documentation, it
talks about Byte string output conversion (in section 32.12.4). My
understanding from that section of the SWIG documentation
(http://swig.org/Doc4.0/SWIGDocumentation.pdf) is that SWIG assumes UTF-8 for
every char when sending it to python.
Do you have any experience working with the SWIG interface language? Is your
understanding similar?
Thanks!
Adam
________________________________
From: Brad Hards <br...@frogmouth.net>
Sent: Wednesday, November 6, 2019 11:02 PM
To: Edson, Adam Robert <are...@psu.edu>; gdal-dev@lists.osgeo.org
<gdal-dev@lists.osgeo.org>
Cc: Bradley, Eliza S <esb...@psu.edu>
Subject: RE: [gdal-dev] python GDAL issue
I think it should check the “type” value. My “maybe this could work” concept
was something like:
--- a/gdal/frmts/nitf/nitffile.c
+++ b/gdal/frmts/nitf/nitffile.c
@@ -2150,6 +2150,8 @@ static char** NITFGenericMetadataReadTREInternal(char
**papszMD,
const char* pszName = CPLGetXMLValue(psIter, "name", NULL);
const char* pszLongName = CPLGetXMLValue(psIter, "longname", NULL);
const char* pszLength = CPLGetXMLValue(psIter, "length", NULL);
+ const char* pszType = CPLGetXMLValue(psIter, "type", "string");
+
int nLength = -1;
if (pszLength != NULL)
nLength = atoi(pszLength);
@@ -2219,7 +2221,17 @@ static char** NITFGenericMetadataReadTREInternal(char
**papszMD,
if (psOutXMLNode != NULL)
{
- const char* pszVal = strchr(papszMD[(*pnMDSize) - 1], '=')
+ 1;
+
+ char* pszVal = strchr(papszMD[(*pnMDSize) - 1], '=') + 1;
+ if (strcmp(pszType, "IEEE754") == 0)
+ {
+ // TODO: fix
+ printf("IEEE754: 0x%02x 0x%02x 0x%02x 0x%02x\n",
pszVal[0], pszVal[1], pszVal[2], pszVal[3]);
+ pszVal = "FIXME1";
+ } else if (strcmp(pszType, "UINT") == 0) {
+ printf("UINT: 0x%02x 0x%02x 0x%02x 0x%02x\n",
pszVal[0], pszVal[1], pszVal[2], pszVal[3]);
+ pszVal = "FIXME2";
+ }
CPLXMLNode* psFieldNode;
CPLXMLNode* psNameNode;
CPLXMLNode* psValueNode;
(I think the pzVal might need to be changed to a union / class that has char*,
a double or an unsigned int; I haven’t dug further than this yet).
Brad
From: Edson, Adam Robert <are...@psu.edu>
Sent: Thursday, 7 November 2019 6:34 AM
To: Brad Hards <br...@frogmouth.net>; gdal-dev@lists.osgeo.org
Cc: Bradley, Eliza S <esb...@psu.edu>
Subject: Re: [gdal-dev] python GDAL issue
Looking at the code, it appears that GDAL actually hard codes any TRE that
takes anything that cannot be parsed as a string (e.g. nitfimage.c
NITFReadICHIPB). So, for BANDSB with its EXISTENCE_MASK and SCALE_FACTOR would
need to be hard coded as opposed to being defined just within the
nitf_spec.xml. Is this the correct interpretation?
Thanks!
Adam
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
