Magnificent seven plus two

A question on geowanking reminded me again of Bill de hÓra's enumeration of the keys to Atom's value:

  • atom:id

  • atom:updated

  • atom:link

  • the extension rules (mustIgnore, foreign markup)

  • the date construct rules

  • the content encoding rules

  • unordered elements

He wrote:

Even if you don't like Atom (or XML for that matter), if your carrier format is going to survive on the web, you need to have addressed these 7 primitives.

For the sake of carrying geographic information on the web, we'll need two additional primitives: location and location construct rules. An item or entry should have one location that is more or less analogous to atom:updated – the current location of the entry in a particular space (Which space? We'll get to that) – not ruling out the possibility of other semantically different locations. The Atom spec says that dates will abide by RFC 3339, period. This means one calendar system (read that as "spatial reference system"), period. Likewise, there should be a single dirt simple construct for location instead of competing options. Date and time can be represented elegantly as text strings with precision that increases as the string grows to the right, but geometries aren't so neatly captured and bulky blocks of XML or JSON seem unavoidable. Of all the geodata formats on the web, KML is doing the best job here: one coordinate system and a single simple yet powerful enough representations for geometries. KML is tied to the Earth, of course, for a Sun-centered (or other) system we'd need a different media type than vnd.google-earth.kml+xml.

KML also gets most of the other primitives right. KML's content encoding rules are an utter mess, but clearly the mass of free aerial and street view imagery is more than compensatory for most web developers. Your own mileage may vary.

Comments

Re: Magnificent seven plus two

Author: Allan Doyle

1. Yikes. Somehow I've fallen off the geowanking list! Thanks for making me realize that.

2. What do you think is sufficient for location? A single point? Or a simple polygon? I'd have said bbox, but I'm guessing bbox is not good enough. Or do we need to allow for all three?

Re: Magnificent seven plus two

Author: Sean

All three of them. KML's points, lines, and polygons aren't too complicated. Multipart geometries are on the complexity borderline. If you're communicating some network event that's relevant to Hawaii, there's little to be gained by representing the archipelago as a multipolygon and excluding the interstitial water. I honestly forget what are the real use cases for multipart geometries, the ones that can't be modeled as a collection of simple parts.

Whether to use polygon, box, or point is an information design decision akin to (Atom analogy here) the decisions whether or not you include full blog text in your feed entries and whether or not you include comments in the feed. That's a choice of content scale. The concept of cartographic scale has worked very well on paper and fairly well on screen, but I'm uneasy (without fully understanding why) about introducing it in headless applications.

Re: Magnificent seven plus two

Author: Allan Doyle

Scale is one of those slippery slope things. It's not strictly necessary, it means different things to different people, and including it would open the floodgates for all sorts of other attributes. Sure, it would be nice to know whether your point refers to something the size of a street lamp or the size of a city. But not knowing that doesn't stop you from doing useful things.