Fire Eagle GeoJSON is fixed. Shapely is great for doing things with your data.

>>> import simplejson
>>> data = simplejson.loads(json)
>>> from shapely.geometry import asShape
>>> for location in data['user']['location_hierarchy']:
...     print location['name']
...     print asShape(location['geometry']).wkt
...
600 N Sherwood St, Fort Collins, CO
POINT (-105.0842514037999962 40.5944633483999979)
Fort Collins, CO
POLYGON ((-105.1527862548999934 40.4800186156999970, -104.9821014404000010 40.4
800186156999970, -104.9821014404000010 40.6392784119000012, -105.152786254899993
4 40.6392784119000012, -105.1527862548999934 40.4800186156999970))
Colorado
POLYGON ((-109.0602493285999941 36.9923210143999981, -102.0415573119999948 36.9
923210143999981, -102.0415573119999948 41.0033493042000003, -109.060249328599994
1 41.0033493042000003, -109.0602493285999941 36.9923210143999981))
United States
POLYGON ((-167.2764129638999862 18.9108390807999989, -66.6879425048999934 18.91
08390807999989, -66.6879425048999934 72.8960571288999972, -167.2764129638999862
72.8960571288999972, -167.2764129638999862 18.9108390807999989))

The Fire Eagle tutorial app is also a neat introduction to OAuth.

Sharper eyes than mine noticed that the Fire Eagle "geojson" format is a bit out of date relative to the spec. I checked my location using the walkthrough app:

>>> import simplejson
>>> data = simplejson.loads(json)
>>> from pprint import pprint
>>> pprint(data['user']['location_hierarchy'][0]['geojson'])
{u'coordinates': [-105.0842514038, 40.594463348399998], u'type': u'Point'}
>>> from shapely.geometry import asShape
>>> x = asShape(data['user']['location_hierarchy'][0]['geojson'])
>>> x
<shapely.geometry.point.PointAdapter object at 0x834ce6c>
>>> x.wkt
'POINT (-105.0842514037999962 40.5944633483999979)'

Fire Eagle point representations are okay, and can be adapted into Shapely geometries. How about the polygon in the location hierarchy?

>>> pprint(data['user']['location_hierarchy'][1]['geojson'])
{u'bbox': [[-105.15278625489999, 40.480018615699997],
           [-104.9821014404, 40.639278411900001]],
 u'coordinates': [[-105.15278625489999, 40.480018615699997],
                  [-104.9821014404, 40.480018615699997],
                  [-104.9821014404, 40.639278411900001],
                  [-105.15278625489999, 40.639278411900001],
                  [-105.15278625489999, 40.480018615699997]],
 u'type': u'Polygon'}
>>> x = asShape(data['user']['location_hierarchy'][1]['geojson'])
>>> x.exterior
Traceback (most recent call last):
...
TypeError: object of type 'float' has no len()

The Fire Eagle polygon representation is wrong: it should be a list of rings, not a ring. (Memo to myself: clearly, Shapely needs to handle this situation better, providing a less ambiguous exception at the very least.)

If we insert that ring into a list, it would be fine:

>>> fe_geom = data['user']['location_hierarchy'][1]['geojson']
>>> fixed_geom = {'type': fe_geom['type'], 'coordinates': [fe_geom['coordinates']]}
>>> x = asShape(fixed_geom)
>>> x
<shapely.geometry.polygon.PolygonAdapter object at 0xb7d0746c>
>>> x.exterior.length
0.65988922139999318
>>> x.area
0.027183228771704648

We've got a problem.

The last traces of snow will be gone from my yard today and these evergreen bunching onions have been enjoying the warmth and sun. Being buried in snow all winter didn't bother them at all.

As I've said before, one of the luxuries of small-scale gardening is the freedom to roll the dice against bad weather. Lettuce, spinach, radishes, turnips, and peas are going in this weekend; worst case is that I lose an afternoon and a few packets of seeds. According to the CPC March-April-May seasonal outlook, it is likely to be another warm and dry spring in Northern Colorado on account of the strong La Nina conditions:

