JSON quacks a lot like a Python dict, so then why not Python (or Java) style dotted namespaces? An arbitrary bit of JSON might be safely extended with GeoJSON geometry like:

{
  ...
  "org.geojson.type": "Point",
  "org.geojson.coordinates": [0.0, 0.0]
}

Or with a feature:

{
  ...
  "org.geojson.geometry": {
    "org.geojson.type": "Point",
    "org.geojson.coordinates": [0.0, 0.0]
  }
}

The GeoJSON working group rejected XML namespaces (such as in JDIL) for 1.0. I recall that I had the most strongly expressed opinion: that GeoJSON should be distinctly JSON and not XML without angle brackets. JSON is less abstracted than XML, closer to code, and dotted namespaces seem like a win to me.

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.

To be held at WWW 2010 in Raleigh, North Carolina next 26 April 2010 [site]:

This first edition of WS-REST, co-located with the WWW2010 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

It would be neat to see some papers on geospatial applications of the REST architectural style on the program.

Busy and having fun! And disgustingly glib about it. The GEOINT community either can't see or won't face its role in the past decade of bamboozlement:

Here we are on the precipice of a new decade. Where did this past decade go? They say time flies when you are having fun or really, really busy. For the GEOINT community, the past decade offered a mixture of both. Many believe, rightly so, that GEOINT came of age in this past decade. The confluence of technologies maturing, political/events (i.e. two wars) and natural disasters has created opportunities and challenges for both the private and public sector. And, as a result, we have seen both sides step up — creating solutions that are light years beyond what was happening ten years ago. And, as we have seen at the most recent GEOINT Symposiums, geospatial intelligence will continue to be the cornerstone for national defense. So, to this we would like to wish the entire GEOINT community a happy and prosperous New Years, as we head into another exciting decade.

The past decade was a slam dunk, baby!

I've never had a year like 2009. My family and I moved to Montpellier, France, to profit (as they say here) from my wife's first sabbatical from teaching at Colorado State. We're at the halfway point of our séjour, glad we came, and looking forward to even more hilarious thrills and spills in 2010. Not only am I fortunate to have such an adventurous family, I am extremely fortunate in these times to be able to take my job with me, and to work for and with such enlightened people. I've travelled in France before, but have never before made my home outside the Rocky Mountains (Utah and Colorado, specifically). I've lived nowhere else in the United States, let alone Europe, so the experience is mind expanding. In my personal life, I can't think of anyone who has impressed me more in the past year than my oldest daughter, who we tossed into the deep end of French école maternelle (preschool) and is making friends and doing fine, and my wife, who has already lapped me in French fluency and wills us all through various opaque bureaucracies. Every time I went to the Prefecture or the OFFI office, I thought about the people who run the immigration gauntlet without the security of a home to return to, little savings, often as a single parent. Humbling.

The past decade? So much good for me, personally, and I've witnessed a lot of inspiring work by others, but for our civilization and the world ... well, it largely stunk, didn't it? A punch in the eye from terrorists in the beginning, an insane stampede into a senseless war, and a kick in the teeth from bankers at the end. All to the soundtrack of the giant sucking sound of our liberties going down the "war on terror" drain. And that's just in the US. Good riddance.

Recently I commented that the saving grace of the the OGC's Web Map Service protocol is that one can use URL rewriting or other tricks to hide parameters like service, request, and version – junk, as in "junk DNA", to those of us who will never in practice rely on protocol version negotiation – and expose to users not a service endpoint but an infinite space of map images addressed by URLs. For example, this request:

GET /geoserver/wms?service=WMS&request=GetMap&version=1.1.1
    &format=image/png&width=800&height=600&srs=EPSG:4326
    &layers=states&styles=population&bbox=-180,0,0,90
Host: http://example.com

Can be replaced by:

GET /maps?format=image/png&width=800&height=600&srs=EPSG:4326
    &layers=states&styles=population&bbox=-180,0,0,90
Host: http://example.com

Or even, using a specialized host, by:

GET /EPSG/4326/states_population.png?bbox=-180,0,0,90&size=800,400
Host: http://maps.example.com

It is the constraint of HTTP called URI addressability that makes this possible. URI addressability means that "a URI alone is sufficient for an agent to carry out a particular type of interaction" [TAG Finding 21 March 2004]. Rewritability isn't the only nice property of resources that are addressable by URIs; it's also then possible to bookmark resources, share links to them, cache them effectively, and migrate users to new locations.

