Google Wave

Yesterday at their I/O conference, Google demonstrated a new communication/collaboration tool that appears to be intended to kill email as the standard form of personal web communication. My first feeling is: Good! Have you ever tried to use email for long, branching communications? The flat, threaded view is trash, and a tree view is not much better. I would love to see this get mainstream attention because it might not only kill email, but also kill off less collaboration tools I personally find less than enjoyable to use. Sharepoint, for instance, I have found to be clunky and have poor integration with email. That isn't really the fault of Sharepoint - email was never meant to be an issue tracker or dynamically update websites. Nor would you want it to, it doesn't have the tools. One of the first things they show off with Wave is how easy it is to do just that (particularly bugtracking). Wave is also free, open source (in some fashion or another), and federated. That last bit means your Waves don't necessarily need to live or interact with Google at all - just like internal email servers you can whip up a Wave server and apparently quite easily. The motivation for Google doesn't immediately occur to me. Best, moderately educated guess is that it might have something to do with HTML5 - the next version of HTML currently supported by roughly zero browsers yet - will be easier to index and search than Flash/Flex/Silverlight. Is Wave supposed to be HTML5's killer app, driving the browsers to pick up support for it faster? As a side note, there appears to be a conspicuous number of references to the television show Firefly in the above presentation and in the project. In the show, the standard communication term used was 'wave', the poll robot they demonstrated included an option for Serenity as the Best Movie Ever, etc. This isn't too wild for them. Keep in mind that Google Earth was apparently inspired by the "Earth" program described in Snowcrash.

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.