[Esip-documentation] geospatial_bounds: how to show 3-D bbox?
John Graybeal
jbgraybeal at mindspring.com
Tue Jan 24 01:06:53 EST 2017
The request for a 3D bounding box WKT example was made while we were working on ACDD 1.3. I looked hard for any representation of 3D in WKT land and the answer I came up with was that it didn’t exist. So our experience was the same, and after some effort I concluded I (for one) was not going to successfully solve that need.
It is a bit redundant to have both _min/_max and/or geospatial_bounds. There was a lengthy discussion, several actually, of whether to have one and/or the other. The inclusion of both reflected several desires of the contributors: compatibility with existing uses, files, and specifications; and the need for a more expressive and less ambiguous (read: less ambiguously defined) bounding system. It makes a bit of extra work for those who wish to be thorough, but not oppressively so, at least so we hoped.
I have a vague recollection that the lat/lon order was odd for a reason, but as the memory is vague and the work was a long time ago, I’ll leave it to others to either justify the oddity or accept your correction.
John
> On Jan 23, 2017, at 6:32 PM, John Maurer via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
>
> Hi ACDD folks,
> Can somebody please provide an example of the Well-Known Text (WKT) that could be used to represent a 3-D bounding box for the ACDD "geospatial_bounds" attribute? Let's say I have the following bounds defined for a global digital elevation model (DEM):
>
> geospatial_lat_min: -90
> geospatial_lat_max: 90
> geospatial_lon_min: -180
> geospatial_lon_max: 180
> geospatial_vertical_min: 0
> geospatial_vertical_max: 1000
>
> Would this cube be expressed in WKT as a "POLYHEDRALSURFACE Z( )", a "POLYGON Z( )", or does WKT recognize "ENVELOPE Z( )"? Either way, can an example please be provided? Google has not been very helpful beyond the simpler POINT and POLYGON representations.
>
> It seems outlandish to provide a POLYHEDRALSURFACE, which ends up as verbose as the following example. This is for a cube with origin at (0, 0, 0) and opposite corner at (1, 1, 1):
>
> POLYHEDRALSURFACE Z (
> ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
> ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
> ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
> ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
> ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
> ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1))
> )
>
> Thoughts?
> Thanks!,
> John Maurer
> Pacific Islands Ocean Observing System (PacIOOS)
> University of Hawaii at Manoa
>
> P.S. It seems a tad redundant to have both the *_min/*_max attributes and the geospatial_bounds.
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
John Graybeal
jbgraybeal at mindspring.com
More information about the Esip-documentation
mailing list