[gdal-dev] NITF TRE support
Kurt Landrus
klandrus at progeny.net
Mon Nov 17 13:19:20 EST 2008
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.
klandrus at progeny.net
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, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush | Geospatial Programmer for
> Rent
>
More information about the gdal-dev
mailing list