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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
