What is GIS? (continued)

In the previous post, I cite Paul Ramsey, Brian Timoney, and James Fee’s various posts on changes in the geospatial sector.  Paul responded with a great post refining his position on Spatial IT vs. GIS.  Due to my argumentative academic training, I can’t leave well enough alone.  Besides, I said I’d follow up on Brian’s post, and the following does so, at least indirectly.

Paul hits the problem on the nose with the following line:

“… (A)s we know, GIS courses are just the bait in the trap, to suck naïve students into a career where” they become either a “digitization monkey” or “map monkey”

Ah, so true, so true.  In brief (ha!), Brian Timoney and James Fee’s posts point to what Paul describes as the end of typical GIS grunt work– work which will “be folded into generic IT workflows, automated, and systematized”.

(Short, but relevant aside.  My wife’s training is in Political Economy and Political Ecology.  She out ranks me with a Ph and D after her name.  She critiques economic systems and is good at it.  Whatever follows of my analysis which is good can be attributed to her.  Whatever is bad, is mine and mine alone.)

So, why so many years of grunt work before the automation?  Why now the end that Brian and Paul declare?  Why must analysts be programmers as Fee declares?  Simple: when I wrote that ESRI was starting to directly directly compete with their a) resellers and b) users, I knew that wasn’t really true.  ESRI has almost always had a) resellers and b) software operators, with a few rare users.  The software operators were valuable to ESRI in order to sell licenses.  In other words, the software was the capital, the software operators the labor, even if that labor was employed by others.  As ESRI gets squeezed, they are in no position to keep all their excess labor.  They will streamline workflows and provide hosting services to drive down cost for the end user at the expense of labor and middlemen.

Your way out as a software operator, is to (in some small or medium or big way) make the software your own, to move from operator to engineer.  Thus, to be an analyst you must be a programmer.  Don’t worry– there’s plenty of space still for good geospatial software engineers.

Finally, Paul draws the distinction between GIS/Planning as

• high touch and interpersonal;
• qualitative and presentational;
• ad hoc and unpredictable.

as contrasted with those flows that can and should be automated.  This is where my tendency to lump (and time in academia) gets in my way of agreeing 100%.  Almost all processes are repeated.  Spend some time doing the high touch, ad hoc, and qualitative work, the fun planning stuff.  As you do it, look for patterns, repetition, and opportunities for automation.  Then, automate the heck out of it.  You’ll thank yourself later.