Re: [Geojson] GeoJSON 2.0

[Carl Reed <[e-mail]>]

+1 on the version number. In most standards (or most software for that
matter) a major version number change, such as 1 to 2 or 2 to 3 indicates
that backwards compatibility may be broken.

Cheers

CArl


On Tue, May 3, 2016 at 4:19 PM, Stefan Hagen <[e-mail]> wrote:

> Hi all,
>
> On 3 May 2016 at 20:02:29 +02:00, Sean Gillies <[e-mail]>
> wrote:
>
> Hi all,
> Getting to the finish requires us to reconcile two concerns:
> 1. We have consensus that WGS84 longitude and latitude only will maximize
> interoperability.
> 2. The above is a breaking change (whether you agree the contract it
> breaks was even working in the first place or not) and has to be done in a
> way that does (ideally) no harm to implementers of geojson.org GeoJSON.
>
> As Martin Thomson has suggested, and Dirk-Willem hinted at previously, I
> propose we consider creating a GeoJSON version 2.0 to make the break while
> giving implementers of the historical spec a unique name for what they're
> implementing: "GeoJSON 1.0".
> GeoJSON 1.0 would continue to be defined at
> http://geojson.org/geojson-spec.html. It has no standard media type and
> no standard file extension.
> GeoJSON 2.0 would be our current draft with the change to "MUST NOT use
> CRS other than the default". Its media type is "application/geo+json" and
> its file extensions are ".geojson" and ".json". The media type
> "application/geo+json" would always mean "GeoJSON 2.0".
> I think it makes the most sense to, as previously suggested, add a
> "version" member to the top-level object and give it a value of "2.0":
>   {"type": "FeatureCollection", "version": "2.0", ... }
> On receiving a GeoJSON document with no version member, a parser could try
> to guess the version by looking for a "crs" member. If absent, the document
> is practically equivalent to GeoJSON 2.0.
> My apologies for the circular route we've taken to get here, but we've
> certainly considered the alternatives to not versioning GeoJSON thoroughly
> and have found them unacceptable.
>
> I second Sean's "motion" as version indicators are like dentist
> appointments (sorry for that one) and because the v1.0 part of the proposal
> also nicely documents the ongoing relevance of the community that brought
> GeoJSON v1.0 into existence.
>
> Stefan
> --
> read: hagen.link
> talk:   eventually
>
> _______________________________________________
> GeoJSON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geojson
>
>


-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: [phone]