GEOG 583
Geospatial System Analysis and Design

Overview of Programming Languages for GIS


An essential element in designing many geospatial systems is the choice of what programming language (or languages) to use. Most of the exciting projects we can envision will involve at least some programming to customize existing tools, or to develop completely new ones.

There is an astounding variety of programming languages that are useful for geospatial professionals today. Wikipedia lists over 600 languages, which excludes the byzantine variety of dialects of BASIC past and present. We will focus here on those most relevant to GIS, which essentially means the most popular languages today, along with a few GIS-specific languages. I will add in a few general languages that show particular promise as well.

Computer screen filled with blurred text
Figure 7.01: There is a dizzying array of programming language choices.
Image credit: F. Hardisty

Select GIS Languages

Here is my take on current GIS languages, in rough order of importance for our community (MGIS program participants). If you see any that are missing, or you disagree with the order in which they are presented, please sing out by leaving a comment below on this page!

C++ -- C++ is a systems programming language, but has kind of lost its way with templates adding overmuch complexity. Not too many people would choose C++ for a new project, but most of the software you use every day was written in C++ (ArcGIS, Windows OS, Firefox, MS Office, etc., etc.), so it isn't going away anytime soon.

C -- C is the granddaddy of the family. When you need top performance, you use C, it is "close to the metal." This is great if you need to code a device driver, not great if you need to create a web app. Many lively open source GIS projects are written in C, for example, the Very Awesome GDAL (Geospatial Data Abstraction Library).

SQL -- SQL is used as a database access and control language. SQL is at the heart of many GIS operations. SQL is a great example of a language that has survived for a long time. Why is this? First of all, it is declarative instead of procedural. That is, SQL statements tell what you want to happen, not how you want it to happen. Therefore, implementation details are hidden and can change over time. This means SQL is set to remain relevant into a world of concurrent processing, which we will discuss in this week's tech trend.

Java -- Java is very popular for web programming in general, and is many programmers' general language of choice. It is one of the contenders for the most popular Open Source GIS languages, used in the GeoServer and JTS projects for example. Java is the most commonly taught language in universities and is arguably the current king of the hill for programming languages in general.

Python -- Python is often used as a scripting language, although many people swear by it for larger systems as well. It is currently gaining a lot of visibility as the primary scripting language for ArcGIS. It kind of functions like a new AML for ArcGIS, in that it provides a high level API to Get Things Done. This was a great choice on Esri's part, in my view, because Python makes a great "glue" language, and it is very easy to work with. It has many extensions, such as SciPython and Numerical Python.

C# -- C# was Microsoft's answer to Java, and is the flagship programming language for .NET. So, if you were starting to write a new add-on to ArcGIS, it would probably be the best choice.

Visual Basic.NET -- VB.Net is now basically an alternative syntax for the same C# runtime. All the power and complexity, none of the respect. :)

Flex -- Flex (from Adobe) had a reputation of being one of the easiest ways to create a RIA (Rich Internet Application). The Esri Flex API is one example of a popular implementation, but Flex/Flash have fallen out of popularity in the last couple of years as browsers and mobile devices have abandoned the Flash plugin.

JavaScript -- The current leader for Web User Interfaces. Google Maps is a heavy user of JavaScript, and so is the leading open source web map client (OpenLayers).

ActionScript -- ActionScript is the language behind Adobe Flash, which for awhile was the leading method for developing nice interfaces and visualizations on a web page. As has happened to Flex, it has fallen fast from popularity, as fewer and fewer platforms support it on the client side.

PHP -- One of the best ways to whip up an interactive website and, thus, quite popular.

R and S -- are scripting statistical languages with a lot of very sophisticated spatial statistics that can use some of the output from ArcGIS.

Ruby -- This is an older language that has become more popular recently. Ruby got major traction due to Ruby on Rails, which made it easy to set up a database-backed application. This has been extended to web maps by GeoCommons. Some other interesting neogeography sites such OpenStreetMap and WeoGeo are also done in Ruby.

Groovy, Jython, Scala -- These are all new languages for the Java Virtual Machine; I have hopes that these will mature into viable choices for GIS.

Avenue, VBA for ArcObjects -- The GIS Programming Hall of Shame. Avenue was in many ways a beautiful thing, so I was sad when Esri killed it. And now they are going to kill VBA for ArcObjects, which was never very beautiful but was quite useful. Sniff.

Programming Language Popularity

Try this!

