Subject: [Geojson] Making GeoJSON explicitly cartesian

From: Sean Gillies <[email-masked]>
Date: Thu, 18 Feb 2016 12:37:51 -0700

The original spec dodged the question of whether implementations should use
great circle interpolation between vertices of a line string or polygon
ring. Here's a PR that (correct me if I'm mistaken, Dw) would make it
explicit that interpolation should be cartesian:

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

Arguing against this is D3, the visualization library. It uses great-circle
interpolation between points when projecting GeoJSON shapes.

  https://github.com/mbostock/d3/wiki/Geo-Paths#shape-generators

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Feb 2016 08:04:25 +1100

GML is Cartesian, right?

On 19 February 2016 at 06:37, Sean Gillies <[email-masked]> wrote:
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 18 Feb 2016 22:13:50 +0100

> On 18 Feb 2016, at 20:37, Sean Gillies <[email-masked]> wrote:
> 
> The original spec dodged the question of whether implementations should use great circle interpolation between vertices of a line string or polygon ring. Here's a PR that (correct me if I'm mistaken, Dw) would make it explicit that interpolation should be cartesian:
> 
>   https://github.com/geojson/draft-geojson/pull/154 <https://github.com/geojson/draft-geojson/pull/154>
> 
> Arguing against this is D3, the visualization library. It uses great-circle interpolation between points when projecting GeoJSON shapes.
> 
>   https://github.com/mbostock/d3/wiki/Geo-Paths#shape-generators <https://github.com/mbostock/d3/wiki/Geo-Paths#shape-generators>

Note that *IF* you go down this route - there are two bits you need then to also define:

1)	How is your BBX defined ? Are these stil rectangles in lat/lon - or also great circles ?

	If the latter - then one needs to rewrite a lot around the date line/poles.

2)	What are they great circles in ? On the 'actual' earth ? The datum (o WGS84),
	the geoid defined by WGS84; or merely (as usual, and I think this is also
	what the above mentioned D3 does) on the perfect *sphere* that goes through
	both points at those coordinates ?

So given that great circles and similar mostly come into play once one is into more sophisticated geoids; and given that, if you can get away with WGS84, one is willing to compromise on that anyway and in a fairly normal mercator world --  I would imagine that straight lines should be carthesian

GML is quite careful in this area.

Dw.

---

From: Carl Reed <[email-masked]>
Date: Fri, 19 Feb 2016 09:53:58 -0700

WRT GML, I would ask a GML expert if there are any such questions.
Personally, Martin, I do not know the answer. That said, GML is now used
extensively in the aviation industry for a variety of uses and domain
encodings (FIXM, WXXM, AIXM) which include requirements for non-cartesian
reference systems. Clemens Portele or Ron Lake could answer specific GML
questions.

Regards

Carl

On Thu, Feb 18, 2016 at 2:13 PM, Dirk-Willem van Gulik <[email-masked]
> wrote:

> The original spec dodged the question of whether implementations should
> use great circle interpolation between vertices of a line string or polygon
> Arguing against this is D3, the visualization library. It uses
> great-circle interpolation between points when projecting GeoJSON shapes.
>
> So given that great circles and similar mostly come into play once one is
> into more sophisticated geoids; and given that, if you can get away with
> WGS84, one is willing to compromise on that anyway and in a fairly normal
> mercator world --  I would imagine that straight lines should be carthesian
>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Calvin Metcalf <[email-masked]>
Date: Fri, 19 Feb 2016 17:08:53 +0000

couldn't it be argued that this is a representational issue that is beyond
the scope of GeoJSON?

On Fri, Feb 19, 2016 at 11:54 AM Carl Reed <[email-masked]> wrote:

> On Thu, Feb 18, 2016 at 2:13 PM, Dirk-Willem van Gulik <
> [email-masked]> wrote:
>
>>

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 19 Feb 2016 18:29:37 +0100

On 19 Feb 2016, at 18:08, Calvin Metcalf <[email-masked]> wrote:

> couldn't it be argued that this is a representational issue that is beyond the scope of GeoJSON?

