Google App Engine is the Python news of the day. Python, WSGI, and Bigtable (well, non-relational datastores generally) are 3 things I've been telling geospatial folks to keep an eye on.

Via Simon Willison.

I continued to think about "mass market geo standards" and standards in general while whipping my yard into shape this past weekend.

The "mass market" thesis is: consumers want or need "x", they can't or don't want to make "x" themselves, and they would rather be ignorant of how "x" is produced. As Ed Parsons put it: "I'd like some cheese ... [but I'd] rather not know how it's made". I won't dispute that there are mass markets for products like paper bags, toilet paper, roller-ball pens, post-it notes, and paperback books. I also won't dispute the fact that people eat a lot of crappy factory cheese food products. These mass markets are a 20th century, first-world phenomenon: an increasingly prosperous middle class with an appetite for goods produced more cheaply on an industrial scale. I don't think mass markets are universal or everlasting. If software or architecture standardization ever worked like this, it won't for much longer.

The internet has changed the nature of interoperation and organization. We're not as dependent on old media and producers as agents of change. People can connect with each other and organize themselves to solve problems. This, of course, is the thesis of Clay Shirky's book: "Here Comes Everybody", and there's abundant supporting evidence in the geospatial domain. Anybody dissatisfied with availability of free and open data can start a community like OpenStreetMap. This is not to say that starting OSM didn't require initiative and hard work, just that there are very few communication hurdles anymore. Anybody who wants to exchange geographic locations via RSS feeds can start a community like GeoRSS. Anybody who wants to discuss alternatives to the OGC's service oriented architecture can start a mailing list like Geo-Web-REST. Anybody who wants to exchange geodata via the JSON format can start a working group like GeoJSON. The designers and developers who want standards can now organize themselves to produce them. Open source, open data, open standards.

By the way: cheese is milk, salt, rennet, microbes, and time. Mix them and wait. Go ask your local artisan cheese maker for the fascinating (no irony here) details.

I noted recently that the Google Maps GeoRSS mapper acts on every location found in a feed. You can exploit this feature to set a map scale independent of the extent of the locations in the feed entries. Add a large bounding box location as a child of the feed, outside any entry:

