GaaS: The Future That Wasn’t

Years ago in the Arc/Info world, we used to perform most of our geoprocessing in ArcInfo Workstation on Windows.  But when we needed to really get work done, we’d use a HP-UX beast of a server to handle some of the more complex geoprocessing.  It was really easy to do right, Esri even use to have some tools to help you accomplish this.  I remember thinking that very soon we’d be able to offload most geoprocessing on remote constellations and then just get back the results.  My personal workstation wouldn’t be bogged down with processing and the server would be doing what we paid good money for.

Well we didn’t know what we were talking about at the time was “GIS as a Service”.  Mostly because we didn’t think of clouds anything more than rain makers.  But the idea of offloading our geoprocessing was something to a person we’d wager would be built into GIS by now.  Of course products like ArcGIS Server and FME Server can run processing remotely but it is not built into workflows.  You have to go out of your way to author scripts that can handle this. I’m curious why things worked out this way.

It could be that with Arc/INFO on Unix going away there wasn’t servers that could handle geoprocessing.  Or it could be that workstations these days are so fast that you don’t need to remote process.  Maybe I’m just old and stuck in my ways that I want to use an Unix server for processing, maybe put a couple of Perl scripts in there and call it a day.  But I think I’m disappointed that we just haven’t seen that much uptake on remote geoprocessing.  The only workflow I’ve used this on that was supported by the software is authoring on FME Desktop and running those workbench scripts on FME Server.

I guess we always assume there will be flying cars and houses on the moon but we’re left with airport departure TVs that show the blue screen of death, smartphones that can be hacked with SMS and our credit cards being stolen left and right.  The reality of GIS in 2015 is it is still enterprise work being done in a workgroup fashion.  GIS isn’t taken seriously by IT because we don’t take ourselves seriously.  Hiding in a corner “doing GIS” is how we’re seen by others.  Time to break the mold.

Scripting in Python

When I first learned that ArcGIS 8 Desktop wasn’t going to support either Avenue or AML, I was very unhappy. As anyone who had done analysis with ArcInfo can attest, I had quite a library of AML scripts to accomplish almost anything. With ArcGIS 8 Desktop, I couldn’t use any of them. The thought I guess was to use Visual Basic or C++, but writing scripts with either of those two languages was like using a sledgehammer to kill a fly, I just stayed with ArcInfo Workstation and the good old AML. Avenue wasn’t supported either (I guess the boat has sailed on Open Source Avenue huh?), but as long as I could still use AML, I was fine. Well fine until we started using Personal Geodatabases. I couldn’t do a thing with those and the number of coverages we were maintaining really dropped as most people have standardized on Shapefiles or the aforementioned Geodatabase.

Well with ArcGIS 9, we finally have a real scripting language again and even one that has made me stop writing AML scripts. I’ve really gotten into scripting with Python and it really has saved me quite a bit of work over having to try and do the same tasks with AML and converting Shapefiles and Geodatabases with ArcCatalog. With Python support came some great Python supporters and many of them have written some good articles to get started. A great resource is an article written by Howard Butler for ArcUser (don’t forget to check out Howard’s blog also!). Beyond that, all you have to do is head down to your local Barnes and Noble to find just about any Python book to get you started. Unlike AML or Avenue, Python is really easy to get started with and the community support available is much greater than ESRI ever had with Avenue or AML or even those of us who used SML and PC/ARCINFO. 😉