I guess the core idea of standardising something is to make things interoperable. 

It would be more than a little surprising to not able to 'convey' which of the two lines in below image (http://www.slaw.ca/2013/07/09/the-great-circle-route/) one means. I.e. I send you a JSON - but I do not make clear if I mean the red line or the yellow line.   And this gets worse if we consider these lines to be one of the 4 of a bounding box.

So I would say this is much more than just a representational issue ;)

Dw.

> 
> On Fri, Feb 19, 2016 at 11:54 AM Carl Reed <[email-masked] <mailto:[email-masked]>> wrote:
> WRT GML, I would ask a GML expert if there are any such questions. Personally, Martin, I do not know the answer. That said, GML is now used extensively in the aviation industry for a variety of uses and domain encodings (FIXM, WXXM, AIXM) which include requirements for non-cartesian reference systems. Clemens Portele or Ron Lake could answer specific GML questions.
> 
> Regards
> 
> Carl
> 
> 
> On Thu, Feb 18, 2016 at 2:13 PM, Dirk-Willem van Gulik <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 18 Feb 2016, at 20:37, Sean Gillies <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/geojson <https://www.ietf.org/mailman/listinfo/geojson>
> 
> 
> 
> 
> -- 
> Carl Reed, PhD
> Carl Reed and Associates
> 
> Mobile: 970-402-0284
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/geojson <https://www.ietf.org/mailman/listinfo/geojson>

---

From: Calvin Metcalf <[email-masked]>
Date: Fri, 19 Feb 2016 17:54:46 +0000

If we mandate great circles we add a burden on certain consumers who don't
care, if we mandate Cartesian we become unusable for certain applications,
pleasing nobody.

On Fri, Feb 19, 2016 at 12:31 PM Dirk-Willem van Gulik <[email-masked]>
wrote:

> It would be more than a little surprising to not able to 'convey' which of
> the two lines in below image (
> http://www.slaw.ca/2013/07/09/the-great-circle-route/) one means. I.e. I
> send you a JSON - but I do not make clear if I mean the red line or the
> yellow line.   And this gets worse if we consider these lines to be one of
> the 4 of a bounding box.
>
>>> So given that great circles and similar mostly come into play once one
>>> is into more sophisticated geoids; and given that, if you can get away with

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 19 Feb 2016 19:07:51 +0100

On 19 Feb 2016, at 18:54, Calvin Metcalf <[email-masked]> wrote:

> If we mandate great circles we add a burden on certain consumers who don't care, if we mandate Cartesian we become unusable for certain applications, pleasing nobody.

First point agreed.  It is a burden; and I'd argue that the very point of geo-json is that this is the burden it is designed to avoid.

The latter point - I guess that the simplicity of GeoJSON and its default GS84 already makes it unsuitable for a very fair number of those applications; and that that group is better served by, for example, systems such as GML.

Dw.

> 
> On Fri, Feb 19, 2016 at 12:31 PM Dirk-Willem van Gulik <[email-masked] <mailto:[email-masked]>> wrote:
> On 19 Feb 2016, at 18:08, Calvin Metcalf <[email-masked] <mailto:[email-masked]>> wrote:
> It would be more than a little surprising to not able to 'convey' which of the two lines in below image (http://www.slaw.ca/2013/07/09/the-great-circle-route/ <http://www.slaw.ca/2013/07/09/the-great-circle-route/>) one means. I.e. I send you a JSON - but I do not make clear if I mean the red line or the yellow line.   And this gets worse if we consider these lines to be one of the 4 of a bounding box.
>

---

From: Calvin Metcalf <[email-masked]>
Date: Fri, 19 Feb 2016 18:31:39 +0000

making a visualization of flight paths based on lines created from starting
and ending airports shouldn't technically break the spec if it's accurate

On Fri, Feb 19, 2016 at 1:10 PM Dirk-Willem van Gulik <[email-masked]>
wrote:

> First point agreed.  It is a burden; and I'd argue that the very point of
> geo-json is that this is the burden it is designed to avoid.
>
> The latter point - I guess that the simplicity of GeoJSON and its default
> GS84 already makes it unsuitable for a very fair number of those
> applications; and that that group is better served by, for example, systems
> such as GML.
>
> Dw.
>
>
> On Fri, Feb 19, 2016 at 12:31 PM Dirk-Willem van Gulik <
>> It would be more than a little surprising to not able to 'convey' which
>> of the two lines in below image (

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 19 Feb 2016 19:57:14 +0100

On 19 Feb 2016, at 19:31, Calvin Metcalf <[email-masked]> wrote:
> 
> making a visualization of flight paths based on lines created from starting and ending airports shouldn't technically break the spec if it's accurate

Well - I think it is an either or

1)	You keep geo-json simple; and WGS84 as the default; with a simple Cartesian story.

	And such a flight path would become a few 100 short straight line segment forming in effect a greatcircle.

2)	You do allow geo-json to become a bit geo aware; i.e. earth-is-round-aware; and introduce coordinate systems properly.

	it still may be much simpler than GML - but still. And then force all render engine to understand a fair chunk of this.

But it is a bit odd to have a simple geo-json like:
{ "type": "Feature",
        "geometry": {
          "type": "LineString",
          "coordinates": [[-87, 41], [140, 35]]
          },
        },

and have one person draw the red-line; and the other system show it to the user as the yellow line.

And the spec not saying which is the preferred, interoperable way.

Dw.

> On Fri, Feb 19, 2016 at 1:10 PM Dirk-Willem van Gulik <[email-masked] <mailto:[email-masked]>> wrote:
> On 19 Feb 2016, at 18:54, Calvin Metcalf <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Martin Daly <[email-masked]>
Date: Fri, 19 Feb 2016 20:19:47 +0000

For me, it has to be 1): facet the LineString if you want to guarantee that it represents a great circle. That's the same as facetting the LineString if you want to represent a circle in a projected CRS (not that *they* are encouraged, obvs).

