GDAL Command line tool naming consistency

[timlinux]

Maybe a thought for GDAL 2.0 one day...

I constantly find that I can't remember the spelling of tools because they arent consistently named:

gdal2tiles.py       gdalenhance         gdal_polygonize.py
gdal2xyz.py         gdal_fillnodata.py  gdal_proximity.py
gdaladdo            gdal_grid           gdal_rasterize
gdalbuildvrt        gdalident.py        gdal_retile.py
gdalchksum.py       gdalimport.py       gdal_sieve.py
gdal-config         gdalinfo            gdaltindex
gdal_contour        gdalmanage          gdaltransform
gdaldem             gdal_merge.py       gdal_translate
gdal-ecw-build      gdal-mrsid-build    gdalwarp

It would be nice to standardise them to use the same naming convention e.g. gdal_ prefix or just gdal prefix. I realise the possibility of you doing this now is around about zero given the entrenched user base you currently have, but maybe you could at least give some thought to new tools being added to the toolbox.

If there is an underlying logic to the naming convention used, it is not obvious (to me) by looking at the list above.

[Even Rouault]

Has been already suggested in http://trac.osgeo.org/gdal/wiki/GDAL20Changes

[warmerdam]

I recognize the inconsistency, but I am dubious that being consistent with new tools would help that much. I have no idea where gdal-ecw-build and gdal-mrsid-build come from. I don't even think making them consistent at GDAL 2.0 is a particularly good idea since it would break many processing scripts unnecessarily.

Given my unwillingness to take any action, I'm going to close this ticket so it doesn't sit open diverting attention from other tickets.

[Even Rouault]

As far as I remember, gdal-ecw-build and gdal-mrsid-build have been introduced by the UbuntuGIS team in their gdal packages to make building of the plugin a bit easier. Cf ​http://www.osgeo.org/pipermail/ubuntu/2009-June/000054.html

[timlinux]

Replying to warmerdam:

I recognize the inconsistency, but I am dubious that being consistent with new tools would help that much. I have no idea where gdal-ecw-build and gdal-mrsid-build come from. I don't even think making them consistent at GDAL 2.0 is a particularly good idea since it would break many processing scripts unnecessarily.

Given my unwillingness to take any action, I'm going to close this ticket so it doesn't sit open diverting attention from other tickets.

Ok no problem - thanks for taking the time to respond to the ticket. As I said in the ticket, I wasn't too hopeful of it being addressed, but hey, if you don't ask, you don't get! :-)

Regards

Tim

[maphew]

I think about this often, every week. I completely understand the treacherous nature of renaming something that's been in use for so long. No matter how careful one is there will be many many cases where it breaks something that is tried and true, and we just can't have that.

I have an idea about how we can have our cake and eat it too though: Create a wrapper program called simply gdal. The gdal wrapper has an internal lookup table which calls the historical unchanged utility name. For example:

gdal warp      --> gdalwarp
gdal translate --> gdal_translate
gdal build ecw --> gdal-ecw-build

this would also open the door to potentially harmonizing the syntax for options (some utilities use either -co or --config, others only --config; some must have infile before outfile, others out before in).

A related idea is gdal as a shell:

$ gdal
gdal> opts = compress:lzw tiled:yes mem:1024 cachemax:500 compress_overs:jpeg
gdal> build vrt infile.tif in2.tif in3 interim.vrt
gdal> warp interim.vrt interim_albers.tif -t_srs epsg:3578
gdal> translate interim_albers.tif final.tif -a_nodata 0
gdal> overviews final.tif -r average 2 4 6 8 16
gdal> exit
$

Or maybe they are both the same thing. No parameters invokes the shell and with parameters just does stuff.

I don't know if this is feasible. If not please feel free to close the ticket again.

[maphew]

oh yeah, forgot one of the key features this would allow: gdal help or gdal commands to show list of all available command line utilities ;-)

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.