[Esip-documentation] geospatial_bounds: how to show 3-D bbox?

John Maurer jmaurer at hawaii.edu
Mon Jan 23 22:10:12 EST 2017


P.S. Your POLYGON example for geospatial_bounds on the following page has
latitudes and longitudes in the wrong order. Instead of listing coordinate
pairs in lat, lon (y, x) order they should be lon, lat (x, y).

http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3

Example: 'POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26
> -110.29, 40.26 -111.29))'.
>

Should be:

Example: 'POLYGON ((-111.29 40.26, -111.29 41.26, -110.29 41.26, -110.29
> 40.26, -111.29 40.26))'.
>

Thanks,
John

On Mon, Jan 23, 2017 at 4:32 PM, John Maurer <jmaurer at hawaii.edu> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170123/e9dc3868/attachment-0001.html>


More information about the Esip-documentation mailing list