[gdal-dev] Policy for C/C++ API for GDAL 2.0 ?

Homme Zwaagstra hrz at geodata.soton.ac.uk
Mon May 21 11:47:30 EDT 2012


On Mon, May 21, 2012 at 09:06:06AM -0500, Howard Butler wrote:
> 
> On May 20, 2012, at 12:23 PM, Even Rouault wrote:
> > -------------------------------------------------
> > Syntax of command line utilities
> > -------------------------------------------------
> 
> I'd like to see some normalization of the arguments, arrangement, and help for the utilities. I'm also unsure how to do so without disrupting everyone.

I'd also love to see some normalisation of the utilities' help, naming
and calling conventions. In an ideal world (!) I think the git and svn
commands provide a great pattern of use: one 'master' executable
providing access to various 'subcommands'. For GDAL this might be
along these lines:

  /usr/bin/gdal_translate -of JPEG src.tiff dst.jpg
  -->
  /usr/bin/gdal translate -of JPEG src.tiff dst.jpg

  /usr/bin/gdalwarp -t_srs '+proj=utm +zone=11 +datum=WGS84' raw_spot.tif utm11.tif
  -->
  /usr/bin/gdal warp -t_srs '+proj=utm +zone=11 +datum=WGS84' raw_spot.tif utm11.tif

The advantage here is that there is a unified hierarchical commandline
interface to all the gdal functionality which is also extensible in
terms of adding new commands and options.

The 'gdal' master executable could also accept options that are
globally applicable to all subcommands e.g.:

  /usr/bin/gdal -quiet subcommand -options

It looks like GNU `argp_parse` could help build such an interface, or
at least provide a reference:
http://www.gnu.org/software/libc/manual/html_node/Argp.html#Argp

Using this paradigm there might need to be a separate `gdal.py` along
similar lines to a binary `/usr/bin/gdal` in order to take care of the
python based utilities. The `argparse` module could be helpful here:
http://pypi.python.org/pypi/argparse

In terms of implementing this with minimal disruption the above could
be something as simple as a wrapper to existing utilities, easing the
migration for users and developers alike.

Alternatively the existing utilities could be 'frozen' whilst new
development takes place within new utilities (whichever new naming
convention is chosen). A configure option (--disable-gdal1?) could
determine whether the gdal1 utilities are installed on the system.

Best regards,

Homme

-- 
Homme Zwaagstra
GeoData Institute
University of Southampton



More information about the gdal-dev mailing list