Re: [Geojson] PR #199: CRS

[Carl Reed <[e-mail]>]

If I might make a suggestion. Consider OASIS CAP as an example of a simple
CRS expression/requirement.

The OASIS Common Alert Protocol (CAP) has been in use and broadly
implemented since March 2004. As with GeoJSON, the OASIS TC group that
developed CAP wanted to keep the alerting protocol as light weight and as
simple as possible for anyone - especially non GIS developers - to
implement. Early on they decided to specify one and only one CRS. There are
no words about using other CRS.

*Version 1.2 of CAP states:*


*Geographic locations in CAP are defined using [WGS 84] (World Geodetic
System 1984), equivalent to EPSG (European Petroleum Survey Group) code
4326 (2 dimensions). CAP does not assign responsibilities for coordinate
transformations from and to other Spatial Reference Systems. See section
1.5 Terminology for the format of coordinate pairs within CAP elements.*

*1.5 *

*The term “coordinate pair” is used in this document to refer to a
comma-delimited pair of decimal values describing a geospatial location in
degrees, unprojected, in the form “[latitude],[longitude]”.  Latitudes in
the Southern Hemisphere and longitudes in the Western Hemisphere are signed
negative by means of a leading dash.*

CAP is now integrated into many alerting systems and mandated as legal
policy related to EM alerting systems in many countries. Now, I am not
suggesting that the same wording be used. However, CAP provides an exemplar
of a standard that specifies a simple CRS rule without any additional
"clutter", such as SHALL NOTs.

Now, as a side note, getting this simple wording took many conference
calls, emails, and several months! I know - I participated in those
discussions.

Regards

Carl


On Fri, Apr 22, 2016 at 6:10 PM, Allan Doyle <[e-mail]>
wrote:

> I was mainly thinking of the discussion in these threads
>
>
> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-June/000790.html
>
>
> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-December/000880.html
>
> https://github.com/geojson/draft-geojson/pull/15
>
> Martin Daly, Howard Butler and I were generally on the side of keeping
> CRS. As I said earlier, if I’m the lone holdout, I’m not going to stand in
> the way of closing this issue.
>
> Allan
>
> On Apr 22, 2016, at 7:54 PM, <[e-mail]> <[e-mail]>
> wrote:
>
> Have been following this conversation with great interest. Sean's
> description of the situation seems very accurate to me.
>
> The influence of Geojson is not limited to strictly conforming
> applications. For example I used the GeoJSON geometry formulation within a
> JSON implementation of O&M published through OGC last year, but did not
> claim that OM-JSON was therefore GeoJSON, because it otherwise wasn't.
> Other elaborations and extensions and deviations will be created, including
> the ones Sean describes that use other crs. Under the regime proposed none
> of these are GeoJSON, but they are still useful, and it is better to tweak
> something that works than start again.
>
> This all seems like a very useful direction, furthermore would cease
> offending the precious petals in the community that care so much about crs,
> and thus diminish the total level of conflict in the world just a little
> bit. 😉
>
> Simon
>
> ------------------------------
> *From:* GeoJSON <[e-mail]> on behalf of Sean Gillies <
> [e-mail]>
> *Sent:* Friday, 22 April 2016 10:38:41 PM
> *To:* Martin Daly
> *Cc:* Martin Thomson; [e-mail]
> *Subject:* Re: [Geojson] PR #199: CRS
>
> On Thu, Apr 21, 2016 at 12:50 AM, Martin Daly <[e-mail]>
> wrote:
> ...
>
> Interoperability when using different CRSs is possible, just less likely
>> with the wider population of GeoJSON consumers.
>>
>> We discussed the possibility of banning other CRSs, but there was no
>> consensus (quite the opposite, I think). I doubt that that has changed.
>>
>
> Martin,
>
> Interoperability when using different CRS is hardly possible for GeoJSON
> because we don't specify a way to identify the intended CRS. If I serve you
> a file with coordinates like
>
>     [4200.0, 4200.0] ...
>
> with no other information, how are you going to use this data? There's no
> interoperability here.
>
> My reading of https://github.com/geojson/draft-geojson/pull/39 and other
> issues is that support for "other CRS are allowed but NOT RECOMMENDED" was
> actually lukewarm at best. Tim, Howard, and I preferred to drop CRS, along
> with Raj Singh. Allan originally did and then switched. I don't think
> consensus is settled here at all and that it is okay to revisit the
> question.
>
> In https://github.com/geojson/draft-geojson/pull/6 it was clear that
> folks who were serving projected GeoJSON were doing so without any CRS
> definition at all, within their own tightly coupled client-server systems
> (web map front ends dedicated to a particular database). Their
> interoperability needs: zero. The impact on their work from a change to
> "other CRS NOT ALLOWED": zero. As I've written elsewhere, I'm doing the
> same thing in production at work and am perfectly content with my
> representations being only GeoJSON-like, not actual standard GeoJSON.
>
> What I'm not content with is receiving application/geo+json GeoJSON from
> others that uses arbitrary and unidentified coordinate reference systems.
>
> Changing SHOULD NOT to "GeoJSON documents MUST NOT use a coordinate
> reference system other than the one defined here" (
> https://github.com/geojson/draft-geojson/pull/197#issuecomment-212898200)
> is my strong preference. If we can't do this, we should consider writing
> http://geojson.org/geojson-spec.html#coordinate-reference-system-objects
> into the draft or writing a replacement for it.
>
> --
> Sean Gillies
> _______________________________________________
> GeoJSON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geojson
>
>
>
> _______________________________________________
> GeoJSON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geojson
>
>


-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: [phone]