Subject: [Geojson] AD evaluation: drafti-ietf-geojson-02

From: Alissa Cooper <[email-masked]>
Date: Tue, 12 Apr 2016 13:28:18 -0700

I have reviewed this document in preparation for IETF last call. It is almost ready for last call, but I have a couple of questions I’d like to discuss below first before proceeding. I’ve also listed some nits that should be resolved together with any last call comments.

Questions:

= Section 3.1.1 =

"Implementations SHOULD NOT extend positions beyond 3 elements.
   Parsers MAY ignore additional elements.  Interpretation and meaning
   of additional elements is beyond the scope of this specification."

Since this is given as a SHOULD NOT I assume there are exception cases envisioned where implementations will specify more than 3 elements. What kind of circumstances might give rise to those exception cases? It would be good to provide some explanation in the spec.

= Section 4 =

"Applications requiring a CRS
   other than the default MUST assume all responsibility for CRS
   identification, coordinate accuracy, and interpretation of missing
   elevation values."

"MUST assume responsibility" is a bit of a strange construction for a normative requirement. I think I get what this is trying to accomplish, but I'm not sure it works as phrased. For coordinate accuracy and interpretation of missing values, I think the idea is really to warn implementors that they will have to fill in the gaps if they receive coordinates meant to be understood using a different CRS than what the application is using. Is that right? If so, I think this should just be phrased as a warning, without the normative requirement.

CRS identification is a bit trickier, because it is included in [GJ2008] but not here, so this sort of sounds like it could be recommending use of the crs parameter as specified in [GJ2008] while also not incorporating that into this spec (for an unspecified reason). If you really want to require implementations to identify the CRS if they're not using the default, then I would think a way to do so (a la [GJ2008]) should be included in this spec. If not, then it seems inappropriate to normatively require that the CRS be identified; a non-normative recommendation would do instead, I think. Note that the decision of what to do here also has bearing on Section 10.3, which basically assumes that the CRS will be identified.

Nits:

= General =

(1) Typically RFCs in the IETF stream are limited to 5 authors. Would you consider collecting authorship under 1 or 2 editors? If not, do all 6 authors here expect to be active in responding to review comments and AUTH48 questions?

(2) The other geographic position formats that have been specified previously in the IETF include some support for expressing uncertainty. It would be helpful to explain somewhere in this spec why it is not doing that.

= Section 3.1 =

s/A Geometry object represents points, curves, and surfaces in coordinate space./A Geometry object represents a point, curve, or surface in coordinate space./

= Section 4 =

s/height in meters above the WGS 84 reference ellipsoid./height in meters above or below the WGS 84 reference ellipsoid./

