Fwd: [gdal-dev] NITF TRE support

[Kurt Landrus]

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.
klandrus at progeny.net
Office: 	703-368-6107 x424
Lab: 	703-368-6107 x520



Begin forwarded message:

> From: Kurt Landrus <klandrus at progeny.net>
> Date: November 17, 2008 1:19:20 PM EST
> To: Frank Warmerdam <warmerdam at pobox.com>, gdal-dev at lists.osgeo.org
> 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.
> 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20081119/92b0b0ff/attachment-0001.html