This morning at the OGC Technical Committee meeting, the Google Earth & Maps team announced an alpha of libkml, an open source (BSD) library for reading/parsing/writing KML 2.2. It’s a C++ library, but includes SWIG bindings for Java, Python, Ruby, Perl and PHP. The hope is that this piece of code will help developers build comprehensive, robust KML support into their applications. But note, this is NOT a mini-Google Earth. You just get KML support – there’s no way to get that streaming earth imagery goodness that you see in GE, although I suppose you can combine this with a map access API (from Google, Virtual Earth, Yahoo!, etc.) to get nice base maps in your app. Enjoy!

Needless to say, I was shocked and amazed when I saw this statement on Microsoft’s new Interoperability Principles this weekend. To summarize, they are committing to make open and public the protocols and APIs for their major products, including Vista, Exchange, SQL Server, and Office. And, wait for this, access to those documents will be free. Is your mind blown yet? How about reading on and seeing that they plan to embrace non-Microsoft standards, and “increase interoperability with open source solutions”? I’m going to take all this at face value and say, “Bravo Microsoft!” I hope it all plays out according to this plan. The IT world will be a much better place if it does.

REST has been a hot topic this year in the geo world. There’s a discussion group, a geographic data server, many blog posts, and email discussions. I’ve been mulling over what this means to OGC over the last couple months, reading RESTful Web Services, and discussing with the various advocates around the community. After all this, I think I know what’s going on, but I don’t think there’s any one clear explanation (despite some nice pieces of the puzzle here and here) available, and there has certainly been little effort to analyze the REST architecture in relation to geographic information systems theory, so that’s what I’ll try to do now.

At its very core, a REST architecture is centered on gaining access to a generally indivisible piece of information, which is generally called a resource. A REST system expects resources to exist at standard, unchanging, URLs (everybody knows cool URLs don’t change). In the case of Atom–the most cited example–this piece of information is the <entry>. Sure there are other resource types, but their primary purpose is to help you find and understand the information resources.

Right away we have a culture clash when it comes to GIS (geographic information systems). This crowd has been trained in geography departments to think of the data set as the primary piece of information. A data set is often called a layer or coverage, and represents some real-world phenomena like vegetation or rainfall or census tracts. The points, lines, polygons or pixels that comprise the data set are of secondary important to the concept of the data set itself. In fact, it’s considered un-cool to think of the shapes (or pixels in the case of imagery) that make up the data set to be concrete objects at all. Rather they are useful proxies of the real objects of concern. For example, you can’t really capture rainfall in a database because it’s not practical to measure every drop of rain. We estimate and approximate and end up storing some model of rainfall in the database, but we don’t ever have the temerity to say we are capturing the one and only representation of rainfall.

Now a programmer might respond, “screw your ivory tower theoretical nonsense. You’ve got information in a computer, and you read and write to it, so keep your conceptual information models to yourself.” And in large part I agree with this viewpoint, but there are some places where we’ll run into trouble. For example, most of the REST material I’ve read treats images as indivisible, binary resources. This won’t work in the geo field, where images are in the gigabyte and terabyte range and you’ve got to design services that provide access to portions of those images. However, aside from imagery I don’t see much of a problem with using a resource-oriented approach to information access. In fact, in the sensor web arena I think a REST approach makes a ton of sense.

UPATE: Sean is convincing me that imagery isn’t a tough problem for RESTies, even if I don’t know what “empirical orthogonal function decomposition” is. Is this related to what I know as imagery formats using wavelet compression?

Whew. I’ve spent a lot of time talking about resources, but if you don’t get the basics right, everything else is meaningless. Now I’ll move on to the other basic, which is accessing resources through “standard” URLs, and additionally, taking full advantage of the HTTP headers available in URL requests. I won’t get too deep into the technology here, because others do that better, but I will say that to me it seems the big point being made is that URLs work in a lot of places–Web browsers, email, all programming environments, etc. Don’t use anything more than URLs unless you really have to. And if you think you really have to, think again and again.

The other piece of the URL issue is using HTTP headers to do things like set expiration dates on information, say some resource is unavailable at the moment, or unavailable forever because it’s been deleted, and lots of other things that HTTP header geeks know about. Now some might say that the arcane wizardry of HTTP header usage is just as complex as the things REST advocates complain about, like SOAP headers and XML query languages. I agree, but the big difference is that the core infrastructure of the Internet–Web servers and routers for example–comes with built-in software to do useful things with HTTP headers, and if you don’t take advantage of them, you are losing the opportunity to get an amazing amount of useful functionality at a much lower cost than paying programmers to build it into your application. This includes all kinds of content description (MIME types), error handling, caching and load balancing to name a few. I don’t see any problem with this principle. It aligns perfectly with the OGC principle to leverage as much of the common Web infrastructure as possible before inventing new, geo-specific technologies. Even advocates of heavier-weight service-oriented architectures should be able to get behind this idea. So read the HTTP spec and use it. And once again, if you find yourself in a situation where you can’t use it, think again, and then once more…

To summarize, I talked at length about information resources, URLs, and HTTP. This is far from a comprehensive introduction to REST, but it hopefully a nice companion to the more general, programming oriented content available elsewhere. Next time I’ll talk about search and retrieval. And if I get enough positive feedback, I might even try to describe how this would all play out in building a collaborative spatial data infrastructure. I’ll be accepting votes in the form of drinks and/or cool ideas at the upcoming URISA and FOSS4G conferences.

So many good systems have been hurt by bad user interfaces. I would say user interface design is a dying art, but a little research shows that it may have never had much life to begin with.

Think about it. Our basic desktop computing windows-mouse-applications metaphor that we use today was pretty much defined 20 years ago with Macintosh GUI (or if you want to be a real purist, you could go back another decade to Unix X-Windows and the Xerox PARC mouse). Since then, applications have taken a muddled approach to user interface design, with more failures than successes. One thing that has been annoying me recently is the treatment of logout commands in Web apps. They always seem to be buried in site navigation controls, when they really fall into a different category completely. Here’s one example from Bank of America, who at least highlights the command in red, but still, “Sign Off” should be a button, and probably should be placed under “Online Banking.”
The real point of this post is to say that I wish more companies in the geospatial industry would do a better job in this area. I think it could really contribute to more usage and revenue growth. Just look at Google. They have no content (even Earth and Maps use content others could buy if they wanted), but they continually capture customers by being the best-of-breed UI. They’ve been so successful at that they even have Microsoft worried that Google’s awesome apps, like Mail, Reader, Docs and Spreadsheets, could actually replace the desktop OS!

So with that in mind, this Infoworld article on Javascript toolkits really caught my attention. Go check out Prototype, Rico and Dojo. They can really help people who usually focus on server-side work to get closer to building more appealing user interfaces. Toolkits are no substitute for truly understanding UI design, but it’s a step in the right direction.

posted on holiday at the foot of the White Mountains..