There are three reasons to syndicate geographic resources:

• To allow users or other agents to track updates or edits
• To make synchronization with other systems cheap and easy
• To generate a sitemap for search engine optimization

The third is a special case of the second. In all cases, GeoRSS permits some simple spatial analysis, filtering, and indexing of the entries in your feed. The basic recipe for syndicating geographic resources using GeoRSS follows:

• Implement just one feed for changes and one more for deep sync and site-mapping. The different versions of RSS are interchangeable enough. Pick one format and go with it.
• Choose Atom. There's a well designed payload element that can easily carry any media, a link relation registry, and a matching publishing protocol (used in Google Data APIs, including the Maps Data API). It's better.
• Pick one GeoRSS flavor. Simple or GML. I prefer the "where" semantics of the latter. I wouldn't put a "time" element in any entry without specifying what time it was (created? modified?) and so I feel uncomfortable when I put an ambiguous "point" element in an entry. Granted, there aren't any location semantics other than "where" currently in use, but it feels risky (to me) to have such latent ambiguity.
• Use zero or one location or "where" element per entry. Don't duplicate locations within an entry using different GeoRSS flavors. Your entry's content may have a geographically rich context, but that's to be described within the content using KML, GML, or whatever. GeoRSS specifies the location of the entry within feed space, and it should be as simplified a location as can be.

There's no consensus on how the concept of cartographic scale is to be applied in the context of a feed. If your feed has a global scope, you should probably use small scale representations of locations. If your feed is local, or hyper-local, scale up accordingly. Perhaps it would be helpful if GeoRSS feeds specified their spatial scale. Not in the form of a ratio as we do for paper maps, and not in the form of "zoom levels", but a form that's useful to internet engineers. Numerical precision? Surely, someone has their spatial thinking cap on and has already figured this out. I'd appreciate being clued in.

Do GIS paradigms and processes scale infinitely inward and outward? I like geeking out on geography as much as the next, but this raised my eyebrows (emphasis mine):

spatial@ucsb seeks to position spatial concepts as the driving force for spatial thinking and for the selection and use of spatial tools. We are initiating the collection with eight concepts that are the focus of spatial reasoning in the use of geographical information. These concepts are demonstrable at all levels of space and time (from sub-atomic to galactic, past through future, and microseconds to ions). They can be rendered understandable through simple illustrations to young children but they are also sufficiently engaging at advanced levels for thinking about scientific and social problems.

All levels of space and time? The so-called "first law of geography" explains only classical phenomena. At small scales its applicability vanishes, and you need quantum physics to explain phenomena like atomic spectra, scattering, and tunneling. Even at the relatively large scale of cells and ice crystals, chemical and physical processes dominate, which makes me skeptical about the application of GIS to the nanoscale (emphasis mine):

When spimelike devices are built at very small geographies, capable of sensing and even manipulating objects at exceptionally fine scales, they become useful for nanoengineering. In recent years, there has been a massive fueling of interest in nanoscale science and development of motors, actuators, and manipulators at nanoscales. With these developments have come a veritable land grab and gold rush for scientific inquiry at hitherto relatively underexplored scales: within the earth, within the body, within objects, within anything to be found between 1 and 100 nanometers. Geographers missed out on the last bonanza at fine scales and were mostly absent from teams tasked with mapping the genome. The cartography required to visually map the genome is trivial and the processes that govern genomic patterns are completely alien to most geographers' skill sets, so their exclusion from these endeavors is understandable. The science and engineering surrounding nanotechnology differ from this situation, however, in that they are primarily concerned with spatiotemporal patterns and processes and the scaling of systems to new dimensions. These areas of inquiry are part of the geographer's craft and fall firmly within the domain of geographic information technologies. Process models with spatial sensing and semantic intelligence could play a vital role in future nanoscale exploration and engineering

The usefulness of spatial thinking fades at larger scales, too: it tells you nothing, for example, about the redshift of distant objects, you must use general relativity. It fails to explain some important phenomena at even modestly large scales, such as the planetary-scale waves that shape the Earth's climate system.

Geography isn't (in my probably biased opinion) a predictive science like physics. It's more like non-experimental branches of sociology or psychology -- relying on and often contributing to advances in fundamental fields, but powerful only in explaining bulk or ensemble features of the world. I should put scare quotes around the word 'only' in the previous sentence, because that's no small thing. Physics alone can't explain the way of the world at scales of human life, so geography will always be an important field, but a return to temperance in its rhetoric might be in order.

Gustavo Niemeyer wonders about collections, queries, and REST:

Now, we want to implement a feature which allows people to access the list of all recent editions of books in their home library, given that they know the URIs for the books because a client program stored the URIs locally in their machines. How would we go about implementing this? We certainly wouldn’t want to do 200 queries to learn about updates for 200 books which a given person has, since that’s unnecessarily heavy on the client computer, on the network, and on the server. It’s also hard to encode the resource scope (as defined in the book) in the URI, since the amount of data to define the scope (the 200 books in our case) can be arbitrarily large. This actually feels like perfectly fit for an RPC: “Hey, server, here are 200 URIs in my envelope.. let me know what are the updated books and their URIs.” I can imagine some workarounds for this, like saving a temporary list of books with PUT, and then doing the query on that temporary list’s URI, but this feels like a considerably more complex design just for the sake of purity.

The sake of purity? Who are these dreaded purity police, anyhow? And how exactly does someone make a "pure" use of the "Whoopee Cushion of Internet protocols"?

This library application already has one collection, the global one, and presumably exposes a number of useful web resources around it: search forms and feeds of several flavors (changesets and archives). The solution, IMO, is not the temporary query resources Gustavo imagines, but smart, permanent user collection resources. Without these, users have no way to share the collections with others or compare their collections to others, and no way to access their collections when away from their desktop library app. Take a look at LibraryThing, Zotero, or OpenLibrary: each have user collections, of books or articles in the first two cases, and changes to book records in the third. User collections, the states of which are stored on a server, are a must-have feature of any application in this class.

