Dotted JSON namespaces

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.


Re: Dotted JSON namespaces

Author: Tom Kralidis

Wouldn't this result in a bulkier encoding? At least with JDIL, the URIs are defined once (at the top/header) and the prefixes are shorthand refs to them.

I do agree that your proposal above is closer to code.

Re: Dotted JSON namespaces

Author: Sean

A little bulkier, yes, but it's not going to add up to a lot of extra bytes relative to the accompanying coordinates. Flatter namespaces will certainly be easier on the eyes.

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

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.


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.

WS-REST 2010

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.

What geo-intelligence failures?

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!

Adieu, 2009

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.

WMS and URI addressability

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

Can be replaced by:

GET /maps?format=image/png&width=800&height=600&srs=EPSG:4326

Or even, using a specialized host, by:

GET /EPSG/4326/states_population.png?bbox=-180,0,0,90&size=800,400

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.


Re: WMS and URI Addressability

Author: Matt Priour

This is precisely what I would favor. Build good 'geo' server technologies and then use HTTP protocols & URI handlers to provide interaction by REST & OGC Standards techniques.

One could go even further with your example and have the root URI of the resource respond with metadata and provide the required parameters for gridded (server cacheable) tiles, defaulting to standard tile size, grid bbox & resolutions.

In this way you could have any reference system, area, tile size, etc referenced using an X Y Z uri construction that is popular in the commercial web mapping apis and so easily used in OpenLayers and other mapping clients as well.

ArcGIS server is the only server that I know of that is currently implementing something like this. It would be relatively simple to implement a service wrapper for any of the other OGC compliant servers that would allow that kind of interaction.

While I like Atom RSS type interactions for feature reporting, I think URI addressing is a much better method for any dynamic, arbitrarily styled and generated image resource.

La volaille

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.


Re: La volaille

Author: Jerome

Hey, talking about food while eating sure is french.

Chickens you can buy right next farm tastes a lot better than the one you can buy in the supermarket (even though there are many quality grades : poulet portion, poulet jaune, poulet de bresse ... yours may be "poulet de basse cour").

The breed, the food they eat and their growth speed are the main parameters. On one side you have the industrialized-über-selected breed, fed with low cost efficient food to get the standard chicken "portion" as fast as possible. On the other hand are the old kinds, fed with grains and killed "when they look fat enough".

As for almost everything, "the slower the better" :/

Least power

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.


Re: Least power

Author: Kirk Kuykendall

It sure seems like domain specific languages are supposed to provide a least power approach too. I wonder why spatial DSL's haven't been developed.

Re: Least power

Author: Michael Weisman

Perhaps I'm missing something (I am far from an expert on CouchDB) but given how easy it is to query very large datasets in a distributed environment with map reduce functions, and how there really is nothing else that I am aware of for doing distributed GIS (the best tool I have found was hadoop streaming with python scripts), I think there is a good case for PostGIS-caliber geometry functions for couchdb.

Re: Least power

Author: Sean

JEQL and CQL come to mind. MapServer has a spatial filter language too.

Last market before Christmas

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.


Re: Last market before Christmas

Author: Pierre GIRAUD

May I suggest you to put the rest in an hermetic jar with some fresh eggs. Omelettes with those eggs will taste the truffe as they were cooked with it.

Re: Last market before Christmas

Author: Sean

Yes, I've read about that practice, and am curious to see how well it works.

Re: Last market before Christmas

Author: atanas entchev

Buying a fresh truffle at a farmer's market is on my bucket list. You are fortunate to have done it.

Re: Last market before Christmas

Author: Jason E. Rist

You have no idea how jealous I am.

Sweeping your front door

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).