(Right? I'm assuming this element also covers depth.)

= Section 10.4 =

s/SHOULD/should/

---

From: Tim Schaub <[email-masked]>
Date: Wed, 13 Apr 2016 14:55:52 -0600

Some responses inline below.

> "MUST assume responsibility" is a bit of a strange construction for a normative requirement. I think I get what this is trying to accomplish, but I'm not sure it works as phrased. For coordinate ac…

I think it makes sense to reword this as a warning.  Applications
using GeoJSON to represent geometries in a CRS other than the default
sacrifice interoperability.

> (1) Typically RFCs in the IETF stream are limited to 5 authors. Would you consider collecting authorship under 1 or 2 editors? If not, do all 6 authors here expect to be active in responding to rev…

The RFC lists 5 of the authors or the original spec who have remained
active in its maintenance and development.  Among them, Sean has
really carried the torch through the IETF process.  But I imagine all
would be willing to participate in reviewing comments and questions
that come out of this process.

I'm personally interested in remaining active and would welcome
suggestions on how to participate in the IETF process.

> s/A Geometry object represents points, curves, and surfaces in coordinate space./A Geometry object represents a point, curve, or surface in coordinate space./

I agree your language sounds more natural.  But a GeoJSON geometry may
also be a multi-point, multi-linestring, multi-polygon, or mixed
collection of point/line/poly.  So a single GeoJSON geometry object
may represent multiple points etc.

> (Right? I'm assuming this element also covers depth.)

https://github.com/geojson/draft-geojson/pull/193

> s/SHOULD/should/

https://github.com/geojson/draft-geojson/pull/194

As noted there, it is not clear to me why we would use "should" for
Antimeridian Cutting considerations (10.4) and SHOULD for Geometry
Collections considerations (10.5), but I'm interested to understand
the distinction.

Tim

> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Apr 2016 22:50:09 -0300

> Collections considerations (10.5), but I'm interested to understand

I thought that I understood the nuance of SHOULD/should usage, but I
think that I'm with Tim on this one.  The point here is to recommend
actions that maximize interoperability, and splitting at the
antimeridian does that.  To my mind, the capitalized variant is
entirely appropriate here.

---

From: "Stefan Hagen" <[email-masked]>
Date: Thu, 14 Apr 2016 13:21:01 +0200

On 12 April 2016 at 22:28:18 +02:00, Alissa Cooper <[email-masked]> wrote:

> ...
Chiming in alongside Tim:
I noticed in the past and also imagine for the future, that all
currently listed authoring members of the GeoJSON community
are willing to participate in reviewing comments and questions
that come out of this process.

> ...
Best,
Stefan
--
read: stefan-hagen.website
talk: eventually

---

From: Sean Gillies <[email-masked]>
Date: Thu, 14 Apr 2016 12:06:52 -0600

On Thu, Apr 14, 2016 at 5:21 AM, Stefan Hagen <[email-masked]> wrote:

> I have reviewed this document in preparation for IETF last call. It is
> almost ready for last call, but I have a couple of questions I’d like to
> discuss below first before proceeding. I’ve also listed some nits that
> should be resolved together with any last call comments.
>
> ...
> Nits:
>
> = General =
>
> (1) Typically RFCs in the IETF stream are limited to 5 authors. Would you
> consider collecting authorship under 1 or 2 editors? If not, do all 6
> authors here expect to be active in responding to review comments and
> AUTH48 questions?
>
>

If we had to reduce the number of authors, we could take from the current
list of 6 the 5 with the most commits

$ git shortlog -sne
   185  Sean Gillies <[email-masked]>
    35  Erik Wilde <[email-masked]>
    29  Sean Gillies <[email-masked]>
    22  Stefan Drees <[email-masked]>
    17  Tim Schaub <[email-masked]>
    11  Martin Thomson <[email-masked]>
     7  Paul Ramsey <[email-masked]>
     6  mpdaly <[email-masked]>
     4  sgillies <[email-masked]>
     3  Tim Schaub <[email-masked]>
     3  S. Andrew Sheppard <[email-masked]>
     2  Simon J D Cox <[email-masked]>
     2  Martin Daly <[email-masked]>
     2  Matthew Perry <[email-masked]>
     2  Erik Wilde <[email-masked]>
     1  Blake Grotewold <[email-masked]>
     1  Simon Cox <[email-masked]>
     1  Dirk-Willem van Gulik <[email-masked]>
     1  Stefan Drees <[email-masked]>

which would be Sean Gillies, Stefan Drees, Tim Schaub, Martin Daly. Does
that seem fair? I'd make sure that all original authors and WG participants
get acknowledged in the draft, of course.

-- 
Sean Gillies

---

From: Allan Doyle <[email-masked]>
Date: Thu, 14 Apr 2016 14:36:19 -0400

I don't see github commits as a valid metric. I find it to be too simplistic, not respectful of the effort put in since the inception, and an inaccurate measure of how much time any given individual has put in to the spec.

There was a discussion of this in 2014:
https://github.com/geojson/draft-geojson/issues/54 <https://github.com/geojson/draft-geojson/issues/54>

> On Apr 14, 2016, at 2:06 PM, Sean Gillies <[email-masked]> wrote:
> 
> 
> 
> On Thu, Apr 14, 2016 at 5:21 AM, Stefan Hagen <[email-masked] <mailto:[email-masked]>> wrote:
> On 12 April 2016 at 22:28:18 +02:00, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> If we had to reduce the number of authors, we could take from the current list of 6 the 5 with the most commits 
> 
> $ git shortlog -sne
>    185  Sean Gillies <[email-masked] <mailto:[email-masked]>>
>     35  Erik Wilde <[email-masked] <mailto:[email-masked]>>
>     29  Sean Gillies <[email-masked] <mailto:[email-masked]>>
>     22  Stefan Drees <[email-masked] <mailto:[email-masked]>>
>     17  Tim Schaub <[email-masked] <mailto:[email-masked]>>
>     11  Martin Thomson <[email-masked] <mailto:[email-masked]>>
>      7  Paul Ramsey <[email-masked] <mailto:[email-masked]>>
>      6  mpdaly <[email-masked] <mailto:[email-masked]>>
>      4  sgillies <[email-masked] <mailto:[email-masked]>>
>      3  Tim Schaub <[email-masked] <mailto:[email-masked]>>
>      3  S. Andrew Sheppard <[email-masked] <mailto:[email-masked]>>
>      2  Simon J D Cox <[email-masked] <mailto:[email-masked]>>
>      2  Martin Daly <[email-masked] <mailto:[email-masked]>>
>      2  Matthew Perry <[email-masked] <mailto:[email-masked]>>
>      2  Erik Wilde <[email-masked] <mailto:[email-masked]>>
>      1  Blake Grotewold <[email-masked] <mailto:[email-masked]>>
>      1  Simon Cox <[email-masked] <mailto:[email-masked]>>
>      1  Dirk-Willem van Gulik <[email-masked] <mailto:[email-masked]>>
>      1  Stefan Drees <[email-masked] <mailto:[email-masked]>>
> 
> which would be Sean Gillies, Stefan Drees, Tim Schaub, Martin Daly. Does that seem fair? I'd make sure that all original authors and WG participants get acknowledged in the draft, of course.
> 
> -- 
> Sean Gillies
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/geojson <https://www.ietf.org/mailman/listinfo/geojson>

---

From: Sean Gillies <[email-masked]>
Date: Thu, 14 Apr 2016 12:44:42 -0600

> entirely appropriate here.

I, too, would like to keep SHOULD. Anti-meridian cutting makes a world of
difference for interoperability.

-- 
Sean Gillies

---

From: Howard Butler <[email-masked]>
Date: Thu, 14 Apr 2016 13:49:49 -0500

You can remove my name.

> On Apr 14, 2016, at 1:36 PM, Allan Doyle <[email-masked]> wrote:
> 
> https://github.com/geojson/draft-geojson/issues/54
> 
>

---

From: Allan Doyle <[email-masked]>
Date: Thu, 14 Apr 2016 14:52:16 -0400

I'd be ok with having a single editor in the running head, i.e. Sean, and the rest of the authors and contributors in a contributors section.

	Allan

> On Apr 14, 2016, at 2:49 PM, Howard Butler <[email-masked]> wrote:
> 
> You can remove my name.
>

---

From: Sean Gillies <[email-masked]>
Date: Thu, 14 Apr 2016 12:52:43 -0600

On Wed, Apr 13, 2016 at 2:55 PM, Tim Schaub <[email-masked]> wrote:

> > Since this is given as a SHOULD NOT I assume there are exception cases
> envisioned where implementations will specify more than 3 elements. What
> kind of circumstances might give rise to those exception cases? It would be
> good to provide some explanation in the spec.
> >
> > = Section 4 =
> >
> > "MUST assume responsibility" is a bit of a strange construction for a
> normative requirement. I think I get what this is trying to accomplish, but
> I'm not sure it works as phrased. For coordinate accuracy and
> interpretation of missing values, I think the idea is really to warn
> implementors that they will have to fill in the gaps if they receive
> coordinates meant to be understood using a different CRS than what the
> application is using. Is that right? If so, I think this should just be
> phrased as a warning, without the normative requirement.
>

Yes, I agree. How about "have sole responsibility" instead of "must" to
make it clear that this is not normative?

-- 
Sean Gillies

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 14 Apr 2016 12:02:33 -0700

> On Apr 14, 2016, at 11:44 AM, Sean Gillies <[email-masked]> wrote:
> 
> On Wed, Apr 13, 2016 at 7:50 PM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> On 13 April 2016 at 17:55, Tim Schaub <[email-masked] <mailto:[email-masked]>> wrote:
> >> = Section 10.4 =
> >>
> >> s/SHOULD/should/
> >
> > https://github.com/geojson/draft-geojson/pull/194 <https://github.com/geojson/draft-geojson/pull/194>
> >
> I, too, would like to keep SHOULD. Anti-meridian cutting makes a world of difference for interoperability.

My issue here is that the normative requirements are given within examples. If this needs to be a normative requirement (which I have no problem with), it should be stated generically, and then the examples can be provided for illustration without normative language.

Alissa

---

From: Allan Doyle <[email-masked]>
Date: Thu, 14 Apr 2016 14:54:36 -0400

> On Apr 14, 2016, at 2:52 PM, Sean Gillies <[email-masked]> wrote:
> 
> On Wed, Apr 13, 2016 at 2:55 PM, Tim Schaub <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Apr 12, 2016 at 2:28 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> 
...
> Yes, I agree. How about "have sole responsibility" instead of "must" to make it clear that this is not normative?
> 

+1

---

From: Sean Gillies <[email-masked]>
Date: Thu, 14 Apr 2016 14:18:46 -0600

Hi Alissa,

You had 2 comments that I haven't yet addressed...

> good to provide some explanation in the spec.

There are historical exceptions. There once was a practice of adding a
linear referencing measure ("M") as a 4th position element of LineStrings
and software is still out there that will write a 4th element if given,
e.g., a PolylineM Shapefile. The 4th element has been used by some to store
a numerical timestamp. That you can't know what the 4th element means
(measure or time?) is why implementers should not do this, and I'm happy to
try to explain that.

Nits:
> (2) The other geographic position formats that have been specified
> previously in the IETF include some support for expressing uncertainty. It
> would be helpful to explain somewhere in this spec why it is not doing that.
>

I'll take a try at this, too. Basically, it's that geospatial applications
don't have established ways of calculating with rough or fuzzy locations
and we'd be getting too far ahead of the field by including it.

-- 
Sean Gillies

---

From: Carl Reed <[email-masked]>
Date: Thu, 14 Apr 2016 14:40:01 -0600

Sean -

Having reviewed some of the IETF RFCs that deal with uncertainty, a slight
clarification. Uncertainty of a location estimate has to do with the
collection method for a location. That uncertainty measure is provided as
part of the metadata/provenance of the location being encoded and
communicated. Whether the measure of uncertainty is used in future
calculations or not is a different discussion. One use case for providing
the uncertainty measure is driven by NextGen 911 and the provision of a
cell phone location. The uncertainty of the location is a function of the
observation measurement technology used (triangulation, GPS, etc). Much
like the USGS +/- measures provided with the various quadrangle map scales.

If anyone is interested, check out https://tools.ietf.org/html/rfc7459. An
excellent piece of work!

>From the introduction:

Location information represents an estimation of the position of a
   Target [RFC6280 <https://tools.ietf.org/html/rfc6280>].  Under
ideal circumstances, a location estimate
   precisely reflects the actual location of the Target.  For automated
   systems that determine location, there are many factors that
   introduce errors into the measurements that are used to determine
   location estimates.

   The process by which measurements are combined to generate a location
   estimate is outside of the scope of work within the IETF.  However,
   the results of such a process are carried in IETF data formats and
   protocols.  This document outlines how uncertainty, and its
   associated datum, confidence, are expressed and interpreted.

Regards

Carl

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Allan Doyle <[email-masked]>
Date: Thu, 14 Apr 2016 16:59:33 -0400

Uncertainty information expressed as metadata could be included in a GeoJSON file. A community such as the one developing RFC 7459 could define metadata elements that can be overlaid onto GeoJSON.

	Allan

P.S. I note that RFC 6280 has six authors listed in the header.

> On Apr 14, 2016, at 4:40 PM, Carl Reed <[email-masked]> wrote:
> 
> Sean -
> 
> Having reviewed some of the IETF RFCs that deal with uncertainty, a slight clarification. Uncertainty of a location estimate has to do with the collection method for a location. That uncertainty measure is provided as part of the metadata/provenance of the location being encoded and communicated. Whether the measure of uncertainty is used in future calculations or not is a different discussion. One use case for providing the uncertainty measure is driven by NextGen 911 and the provision of a cell phone location. The uncertainty of the location is a function of the observation measurement technology used (triangulation, GPS, etc). Much like the USGS +/- measures provided with the various quadrangle map scales.
> 
> If anyone is interested, check out https://tools.ietf.org/html/rfc7459 <https://tools.ietf.org/html/rfc7459>. An excellent piece of work! 
> 
> From the introduction:
> 
>    Target [RFC6280 <https://tools.ietf.org/html/rfc6280>].  Under ideal circumstances, a location estimate
> On Thu, Apr 14, 2016 at 2:18 PM, Sean Gillies <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alissa,
> 
> There are historical exceptions. There once was a practice of adding a linear referencing measure ("M") as a 4th position element of LineStrings and software is still out there that will write a 4th element if given, e.g., a PolylineM Shapefile. The 4th element has been used by some to store a numerical timestamp. That you can't know what the 4th element means (measure or time?) is why implementers should not do this, and I'm happy to try to explain that.
> 
> Nits:
> 
> = General =
> 
> I'll take a try at this, too. Basically, it's that geospatial applications don't have established ways of calculating with rough or fuzzy locations and we'd be getting too far ahead of the field by including it.
> 
> -- 
> Sean Gillies
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 14 Apr 2016 15:07:54 -0700

> On Apr 13, 2016, at 1:55 PM, Tim Schaub <[email-masked]> wrote:
> 

Responding to this and a few of the other responses — the 5-author limit is not a hard-and-fast rule, but if there are more than 5 authors we will need to seek specific approval from the IESG. I am fine with whichever resolution you all decide on — dropping 1 author; reducing down to 1 editor + contributors; or keeping the author list as-is, committing to being responsive during AUTH48, and requesting the approval from the IESG.

> may represent multiple points etc.

Ok, fair enough.

Alissa

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 15 Apr 2016 11:08:32 +0200

> Uncertainty information expressed as metadata could be included in a GeoJSON file. A community such as the one developing RFC 7459 could define metadata elements that can be overlaid onto GeoJSON.

I would also add that by reducing the number of digits in the coordinate - you are in effect able to ‘fuzz’ the location to a 1x1 degree box - which is about 100 km x 100k at the equator - and larger than 50x100km for most of the inhabited world.

That is fair bit of practical leeway to express uncertainty.

One could update the spec with something like

	Implementors SHOULD not overrepresent the accuracy of the location; and limit the number of digits. Thus a coordinate of 50,20 is not as precise than 50.000,19.9999’.

Or even stronger - where we state that the number of digits MUST be in correspondence with the accuracy. Which IMHO is a bridge too far — to many implementors are very far away from the fire - and hence have no idea.

Dw
>> On Apr 14, 2016, at 4:40 PM, Carl Reed <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Sean -
>>

---

From: James Winterbottom <[email-masked]>
Date: Fri, 15 Apr 2016 19:30:10 +1000

This concept was done to death in Geopriv and not well regarded.
Dig up the archives if you want the full story, or ask the chair… *8)
I don’t recommend embarking down that road again though.

Chers
James

> On 15 Apr 2016, at 7:08 pm, Dirk-Willem van Gulik <[email-masked]> wrote:
> 
> On 14 Apr 2016, at 22:59, Allan Doyle <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Carl Reed <[email-masked]>
Date: Fri, 15 Apr 2016 08:37:26 -0600

Putting my "standards geek" hat on, be careful that the spec does not get
overloaded with best practice content. This is easy to do. Perhaps the
group should consider two documents: A short, normative document (the way
GeoJSON used to be) and then a companion best practice RFC. Many other
internet standards are structured this way. So, in that case guidance on
digits per coordinate versus size of the encoding, anti-meridian guidance,
guidance at the poles, and so forth would be in the best practice guidance
document and not in the "core" normative document.

Just a thought.

Regards

Carl

On Fri, Apr 15, 2016 at 3:08 AM, Dirk-Willem van Gulik <[email-masked]

> Uncertainty information expressed as metadata could be included in a
> GeoJSON file. A community such as the one developing RFC 7459 could define
> metadata elements that can be overlaid onto GeoJSON.
>
>
> I would also add that by reducing the number of digits in the coordinate -
> you are in effect able to ‘fuzz’ the location to a 1x1 degree box - which
> is about 100 km x 100k at the equator - and larger than 50x100km for most
> of the inhabited world.
>
> Implementors SHOULD not overrepresent the accuracy of the location; and
> limit the number of digits. Thus a coordinate of 50,20 is not as precise
> than 50.000,19.9999’.
>
> Or even stronger - where we state that the number of digits MUST be in
> correspondence with the accuracy. Which IMHO is a bridge too far — to many
> implementors are very far away from the fire - and hence have no idea.
>
> Dw
>
>
> If anyone is interested, check out https://tools.ietf.org/html/rfc7459.
> An excellent piece of work!
>
> From the introduction:
>
>>> (1) Typically RFCs in the IETF stream are limited to 5 authors. Would
>>> you consider collecting authorship under 1 or 2 editors? If not, do all 6
>> I'll take a try at this, too. Basically, it's that geospatial
>> applications don't have established ways of calculating with rough or fuzzy
>> locations and we'd be getting too far ahead of the field by including it.
>>
>> --
>> Sean Gillies
>>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 15 Apr 2016 10:52:53 -0700

> On Apr 15, 2016, at 2:30 AM, James Winterbottom <[email-masked]> wrote:
> 

Indeed, and this is why we ended up with RFC 7459.

My comment was not that this document needs to support expression of uncertainty. My comment was that the document needs to say something about why it is not supporting uncertainty. Saying that it is not currently supported in applications but could be specified with new metadata elements in the future seems reasonable to me.

Alissa

> 
> Chers
> James
> 
> 
> 
>> On 15 Apr 2016, at 7:08 pm, Dirk-Willem van Gulik <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 15 Apr 2016 11:15:15 -0700

>> CRS identification is a bit trickier, because it is included in [GJ2008] but not here, so this sort of sounds like it could be recommending use of the crs parameter as specified in [GJ2008] while…

After some off-list exchanges, I’d like to probe a bit more on the way the spec deals with the choice of CRS currently. I understand that the way the original GeoJSON spec handled choice of default CRS and support for alternatives was not ideal from an interoperability perspective, because even when use of an alternative CRS was flagged it was sometimes ignored. So I think I get the motivation for not having the WG draft support declaration of alternative CRS.

However, when we’ve defined location formats in the IETF before (PIDF-LO, geoURI), they have supported the ability to specify the CRS. My understanding is that most other globally recognized location format standards also support this. So not doing so here would be a substantial deviation from established practice, and could create problems of interoperation within systems that support multiple formats.

Furthermore, won’t existing implementations need to change in order to support the IETF-standardized version of GeoJSON? Why doesn’t that then create an opportunity to enable support for, at a bare minimum, refusing to process GeoJSON objects that declare an alternative CRS? I guess what I’m wondering is if the situation is still as it was when support for the crs member was added to the original GeoJSON spec. 

Alissa

---

From: Christine Waigl <[email-masked]>
Date: Fri, 15 Apr 2016 11:48:17 -0800

I have one question and one remark on this.
On Fri, Apr 15, 2016 at 10:15 AM, Alissa Cooper <[email-masked]> wrote:
>
>
> After some off-list exchanges, I’d like to probe a bit more on the way
the spec deals with the choice of CRS currently. I understand that the way
the original GeoJSON spec handled choice of default CRS and support for
alternatives was not ideal from an interoperability perspective, because
even when use of an alternative CRS was flagged it was sometimes ignored.
So I think I get the motivation for not having the WG draft support
declaration of alternative CRS.
>
> However, when we’ve defined location formats in the IETF before (PIDF-LO,
geoURI), they have supported the ability to specify the CRS. My
understanding is that most other globally recognized location format
standards also support this. So not doing so here would be a substantial
deviation from established practice, and could create problems of
interoperation within systems that support multiple formats.

1 - Question: What should happen when the something comes along and
supersedes WGS 84? To come up with a buzzword, don't we have a CRS agility
problem here? We *will* get a new geoid one day after all...

2 - Remark: I'm very much sharing Alissa's concerns. In the use cases I am
most personally familiar with [*], the ability to specify a CRS and use a
non-WGS 84 CRS would be a make-or-break requirement for adopting GeoJSON
(to supersede, essentially, ESRI Shapefiles). In other words, I have no
problem whatsoever with "The default reference system for all GeoJSON
coordinates SHALL be a geographic coordinate reference system, using the
WGS 84 [WGS84] datum, and with longitude and latitude units of decimal
degrees. " or "GeoJSON processing software SHALL NOT be expected to have
access to  coordinate reference systems databases." I just want to have the
ability to specify an (optional) CRS element in what's essentially
metadata. I'm fine with the existence of processing systems out there that
would choke on/reject my non-WGS 84 GeoJSON.

Thanks,

Chris Waigl

(*) This would be for example public agencies whose holdings may be (in the
US) in NAD 83 and even some NAD 27, or ETRS89 (official EU recommendation)
with some obstacles to standardising on WGS 84. Or my own use case, which
is persisting intermediate and final dataset output from data analysis,
where often WGS 84 makes no sense at all, as they involve spatial
statistics (ie., need to measure areas and distances).

-- 
Christine (Chris) Waigl - [email-masked] -  +1-907-474-5483 - Skype:
cwaigl_work
Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA

---

From: Martin Daly <[email-masked]>
Date: Fri, 15 Apr 2016 19:58:48 +0000

Alissa,

> After some off-list exchanges, I’d like to probe a bit more on the way the spec
> deals with the choice of CRS currently. I understand that the way the original
> GeoJSON spec handled choice of default CRS and support for alternatives was
> not ideal from an interoperability perspective, because even when use of an
> alternative CRS was flagged it was sometimes ignored. So I think I get the
> motivation for not having the WG draft support declaration of alternative CRS.
> 
> geoURI), they have supported the ability to specify the CRS. My understanding
> is that most other globally recognized location format standards also support
> this. So not doing so here would be a substantial deviation from established
> practice, and could create problems of interoperation within systems that
> support multiple formats.
> 
> Furthermore, won’t existing implementations need to change in order to
> support the IETF-standardized version of GeoJSON? Why doesn’t that then
> create an opportunity to enable support for, at a bare minimum, refusing to
> process GeoJSON objects that declare an alternative CRS? I guess what I’m
> wondering is if the situation is still as it was when support for the crs member
> was added to the original GeoJSON spec.

CRSs are a minefield. They are poorly understood, sometimes poorly implemented, by developers even inside the GIS/spatial domain. The widely used WKT definitions are unfriendly to developers of all stripes, but most of all web developers. Axes order issues plague standards bodies, specifications, formats, and developers.

Just as with some other stuff that we've rejected on the grounds of simplicity, alternatives to GeoJSON are out there that do embrace CRS choice more fully. I would recommend to anyone with non-simple CRS requirements to choose one of them.

Within a domain of use, parties can agree to use the old [GJ2008] CRS object however they see fit, and can expect to interoperate with each other. They run the risk of not interoperating with the wider world though, which is made clear in the text as it stands. For example, don't expect Github to start displaying GeoJSON that uses anything other than the default CRS in the right place in the world:

https://help.github.com/articles/mapping-geojson-files-on-github/

(Note that they call the default CRS a "projection", which it isn't. That isn't a criticism, just an example of a common, basic terminology misunderstanding that points to a wider problem.)

Both GeoRSS Simple and OGC KML take the same, fixed CRS based on the WGS 84 datum, approach.

Martin

---

From: Carl Reed <[email-masked]>
Date: Fri, 15 Apr 2016 14:45:59 -0600

As Martin states, CRS discussions can become quite contentious.

Eight years ago, the OGC - after months of discussion and argument - agreed
to Axis Order guidance for not just the OGC but the broader community:

http://www.ogcnetwork.net/axisorder

The reason for providing this guidance was decreasing interoperability of
geo-encodings due to inconsistent use and/or lack of documentation on the
correct use of CRS for that encoding. For example, a developer might state
WGS 84 (EPSG 4326) in their documentation but then provide an encoding
where the axis order is reversed. This was a big issue even within just the
OGC membership. Hence the guidance.

The bottom line of the guidance is "honesty"

KML, CAP, PIDF-LO, GeoRSS and many more specs and standards follow this
guidance either by design, by the developer understanding of CRS, or by
following the guidance.

GeoJSON should be Case 2 but as soon as you try to add additional
conditions, then long discussions ensue. Even though I believe in CRS
flexibility for any encoding, I would be quite happy if GeoJSON simply
stated WGS 84 but with the axis order reversed, which is aka CRS:84 (WGS 84
longitude-latitude).

Regards

Carl

On Fri, Apr 15, 2016 at 1:58 PM, Martin Daly <[email-masked]>
wrote:

> the spec
> understanding
> CRSs are a minefield. They are poorly understood, sometimes poorly
> implemented, by developers even inside the GIS/spatial domain. The widely
> used WKT definitions are unfriendly to developers of all stripes, but most
> of all web developers. Axes order issues plague standards bodies,
> specifications, formats, and developers.
>
> Just as with some other stuff that we've rejected on the grounds of
> simplicity, alternatives to GeoJSON are out there that do embrace CRS
> choice more fully. I would recommend to anyone with non-simple CRS
> requirements to choose one of them.
>
> Within a domain of use, parties can agree to use the old [GJ2008] CRS
> object however they see fit, and can expect to interoperate with each
> other. They run the risk of not interoperating with the wider world though,
> which is made clear in the text as it stands. For example, don't expect
> Github to start displaying GeoJSON that uses anything other than the
> default CRS in the right place in the world:
>
> (Note that they call the default CRS a "projection", which it isn't. That
> isn't a criticism, just an example of a common, basic terminology
> misunderstanding that points to a wider problem.)
>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Martin Thomson <[email-masked]>
Date: Sat, 16 Apr 2016 12:08:35 +1000

> stated WGS 84 but with the axis order reversed, which is aka CRS:84 (WGS 84

Is there a specific change to the document that would help here?  I
know exactly how tricky this is, so I don't want to say how this could
be improved.

The current text is:

   The default reference system for all GeoJSON coordinates SHALL be a
   geographic coordinate reference system, using the WGS 84 [WGS84]
   datum, and with longitude and latitude units of decimal degrees.
   This coordinate reference system is equivalent to the OGC's "http://
   www.opengis.net/def/crs/OGC/1.3/CRS84" [OGCURL].  To maximize
   interoperability, GeoJSON data SHOULD use this default coordinate
   reference system.  An OPTIONAL third position element SHALL be the
   height in meters above the WGS 84 reference ellipsoid.  In the
   absence of elevation values, applications sensitive to height or
   depth SHOULD interpret positions as being at local ground or sea
   level.

---

From: Tim Schaub <[email-masked]>
Date: Sat, 16 Apr 2016 09:28:28 -0600

On Fri, Apr 15, 2016 at 8:37 AM, Carl Reed <[email-masked]> wrote:
> overloaded with best practice content. This is easy to do.

Having just said I was in favor of Sean's suggestion to maintain the
geometry collection and anti-meridian cutting stuff as normative, I
also like the idea of not ending up with a spec that is bogged down
with best practice recommendations.

Having two RFC sounds like a lot of extra work to me - and I imagine
it would be too easy to dismiss the second.

Do others think that these best practices recommendations should be
non-normative in favor of limiting the required reading to implement a
compliant parser?

> Perhaps the group
> should consider two documents: A short, normative document (the way GeoJSON
> used to be) and then a companion best practice RFC. Many other internet
> standards are structured this way. So, in that case guidance on digits per
> coordinate versus size of the encoding, anti-meridian guidance, guidance at
> the poles, and so forth would be in the best practice guidance document and
> not in the "core" normative document.
>
> Just a thought.
>
> Regards
>
> Carl
>
>
> On Fri, Apr 15, 2016 at 3:08 AM, Dirk-Willem van Gulik
> <[email-masked]> wrote:
>>
>> you are in effect able to ‘fuzz’ the location to a 1x1 degree box - which is
>> about 100 km x 100k at the equator - and larger than 50x100km for most of
>> the inhabited world.
>>
>> the uncertainty measure is driven by NextGen 911 and the provision of a cell
>> phone location. The uncertainty of the location is a function of the
>> observation measurement technology used (triangulation, GPS, etc). Much like
>> the USGS +/- measures provided with the various quadrangle map scales.
>>
>>    Target [RFC6280].  Under ideal circumstances, a location estimate
>>>> authors here expect to be active in responding to review comments and AUTH48
>>>> questions?
>>>>

---

From: Tim Schaub <[email-masked]>
Date: Sat, 16 Apr 2016 13:08:04 -0600

On Fri, Apr 15, 2016 at 1:48 PM, Christine Waigl <[email-masked]> wrote:
>> After some off-list exchanges, I’d like to probe a bit more on the way the
>> spec deals with the choice of CRS currently. I understand that the way the
>> original GeoJSON spec handled choice of default CRS and support for
>> even when use of an alternative CRS was flagged it was sometimes ignored. So
>> I think I get the motivation for not having the WG draft support declaration
>> of alternative CRS.
>>

We get a new geoid every day :)

I think you mean that some day the bulk of spatial data will use a
geographic coordinate system with something newer than the WGS 84
datum (and there are options to choose from today).  I agree.  The
motion of the tectonic plates also means that GeoJSON created today
won't represent the same "places" in the future.  Depending on your
perspective, the latter might actually be a bigger problem than the
former.

The point of standardizing on the WGS 84 datum is to maximize
interoperability with minimal burden on consumers and producers.  The
"crs" member in the community spec only resulted in a lot of invalid
GeoJSON (the use of a projected coordinate system without a crs
member) and parsers that couldn't actually handle what GeoJSON
allowed.

I think removing the option to specify alternative coordinate
reference systems is a good tradeoff - favoring simplicity and
interoperability at the expense of some flexibility and longevity.

> non-WGS 84 CRS would be a make-or-break requirement for adopting GeoJSON (to
> supersede, essentially, ESRI Shapefiles). In other words, I have no problem
> whatsoever with "The default reference system for all GeoJSON coordinates
> SHALL be a geographic coordinate reference system, using the WGS 84 [WGS84]
> datum, and with longitude and latitude units of decimal degrees. " or
> "GeoJSON processing software SHALL NOT be expected to have access to
> coordinate reference systems databases." I just want to have the ability to
> specify an (optional) CRS element in what's essentially metadata. I'm fine
> with the existence of processing systems out there that would choke
> on/reject my non-WGS 84 GeoJSON.
>
> Thanks,
>
> Chris Waigl
>
> with some obstacles to standardising on WGS 84. Or my own use case, which is
> persisting intermediate and final dataset output from data analysis, where
> often WGS 84 makes no sense at all, as they involve spatial statistics (ie.,
> need to measure areas and distances).
>
> --

---

From: Sean Gillies <[email-masked]>
Date: Sat, 16 Apr 2016 17:38:11 -0600

> non-normative in favor of limiting the required reading to implement a

I can live with "should" when it comes to geometry collections and
antimeridian cutting (as our AD suggested). I don't think the draft is
anywhere near overloaded with interop recommendations and would not like
these to be removed.

---

From: James Winterbottom <[email-masked]>
Date: Sun, 17 Apr 2016 09:52:34 +1000

Thanks Alissa,

My comment was more around the suggestion of trying to use the number of significant digits in the definition of the latitude and longitude as a direct expression on uncertainty. Think the RFC 3825 saga.

Cheers
James

> On 16 Apr 2016, at 3:52 am, Alissa Cooper <[email-masked]> wrote:
> 
> 
>> On Apr 15, 2016, at 2:30 AM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Sean Gillies <[email-masked]>
Date: Sat, 16 Apr 2016 22:00:24 -0600

Hi Chris,

On Fri, Apr 15, 2016 at 1:48 PM, Christine Waigl <[email-masked]> wrote:

> > However, when we’ve defined location formats in the IETF before
> (PIDF-LO, geoURI), they have supported the ability to specify the CRS. My

Given that we want to maximize interoperability by choosing a single,
global coordinate reference system, how agile do we need to be? How soon do
you expect WGS 84 to be replaced by another widely-deployed global system?
When that happens, I think we should write another I-D that updates this
one and that recommends a new single, global coordinate reference system
and specifies how implementations would make the transition.

> (*) This would be for example public agencies whose holdings may be (in
> the US) in NAD 83 and even some NAD 27, or ETRS89 (official EU
> recommendation) with some obstacles to standardising on WGS 84. Or my own
> use case, which is persisting intermediate and final dataset output from
> data analysis, where often WGS 84 makes no sense at all, as they involve
> spatial statistics (ie., need to measure areas and distances).
>

GeoJSON isn't designed to replace the Shapefile (explained at
https://en.wikipedia.org/wiki/Shapefile for those of us who are not
familiar with the format) or GML (the OGC's XML dialect) and is not very
well suited for authoritative holdings as you say above. GeoJSON is for
internet messages about geographic features, messages that aren't stopped
at international CRS borders, and that are relatively uncomplicated by
cartographic concepts or feature ontologies. It's a limited but important
role, and one where GIS technologies have not succeeded.

GeoJSON is a simple format, for sure, but that doesn't mean the systems on
either end of the message can't be as sophisticated or complex as they need
to be. Or that they can't use, say, GML when GeoJSON is inadequate.

-- 
Sean Gillies

---

From: Sean Gillies <[email-masked]>
Date: Sat, 16 Apr 2016 22:18:55 -0600

On Sat, Apr 16, 2016 at 5:52 PM, James Winterbottom <
[email-masked]> wrote:

>
> Thanks Alissa,
>
> My comment was more around the suggestion of trying to use the number of
> significant digits in the definition of the latitude and longitude as a
> direct expression on uncertainty. Think the RFC 3825 saga.
>

James, thanks for pointing this out. I've been thinking that something
along the lines of RFC 5870's

   Note: The number of digits of the values in <coordinates> MUST NOT be
>    interpreted as an indication to the level of uncertainty.

is the least that the GeoJSON draft should say about uncertainty.

-- 
Sean Gillies

---

From: James Winterbottom <[email-masked]>
Date: Sun, 17 Apr 2016 14:43:15 +1000

Thanks Sean… *8)

> On 17 Apr 2016, at 2:18 pm, Sean Gillies <[email-masked]> wrote:
> 
> On Sat, Apr 16, 2016 at 5:52 PM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thanks Alissa,
> 
> James, thanks for pointing this out. I've been thinking that something along the lines of RFC 5870's
>

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 18 Apr 2016 09:48:31 +0200

> On 16 Apr 2016, at 17:28, Tim Schaub <[email-masked]> wrote:
> 

While I understand where Carl is coming from - I think that in this specific case - things like how to deal with the Meridian and what not is actually normative.

Ultimately we do this to get interoperable implementations. And given how odd this space is (a coordinate system that loops; with places at the poles where one coordinate can be anything while the other is +/- 90) — such is needed.

> non-normative in favor of limiting the required reading to implement a

IMHO it is not enough to parse the numbers; you also need to know (and be warned) if it is lat,lon; and what exactly that means in order to get interoperable parsers.

When it comes to that coordinate issue; e.g. how many digits — then we are on sloppier ground. And one could imagine a best practice document/companion.

But two standard abiding, expecting to be interoperable, implementations should NOT express the BBX around Micronesia differently and mis-interpret the others.

Dw

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 18 Apr 2016 12:53:20 +0200

> On 15 Apr 2016, at 11:30, James Winterbottom <[email-masked]> wrote:
> 

Aye - sat first row on that discssion.

However - my comment was not so much intended for privacy — but more towards the use in (existing) geographic information systems in a system to system interoperable fashion; where a fair number of existing (govt/geo-observation systems) are primed to understand/take the limited (or not) number of digit  - and without ado - interpret it as information. 

I guess this is as in systems that run over long periods of time - errors in the coordinate systems and their relative annual shift (usually in the meters per decade) is taken for granted.

Dw.