Future of GIS Analysts, Part 1

A question occurred to me as a result of a comment made by David Bouwman on Twitter. Folks were congratulating James Fee, who had just been offered an opportunity to teach GIS at the Arizona State University masters program.

Teach them that "GIS Analyst" will be a rare job in 10 years - just like "Database Analyst" is today.

My question(s): what do we mean by GIS Analyst in this context - what functions do they provide today that will be unnecessary or absorbed by other jobs? My official title is something like GIS analyst, though this kind of talk might be more disconcerting if I hadn't already oriented my career towards application development. But I know people I work with, professors, and certainly students today would be interested in discovering if this was in fact the case. If we were to properly investigate this matter, lets consider first what GIS analysts (which we can probably group with specialists, technicians, etc) do that makes them necessary today, and then, in part two, we can examine what that role might look like - if it exists at all - in the future. Here is a quick list of the roles I've seen played by GIS analysts:

1. Map production: Your standard cartography work. Organizing the layers, layouts, titles, etc into an aesthetically pleasing package and either plotting/printing it off, or, more recently, publishing it as a service.
2. Requirements gathering: Client communication, identifying potential solutions from user stories, project specification and some project management.
3. Feature creation and maintenance: Gathering and organizing data from disparate sources, digitizing/COGO work. Associated documentation/metadata probably falls in here too.
4. General IT/helpdesk support: Particularly the case when it is a small firm without a real IT department or person, or if that person/department is swamped, or doesn't know anything about GIS software, or IT's grasp on individual departments is tenuous.
5. Database/content management: Organizing databases, particularly ESRI geodatabases - what belongs in a given dataset, should it be part of the network, etc. File management of documentation, supplementary data.
6. Minor automation tasks: Modelbuilder, Python, VBA stuff. Almost any programming task where not knowing the basics of object oriented programming is not much of a hindrance (though it makes for terrible code).

I'm missing probably a hundred more things analysts do and I'd like to invite everyone to help me add to the list.

GITA Arizona Conference Trip Report

Geospatial Information Technology Association (Arizona Chapter) got together yesterday to present new infrastructure GIS applications in the valley. Here are the presentations and some commentary: City of Phoenix showed off their new internal Flex/ArcServer application that replaces their older and less frequently used IMS application. It looks like it duplicates much of the functionality of ArcExplorer with some additional tools for work orders, etc.

• Why Flex? They found it had the best preformance, only required knowing Actionscript and MXML, and there was a lot of the UI built-in.
• Multiple MXDs (i.e., web services) one interface.
• They've received good feedback from users and doubled their user base.

Salt River Project demonstrated a tool many people may not know about for improving ArcServer performance. Turns out a lot of latency can be the result of the symbology, labeling, and other components.

• ESRI publishes a free tool that gives you per-layer statistics on performance called MXDPERFSTAT.
• Stuff to avoid: halos, definition queries (use db views instead).
• Stuff to use if you can: Simple Symbols, Annotations.
• Additional tips for Oracle users: watch for the high watermark issue

City of Mesa shows off some 3D & 4D stuff in Google Earth, used for land use planning around the Phoenix-Mesa Gateway Airport.

• Some issues: height requirements, noise requirements.
• Used ASU's "Decision Theatre".

More City of Phoenix. Interop talk about moving parcel layers around. Record number of uses of the word "Open" when describing a business process that uses nothing but proprietary software. The GIS of the Phoenix Skyharbor Airport - a city unto itself. Described as 2.25D, contains extreme detail and enters into traditional CAD territory.

• Every fire extinguisher, every door, every thing appeared to be part of the inventory. $3m budget for data gathering.
• Layered approach - users can select different level/terminal and the application puts you indoors.

Boots on the Ground in GIS Analysis and Development

While I do a lot of GIS development these days, I am pleased to do some solid analysis work as well. I was recently given the task to delineate land use/land cover using standard remote sensing image interpretation methods. I'd like to think I've pretty well trained in this kind of work, and my experience has confirmed one particular part of that training that was universally emphasized - boots on the ground. You can create a cunning story about exactly what is happening in a given air photo and can be completely, utterly wrong in all regards. This can happen whether you are a fully certified photogrammetrist or just a novice staring at something weird in Google Earth. Seeing what you are studying up close and first hand, assuming you can, is essential to avoiding these kinds of mistakes. In the case of my current project, I would say it was essential I went out and actually traipsed through the study area. The air photos and other sources did not prepare me to interpret the vegetation I can now pick out extremely well. Many professions call attention to this. Military commanders who ignore the front can find tactical situations dictating strategy in ways they neither expect nor desire. I don't see it nearly as stressed in developer circles - books, online sources, or in my own experience (though AGILE practices come pretty close in terms of constant and face to face communication with clients). You shouldn't be learning what your users want exclusively from their management or your marketing/sales department, and in many cases I have seen, selling an idea to management only seems to be half the job. A really enlightening experience was going out into the field, sitting in the trucks with a user, and just watching them use the technology and see the actual business process in action. It is amazing how much it can differ from abstract flowcharts and user stories cooked up by others or even straight from their mouths. They'll lie to you, and I don't mean intentionally. They'll omit something because they do it every day and imagine it is second nature to their audience, or they forget, or they won't think something is relevant. It is your job to ferret out the real requirements or the real trees you are looking for. Worst case scenario: you get out of your office and see the sun for the first time in a year outside the weekends. Anyone have any stories about similar situations? Images from Googleblog, this talented Flickr user.

There is location and then there is behavior.

Google Latitude, which effectively embodies the business case of Loopt until some kind of conversation occurred at Google, allows users with mobile phones to opt-in to a service which broadcasts their location. People can search for their friends locations and retrieve Twitter-like messages by them. Location is a good start, but more interesting is a presentation I recently viewed on behavior and its use for location based apps like this one. Why just try to find your friends somewhere when you can go ahead and predict where they, and people like them and you, are going to be? I rather like the privacy policy too (anonymity, you own the data you create).