[GeoJSON] Future plans for GeoJSON

[Stefan Drees]

On 26.04.13 18:27, Howard Butler wrote:
>
> On Apr 26, 2013, at 11:07 AM, Sean Gillies <sean.gillies at gmail.com> wrote:
>> One thing I'd like to consider, either before or during the
>> process, would be to strip out the CRS parts of the specification that
>> get very little use. Specifically, the linked and named CRS types.
>> I've only seen non-long/lat GeoJSON in the wild a couple times (City of
>> Chicago's open data is one) and the producers aren't following the
>> specification with regards to CRS. This suggests to me that those parts
>> of the spec are either broken or superfluous.

> As one of the primary forces behind the CRS stuff, I support the
> removal of CRS from the GeoJSON specification. Adhoc specification of
> the coordinate system would then be left to the implementor, and a
> thousand turdblossoms can bloom.

coming from the outside, I think the smaller and compacter the better to 
conserve the spirit of the spec when submitting as RFC.


> A question that should be asked is what the impact of this change
> would be on folks, however. Now that we have javascript reprojection
> engines, the necessity of the crs member is probably not so great in the
> GeoJSON specification (lack of this is what precipitated my desire for
> the crs member in the first place -- you had to go server side to do any
> reproduction operations).

I understood, that the design decision to not support any coordinate 
system imaginable also brought controversial discussions that when the 
member crs is missing from the wannabe RFC candidate would not trigger 
any pressure on the spec. Right?


> It might make more sense to break the crs stuff into its *own* JSONy
> specification, either by leveraging OGC's URN stuff more explicitly, or
> doing something entirely different (proj.4-based, though somewhat
> deficient, seems to have a lot of more generic traction). Then GeoJSON
> could simply reference that effort.

To me this sounds like the job for a vocabulary, where properties may be 
stored that annotate how the data is to be interpreted. I would also 
assume, that clarity through referencing something more complete or with 
more traction as you coin it instead of having a minimal reduced "copy" 
inside GeoJSON might be a good step.

But this of course should also be based on feedback of the community.


All the best,
Stefan.