How to describe a terrain following bbox

@dirkx points out in #154 that "flat" surfaces like lakes and plains aren't flat relative to the WGS84 reference ellipsoid, making it difficult to specify a 3D bbox bounded by the local terrain or water surface. For positions, we have a convention for local terrain height.

In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

How about something like this for a bbox that extends from the local ground to 100 meters above?

"bbox": [%minlon%, %minlat%, null, %maxlon%, %maxlat%, 100.0]

And this for a bbox that extends from 100 meters below to the local ground or sea level?

"bbox": [%minlon%, %minlat%, -100.0, %maxlon%, %maxlat%, null]

This interpretation would depend on either of the min/max elevation being null.

On 21 Feb 2016, at 21:41, Sean Gillies notifications@github.com wrote:

@dirkx points out in #154 that "flat" surfaces like lakes and plains aren't flat relative to the WGS84 reference ellipsoid, making it difficult to specify a 3D bbox bounded by the local terrain or water surface. For positions, we have a convention for local terrain height.

In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

How about something like this for a bbox that extends from the local ground to 100 meters above?

"bbox": [%minlon%, %minlat%, null, %maxlon%, %maxlat%, 100.0]

And this for a bbox that extends from 100 meters below to the local ground or sea level?

"bbox": [%minlon%, %minlat%, -100.0, %maxlon%, %maxlat%, null]

This interpretation would depend on either of the min/max elevation being null.

Not sure - but I would expect this solution to cause more issues than it solves.

Firstly - local terrain level or water surface level is often either ill defined -or- has some well defined coordinate reference system. In the latter case you should really use that (and announce in your geo-json). In the first case - it is hard to be interoperable with someone else.

Secondly - in cases where you have this issue; you need to work out what the vertical is — is it perpendicular to your reference surface ?

Or is it perpendicular to a water surface — i.e. is it much like a plum line ? The reason that matters is that, depending on which you pick, either your coordinate point (lat,lon) changes as you go up or down; or you ‘mean’ a different physical point on earth as you go up and down). And for things like plains (rather than the sea) - relative to what height you do this also matters - as for a plateau at 3000 feet - the ‘difference’ between the two at sea level can be really rather large.

Apologies for trying to not use the proper technical terms and math - but using an inexact narrative to illustrate what i think the problem is.

Suppose you have a body of water (say the Titicaca lake at 10k feet, in Peru on a windless day); on which a reed-raft is floating, at position A:

