[Geojson] versioning in geojson

Christopher Schmidt crschmidt at metacarta.com
Tue Jul 7 07:41:38 PDT 2009


On Tue, Jul 07, 2009 at 04:02:46PM +0200, Philippe Duchesne wrote:
> Hello all,
> 
> i'm working on an encoding that includes geojson chunks.
> I'm hitting the problem of version encoding. I guess this also arises
> with geojson-only applications, and i'd like your views on this.
> 
> Basically, when a client negociates with a server to exchange data,
> they may have to agree on the encoding version. We currently only have
> geojson 1.0, but what about when we will have an hypothetical 2.0
> client with 1.0 servers out in the wild ? or vice-versa ?

This was asked before we finished the spec, andm y opinion then (and
now) was:

 * If some future version of GeoJSON is completely backwards
   compatible, then it is still 1.x.
 * If it's not, it'll be 2.x.
 * if we ever make a 2.0 (or even a 1.1) we consider adding a version 
   key/value pair at that time.
 * If it doesn't have a version, it's 1.0


> I'm not talking about application schemas (this has been discussed
> extensively in previous threads, and i understand this is not in the
> scope of geojson), but simply about having a way to know what version
> of geojson i'm receiving when i query some geojson datasource. Even
> better, having a way to ask the server a specific encoding.

Currently, you're receiving GeoJSON. If there was a 2.0, presumably it
would identify itself. Either way, your code will need to be changed to
accomodate.

> should it be done using HTTP headers ? (i don't think so)
> should it be done by wrapping the geojson chunk in an
> application-specific json wrapper that provides the versioning
> metadata ? (but then geojson cannot be used on its own)
> other options ?

Should we really bother to worry about it now, when there is only one
version of GeoJSON?

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the GeoJSON mailing list