I was working on a Yahoo Pipe last night, and I noticed that Pipes will automatically figure out if you have created a geospatial pipe, and show it on a map without you having to do anything! And to top it off, you can get KML output of your pipe! Now if they drop the old-fashioned W3C Geo point-only format and support real GeoRSS they’ll really have something (hint, hint).

What this means is that you can create and export KML content from Google, Microsoft and Yahoo! now. The mind bubbles at the possibilities…

By the way, if you’re actually interested the content of my Cambridge, MA Happenings pipe and not just the technology, you should know that there are a lot of good events that aren’t getting properly geo-located, so read the feed, not just the map.

I’d like to send out a welcome to one of OGC’s newest members, Microsoft. The SQL Server team is readying spatial support in the database with SQL Server 2008, which will have lot’s of OGC goodness built-in, like Well-Known Text and GML data encodings, and Simple Features for SQL access.

The Virtual Earth team has long supported GeoRSS in their Collections, and KML import and export is the newest OGC-related feature in the Virtual Earth/Live Maps product. Check out Steve Lombardi’s excellent blog for more info. MapCruncher is another very cool offering in the online-geo space that allows “regular” folks to upload scanned maps and perform some basic image rectification so that they can be overlaid on orthophotos.

I can’t wait to see what people do with all these features, and hope to see some cool cross-product mashups with all the content in Google, Microsoft and Yahoo geo-services.

I’ve followed Jon Udell’s work for a long time. I’ve found him to have some of the most interesting, original, and clearly presented thoughts on information technology over the years. I’m giving him a blog shoutout because recently he’s been delving into topics near and dear to my own heart. Namely geo web services, exploratory spatial data analysis, urban planning, and GeoRSS. If you’re like me, you’ll want to check out his blog. Especially these entries:

• What’s easy, and what’s hard, about getting from Excel to a GeoRSS-enabled mashup
• A geographic analysis of local crime data
• Excel geocoding adventures

The “map butcher” answered my plea and built a handy GeoRSS export tool for ArcMap. Check out his post here or go straight to the script on ArcScripts. ESRI might eventually implement a nice, full-featured, professional GeoRSS exporter, but if you want something this year, this is probably your best bet.

We had a nice group of about 15 at the OGC BOF at Where 2.0. Unfortunately, we were programmed at the same time as the OSGeo BOF, so a lot of the developers most active in lightweight OGC services like GeoRSS GML and WFS Simple (soon to be rechristened as GeoQuery Service as it moves towards 1.0, but more on that later) couldn’t be with us. Still, we were able to hit a couple GeoRSS issues and delve into other areas.

At one point we got into the issue of representing a single object that has different geographic locations at different times–like an airplane or a ship track. This was a big mailing list discussion earlier in the year, but I don’t think anyone mentioned the fact that Atom has an official way of handling this. If you look at the description of the <id> element in an <entry>, you’ll find this:

Two entries in a feed can have the same value for id if they represent the same entry at different points in time

So as long as <entry>s have the same id, you can change the time, geography, etc., and readers should consider them to represent the same object in different states. Sound like what we’ve been looking for?

On the WFS Simple/GeoQuery Service front, everyone seems happy with the basic data access proposal, but need more query support than time and bounding box. The general consensus from this group and various emails and site comments is to go with regex as a query language, but to NOT have XPath expressions. The thinking here is that XPath queries go too far towards requiring a certain level of XML representation of one’s data on the server, which is a much larger hurdle to adoption than simply outputting XML after a query has run in the database. A quick survey of the attendees felt that all the major databases out there had regex support, including Oracle, DB2, SQL Server, MySQL and PostgreSQL. Programming languages are all covered too.

You may be wondering, why yet another name change? We’ve already gone from WFS Basic (which was confusing because the WFS spec calls its HTTP GET profile WFS Basic) to WFS Simple. The reason is because there was a feeling at the last OGC Mass Market Working Group meeting that a service that did not require GML output should not be called WFS anything. This is a good point as the word Feature means something very specific in OGC terminology, and this service does not necessarily return features. I think it’s a “good thing” to not confuse the market by having a WFS service that doesn’t return GML, so barring something drastic–like someone has already used the term, WFS Simple is now GeoQuery Service.

So in upcoming weeks look for a new GeoQuery Service site on OGC Network with pages for Atom/GeoRSS queries (GQS-Atom?) and a “pure” RESTful approach to geodata query that Chris Holmes of GeoServer is cooking up.