(http://picpaste.com/CARXpo6l.png)

Then you could describe the position of this boat as the lat/lon of point ‘B’ plus a certain ‘Z’ up. So the boat is at (lat,lon,Z).

If one where to use the local terrain, as you use in your BBX example - you’d have a puzzle as how to describe this.

We have a certain height relative to the local terrain - i.e. Z’; so the coordinate would perhaps end up being the lat and lon of C; and a height Z’.

If that sounds a bit silly - then consider the example of the Peruvians building a rather high wind turbine on that lake/plain (or, if you prefer, a nice AUV at 300 feet above the surface doing measurements for water/flooding purposes):

(http://picpaste.com/ECeXvZMk.png)

In that case you’d have your definition of height; Z’ relative to a point D (on the surface) — whose coordinates you would express as ‘E’ + Z'' (rather than C + Z’’’) to which ‘Z’ is added.

Note that this ‘side’ view is simple, in reality the line between B-E will be at a more complex 3d angle. And note that none of these offsets are trivial in this example; we are talking the sort of (many) meter(s) that matter to flood planning, AUV stitching of photos, planning permission, property boundaries and what not.

So I would avoid going down this path and state that the height is AS DEFINED by the reference coordinate system; and if nothing is explicitly stated about this - it is WGS 84; and hence perpendicular WGS84.

And live with the fact that you either have the ease of WGS84 and everything perpendicular in simple mercator style (and live with the fact that flat surfaces suck; and the poles are hard) —or— you advertise a specific optimised coordinate reference system and hence accept that not everyone will quite get your JSON -or- you need to use something like GML. Happy to go through he spec and highlight the places where we need to be clear about this.

Alternatively - one could stipulate the usual list of datums as a ‘should’ in the specification. Virtually all implementors will need some of that anyway.

@dirkx thanks for the discussion. 3D geographic bounding "boxes" are problematic, that's for sure. I've never actually seen one in wild GeoJSON, which is telling me something.

I'm going to close this issue and propose no changes to the draft.

I forwarded the bbox issue to the OGC CRS Working Group. The following are some of the responses, which I am providing as background/educational material that this group may use - or not - to resolve issue 156. Both responses are from geodesy professionals.

Regards

Carl

From New Zealand:

MSL can also vary quite significantly over short distances too. For example NZ's long N-S extent results in very significant tidal flows at the N&S extremities of its main islands with the result that MSL can differ by a couple of meters where E and W coasts meet when compared to the datum for contours on land.

From EPSG Community

The lack of parallelism of a gravity-related reference surface (a vertical CRS) to that of an ellipsoid modelling the earth is a valid issue, but not that of greatest concern. The angle subtended between the verticals to these two surfaces is small so the height or depth difference along the vertical is small and unlikely to be significant. Of far greater concern is the absolute offset between the two surfaces. The ellipsoidal surface may be offset from mean sea level by +/- 100m. And then a vertical CRS's datum may not necessarily be at mean sea level: e.g. that for Belgium is mean low water, about 2.7m, below MSL. The vertical datum for marine charts is usually Lowest Astronomic Tide [this convention not followed in US and some other countries]. Lakes (like Titicaca) may have their own datum: the Caspian Sea datum is about 28m below oceanic MSL (and this is different from the Caspian sea surface which is about 1-2 metres above Caspian datum, varying on hydrological flows into and evaporation from the basin).

If you want to describe the bounds of an envelope through its min/max coordinates then you first need to identify the CRS. Without that any coordinate values are at best ambiguous and at worst meaningless and certainly not interoperable. The coordinates need to be ordered consistently with the axis order defined in the referenced CRS description. If you want a 3D envelope then you need a 3D CRS (either true or compound 2D+1D). Your choice is to require citation of a user-identified CRS or to mandate a specific CRS. Engineers sometimes get upset with the notion that water can flow uphill under the influence of gravity, which can happen using ellipsoidal heights. Mandating WGS 84 for horizontal purposes might be ok (or might not - that is a separate discussion) but for 3D a compound system of WGS 84 for horizontal and EGM2008 height for vertical might be better. If you do choose to mandate WGS 84 3D then because small differences in height have greater significance than the same difference does in a horizontal context, you really should identify to which of the six varieties of WGS 84 you are referring (they differ in height by up to

1.5m).

The attached shows a cross-section between the Black Sea and the Caspian Sea showing various vertical reference surfaces used locally in Georgia and Azerbaijan.

[image: Inline image]

On Mon, Feb 22, 2016 at 4:44 AM, Dirk-Willem van Gulik <dirkx@webweaving.org

wrote:

On 21 Feb 2016, at 21:41, Sean Gillies notifications@github.com wrote:

@dirkx points out in #154 that "flat" surfaces like lakes and plains aren't flat relative to the WGS84 reference ellipsoid, making it difficult to specify a 3D bbox bounded by the local terrain or water surface. For positions, we have a convention for local terrain height.

In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

How about something like this for a bbox that extends from the local ground to 100 meters above?

"bbox": [%minlon%, %minlat%, null, %maxlon%, %maxlat%, 100.0]

And this for a bbox that extends from 100 meters below to the local ground or sea level?

"bbox": [%minlon%, %minlat%, -100.0, %maxlon%, %maxlat%, null]

This interpretation would depend on either of the min/max elevation being null.

Not sure - but I would expect this solution to cause more issues than it solves.

Firstly - local terrain level or water surface level is often either ill defined -or- has some well defined coordinate reference system. In the latter case you should really use that (and announce in your geo-json). In the first case - it is hard to be interoperable with someone else.

Secondly - in cases where you have this issue; you need to work out what the vertical is — is it perpendicular to your reference surface ?

Or is it perpendicular to a water surface — i.e. is it much like a plum line ? The reason that matters is that, depending on which you pick, either your coordinate point (lat,lon) changes as you go up or down; or you ‘mean’ a different physical point on earth as you go up and down). And for things like plains (rather than the sea) - relative to what height you do this also matters - as for a plateau at 3000 feet - the ‘difference’ between the two at sea level can be really rather large.

Apologies for trying to not use the proper technical terms and math - but using an inexact narrative to illustrate what i think the problem is.

Suppose you have a body of water (say the Titicaca lake at 10k feet, in Peru on a windless day); on which a reed-raft is floating, at position A: (http://picpaste.com/CARXpo6l.png)

Then you could describe the position of this boat as the lat/lon of point ‘B’ plus a certain ‘Z’ up. So the boat is at (lat,lon,Z).

If one where to use the local terrain, as you use in your BBX example - you’d have a puzzle as how to describe this.

We have a certain height relative to the local terrain - i.e. Z’; so the coordinate would perhaps end up being the lat and lon of C; and a height Z’.

If that sounds a bit silly - then consider the example of the Peruvians building a rather high wind turbine on that lake/plain (or, if you prefer, a nice AUV at 300 feet above the surface doing measurements for water/flooding purposes): (http://picpaste.com/ECeXvZMk.png)

In that case you’d have your definition of height; Z’ relative to a point D (on the surface) — whose coordinates you would express as ‘E’ + Z'' (rather than C + Z’’’) to which ‘Z’ is added.

Note that this ‘side’ view is simple, in reality the line between B-E will be at a more complex 3d angle. And note that none of these offsets are trivial in this example; we are talking the sort of (many) meter(s) that matter to flood planning, AUV stitching of photos, planning permission, property boundaries and what not.

So I would avoid going down this path and state that the height is AS DEFINED by the reference coordinate system; and if nothing is explicitly stated about this - it is WGS 84; and hence perpendicular WGS84.

And live with the fact that you either have the ease of WGS84 and everything perpendicular in simple mercator style (and live with the fact that flat surfaces suck; and the poles are hard) —or— you advertise a specific optimised coordinate reference system and hence accept that not everyone will quite get your JSON -or- you need to use something like GML. Happy to go through he spec and highlight the places where we need to be clear about this.

Alternatively - one could stipulate the usual list of datums as a ‘should’ in the specification. Virtually all implementors will need some of that anyway.

Dw

GeoJSON mailing list GeoJSON@ietf.org https://www.ietf.org/mailman/listinfo/geojson

Carl Reed, PhD Carl Reed and Associates

Mobile: 970-402-0284

Carl,

Thanks for passing that on. Lot of extra information. Two things which perhaps we somehow need to convey in the draft

-> The answers from the professionals all focus on the CRS — and that iwth that; things like parallelism and so on is not much of a concern.

While at the same time our geo-json draft, for all the right reasons*, does not have much of a CRS; a simple, global, WGS84 for the whole world.

-> They also show that even with the CSRs - the vertical heights are an issue.

So somehow we need to convey in our draft that, if we take the image from Calr, that the DOTTED line is the ‘straight’, and conceptually ‘water flat’ line in the world of geo-json.

Dw.

*: (I am acknowledging here that we are somewhat lacking the use cases; and are implicitly calling out issues where the ‘simple’ use case is stretched).

On 23 Feb 2016, at 23:10, Carl Reed carl.n.reed@gmail.com wrote:

I forwarded the bbox issue to the OGC CRS Working Group. The following are some of the responses, which I am providing as background/educational material that this group may use - or not - to resolve issue 156. Both responses are from geodesy professionals.

Regards

Carl

From New Zealand:

MSL can also vary quite significantly over short distances too. For example NZ's long N-S extent results in very significant tidal flows at the N&S extremities of its main islands with the result that MSL can differ by a couple of meters where E and W coasts meet when compared to the datum for contours on land.

From EPSG Community

The lack of parallelism of a gravity-related reference surface (a vertical CRS) to that of an ellipsoid modelling the earth is a valid issue, but not that of greatest concern. The angle subtended between the verticals to these two surfaces is small so the height or depth difference along the vertical is small and unlikely to be significant. Of far greater concern is the absolute offset between the two surfaces. The ellipsoidal surface may be offset from mean sea level by +/- 100m. And then a vertical CRS's datum may not necessarily be at mean sea level: e.g. that for Belgium is mean low water, about 2.7m, below MSL. The vertical datum for marine charts is usually Lowest Astronomic Tide [this convention not followed in US and some other countries]. Lakes (like Titicaca) may have their own datum: the Caspian Sea datum is about 28m below oceanic MSL (and this is different from the Caspian sea surface which is about 1-2 metres above Caspian datum, varying on hydrological flows into and evaporation from the basin).

If you want to describe the bounds of an envelope through its min/max coordinates then you first need to identify the CRS. Without that any coordinate values are at best ambiguous and at worst meaningless and certainly not interoperable. The coordinates need to be ordered consistently with the axis order defined in the referenced CRS description. If you want a 3D envelope then you need a 3D CRS (either true or compound 2D+1D). Your choice is to require citation of a user-identified CRS or to mandate a specific CRS. Engineers sometimes get upset with the notion that water can flow uphill under the influence of gravity, which can happen using ellipsoidal heights. Mandating WGS 84 for horizontal purposes might be ok (or might not - that is a separate discussion) but for 3D a compound system of WGS 84 for horizontal and EGM2008 height for vertical might be better. If you do choose to mandate WGS 84 3D then because small differences in height have greater significance than the same difference does in a horizontal context, you really should identify to which of the six varieties of WGS 84 you are referring (they differ in height by up to >1.5m).

The attached shows a cross-section between the Black Sea and the Caspian Sea showing various vertical reference surfaces used locally in Georgia and Azerbaijan.
On Mon, Feb 22, 2016 at 4:44 AM, Dirk-Willem van Gulik > wrote: On 21 Feb 2016, at 21:41, Sean Gillies > wrote: > @dirkx points out in #154 that "flat" surfaces like lakes and plains aren't flat relative to the WGS84 reference ellipsoid, making it difficult to specify a 3D bbox bounded by the local terrain or water surface. For positions, we have a convention for local terrain height. > > In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level. > > How about something like this for a bbox that extends from the local ground to 100 meters above? > > "bbox": [%minlon%, %minlat%, null, %maxlon%, %maxlat%, 100.0] > > And this for a bbox that extends from 100 meters below to the local ground or sea level? > > "bbox": [%minlon%, %minlat%, -100.0, %maxlon%, %maxlat%, null] > > This interpretation would depend on either of the min/max elevation being null. Not sure - but I would expect this solution to cause more issues than it solves. Firstly - local terrain level or water surface level is often either ill defined -or- has some well defined coordinate reference system. In the latter case you should really use that (and announce in your geo-json). In the first case - it is hard to be interoperable with someone else. Secondly - in cases where you have this issue; you need to work out what the vertical is — is it perpendicular to your reference surface ? Or is it perpendicular to a water surface — i.e. is it much like a plum line ? The reason that matters is that, depending on which you pick, either your coordinate point (lat,lon) changes as you go up or down; or you ‘mean’ a different physical point on earth as you go up and down). And for things like plains (rather than the sea) - relative to what height you do this also matters - as for a plateau at 3000 feet - the ‘difference’ between the two at sea level can be really rather large. Apologies for trying to not use the proper technical terms and math - but using an inexact narrative to illustrate what i think the problem is. Suppose you have a body of water (say the Titicaca lake at 10k feet, in Peru on a windless day); on which a reed-raft is floating, at position A: (http://picpaste.com/CARXpo6l.png http://picpaste.com/CARXpo6l.png) Then you could describe the position of this boat as the lat/lon of point ‘B’ plus a certain ‘Z’ up. So the boat is at (lat,lon,Z). If one where to use the local terrain, as you use in your BBX example - you’d have a puzzle as how to describe this. We have a certain height relative to the local terrain - i.e. Z’; so the coordinate would perhaps end up being the lat and lon of C; and a height Z’. If that sounds a bit silly - then consider the example of the Peruvians building a rather high wind turbine on that lake/plain (or, if you prefer, a nice AUV at 300 feet above the surface doing measurements for water/flooding purposes): (http://picpaste.com/ECeXvZMk.png http://picpaste.com/ECeXvZMk.png) In that case you’d have your definition of height; Z’ relative to a point D (on the surface) — whose coordinates you would express as ‘E’ + Z'' (rather than C + Z’’’) to which ‘Z’ is added. Note that this ‘side’ view is simple, in reality the line between B-E will be at a more complex 3d angle. And note that none of these offsets are trivial in this example; we are talking the sort of (many) meter(s) that matter to flood planning, AUV stitching of photos, planning permission, property boundaries and what not. So I would avoid going down this path and state that the height is _AS DEFINED_ by the reference coordinate system; and if nothing is explicitly stated about this - it is WGS 84; and hence perpendicular WGS84. And live with the fact that you either have the ease of WGS84 and everything perpendicular in simple mercator style (and live with the fact that flat surfaces suck; and the poles are hard) —or— you advertise a specific optimised coordinate reference system and hence accept that not everyone will quite get your JSON -or- you need to use something like GML. Happy to go through he spec and highlight the places where we need to be clear about this. Alternatively - one could stipulate the usual list of datums as a ‘should’ in the specification. Virtually all implementors will need some of that anyway. Dw --- GeoJSON mailing list GeoJSON@ietf.org mailto:GeoJSON@ietf.org 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

geojson / draft-geojson

How to describe a terrain following bbox #156