Create a new resource for each user collection that exposes a list of the most recent editions of each book, along with links to the new and currently held editions, formatted using Atom so that you can track updates in a feed reader, and you're all set. Using RPC here seems an attempt to route around a problem that doesn't exist, or worse: routing around a must-have feature.

I took our highly energetic older daughter on an expedition to find the Gallo-Roman site of Ambrussum yesterday. It's easy to find coming from Montpellier: exit the A9 at Lunel, pay € 1.30, follow the D34 direction Lunel (South) and take a left on D 110 direction Villetelle. Not shown in Google's streets is that you can bear right and continue parallel to the A9, then turn right again at the next intersection (no explicit sign to Ambrussum) amid vines. Continue past the museum under construction and adjacent excavation to parking at Le Pont. [map]

There's shade for picnicking at the Pont. Constructed around 30 BC, it was used up until the 14th century, then partially dismantled and wrecked by flood waters.

A long-gone embankment (my interpretation) connected this bridge to the nearby section of the Via Domitia.

That's limestone, not the hardest rock in the world, but still those ruts attest to the traffic on this road (view from above here). Uphill are found the remains of fortifications, buildings, a public edifice, and (best of all, in my daughter's opinion) a large patch of wild blackberries.

Taking the same frontage road back to the D34 and A9 entrance, you'll pass a backdoor to an autoroute rest stop ("aire" en français). A stop there to slip through and get ice cream bars from the gas station boutique is highly recommended.

We had an idyllic overnight flight from Denver, long slog through the mirror-world disasters of LHR (nice new terminal, but no jetways or gates, lots of hiking) and CDG (plenty of jetways and gates, dangerously decrepit terminal), and a with only 2 rough bedtimes are comfortably established in Montpellier. My wife, Ruth, has a sabbatical from CSU, a Fulbright, and an appointment at INRA (French equivalent of the USDA, more or less). I'm telecommuting to ISAW. This is our home for the next year.

It's an interesting city. We're in the quartier Les Cévennes which rather reminds me of some Albuquerque neighborhoods: dusty and somewhat scruffy, renting from a pair of teachers who are off on an exchange to Morocco. There's a fine bakery and a good pizzeria down the street, we hear the neighborhood école is excellent, and there's a reliable evening breeze. One trip to a suburban garden store, one trip to a kitchen boutique in the centre for the essential skillet and badass chef's knife, and British Airway's return of my oldest's car seat so we can get safely to the beach, and we'll be completely set for the summer.

The Tour de France is in Montpellier tomorrow: every seven minutes a team departs la Place de la Comédie in the center, heading up the 1 km hill on our own Avenue du Professeur Louis-Ravas less than 4 minutes on, and then looping around to the NW, West, and SW, arriving at the Stade Yves-du-Manoir about 45 minutes later. This evening, my oldest daughter and I went out to take some pictures in the rue before the race.

This spot on top of a wall at the Maison pour tous Paul-Emile-Victor should be the best viewing location. I'm not sure how early I'll need to get out there with the patio chairs. An hour before the caravan?

My kid is excited about the race: wants to be a bike racer when she grows up, race with her little sister (like the Schleck brothers), be fast like Mark Cavendish, and sleep in castles every night.

Last photo is looking down the course (and uphill) toward the Alco roundabout and Grabels. We'll try to reproduce these shots during the race tomorrow afternoon.

Hey, somebody discovered __geo_interface__. If you'd rather use Python's standard json module than geojson, you'll need to implement a custom encoder as documented:

>>> import json
>>> class GeoEncoder(json.JSONEncoder):
...     def default(self, obj):
...         if hasattr(obj, '__geo_interface__'):
...             return obj.__geo_interface__
...         return json.JSONEncoder.default(self, obj)
...
>>> class GeoThing(object):
...     __geo_interface__ = {'type': 'Point', 'coordinates': [0.0, 0.0]}
...
>>> json.dumps(GeoThing(), cls=GeoEncoder)
'{"type": "Point", "coordinates": [0.0, 0.0]}'

The geojson module does this for you, and more, but clearly needs to work with json from 2.6 as well as simplejson.

The Geojson, Rtree, Shapely, and OWSLib packages all originated in Pleiades, a digital project sponsored by the NEH Office of Digital Humanities, and run out of, first, the University of North Carolina's Ancient World Mapping Center, and, now, New York University's Institute for the Study of the Ancient World. All but Shapely are now at least partially lead by developers not at AWMC or ISAW. I'm proud of the fact that elements of Pleiades are being reused by different developers in new contexts, and plan to make their utility and broad appeal a part of future proposals for the development of geographic applications in the digital humanities. I'd like to see other stakeholders making similar appeals.

Are these packages important to you and your company or organization? Do you appreciate them? If so, kindly consider sharing your appreciation with the internet community and potential sponsors therein by writing a short blurb on our wiki. It's the next best thing to blogging fanatically about them. Thanks!

Speaking of the recovery.gov overhaul, Erik Wilde has been digging into recovery.gov from the start and has some excellent recommendations for open, transparent architecture. It's essential reading, and entirely apart from the private vs. public foodfight that Darrell Issa is engaged in.

A few years ago, I would have said that ESRI was genetically incapable of implementing an open, transparent architecture. The original Geospatial One Stop made a mockery of the web (and remains so). But there have been some signs that things are changing: bookmarkable search results, OpenSearch descriptions discoverable via links in http://geoss.esri.com/geoportal/catalog/main/home.page, Atom feeds with GeoRSS elements. It's no longer a laughable proposition.