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).