[PATCH] GDAL utilities : parameters handling and user feeback

[pierrick.brihaye@…]

Hi,

Parameters handling looks sometimes inconsistent. Compare :

C:\OpenEV_FW>gdal_translate -co "COMPRESS=WRONG" demo-data\utm.tif test1.tif
Input file size is 512, 512
0.Warning 5: COMPRESS=WRONG value not recognised, ignoring.
..10...20...30...40...50...60...70...80...90...100 - done.

... which outputs a warning.

versus :

C:\OpenEV_FW>gdal_translate -co "WRONG=WRONG" demo-data\utm.tif test1.tif
Input file size is 512, 512
0...10...20...30...40...50...60...70...80...90...100 - done.

... which outputs nothing.

Also, I would like to have a smart detection of the ouptut format when possible :

C:\OpenEV_FW>gdal_translate demo-data\utm.tif test1.ecw
Input file size is 512, 512
0...10...20...30...40...50...60...70...80...90...100 - done.

... generates a GeoTIFF file, which is the default format, where I would
obviously expect an ECW file. I'm aware that there may be conflit issues,
especially with a jpg extension which can be handled by 2 drivers (define a
default one ?).

Furthermore :

- it would be nice to output creation options, default or not
- gdal_merge.py can't deal with wildcards : gdal_merge.bat -o output.tif
directory\*.tif would be very useful.

Such enhancements would IMHO make GDAL tools more friendly to the newbies.

Cheers,

p.b.

[warmerdam]

Pierrick,

Quite a few items here. 

1) It is true that GDAL drivers do not check for, nor report on unsupported
   creation options and this can be quite confusing.  My hope in introducing
   the driver level metadata describing options (try gdalinfo --format GTiff to 
   see this info) is that I can eventually use it for validation of creation
   options. 

2) Smart format detection based on extensions would be desirable, though by
   no means universally possible.  

3) Outputing all creation options (default or otherwise) would be nice, but
   would require quite a bit of work because knowledge of defaults is often
   embedded in the drivers themselves which aren't in a position to directly
   output anything.  I don't expect to act on this item. 

4) gdal_merge.py cannot handle wildcards *on windows* because the windows
   shell does not do wildcard expansion like on other platforms.  For
   executables there is an option to build wildcard expansion into the 
   program but this does not currently exist for scripts.  There might be
   some sort of python package that could provide this. 

For now I consider these all enchancement requests, and will leave the report
open for a while incase I can get to some of them. 

[pierrick.brihaye@…]

Hi,

>It is true that GDAL drivers do not check for, nor report on 
>unsupported creation options and this can be quite confusing.

And I think it will become more and more confusing when their number increase...
As an example an RGB .tif file is gdal_translate'd in color whereas it is
gdal_merge'd in B&W.

>(try gdalinfo --format GTiff to see this info)

This is OK, i.e. well documented. BTW :

gdal_translate|more

outputs :

Usage: gdal_translate [--help-general]
       [-ot {Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/
             CInt16/CInt32/CFloat32/CFloat64}] [-not_strict]
       [-of format] [-b band] [-outsize xsize[%] ysize[%]]
       [-scale [src_min src_max [dst_min dst_max]]]
       [-srcwin xoff yoff xsize ysize] [-a_srs srs_def]
       [-projwin ulx uly lrx lry] [-co "NAME=VALUE"]*
       [-gcp pixel line easting northing]*
       [-mo "META-TAG=VALUE"]* [-quiet]
       src_dataset dst_dataset

GDAL 1.2.1.0, released 2004/06/23

The following format drivers are configured and support output:
[snip the long driver list]

IMHO, the drivers list is not necessary for *default* help. Bug "General Command
Line Switches" would be helpful instead.

BTW, notice the need for a piped "more" : only 25 lines on Windows 98 ;-)

>Smart format detection based on extensions would be desirable, though by
>no means universally possible. 

I agree.

>Outputing all creation options (default or otherwise) would be nice, but
>would require quite a bit of work because knowledge of defaults is 
>often embedded in the drivers themselves which aren't in a position to 
>directly output anything.

Bad luck :-) I agree that "driver auto-description" would imply refactorings
that are not necessary worth the value.

>gdal_merge.py cannot handle wildcards *on windows* because the windows
>shell does not do wildcard expansion like on other platforms.

Bad luck (bis) :-)) Strange enough... shall we expect a better compatibility
with further Python versions ?

>For now I consider these all enchancement requests, and will leave the report
>open for a while incase I can get to some of them. 

Thank you. Nothing harmful in my RFE... I'm not a newbie anymore :-)

Cheers,

p.b.

[Even Rouault]

I'm enclosing a patch that implements validation of creation options towards the creation option list returned by the driver.

[warmerdam]

Some care must be used with this validation since at least a few drivers have options not described in the creation option descriptions. Sometimes this is due to sloth, in other cases very specialized options are implemented for specific purposes, and not considered appropriate to document for general users.

Actually, reviewing the patch, it does not actually seem to terminate processing when an error is reported. So I suppose it may be ok.

Even, could you go ahead and apply this in trunk,and send an email to the gdal-dev list describing what you have done so people have a little warning?

[Even Rouault]

Yes, I intentionnaly put warnings instead of failures. Commited in trunk in r12380. Email on gdal-dev list to come soon.

[warmerdam]

This seems to be working fine. Closing.