THE TEMPERATURE OUTLOOK FOR MARCH FAVORS ABOVE AVERAGE TEMPERATURES ACROSS MOST OF THE SOUTH FROM NEW MEXICO EASTWARD... ACROSS THE SOUTHERN AND CENTRAL PLAINS... AND ALONG THE EASTERN SEABOARD FROM FLORIDA NORTHWARD THROUGH THE NORTHERN MID-ATLANTIC. BELOW-AVERAGE TEMPERATURES ARE MOST LIKELY IN THE PACIFIC NORTHWEST AND IN SOUTHERN CALIFORNIA AND ALSO IN SOUTHERN ALASKA AND THE ALASKAN PANHANDLE. THE OBSERVED BELOW-AVERAGE SSTS ALONG THE CALIFORNIA COAST FAVOR A CONTINUATION OF BELOW AVERAGE TEMPERATURES IN SOUTHERN CALIFORNIA. THE TEMPERATURE FORECAST OVER THE REST OF THE CONUS AND ALASKA IS CONSISTENT WITH OBSERVATIONS FROM PREVIOUS STRONG LA NINA EPISODES. THE TEMPERATURE FORECAST IN THESE REGIONS IS ALSO SUPPORTED BY THE SMLR AND THE CCA, AS WELL AS UPDATED FORECASTS FROM THE CFS.

THE PRECIPITATION FORECAST FOR MARCH USED FEBRUARY - APRIL LA NINA COMPOSITES AS THE STARTING POINT, WHICH INDICATES MEAN DRY CONDITIONS ACROSS THE ENTIRE SOUTHERN U.S. AND WETTER THAN AVERAGE CONDITIONS IN THE PACIFIC NORTHWEST AND IN THE OHIO AND TENNESSEE VALLEYS. INDICATIONS IN THE SHORT TERM FAVORED EXPANDING THE REGION IN THE OHIO AND TENNESSEE VALLEYS INTO PARTS OF THE NORTHEAST... AND SCALING BACK SOME OF THE DRY IN THE SOUTHEAST. DRIER THAN AVERAGE CONDITIONS ARE ALSO FAVORED IN SOUTHERN ALASKA... AS INDICATED BY THE CFS AND THE CCA.

ArcGIS developers are embracing Web architecture as enthusiastically as we on the open source side. Maybe even a bit more. Via Dave Bouwman, and James Fee.

The community that would become OSGeo has long criticized ESRI and its users for tepid support of WxS protocols and formats. I suspect (cynic, me) that lesser enthusiasm had more to do with business competition than to foresight of the changing tide, but it seems to me that ESRI and the ArcGIS server users, having drunk less of the kool-aid, are now in a better position to innovate with REST than the free and open source GIS community. The Windows tools don't hurt either.

Looking back, I realize I forgot to mention an easy way to help ordinary web clients find and tap into WMS from a feed: HTML forms. Here's a feed entry representing a form:

<entry>
  <title>GetMap Form</title>
  <summary>Easy entry point to a web map service</summary>
  <link
    rel="alternate"
    type="text/html"
    href="http://example.com/getmap-form.html"
    />
  ...
</entry>

where getmap-form.html is:

<html>
  ...
  <form method="GET" action="http://example.com/wms">
    <input type="hidden" name="service" value="WMS"/>
    <input type="hidden" name="request" value="GetMap"/>
    <input type="text" name="layers" value="layer1,layer2"/>
    <input type="text" name="bbox" value="-180.0,-90.0,180.0,90.0"/>
  ...
  </form>
</html>

For a more concrete (though not exactly WMS) example, see this form.

Helping Brian realize his idea was fun. Here's his summary. What's next?

There was considerable discussion as to what's next. We hope to offer "getting started" workshops in the coming months to help new users over the learning curve hump. In addition, getting experienced users together for more "deep dive" knowledge sharing is a priority.

I suspect that there are a lot of folks who can't make the trip to Capetown later this year. This might open a small market for open source GIS workshops and face-to-face meetings in this region, like the early MapServer/GDAL/PostGIS meetings. I'd like to be a part of that.

