Sean Gillies Blog

Could WMS have been REST-ful? Andrew Hallam says probably not. I think he's being too strict about REST. It's quite acceptable to send data specifying aspects of your request. A REST-ful WMS request would look like:

GET http://host/wms/1.1.1?layers=one,two&...

The WMS service and version would be specified not in the query, but by the HTTP method and URI. Every other parameter is now of a kind: they parameterize a view of the WMS resource.

I like where Paul Ramsey is going with this. It's not just trendy: it's the way the web works.

Paul Ramsey has an implementation at http://mapserver.refractions.net/cgi-bin/tms/.

I think URL traversal is going to expand and perhaps even blow some minds. Presently, the open source GIS community thinks about web applications almost exclusively in terms of CGI.

Web mappers: what are you doing about accessibility?

Me? I'm using Plone for a solid start. Pleiades is using OpenLayers and Google Earth to visually display georeferenced content; neither of these are fully accessible. It's a hard problem, for sure. One of our technical observers is a CompSci specialist in accessible UIs. He sees the problem as rich and chewy, which means it won't be solved any time soon. Last time we met he had some interesting ideas, and I hope to be able to write about realizations of them next year. Pleiades' feed-based, "viewer"-independent, architecture should help.

The REST Dialogues looks like it will be good stuff, although The S stands for Simple is more fun. If I were more clever, I would have taken this approach to discussing W*S.

It's an improvement over the abysmal ArcIMS client, for sure, but is less impressive than all the hype suggested. The HTML table of operation panes looks and feels clunky. Reordering the panes conflicts with Firefox's right-click menu. The scale bar is nowhere near as sexy as Tim Schaub's (in PrimaGIS and OpenLayers), and the scale slider is nowhere near as smooth as the one in Google Maps. I was expecting it to feel more usable and look more appealing.

Jason Birch points out new MapGuide Open Source demos that beg to be compared against the ArcGIS Server ADF demos. I spent a few minutes trying out the three generic tasks and must say, this is more like it. Autodesk is employing some UI and graphic designers. They haven't found the sweet spots yet, but are closer than the ADF team. They need to drastically reduce the number of mouse clicks needed to theme a layer -- the color picker is particularly painful to use. The markup task is poorly named (HTML is markup), and almost useless. The larger goal is to share placemarks (or lines, or polygons) with other users across applications. Why jail them inside MapGuide? The feature query task ought to support more complex multi-property queries, and the polygon digitization tool is a nightmare (The ADF's performs much better).

The browser swamp is a rough home for GIS applications. One of the keys to success is putting swamp dwellers to work on an application. In theory, MapGuide Open Source has the edge: there aren't any proprietary barriers to the participation of a PHP or Javascript savant. I suspect that ESRI prefers to retrain its desktop developers for swamp duty. (This suspicion is based on an article -- which I found via Jeff Thurston, and can not now find at all -- where an ESRI technical lead spoke about the pressing need for strong typing in Javascript.) I'm betting on the swamp dwellers.

Returning from the OGC's Technical Committee meeting, Ed Parsons writes:

... OGC needs to embrace and recognize the needs of the mass market, as I pointed out in my presentation maybe there is now a new requirement for interoperability, above the levels of W*S services at the mapping API level.

Ed's right, although I would eliminate the wishy-washy "mass market" term, cut right to the chase, and rephrase the statement as:

The OGC needs to embrace and recognize the needs of the Web.

W*S protocols have opened minds and hinted at possibilities, but are not engendering a geo-web. Pictures and data flow dutifully through channels, but there is no evolution of linkage, no complex, organic patterns or structures, no sum that is bigger than its parts. There's no web here.

It's time for a new approach. It's time to geo-enable the Web.

Update: Jo has more on the subject. I agree, "Mass Market" is patronizing.

I'm pretty sure Raj Singh (whose path I somehow managed to never cross at OSG05), gets this already, but one of the things the OGC needs to understand before it can help to geo-enable the Web is that there's more to ubiquity than just dumbing down specifications to the grade level of the mass market. Systems with simple rules allow the evolution of complex and surprising features. Our teeming, expanding, World Wide Web was made possible by its deliberately simple design.

At the end of his post, Singh asks:

And finally a note about the name, Mass Market. I'm not in love with the name either. Don't hire me to name your next product. But what if we had called it the geoweb working group? Would I be getting flamed like Google did over that new geoweb layer in Earth?

As far as I could tell, the reaction against Google's geographic web layer came entirely from pro-OGC quarters, so I doubt that "OGC GeoWeb Working Group" would have sparked any flames.

Dave Megginson's post is getting around the blogosphere. I saw it via Pete Lacey and Tim Bray. It would be a shame if other organizations followed Google in this direction.

