"How do I get a GIS job?"

I got this question from a recent grad and I'm not sure if I gave a good answer. Or, for that matter, if there is much advice that would help someone graduating into this job market. One theory going around is that timing like that can hurt forever.

This was my response:

What kind of GIS job do you want? I see the GIS field as roughly divided into administrative, technical, and special domain-specific knowledge areas. You can specialize and in some cases earn more, or diversify and be able to potentially apply for a larger number of positions. Everyone falls a little into all of these categories. Decide to what extent you wish to specialize, and in what area.

1. Administrative
Your project managers, leaders, and communicators. Even the nerdiest technical expert needs to be able to properly gather objectives and communicate requirements. The deeper you go into this, the more likely you will be delegating the actual GIS work.

You get better at this by getting better at written and verbal communication in general. I don't feel exceptionally qualified to talk about leadership, though increasingly I have been thrust into project management work.

2. Technical
GIS is a technical field. If you lack technical skills in a technical field you should fully expect to be mocked. This area can actually be further subdivided into the people leaning toward system admin/computer janitor work and dedicated developers.

I can recommend some fantastic books if you were interested in development - starting with The Pragmatic Programmer, CODE, Code Complete, and Programming Pearls. Just reading isn't enough, I would look into contributing to open source projects.

For the GIS admin/analyst types, I'd recommend working through the entirety of the book GIS for Web Developers. You can go from nothing to managing an entire open source GIS stack (which is fairly similar to ESRI's in terms of architecture).

3. Domain knowledge
Geographic information systems are usually serving some greater business need such as the mandates of public agencies or the profit center of a private corporation. Specialized knowledge of those needs are a career in themselves, and the more you specialize in this the more that career becomes yours. People that fall closer to this area exist on the fuzzy line between actual GIS professional and being a professional in something else.

I'm not going to claim I am the best authority on this particular topic, but I've had success with this particular mindset. A good discussion on what skills you need for each can be found on the new GIS -StakeExchange website here: http://gis.stackexchange.com/questions/883/gis-development-skills

Posted via email from The Pragmatic Geographer

SortaLogic

The new job is different from my former one in the kind of work so far, the organization, and the environment. The responsibility for other systems - customer service, outage management, geographic information - is not on "some other team" in some other department in the company, but your responsibility.

There is only one technical team, and while other departments have personnel that are technically competent, ultimately your team is charged with making everything run on a day to day basis.

A good example here is on a rush job today - pulling data out of what we'll call a relational spatial database (CertaLogic) and putting it into an industry standard XML format (Multispeak). I am not familiar enough with CertaLogic to do an extensive complaint, but it is sufficient to say that whatever flavor we have is not easily mapped to said industry standard.

In my previous job, I would have seen this requirement coming. The confusion over whether or not it was a task I was responsible for comes from the fact that at a smaller firm, more work appears to be contracted out to 3rd parties, and one of them was charged with doing the "migration". Much of my department was surprised that this didn't include some specific parts of our GIS.

As with all unexpected requirements, there was some pressure to get it done fast.

Short answer for those that in the same situation, you have three options. Roll your own solution using a standard xml library (lxml for Python, System.Xml for .NET, etc.), XmlSpy/MapForce, or use SQL's built in XML functionality.

(Edit: hat tip Scott Hanselman for XmlSpy)

Future roles of a GIS analyst: The problems of cartography

The company I work for is both a water and power utility. Both sides have their own geographic information systems, with parts of IT trying to integrate both systems into one big GIS database. While there are complications on the technical end, let me try to describe some of the issues on such an integration from a cartographic perspective:

• Clients, usually from one group or the other, are accustom to very specific symbols for specific map features.
• All of the historic maps from either side have had consistent symbology that match said clients preferences.
• The two groups symbology clashes - what is the red line; a 70kv line, water main, or a user annotation from someone in the field?
• The extents of the features clash.
• A lot of features are not loosely coupled: there are groups where if something is not present it makes no sense, or applications that may require it fail.
• The labeling becomes very problematic for the same reasons symbols do.
• Definitions! What does "deactivated" mean exactly across very different features in different groups?
• There are a truly massive number of features. So many that a given client is not necessarily going to know what they really need.
• How do you project it? The scales of the datasets vary immensely.
• What coordinate system - clients have different preferences in this matter, and one has a custom one of their own creation.