More precisely, the saving grace of WMS is that its protocol parameterization doesn't obstruct URI addressability.

Adam Gopnik, at the end of the second essay ("The Strike") in his collection Paris to the Moon, writes:

The turkey, not quite incidentally, was so much better than any other turkey I have ever eaten that it might have been an entirely different kind of bird.

We (by which I mean my family and I) are having similar experiences with la volaille. On the morning of Christmas Eve, I went down to Les Arceaux to pick up the dinde de Noël my wife had ordered the week before from a local producer. A flock of birds, 30 or so, was waiting behind the plexiglass counter of trailer, each marked with a weight, price, and name (one mine). I didn't see a bird over 5 kilos. Mine, at 3 kg, would be considered a smallish, but not tiny bird. The producer asked me if I wanted him to finish the turkey; I could have brought it home with feet, head, and lungs attached if I'd desired. I did not. He whacked off the extremities, removed the organs, replaced the ones normally considered edible, I paid him and brought home a fowl that if not overcooked (it was, slightly) could have been the best we'd ever eaten.

We've been getting chicken from the same producer: whole birds and wings, plump meaty wings from well-exercised birds, driven up into the trees several times each day, perhaps, by a well-trained French farm dog. My wife is permanently astounded at the smell of the chicken, or rather the lack of smell. Sushi-grade poulet, this is. Even supermarket chicken seems years fresher than its American counterpart. We don't completely understand the factors. Is there a shorter supply chain? We can buy directly from a producer, but I get the sense that mass market birds also spend less time in carcass state around here. A very good thing. Unconsolidated industry? Geography? We'll look into it.

One thing for certain is that the French still, in the 21st century, expect their ingredients to be fresh and their meals to be well made. Yesterday I rode in the Font-Romeu télécabine with a pair of 20-something French dudes, and evesdropped on their conversation about food. One of them wearing one of those ridiculous rainbow poly fleece dreadlock ski hats, not something I'd expect to see on the head of a gourmet. "What's for dinner?" "Cuisse de canard (duck leg, roasted)." "With what?" "Potatoes." "Boiled? I'd prefer a gratin." "That's a little heavy to go with duck, in my opinion ..." They then veered into a reminscence of favorite meals past. This wasn't the first time I'd experienced this; it's a bit like living in the Food Channel here.

Volker Mische on the future of GeoCouch:

You will lose functionality like reprojection. The spatial index won't know anything about projections. So GeoCouch won't be projection aware anymore, but your application still can be. For example if you want to return your data in a different projection than it was stored, you do the transformation after you've queried GeoCouch.

You would also loose fancy things for geometries, like boolean operations on them. But this is something I'd call complex analytics, and not simple querying.

GeoCouch would only support three simple queries: bounding search, polygon search and radius/distance search. If the search would be within a union of polygons, let's say all countries of the European Union, you would simply make the union operation before you query GeoCouch.

To me, this design acknowledges something like a Rule of Least Power for GIS interfaces:

When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The "Rule of Least Power" suggests choosing the least powerful language suitable for a given purpose.

Never before have I had the chance to buy a fresh truffle at my local farmer's market, and I seized that opportunity this morning.

I'm told that the season for Tuber melanosporum is just getting started. This one was sold to me by folks that specialize in beautiful dry-cured hams and is from the nearby oak woods. I actually smelled them before I saw them, and the scent is everywhere around us: the car, the kitchen, the pantry. We wasted no time in shaving off a good quantity to use in omelettes made of farm-fresh organic eggs.

The rest of that nugget is destined to be tossed with roasted roots and bulbs: sweet potato, céleri-rave (celeriac), rutabaga, and fenouil (fennel) for a Christmas dinner side dish.

It was frosty this morning at the market, but just as busy as ever. Freezing together in open air shopping solidarity and the shared mission of acquiring fresh ingredients for holiday dinners seemed to draw people together. I had more interaction with other market-goers than on any other trip.

Good advice:

Finding #8: Starting by sweeping your front door.

Before you agonize about how RESTful your back-end management protocol is, how about you make sure that your management application (the user front-end) is a decent Web application? One with cool URIs, where the back button works, where bookmarks work, where the data is not hidden in some over-encompassing Flash/Silverlight thingy. Just saying.

William Vambenepe's article is as good as advertised (via Tim Bray).