Opened 13 years ago

Closed 5 years ago

#3818 closed enhancement (wontfix)

GDAL Command line tool naming consistency

Reported by: timlinux Owned by: warmerdam
Priority: lowest Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc: Mateusz Łoskot

Description

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.

Change History (8)

comment:1 by Even Rouault, 13 years ago

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

comment:2 by warmerdam, 13 years ago

Resolution: worksforme
Status: newclosed

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.

comment:3 by Even Rouault, 13 years ago

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

in reply to:  2 comment:4 by timlinux, 13 years ago

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

comment:5 by maphew, 13 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:6 by maphew, 13 years ago

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 ;-)

comment:7 by Mateusz Łoskot, 12 years ago

Cc: Mateusz Łoskot added

comment:8 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.