There are multiple reasons that Microsoft SQL Server and PostGIS have completely separate types (GEOMETRY and GEOGRAPHY), and completely separate implementations for the two cases. Do we want to include rules about which hemisphere is covered by a Polygon whose outer ring is the equator, for example? I doubt it.

I have no qualms about emphasising simplicity over ubiquity.

I don't mind whether or not the spec stays silent on the matter. I was going to point out that it never did Esri Shapefile any harm to stay silent, then I looked it up and saw that it defines "vector" as "A Cartesian (i.e., x,y) coordinate-based data structure commonly used to represent
geographic features." I've clearly never read that far before...

Martin

From: GeoJSON [mailto:[email-masked]] On Behalf Of Dirk-Willem van Gulik
Sent: 19 February 2016 18:57
To: Calvin Metcalf <[email-masked]>
Cc: Sean Gillies <[email-masked]>; Carl Reed <[email-masked]>; [email-masked]
Subject: Re: [Geojson] Making GeoJSON explicitly cartesian

On 19 Feb 2016, at 19:31, Calvin Metcalf <[email-masked]<mailto:[email-masked]>> wrote:

{ "type": "Feature",

        "geometry": {

          "type": "LineString",

          },

        },

Dw.

On Fri, Feb 19, 2016 at 1:10 PM Dirk-Willem van Gulik <[email-masked]<mailto:[email-masked]>> wrote:
On 19 Feb 2016, at 18:54, Calvin Metcalf <[email-masked]<mailto:[email-masked]>> wrote:
If we mandate great circles we add a burden on certain consumers who don't care, if we mandate Cartesian we become unusable for certain applications, pleasing nobody.

Dw.

On Fri, Feb 19, 2016 at 12:31 PM Dirk-Willem van Gulik <[email-masked]<mailto:[email-masked]>> wrote:
On 19 Feb 2016, at 18:08, Calvin Metcalf <[email-masked]<mailto:[email-masked]>> wrote:
couldn't it be argued that this is a representational issue that is beyond the scope of GeoJSON?

Dw.