<?xml version="1.0" encoding="utf-8"?>
<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:thr="http://purl.org/syndication/thread/1.0"
  >
  <georss:where>
    <gml:Polygon>
      <gml:exterior>
        <gml:LinearRing>
          <gml:posList>
            0.0 -50.0 70.0 -50.0 70.0 -120.0 0.0 -120.0 0.0 -50.0
          </gml:posList>
        </gml:LinearRing>
      </gml:exterior>
    </gml:Polygon>
  </georss:where>
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>NCAA Men's Final 2008</title>
    <summary>UNC-Chapel Hill vs UCLA. San Antonio, TX. 7 April 2008.</summary>
    <content type="application/xhtml+xml" src="http://example.org/entries/1"/>
    <georss:where>
      <gml:Point>
        <gml:pos>29.422853 -98.493805</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>

    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />

    <title>UNC-Chapel Hill</title>
    <summary>This is the location of the UNC (http://www.unc.edu) campus in
    Chapel Hill. Related to: http://example.org/entries/1.</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>35.914078 -79.056931</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>

    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />

    <title>UCLA</title>
    <summary>This is the location of the UCLA (http://www.ucla.edu) campus in
    Westwood. Related to: http://example.org/entries/1.</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>34.060623 -118.445663</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
</feed>

and GMaps displays the feed on a map zoomed out to encompass the bounding region specified for the feed.

Compare that to this map of the same feed with the top-level location removed:

I'm thinking this quirk just might be a good practice.

Update (2008-04-6): So much for my finals prediction.

My reward for braving the blustery weather to run yesterday was seeing 3 Osprey, just arrived from their winter range, fishing at the "ponds" (flooded gravel pits) along the Cache la Poudre River. The birds, or their parents, were introduced to the region in 1989: before the construction of reservoirs there was no habitat for Osprey on the eastern slope of the Front Range.

This Osprey photo was taken by Mike Baird near Los Osos, California. I saw 2 up close on the Mendocino Coast last summer, but wasn't carrying a camera at the time.

I like Tom's new name for "neogeography" so much that I'm adopting it for my blog tagline.

Looks like Andrew Turner's presentation provided the fresh air that Ed Parsons was enjoying. His material looks great and I'd like to see this reprised someday. Getting a bit of credit at the end is gratifying: I'm proud of the work I've done to introduce some of these ideas to the geospatial community.

Still, I think the "mass market geo standards" concept is bullshit. If anyone can explain how framing architectures and architectural styles as consumer products benefits developers and designers, I'm all ears and eyes.

I've added a service to Mush that demonstrates the concept of dereferencing linked locations. Only GeoRSS entry locations are currently supported. See the wiki page there for more details.

I was going to use this as an excuse to learn more about Pylons. What I ended up learning is that I don't like Routes, the default Pylons URL dispatcher, and so I just made my own Selector-based app deployable with Paste Deploy. The public read-only repo for Mush is now here.

No joke: I'm loving Vimperator.

Charles Cumming's The 21 Steps supports my thesis that not only is one location not enough to tell a story, one narrative or analytical chunk is not enough to tell a story. Entries and placemarks are cheap: break that story up and serialize it.

Via O'Reilly Radar.

I saw several references to "GeoRSS 2.0" recently by people who are attending the OGC TC meeting in St. Louis. Here's my 2 cents on 2.0:

• Deprecate the simple geometry encoding and just go with GML in a georss:where element already. Yes, this is a complete about face from my position in 2006. Nevermind XML Schema, I'm just saying that the GML encoding is more expressive, more clearly defined, and not significantly more difficult to produce or parse. I've even contributed a GML parsing patch for the Universal Feed Parser. If I can do it, how hard can it be?
• Specify cardinality: an entry should have 0 or 1 geometry (see following comments about multiple locations).
• According to the 1.0 spec: "GeoRSS geometry is meant to represent a real feature of the Earth's surface". Why not above the surface, or below? Do you really think that's going to stop Satan from using GeoRSS to geo-tag news from the hellish center of the Earth? I think this language can go in 2.0 and take elev, floor, and radius along with it. We're all better off using 3D coordinate reference systems, and the quick adoption of KML shows that a third dimension isn't a serious stumbling block.
• In the next paragraph, it is written: "GeoRSS is a way of relating Web content to Earth features". That statement is more dense and chewy that it seems. To me, it seems like specifying nothing more than how to add location to entries is a worthy enough effort. The relationship of entries to the real world is really more of a semantic web concern.
• The semantics of featuretype tag and relationship tag better belong to entry entities than to location entities. The fact that they are not significantly used is, in my opinion, tacit acknowledgement of the truth of that statement. Atom and RSS already allow you to categorize entries and items, which makes featuretype tags unnecessary. Atom also provides a mechanism to relate entries to other entities on the Web: links obviate the need for relationship tags.
• Multiple locations I have already blogged. Entries are cheap.
• The 1.0 spec only considers literal geometries. Referencing external geometries is something else that's being considered for a future version. I'm -0 on the first option (inspired by http://rest.blueoxen.net/cgi-bin/wiki.pl?XMLSemanticWeb) and -1 on the second (inspired by http://tools.ietf.org/html/rfc4287#section-4.1.3.2). I now prefer an approach that first came up on the GeoRSS list here, and which Tom Elliot and I had also been discussing that fall: using Atom links and custom relations. The equivalent of that first option could instead be something like:

<entry>
  ...
  <link
    rel="http://www.georss.org/relations/is-colocated-with"
    href="http://pleiades.stoa.org/places/639166.atom"
    type="application/atom+xml;type=entry"
    />
</entry>

Update (2008-03-28): Notes on my adventures in this direction are at http://atlantides.org/trac/concordia/wiki/AtomLocationByReference.

If you push more semantics from the location up into the entry, using Atom and its extensions, the ground that GeoRSS has to cover shrinks, a good thing for any specification. But what about RSS 1.0 and 2.0? The former can draw on RDF, of course. Maybe the latter needs links from SSE.