[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