Ok never-mind, I found the problem was I was using a comma, to delimit
the tre-name and contents, and Franks note indicated an '=' was needed.
The NITF documentation page needs to be updated to reflect this.
Thanks;
Kurt Landrus
Progeny Systems Corp.
[EMAIL PROTECTED]
Office: 703-368-6107 x424
Lab: 703-368-6107 x520
Begin forwarded message:
From: Kurt Landrus <[EMAIL PROTECTED]>
Date: November 17, 2008 1:19:20 PM EST
To: Frank Warmerdam <[EMAIL PROTECTED]>, [email protected]
Subject: Re: [gdal-dev] NITF TRE support
Ok thanks for your reply. I downloaded the beta, and updated my code
to use the options in the create fcn.
I am now getting an error from the driver on the create call, for
the options.
I am creating the option with the TRE in the same format as loaded
using GDAL.
### saving TRE SENSRA = FSBS2 +35.000000-077.000000B+01200f
+74.998+000.000+014.996+70.000+009.998010.0N0020.0f075.0+1020m
### treContents = TRE=SENSRA,FSBS2 +35.000000-077.000000B
+01200f
+74.998+000.000+014.996+70.000+009.998010.0N0020.0f075.0+1020m
ERROR 1: Could not parse creation options SENSRA,FSBS2
+35.000000-077.000000B+01200f
+74.998+000.000+014.996+70.000+009.998010.0N0020.0f075.0+1020m
$ gdalinfo --version
GDAL 1.6.0beta2, released 2008/11/12
Here is the code snippet where this error occurred.
if (saveOk) {
// save TRE segments to dataset.
char *treValue = NULL, *treName = NULL,
*treContents = NULL;
char *tre = "TRE_SENSRA";
char **options = NULL;
parasite = gimp_image_parasite_find (image_ID, tre);
if (parasite != NULL) {
treValue = (char *) g_strndup(gimp_parasite_data
(parasite),
gimp_parasite_data_size
(parasite));
gimp_parasite_free (parasite);
treName = g_strdup(tre+4);
IFDBG printf( "### saving TRE %s = %s\n",
treName, treValue);
treContents = g_strconcat(treName, ",",
treValue, NULL);
options = CSLSetNameValue( options, "TRE",
treContents );
IFDBG printf( "### treContents = %s\n",
*options);
}
dataset = GDALCreate( driver, filename, width,
height, channels,
GDT_Byte, options );
if( dataset == NULL ){
g_warning("NITFview error opening dataset\n");
saved = FALSE;
}
Do you have any suggestions why it can't parse the options?
Thanks;
Kurt Landrus
Progeny Systems Corp.
[EMAIL PROTECTED]
Office: 703-368-6107 x424
Lab: 703-368-6107 x520
On Nov 13, 2008, at 8:30 PM, Frank Warmerdam wrote:
Kurt Landrus wrote:
Ok, I was looking through nithfile.c, am I correct in
understanding that the only TRE supported for saving is BLOCKA,
and that each additional TRE needs to be handled
individually?
I need to add support for the following TREs. But I don't really
need to add new SDE headers, but preserve the original values as
read
using GDALGetMetadataItem.
SENSRA
AIMIDB
ACFTB
Is there an easy way to save back an TRE that was read using GDAL
(/0 escaped string)
or should I pull out all the fields from the string, and then
reassemble them in a function as is done for BLOCKA?
Kurt,
The GDAL trunk code (ie. 1.6 beta2) does include generic support for
writing *image* TREs. Each TRE needs to be in the creation options
list as an item with TRE=<trename>=<content of tre> and the content
must be
escaped using the BackslashQuotable scheme.
This is exactly the same format the TREs are read into the TRE
metadata domain.
Currently there is no support for writing file TREs.
Best regards,
--
---------------------------------------
+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for
Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
