The Future Of GIS Scripting? Designing A Functional GIS Using Simplified Coding
Suppose you could write yourself a working GIS at home, in a very simple language. Would you?
In this article, I would like to seriously consider that question. People sometimes think that it is preferable that GIS scripting languages be complex, in order to retain the under-the-hood power of those languages. This may be a false dichotomy, however; I think it’s much more clearly the case that GIS programming and scripting can, and should, be made simpler for the end user.
Before I start explaining why I think this is true, let me unveil to you an example of some very simple code I wrote that produces something with functional GIS capabilities. It’s a small example, which draws a polygon (showing the U.S. state of Iowa) from geographic point coordinates, and permits the user to zoom, pan and recentre the object on the screen using buttons in a graphical user interface.
Click on the above picture to download a ZIP archive folder for the project – note that the folder contains the executable application.
The code for this example application was entirely written in a language designed to be used by late elementary and early junior high school students. The question I want to ask, in all seriousness, is why GIS professionals are writing code in more complicated languages when it is possible to do this instead.
I ask this question for a reason. One of the seemingly inevitable changes that GIS professionals must put up with in their line of work is the obsolescence of scripting languages. When I first worked with ESRI products in my younger days, there were two approaches taken to scripting. ArcINFO used the Arc Macro Language (AML), which worked more as a command line style of interaction between the user and the system than scripting per se; the newer ArcView used Avenue which was more of a conventional a scripting system. Both have now gone the way of the dodo; ESRI no longer provides support for either of these once-essential languages.
Nowadays, GIS professionals go out of their way to learn the Python language, since that is the language in which most scripting is done, as well as application development. Since Python is a compiled language with full object orientation, it is certainly an improvement on the inflexible AML and Avenue languages. GIS has turned a corner by graduating to a more flexible language, which can also contribute to the expansion of an open-source GIS culture and the sharing of code modules not just to improve upon a particular map, but to expand upon the capabilities of GIS applications themselves, or to create entirely new ones.
Given all this, it is easy to cast aspersions on the earlier professionals who, it would now appear, wasted so much of their time learning scripting languages that no one uses any longer. To some extent, of course, that is the nature of the beast – when one works in a field where new applications replace old ones in a short period of time, one always runs the risk of acquiring knowledge which may become obsolete in that short period of time.
However, because one sees obsolescence potentially looming around the corner, one does not necessarily have to take it for granted. Scripting languages will also change – Python will in all likelihood not remain at the top of the heap for GIS programming forever. But we can appreciate the direction in which changes to scripting languages are likely to occur.
It seems relatively certain that two pressures will be brought to bear on scripting language development in the future – there will be pressure for a scripting language to be as simple as it can be, for the user; and, there will be pressure for the language to remain as powerful as it can be, in terms of what it can accomplish for the user.
Recently, I gave those two pressures some thought. Why would it not be the most likely of progressions, I reasoned, that the simplicity of code would be formally split off from the powerfulness of underlying tools. Indeed, that has been the overall trend since computing started – computer scientists have long distinguished between levels of languages?
The kind of language “closest to the hardware” is machine language – zeroes and ones. Because it would be excessively tiresome for programmers to program in zeroes and ones all the time, languages of increasingly greater complexity have been created. One more step “further from the hardware” is assembly language, which aggregates the zeroes and ones in a bit more of a user-friendly fashion, so that one can make changes to them much more quickly. Another stage removed from the hardware are “high-level” languages, which can be as simple as a “Basic” language or as complex as the more modern C++, Java, or Python. These languages aggregate the assembly language instructions, in the same fashion that the assembly language aggregates the zeroes and ones.
Scripting languages have also long been conceptualised as “very-high-level” languages. The old Avenue scripts, for example, ran within an application written in a different programming language than Avenue; they ran “on top” of the high-level language, in other words.
Moving on to Python in order to get the power of a compiled language that can create applications is a step backward, seen conceptually through that lens. The advantage the old Avenue used to give was simplicity of code; the only problem was that in order to get that simplicity, you didn’t get to also learn how to program applications. This is the importance of the shift to Python.
But what if you could get the best of both worlds? What if you could get the simplicity of coding of the old Avenue without sacrificing the power of a compiled language that could write applications?
My view is that this is possible. I thought to myself, what if there were a language out there written with the specific goal of being simple, but written on top of a powerful compiled language, so that the strengths of that underlying language were not lost? That thought led me to search around on the internet until I discovered the SIMPLE language, a language specifically written to be understandable by those at the upper elementary or junior high school level. (Check out http://www.simplecodeworks.com/New/tutorial/ for a quick overview of the language – be forewarned, the website is also geared for children, so this will not seem like a very professional site by our standards.)
SIMPLE is a language that has a grand total of 23 keywords, and it accomplishes most of what it does through an additional collection of functional subroutines assembled in the language’s system library. It is very easy to use, and thus script code is far more intelligible to the average person in SIMPLE than it is in Python. But in addition to that, SIMPLE is written “on top” of C++, and this means that any code that can be written in C++ may appended directly to the SIMPLE code (just by preceding the C++ code with “C++” and following it with “C--”).
C++ is not in itself a perfect language on which to perch SIMPLE. The major drawback of C++, indeed, is that it does not work on all platforms. But this is in a sense beside the point. It would as easily be possible to create the same SIMPLE language keywords and system library on top of Java, which does work on all platforms. It could also, if we get right down to it, be constructed on top of Python. The greater issue is that we can still separate out the important programming functions for the user from the “stuff under the hood” we can get at using a more powerful underlying language.
None of this is meant to unduly slag Python, which is certainly a far more comprehensible language than many previous languages GIS professionals have had to deal with. Indeed, simplicity of code was one of its design considerations. But, not surprisingly, SIMPLE’s still a lot simpler.
Check out the code for my GIS application showing the state of Iowa. Here are the text files SIMPLE used to compile my executable:
* The calculation of the centre of the polygon map extent
Wouldn’t it be much easier to deal with that? You be the judge. For myself, I think the productive capacities of GIS would be absolutely liberated if even the average user felt comfortable writing scripts that could contribute to some wider open-source GIS project.
This is interesting code, but I don’t like the Iowa.txt file. It would be more efficient to have a file of three columns of coordinates, x, y and z, rather than all these SET commands. Most data files would have the three columns and then have a routine to read that data.
Hi, Brian.
I agree with what you’ve posted here. I’ve been doing further work on this program (which now does Earth Centered-Earth Fixed translations of latitude/longitude/altitude coordinates as well, by the way, so it is now a 3D modeling program). I wanted to be able to bring in any CSV file of x, y, z coordinates in order to use the program. However, I solved this problem in perhaps the opposite way from the way that you suggested – instead of having the program read the CSV file of coordinates directly, I wrote a short new application that converts my CSV files into a text file with all of my “Set” commands. The upshot is the same, my app reads data originally provided in a CSV file that has only the x, y, z coordinates. It’s just that I had my app write a new text file rather than read directly from the CSV.
You might ask why I went to that kind of trouble. Either way, of course, the problem gets solved, but this might seem like an extra step. The only answer I have is that I preferred to have “strongly-typed code”. I wanted a file that showed directly to which variable each of the values in the CSV got assigned. This might help me debug, and additionally might help me find a particular set of coordinates in a long list. Also, I couldn’t link directly to the CSV file as a module because the CSV file is not written in Simple. But by converting the CSV file into Simple code, I can link the converted file into my main program simply by calling the module. So in that sense it’s a little simpler.
Also, I am aware that some languages (Python, for example) have commands that let you feed in a long list of data coordinates without repeating the command umpteen times. That is preferable, and perhaps it is a deficiency of the Simple language that it doesn’t really do that. It wasn’t my point in this article, though, to say that the Simple language is absolutely the simplest that could ever be devised. In some areas, Python coding is simpler. In most, however, Simple is simpler. Beyond that, I was more interested on the whole in demonstrating that GIS coding, in general, can be a _lot_ simpler than it currently is.
Anyway, I appreciate the interest you’ve shown in my work, and am thankful for your thoughtful comment. I hope to make public my most recent work, with the 3D functionality and the program that writes modules from CSV data, in the next few weeks.