This is how it's going to grow? From KML in sitemap files? I have mixed feelings about this.

On the one hand, I'm very interested in seeing the Web we have now geo-enable itself. I'd love to be able to search Google (or Yahoo, or whatever) for coverages and features, and never again visit barely usable geodata portals. On the other hand, this particular approach is just another damned catalog, and one based on a single application's proprietary language.

The software that runs this blog has been letting me down. After some consideration, I decided that instead of switching or rolling my own, I'd be like the guy who soups up his Ford Pinto wagon (COREBlog in my case). New wheels, new paint, and tinted glass. Later, maybe, new seats and sound system.

On the programming side of the upgrade: new, permanent, hackable, readable, and indexable URLs. The old URLs, formed like:

http://zcologia.com/news/{id}

sucked. There's just no way around that. They were hackable in that you could increment or decrement the id to get subsequent or previous entries, but had no other virtues unless you count (and I did for a while) their extreme shortness as a virtue. Now, the URLs are changed to:

http://zcologia.com/news/{id}/{slug}/

Keeping the id guarantees uniqueness and preserves hackability. A slug derived from the entry title -- in this particular case "Blog Upgrade" -> "blog-upgrade" -- provides a tiny bit of context to aid web surfers and indexers. I changed not a thing in the ZODB. All I've done is reimplement __bobo_traverse__() for COREBlog.Entry so that the proper object gets published on a slug-ged request, and reimplement index_html() for the same class to redirect to the new canonical URL. If an agent comes for a deprecated URL, it gets a status 301 response with the new location:

sean@lenny:~$ curl -v http://zcologia.com/news340
...
> GET /news340 HTTP/1.1
> User-Agent: curl/7.15.4 (i486-pc-linux-gnu) libcurl/7.15.4 ...
> Host: zcologia.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 15 Jan 2007 20:29:47 GMT
< Server: Zope/(Zope 2.8.6-final, python 2.4.3, linux2) ZServer/1.1
< Content-Length: 0
< Location: http://zcologia.com/news/340/blog-upgrade/
< Content-Type: text/plain; charset=UTF-8
...

On the policy side: new, full-content feed of entries. I'm optimistic that this will increase the depth, if not the breadth, of my readership. Any any rate, I'm not selling ads on my blog pages, so there's nothing to lose.

Joe Gregorio points out the great scale leap between the Web and the largest of intranets. This is the same point I've been trying to make about W*S and the Web. The OGC standards are designed for the enterprise, some thousands of users on an intranet. It's unlikely that they scale to millions or billions of users.

Platial's Chris Goad is offering JDIL as a way forward for Geo-JSON. JDIL (I presume this is an acronym for JSON Data Integration Language) is used at Platial to map RSS 1.0 XML feeds to JSON [example feed]. It's thorough and seems a decent solution to the problems particular to RSS 1.0, but those problems don't exist in my applications.

The reason for the interest in Geo-JSON, for those who aren't familiar with JSON, is twofold: JSON can be evaluated by your browser's javascript engine, and, wrapped in javascript, can exploit a hole in your browser's same-domain policy (nicely explained by Douglas Crockford here) and allow you to integrate geo-data from diverse sites. The same-domain policy prevents us from using XML, and efforts to port XML features to JSON seem to be an inevitable result. I'm not as pessimistic about these efforts as some.

The Geo-JSON I am using for Pleiades [wiki, example] is inspired by Atom 1.0. There's no pastiche of namespaces, and, as far as I'm concerned, any specialized content could be carried as an escaped XML string property. I also prefer arrays of numeric coordinates to JDIL's georss:type string property, as it removes the need to parse a string on the client end. What to do about polygons with holes or multi- types is an open question. I think the way to go is to follow WKT, but with arrays of numbers instead of text.

I think that if you write something cautionary about GeoRSS, like this:

Do be careful, because while these are "standards" they've not been approved by anyone, just put out there by their creators.

and also happen to consult for an industry standards organization that maintains standards alike to GeoRSS, you probably ought to make a disclosure statement of some sort. Even if your blogging has been generally favorable to GeoRSS.

Standardizing on RSS is a no-brainer. There are orders of magnitude more information being shared via RSS than by OGC protocols. It works. It scales. It's extensible. It's not going away. The success of RSS is very much a grassroots story. These folks didn't wait for W3C approval, they mobilized and took the web by storm.

The largest risk for you, the GeoRSS implementor, is that you'll go overboard with multi-part GML 3 geometries that others won't parse. Don't get me wrong, GML 3 is my favorite OGC spec by far, and has been a big influence on the development of PCL's feature model, but the fact remains that there aren't yet any full-featured GML parsers that integrate well with the top web scripting languages. I'm trying to do something about that, for Python, but it's nowhere near ready.

Update: I'm clueless. No disclosure needed.