[Gdal-dev] Re: CreateCopy vs Create

[Frank Warmerdam]

gwalter at atlsci.com wrote:
> Hi Frank,
> 
> Thanks, that was helpful.  If you could bear two more little questions:
> 
> 1) Is gdal-dev the equivalent of openev-discuss?  I found a link on the website
> that referred to the group, but when I tried to click on it, it came up with a
> page warning that it was an age-restricted site and had adult content???  I would
> be interested in receiving posts regarding changes made to gdal and answers to
> general questions.

Gillian,

I have migrated gdal-dev to remotesensing.org.  But yes, gdal-dev is the
general discussion list for GDAL related issues, much like openev-discuss.

> 2) Is there a way to test in advance which output data types are supported for a
> given file format?  I looked at the metadata options in gdal.h and in some of the
> drivers, but it looks as if this is dealt with within the creation functions.
> Are there any plans to pass up this info (eg. by creating, for instance, a
> metadata string or strings along the lines of the DCAP_CREATECOPY)?  It might be
> useful later on if we ever do more rigorous error handling (or for making certain
> options sensitive or not depending on the chosen format).  Then again, maybe it
> would just bloat things.  There are error messages printed in the terminal at
> least.

There was no way to pre-detect what data types a given driver will support at
creation time.  However, I agree this would be useful, so I have created the
DMD_CREATIONDATATYPES metadata and committed support for it to all drivers.  It
is metadata on the driver containing a list of space separated data types supported
by the Create or CreateCopy method on the driver.

For instance, for GeoTIFF it looks like this:

     poDriver->SetMetadataItem( GDAL_DMD_CREATIONDATATYPES,
                                "Byte UInt16 Int16 UInt32 Int32 Float32 "
                                "CInt16 CInt32 CFloat32 CFloat64" );

> Also, I have created some help files and screenshots here for the export tool for
> linking in with gvhtml's set_help_topic function, though I haven't checked them
> in.  Peter suggested that we might want to come up with a naming convention for
> tools, and that Tool_Export may be more intuitive than Tool_GDAL for the average
> openev user.  Maybe Tool_Export.py for the tool and a corresponding
> Tool_Export.html in the html directory or something along those lines.  

This seems reasonable.

 > I've also added (locally) Andrey's change for auto-detecting create-enabled formats,
 > though
> I modified it to require that Create and CreateCopy both be available because
> gdal_translate needs both depending on the circumstances.  Unfortunately, this
> only extends the list by one: the ever-popular HFA.  Once the scaling options
> have been added to VRT, I'll try to modify it to use CreateCopy() and modify
> VRT's at the python level instead.

Once the scaling is incorporated into VRT format, gdal_translate should never
need to call Create() unless there is no CreateCopy().

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