On Fri, Feb 19, 2016 at 11:54 AM Carl Reed <[email-masked]<mailto:[email-masked]>> wrote:
WRT GML, I would ask a GML expert if there are any such questions. Personally, Martin, I do not know the answer. That said, GML is now used extensively in the aviation industry for a variety of uses and domain encodings (FIXM, WXXM, AIXM) which include requirements for non-cartesian reference systems. Clemens Portele or Ron Lake could answer specific GML questions.

Regards

Carl

On Thu, Feb 18, 2016 at 2:13 PM, Dirk-Willem van Gulik <[email-masked]<mailto:[email-masked]>> wrote:

On 18 Feb 2016, at 20:37, Sean Gillies <[email-masked]<mailto:[email-masked]>> wrote:

Dw.

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

--
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284
_______________________________________________
GeoJSON mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geojson

---

From: Sean Gillies <[email-masked]>
Date: Sun, 21 Feb 2016 13:05:52 -0700

Hi all,

I see consensus for plate carrée straight lines. Dw, I'll address the merge
conflicts in https://github.com/geojson/draft-geojson/issues/154 and we'll
follow up there.

On Fri, Feb 19, 2016 at 1:19 PM, Martin Daly <[email-masked]>
wrote:

> For me, it has to be 1): facet the LineString if you want to guarantee
> that it represents a great circle. That’s the same as facetting the
> LineString if you want to represent a circle in a projected CRS (not that *
> *they** are encouraged, obvs).
>
>
>
> There are multiple reasons that Microsoft SQL Server and PostGIS have
> completely separate types (GEOMETRY and GEOGRAPHY), and completely separate
> implementations for the two cases. Do we want to include rules about which
> hemisphere is covered by a Polygon whose outer ring is the equator, for
> example? I doubt it.
>
>
>
> I don’t mind whether or not the spec stays silent on the matter. I was
> going to point out that it never did Esri Shapefile any harm to stay
> silent, then I looked it up and saw that it defines “vector” as “A
> Cartesian (i.e., x,y) coordinate-based data structure commonly used to
> represent
>
> geographic features.” I’ve clearly never read that far before…
>
>
>
> Martin
>
>
>
>
>
> *From:* GeoJSON [mailto:[email-masked]] *On Behalf Of *Dirk-Willem
> van Gulik
> *Sent:* 19 February 2016 18:57
> *To:* Calvin Metcalf <[email-masked]>
> *Cc:* Sean Gillies <[email-masked]>; Carl Reed <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Geojson] Making GeoJSON explicitly cartesian
>
>
>
> making a visualization of flight paths based on lines created from
> starting and ending airports shouldn't technically break the spec if it's
> accurate
>
>
>
>
>
>           And such a flight path would become a few 100 short straight
> line segment forming in effect a greatcircle.
>
>
>
> 2)       You do allow geo-json to become a bit geo aware; i.e.
> earth-is-round-aware; and introduce coordinate systems properly.
>
>
>
>           it still may be much simpler than GML - but still. And then
> force all render engine to understand a fair chunk of this.
>
>
>
> But it is a bit *odd* to have a simple geo-json like:
>
> { "type"*:* "Feature",
>
>         "geometry"*:* {
>
>           "type"*:* "LineString",
>
>           "coordinates"*:* [[-87, 41], [140, 35]]
>
>           },
>
>         },
>
>
>
> On Fri, Feb 19, 2016 at 1:10 PM Dirk-Willem van Gulik <
-- 
Sean Gillies

---

From: Sean Gillies <[email-masked]>
Date: Tue, 23 Feb 2016 10:21:37 -0700

Are there any objections to the draft change in
https://github.com/geojson/draft-geojson/pull/157?

On Sun, Feb 21, 2016 at 1:05 PM, Sean Gillies <[email-masked]>
wrote:

>
> Hi all,
>
> I see consensus for plate carrée straight lines. Dw, I'll address the
> merge conflicts in https://github.com/geojson/draft-geojson/issues/154
> and we'll follow up there.
>

-- 
Sean Gillies