This is all without mentioning that there are plenty of subgroups like environmental, telecom, or legal, which have their own customs and requirements. At least for us, I think the role of cartographer will still have a place here for a long time, trying to organize all this stuff for human consumption. I don't think these issues are unique. Nor do I think that they wouldn't exist if there was tighter integration between the two groups that generate the bulk of the geographic data. I think we are on the cusp of a revolution of both location-aware and location gathering technology - and more data requires better means of organizing and displaying it. Some of this can be automated, but not much I think. I have yet to see software that can easily determine if a given map - or web map application - contains the necessary data for its audience and that data is organized in such a way to be legible, queryable to the client's satisfaction, and aesthetically pleasing. ESRI has put a lot of effort into simply automating the placement of labels, but it is by no means perfect and often requires extensive customization. Perhaps Dave Bouwman is right and "GIS analyst" - already a nebulous term - is not a career that will exist in the future. But I fail to see a way to do all of the above without someone dedicated to cartography.

Future of GIS Analysts, Part 2

In the first part of this post, I tried to put together a simplified list of some of the activities that I have found GIS analysts doing as a part of their job. The goal was to get folks talking about future roles and if GIS analysts have a future ten years from now. I was happy commentators posted some things I missed. I hadn't included, but was helpfully mentioned by geographygeek in the comments, the role of an analyst after the data has been collected and processed. Some (hopefully most) are trained to answer the question, "Well, what does that mean?" Another commenter, KindaSpatial (who puts out a rather good geography podcast), wanted me to talk a bit about some of the newer 3D and hyperlocal data and interpretation. I'm honestly not sure if I am qualified to, but I'll give it a shot and have people correct me later. I like to think of blogging as more of a dialog. On closer inspection, each of these should be their own blog post, so that is what I will do. For now, I will give my initial impressions by going down the list and examine each item, asking the same questions: Can this be automated? Is it easily outsourced Is another profession largely absorbing it? Here are my thoughts. They are not quite fleshed out, feedback greatly encouraged.

1. Map production: Outsourcing: try to make or get a good, topic specific map via phone conversation. Automation: still a lot of overhead software knowledge required for the kind of quality maps necessary for professional reports. Professional designers have all of the aesthetic abilities necessary for this, but little knowledge of the pitfalls of cartography - maps are like statistics that are even easier to lie with.
2. Requirements gathering: Probably impossible to automate, and you can read the hilarious results of trying to outsource it elsewhere. Increasingly the realm of project managers with enough GIS experience to know what is available/feasible.
3. Feature creation and maintenance: The simple stuff can and will be outsourced or automated. Stuff that requires boots on the ground simply can't, and yes it is hard to tell the difference. I don't think the dimensionality of the data makes a significant difference here.
4. General IT/helpdesk support: This really is the work of IT professionals, but for smaller firms or feudal departments it isn't going anywhere.
5. Database/content management: All information has a location-based component, and this function exists as only so long as professional database administrators are uninterested in how the middleware (SDE and PostGIS I believe) works.
6. Minor automation tasks: Prime candidate for professionals to do the automation - it ends up being cleaner and reusable.
7. Post-processing interpretation: (hat tip: geographygeek) This dovetails nicely which what I think is the core of GIS - the visual display of quantitative information. What you replace a geostatistician with? It doesn't seem to easily fit in with other professions, the methods are unique enough to be difficult to automate for easy public use.
8. Hyperlocal data: (hat tip KindaSpatial) The mass of data associated with this seems to require, not merely lend itself to automation. Turning that stuff into interesting visual works or meaningful statistics sort of falls under the previous point.

Based on any comments/corrections I get, I'll be going though these points individually. I haven't been at the GIS game too long, so I'd love to hear from some people from different backgrounds.

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.