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

Tue Jan 24 13:47:46 EST 2017

Actually, I believe there is more to this topic. The spec says the order
should follow the CRS given*. For EPSG:4326
<http://spatialreference.org/ref/epsg/wgs-84/>, the order is lon lat. For
CRS:84, the order is lat lon. Yes, confusing, but stuck that way for legacy
reasons. So, I believe it depends on geospatial_bounds_crs. In my case (and
in many cases, I'm guessing, including the ACDD default), I'm setting
geospatial_bounds_crs to ESPG:4326, so I believe I (and your wiki example)
should use lon lat order in geospatial_bounds. This also trips up people a
lot in WMS 1.3.0 requests, where lon lat order switches between EPSG:4326
and CRS:84 (one example
<https://viswaug.wordpress.com/2009/03/15/reversed-co-ordinate-axis-order-for-epsg4326-vs-crs84-when-requesting-wms-130-images/>).
Thoughts?
Cheers,
John

* http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#41

> If <axis order> is omitted from the WKT string the sequence of <axis>
> descriptions shall imply the order of the axes and of coordinates
> referenced to the CRS.
>

On Tue, Jan 24, 2017 at 8:10 AM, Anna Milan - NOAA Federal via
Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> So - I should NOT change the order in the wiki example?
>
> Anna
> *~~~~~~Metadata Adds Meaning~~~~~~*
> Anna.Milan at noaa.gov, 303-497-5099 <(303)%20497-5099>
> NOAA National Centers for Environmental Information
> (formerly NOAA’s National Geophysical Data Center)
> http://www.ngdc.noaa.gov/metadata/emma
> *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
>
> On Tue, Jan 24, 2017 at 7:50 AM, Jim Biard via Esip-documentation <
> esip-documentation at lists.esipfed.org> wrote:
>
>> Sadly (to me, at any rate), the official EPSG/OGC/WKT definition for
>> latitude longitude order is lat before lon. It's left-handed and drives me
>> insane every time, but apparently the historical definition from way back
>> is lat before lon. It makes regular headaches for people that need to
>> accomodate both projected and geodetic coordinates, but it is what it is.
>>
>> Here's a discussion - http://lists.osgeo.org/piperma
>> il/postgis-users/2015-November/040971.html
>>
>> Grace and peace,
>>
>> Jim
>>
>> On 1/23/17 10:10 PM, John Maurer via Esip-documentation wrote:
>>
>> 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_D
>> ata_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.
>>>
>>>
>>
>>
>> _______________________________________________
>> Esip-documentation mailing listEsip-documentation at lists.esipfed.orghttp://lists.deltaforce.net/mailman/listinfo/esip-documentation
>>
>>
>> --
>> [image: CICS-NC] <http://www.cicsnc.org/> Visit us on
>> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
>> *Research Scholar*
>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>> North Carolina State University <http://ncsu.edu/>
>> NOAA National Centers for Environmental Information
>> <http://ncdc.noaa.gov/>
>> *formerly NOAA’s National Climatic Data Center*
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbiard at cicsnc.org
>> o: +1 828 271 4900 <(828)%20271-4900>
>>
>> *Connect with us on Facebook for climate
>> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
>> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
>> Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
>> @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. *
>>
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>>
>>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170124/ff773728/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170124/ff773728/attachment-0001.png>