2009 (old posts, page 6)

Geographic syndication in a nutshell

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.


Re: Geographic syndication in a nutshell

Author: Sean

A Twitter user politely objected to my use of "cartographic scale" in the last paragraph above. As a way of explaining what I mean, consider a feed entry's summary element: it's a representation of the entry's content at the feed browsing "scale", and there's more craft to a good summary than brute filtering like truncation at 140 characters. A summary needs key words and hooks. Some of the same considerations have to be made when making a GeoRSS location representation for an entry. An entry in the spatial context of a city can't very well include a detailed 3D representation of the city within a georss:where element, and brute filtering isn't any more useful. In some feeds, this location would be represented as a point. In others, as a simplification of the municipal boundary. It's an almost cartographic decision.


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.


Re: Geo-grandiosity

Author: Kirk

I'll be happy when we can just scale between flat-earth and round-earth levels of detail.


We're getting closer - I'm told SQL 11 overcomes this.

Re: Geo-grandiosity

Author: Sean

Please, we don't call it "SQL" around here. Good point though: in practice we have (at least) two kinds of spatial thinking, and it isn't trivial to switch between them.

Re: Geo-grandiosity

Author: Ron Lake

It is difficult to think of anywhere that "geography" has enlarged our formal understanding of space. It has indeed enriched our notion of the space we inhabit or perceive, as it draws our attention to the connectivity between ourselves and one another, and between ourselves and the natural world of which we are a part. The formalization of ideas of space is the subject of mathematics and while geographers and GIS people have rediscovered some of this, I think the contributions in the other direction are on the whole pretty minor. Areas of mathematics like differential geometry and topology have much to teach us about the formal understanding of "space". I suggest the reading of Max Jammer (http://en.wikipedia.org/wiki/Max_Jammer) and Poincare's famous essay "Why Space has 3 dimensions". If your mind tends to much less formal and some might say obtuse understanding I suggest Gaston Bachelard's The Poetics of Space (http://en.wikipedia.org/wiki/The_Poetics_of_Space.

Collections, queries, and REST

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.


Re: Collections, queries, and REST

Author: Gustavo Niemeyer

I've continued the discussion in the original post:



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.

Nous sommes arrivés à Montpellier

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.


Re: Nous sommes arrivés à Montpellier

Author: Benjamin Chartier

Welcome to France.



Author: ReLuc

Welcome in my city! I hope we can meet this year in Montpellier.


Re: Nous sommes arrivés à Montpellier

Author: Sean

Merci, Benjamin. René-Luc: I will send you an email immediately.

Re: Nous sommes arrivés à Montpellier

Author: Jason E. Rist

Je suis jealoux

Re: Nous sommes arrivés à Montpellier

Author: Vincent Heurteaux

hey Sean,

Welcome !

Feel free to come to "La Maison de la Teledetection" to meet us.



Re: Nous sommes arrivés à Montpellier

Author: Sean

Jason: as nice as summer evenings are in the Fort, they're even better here. No mosquitoes! La mer Méditerranée was a little cold this morning, but will be getting warmer. Vicent: I know that neighborhood, having stayed at the Camping Plein Air des Chênes last fall with daily trips past the Agropolis and Zoo.

We're hosting the Tour

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.



Re: We're hosting the Tour

Author: Jason E. Rist

I can't tell you how jealous I am of you right now...

Re: We're hosting the Tour

Author: James Fee

Boy that looks awful. I have no idea how you'll be able to survive there. ;)

Geo interface and Python 2.6

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.


Re: Geo interface and Python 2.6

Author: Kurt Schwhr


Thanks for the tip on how to use the standard json.


Showing support for GIS-Python software

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!


Re: Showing support for GIS-Python software

Author: Venkatesh Raghavan

My sincere appreciation to Sean Gillies and Pleiades. Our recent project

on GPS tracking has greatly benefited form Shapely and we hope to use other

tools like OWSLib in our future work.

Dissecting recovery.gov

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.


Re: Dissecting recovery.org

Author: Sean Gorman

Just double checking that you mean recovery.gov and not recovery.org which is run by Onvia a private company?

Still fighting the good fight and the folks at recovery.gov are paying attention to what the community is posting on open and transparent architectures. Although the geo-working group has been postponed while the overhaul is considered. Hopefully it will be reconstituted and continue in the right direction.



Re: Dissecting recovery.gov

Author: Sean

Thank you for catching my error.

Re: Dissecting recovery.gov

Author: James Fee

Wonders if ESRI should just buy Recovery.com and run with it. Sean G., you might be on to something here.