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.

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.

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.

Here's my list of some of the biggest and best of the community, blogosphere, and things tangential in the last 12 months, in no particular order, and with no apologies about the open source bias. I've omitted many worthy persons, events, and developments. Feel free to write about them in comments or on your own blog. You may be surprised at how long it takes you to make even deliberately casual, non-definitive, best-of lists.

My old hometown Jazz routed the Mavericks last night for Jerry Sloan's 1000th win. For now -- and for the first time in my memory -- the Mountain West, led by the Phoenix Suns, Utah Jazz, and Denver Nuggets, is the NBA's dominant geographic region.

I don't see the point in fussing about Google's new geographic web layer. ESRI's Geography Network and the scattered archipelago of W*S servers may have come first, but neither constitute a functioning web. Google's geo web is as legitimate as any other.

If you're interested in digital gazetteers and didn't make it to this week's workshop in Santa Barbara, check out the notes of my boss, Tom Elliot.

Update: interesting ideas coming from the Ethnophysiography Project.

I'm with Jonathan Crowe, Adena's sense of special interest is turned inside-out. And Planet Geospatial is still not a blog.

I too looked into Hadjieleftheriou's Spatial Index Library before settling on shapelib's quad tree (for Quadtree). My C++ chops are a bit flabby these days, and Frank's C code is very easy to work with. Given my limited time and minimal requirements, the choice was obvious. Now, I'll definitely be looking into the QGIS R-tree implementation.

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.