Hail the Command Line
GIS in General, Open Source February 24th, 2006In this day of GUI GIS, sometimes you can’t beat the good old command line for getting a job done, regardless of whether you use Linux/Unix, Mac OS X, or Windows. This may sound strange coming from someone heavily invested in a GUI project but its true.
Case in point - I recently needed to create two seamless regional layers from over 100 individual shapefiles. The source shapefiles were stored in individual subdirectories two levels deep. This translates into a lot of pointing and clicking to add each shapefile to the appropriate list in a GUI prior to appending them all together. To make matters worse, I had two shapefiles in each subdirectory that needed to be merged, resulting in two layers. This would mean even more pointing and clicking.
Enter a humble Ruby script (about 15 lines with comments) mixed in with a little bit of ogr2ogr and the process takes no time at all. Of course you can substitute Ruby with Perl/Python/Shell or whatever. Fortunately the individual files were consistently named in each directory. The script just gets the list of top-level directories, creates a command to pass to ogr2ogr and executes it, successively appending the individual shapefiles to create the regional shapefile. This takes like 10 seconds to run. Creating the second shapefile was a matter of changing a line or two in the script (I didn’t take time to make it robust with argument handling) and in another 10 seconds the job is done. In the GUI world, I’d still be clicking around (Ok, I’m exaggerating but you get the idea).
Of course most of the GUI Desktop GIS applications provide some sort of scripting language to do this sort of job, but often navigating the complicated API associated with an embedded scripting language takes longer to do than the actual job. If I’m in a hurry, I just want to get the job done, not navigate some complex object model to work out how to do a simple task.
There seems to be a trend in the commercial GIS world away from command line interfaces in favor of heavy GUI toolboxes and interfaces. I often find these limiting and extremely slow, if they operate at all. Mixing a scripting language executed from the command line with the many excellent Open Source GIS tools (GDAL/OGR included) often provides a fast and powerful way to get the job done.
February 24th, 2006 at 8:07 am
Excellent point! I think GUIs are a great way to explore a process, do a quick and easy job and to learn the basics but it just doesn’t scale well. Doing something once or twice in a GUI works fine but if you’ve got to do it more than a few times, you almost always benefit from writing a script.
To be fair to the commercial GIS world, ESRI at least has the model builder which allows you to string together various tools in a visual flowchart style and parametrize them. You can even output the model to a python script. But all in all, its a shame that ESRI has put their ArcInfo Workstation CLI on the back shelf for so long. Maybe I’m biased since I learned GIS at the ArcInfo command line but it is still more powerful and stable than anything in their ArcGIS GUI line of products.. yet some people don’t even know it’s there!
March 6th, 2006 at 3:12 pm
Two places where command line would be very useful in QGis (and other OS Gis projects):
* managing spatial queries. I’m still missing the “MapBasic Window” in MapInfo and a simple SQL syntax to express spatial operations;
* managing import/export. OGR — to cite a specific software — has options to deal with several different import problems. Unfortunately GUI “Open File” and “Import” dialogs show (and handle) only defaults. In QGis this is very frequently wrong, expecially since Frank Warmerdam choose a strict interpretation of formats (expecially DGNs and Shapefiles).
Anyway, GUI alone is a good approach but “hides the engine” when the user asks for a more focused action (in this case, hiding obscure options in deep menu structure is a problem, not a solution), CLI alone causes steep learning curve. Just show the output of menu commands for CLI users (or future users) and implement useful commands in the GUI. Good interface design is just deciding where to put rarely used commands without burying them or dropping them out.
Cheers and thank you.
Carlo
June 18th, 2006 at 10:55 am
Of course the command line is more efficient, for those who can ‘Write the language’.
It should be realized though, that if you can ‘write a picture’ there ’should’ be an easier way to ‘draw’ a picture.
This is basically all we are trying to do with GIS. Attach information to pictures.
The complexity of GUI should only be for the programmers who are trying to develope the interface, and not for the end user.
Of course, GUI is in my blood, coming from
C64,Amiga, and finally over to Mac.
I dream in pictures, not code
February 3rd, 2008 at 11:30 am
[…] go—I was thinking about posting on this same topic just the other day, although I may be repeating myself. The efficiencies of the command line cannot be overstated. I too have seen that deer in the […]