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.
One thought on “What is GIS? (continued)”
The breadth of knowledge required for projects in the current world is quite large! Very diverse topics are being colluded. Hence you end up with 2 (of the possibly infinite) types of people:
* GIS/Planning person who “knows” programming
* Software engineer/developer who “knows” GIS
If one has been paying any attention to the past decade, one should realise that “knows” is the most important aspect. After this one simply determines (a) how much knowledge of analysis is actually required for the project to succeed or (b) how much technical_expertise/engineering_experience is actually required for the project to succeed.
It would be interesting to hear your thoughts (and Paul’s) on how one can eek out a living if one is from the other side: Software Engineer -> GIS/Planning professional