Subject: [Geojson] Interpretation of undefined Z (elevation)

From: Sean Gillies <[email-masked]>
Date: Wed, 16 Dec 2015 16:43:55 -0700

Hi all,

In the issue tracker (https://github.com/geojson/draft-geojson/issues/87)
we have the beginning of consensus specifying the interpretation of
undefined elevations. In other words, how to interpret elevation when
GeoJSON coordinate position arrays have only 2 (lng and lat) elements.

https://tools.ietf.org/html/rfc5870#section-3.4.5 says

 A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude>
>  MAY assume that the URI refers to the respective location on Earth's
>  physical surface at the given latitude and longitude.
>

I propose to add an equivalent paragraph to the Positions section of the
GeoJSON draft in an edit linked from that issue. Any objections or
suggestions for improvement over that text?

-- 
Sean Gillies

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Dec 2015 15:22:15 +1100

That is fairly imprecise, but it was sensible then, it's probably
still a good idea (usable locations being preferred over unusable ones
and 2d being very common in practice).

What if someone specifies an explicit CRS?

On 17 December 2015 at 10:43, Sean Gillies <[email-masked]> wrote:
> Hi all,
>
> In the issue tracker (https://github.com/geojson/draft-geojson/issues/87) we
> have the beginning of consensus specifying the interpretation of undefined
> elevations. In other words, how to interpret elevation when GeoJSON
> coordinate position arrays have only 2 (lng and lat) elements.
>
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Tim Schaub <[email-masked]>
Date: Thu, 17 Dec 2015 04:28:34 +0000

Has this come up as a shortcoming of the current spec?

I'm not opposed to adding the proposed language. But I'm curious about the
motivation.

It is not clear to me what value we add to the spec by including additional
"consumers MAY use common sense" type language. The downside of this trend
is that the substance of the spec gets buried.

---

From: Sean Gillies <[email-masked]>
Date: Thu, 17 Dec 2015 10:55:53 -0700

> I'm not opposed to adding the proposed language. But I'm curious about the

GeoJSON isn't useful for fully 3D representations of surfaces, of course,
but it can be used to represent above-ground flight paths or subterranean
tunnels or waterways or tracks of a submarine. Paths where height above or
depth below a surface is important.

Say you have a GeoJSON document containing linear features with positive
elevation values and these represent tracks of airplanes. Say you have
another containing point and linear features with negative elevation values
that represent tracks of underwater objects. Using the elevation values you
can do some kinds of analysis and oblique visualizations not possible with
strictly 2D data.

Now say you have another GeoJSON file containing features with no
elevation. These might be boundaries or ship tracks. Analyzing or
visualizing these features together with the above and below-surface
features from the previous paragraph requires an interpretation of the
missing elevations.

Here are a few missing elevation interpretation strawmen:

- the position is at the center of the earth.
- the position is infinitely far from the center of the earth.
- the position is at a random distance from the center of the earth.
- the position is on the WGS 84 reference ellipsoid.

I hope we all agree that the first three are ridiculous and that the fourth
is not how most developers interpret missing elevations. I think that local
ground or sea level is our prevailing unwritten interpretation and that we
should write it down in the spec.

>
> It is not clear to me what value we add to the spec by including
> additional "consumers MAY use common sense" type language. The downside of
> this trend is that the substance of the spec gets buried.
>

Can you be more specific about what substance is being buried?

-- 
Sean Gillies

---

From: Sean Gillies <[email-masked]>
Date: Thu, 17 Dec 2015 11:07:54 -0700

> What if someone specifies an explicit CRS?

I will make it clear that this interpretation is only for GeoJSON's default
CRS. We can trust those who use a different CRS to do the right thing for
their applications.

-- 
Sean Gillies

---

From: Tim Schaub <[email-masked]>
Date: Thu, 17 Dec 2015 11:26:39 -0700

On Thu, Dec 17, 2015 at 10:55 AM, Sean Gillies <[email-masked]> wrote:
> Now say you have another GeoJSON file containing features with no elevation.
> These might be boundaries or ship tracks. Analyzing or visualizing these
> features together with the above and below-surface features from the
> previous paragraph requires an interpretation of the missing elevations.
>

The parts of the spec that any implementation MUST follow.