Programming language history and popularity is important for the viability of a language. If you're interested, take a stab at the quiz for this week in Canvas - look for the Lesson 7 Programming Language Popularity Quiz, then check your answers by visiting the web pages below. These resources help keep track of what's hot and what's not.

Timeline of Programming Languages

Characterizing Programming Languages

One important means of characterizing programming language is according to their type systems, that is, the rules by which one can assign meaning to variables or objects. One fundamental divide is between static and dynamic typing. Statically typed languages such as C, C++, C#, and Java, evaluate type information at compilation time, and reject code that does not seem well-formed. The advantage of this is that many errors can be caught at compile time instead of run-time, and the earlier errors are caught, the easier they are to fix. The disadvantage of static typing is that it makes the code more verbose as type information is added, and you can sometimes spend a lot of time "making the compiler happy." Dynamically typed languages such as Python Lisp, and Objective-C, conversely, delay type checking until run-time. Therefore, you often don't have to specify the type of a variable before you use it. The advantage of dynamic typing is in ease of programming; the disadvantage is that some errors will slip through until the program is running, and these errors can be difficult to interpret.

Representing Languages

Languages themselves are endless clauses of textual representations of the underlying binary math. Computer operations are written in these textual representations that are lists of arcane and difficult operands and structures. To help in planning the programing of a set of instructions these can be related to one another using simple UML drawings and labels e.g., this IBM UML Implementation, as seen below.

Please watch the following video, Sketching with Rational Software Architect (a short demonstration of Rational Software Drawing) which will be useful later if you are not familiar with UML (7:38).

Click for Transcript of Sketching with Rational Software Architect

PRESENTER: This video demonstrates some of the new sketching capability available in the latest version of Rational Software Architect, version 8.0.1. Sketching tools allow architects and modelers to sketch out their designs at a higher level without first having to worry about specific model semantics. As you can see, ideas are quickly sketched out using just a mouse.

Once a design is sketched out, a modeler can then flesh out their sketch by naming figures, adding colors, or changing shapes. A modeler could also convert all or part of their sketch into a semantic model. In this case, we will select some sketch shapes and add them to a new UML model.

Having been added to the new model, we will now convert the selected shapes into UML elements. Even though we have generated a new separate model from the sketch, links were automatically added between the initial sketch and the final model. This allows storyboarding of the evolution of this design.

The tool palette was kept simple so that you can keep your focus on your design and not on what shape to pick for the customer service rep. Only when the sketch is finished do you need to think about adding color, changing shapes, or even adding graphics to the diagram. You could also convert any text in your sketch into rich text format, or RTF.

Sketch tools have been optimized to quickly record your ideas, including the ability to add several shapes at once in a grid. Sketch shapes can also contain other shapes to allow a sketch to be segmented and collapsed. The line tool can be used to quickly connect shapes.

The line tool can also help segment your sketch by creating borders. The text tool can be used to add text to any aspect of your sketch, including titles and line labels. You'll also notice that sketch shapes dynamically move to make room for new shapes. Line labels can also be added by clicking on the Line Rename button. Or you can just select a line and start typing.

The URL tool lets any sketch link into any other sketch or model, external file, or website. Each URL button can reference multiple external links. Sketches can be scaled by segmenting the sketch into multiple containers, which can then be collapsed. Or parts of a sketch can be used to create a new sketch or UML model or deployment topology, which is then automatically linked back into your original sketch at the sketch level or at an individual model element level.

Sketches can also be automatically converted to a polished diagram using Rational's themes. Rational's layer support allows you to dynamically show phases of a design. Sketch figures can be added to any existing Rational Software architect UML diagram. Sketch figures allow UML elements to be contained and collapsed. Sketch lines can be added between any element without regard to semantic meaning. Only later do you need to think about the type of relationship you want to create. Deployment topologies have several domains and numerous element types. You can use sketch shapes to map out a broad design first, then convert each shape to an exact model element in whatever order is most productive to you.

Instead of creating a sketch from scratch, you can also create a sketch from an existing UML or topology diagram. Or you can add any image to the background to either trace or compare against. Or you can just set the background to something you would typically sketch ideas on.

I would like to thank Daniel Bird, Michael Elder, and Daniel LeRoux for their contributions to Sketcher. You can find a trial version of Software Architect at this link.

These kind of programing tools can be used for not just planning but some can generate or alter the code. This does not mean that we can now program in natural language that is still a Holy Grail to be found (hopefully sooner than later). It does mean that language stubs can be generated and populated and some of the backbone programing tasks can be automated.