After reading Jeroen's latest post I have a better understanding of what he's trying to accomplish. I too have a use case for representing OGC services in feeds. I'm a critic of the OGC service architecture but can't deny that they are being used and referenced in academic studies, and that there is therefore a need to model and represent them in an ORE resource map feed. I'm going to propose a way to do that and then work back toward Jeroen's use case.

Consider this feed, an ORE-like aggregation that Tom is using to demonstrate how we can form a federation of digital classics projects using a syndication architecture:

http://homepages.nyu.edu/%7Ete20/examples/nearby/cyrene.atom

How does one represent an OGC web map service (WMS) in this feed? As an entry:

<feed>
  ...

  <entry>
    <title>Cyrene WMS</title>
    <id>urn:uuid:56b8421c-5150-458d-ac92-ee9e698593b5</id>
    ...
    <link rel="alternate" href="???"/>
  </entry>

</feed>

What's the link href to be? My interpretation of the alternate link relation is that it should be the URI to the closest thing a WMS has to a "home page". Ideally that would be its capabilities document. (Aside: making an OWS capabilities document a plain old web resource instead of an RPC call would greatly improve the OGC service discovery story. I'm not the first to make this suggestion.)

The entry then becomes something like:

<entry>
  <title>Cyrene WMS</title>
  <id>urn:uuid:56b8421c-5150-458d-ac92-ee9e698593b5</id>
  ...
  <link
    rel="alternate"
    href="http://example.com/?service=WMS&request=GetCapabilities..."
    type="application/vnd.ogc.wms_xml"
    />
</entry>

It would also be very useful to aggregate into an ORE resource map specific images from a WMS, particularly if they are used as illustrations in publication:

<entry>
  <title>Figure 8: Cyrene Overview</title>
  <id>urn:uuid:408cdb6c-185d-4c45-862b-2809158e0c4f</id>
  ...
  <link
    rel="alternate"
    href="http://example.com/?service=WMS&request=GetMap&format=image/png&bbox=..."
    type="image/png"
    />
</entry>

There's less need for extra metadata in this case: specifying image/png says it all. It's implicit that clients will address the link href with a GET request, and that you can get a map image directly like this is one of the redeeming features of WMS.

So, that's how I see OGC services represented in an ORE-like feed. Jeroen's use case is different: he'd like to use a feed as a lite capabilities document. I'm not sure this is a great idea. Bypassing the service capabilities seems a bit dangerous. If it's only that capabilities documents are too big (and I've run into some that are 4 megabytes, which is ridiculous), providers should be encouraged to break these down into smaller collections of logically related feature types, coverages, and layers. Still too big? Take advantage of HTTP's built-in caching mechanisms. Provide ETags and Last-Modified times to help clients limit fetches and parsing. Implement caching proxies.

If you still need to represent GetMap (or other functions) in a feed, there are some possibilities, and some limitations. URI templates don't belong in atom:link. Instead, Joe Gregorio has proposed a link_template element. It's not official by any means, but in combination with a new relation (allowed by Atom), it could let you make an entry like so:

<entry>
  <title>GetMap Endpoint</title>
  <id>urn:uuid:09e7a48a-428a-4418-aef4-ea157806d9db</id>
  ...
  <t:link_template
    rel="http://opengis.net/relations/getmap-endpoint"
    href="http://example.com/?service=WMS&request=GetMap&format={format}&bbox={bbox}"
    />
</entry>

I think that a custom link relation could be the hint Jeroen is looking for. The OGC's content type problem still needs to be fixed.

I left a comment on Jeroen Ticheler's blog, recommending Atom over RSS 2.0, which seems to have been eaten. Coincidentally, Dan Cohen reminded me today about the new ORE specification and its Atom serialization. I think there are some good lessons in ORE for the geospatial respository people. Atom as a format is one.

We have some graph-y plans for the resources of Pleiades and related projects that fit perfectly with ORE.

Very cool. Is this neogeogenomics? I hope the JTS/GEOS architects are equally pleased. You could do this with the OGR Python bindings of course, but since there are no projections involved, and no GIS data to read – only the comparably baroque genetic software formats – there's little point in doing so. I designed Shapely to provide simple spatial functions and otherwise get out from under the feet of your imagination.