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

Wed Jan 25 18:14:33 EST 2017

To be more precise, you could change this to "urn:ogc:def:crs:EPSG::4326".
This avoids any ambiguity as to coordinate order since it is defined as lat
lon order by this URN. Some software will treat "EPSG:4326" as lon lat
order given the historical ambuiguities (e.g., deegree
<https://github.com/deegree/deegree3/wiki/Axis-order-handling>), but
"urn:ogc:def:crs:EPSG::4326" should always be treated as lat lon order in
axis-aware products. Unfortunately, there will still be software that are
not axis-aware and always treat these as lon lat order regardless (e.g.,
PostGIS).
Cheers,
John

On Wed, Jan 25, 2017 at 12:47 PM, David Neufeld <david.neufeld at noaa.gov>
wrote:

> That sounds right to me, and since the wiki references EPSG:4326 we
> should be good.
>
>
>
> On Tue, Jan 24, 2017 at 11:47 AM, John Maurer via Esip-documentation <
> esip-documentation at lists.esipfed.org> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>>
>>
>
>
> --
> David Neufeld
> Senior Associate Scientist
> CIRES
> Software Engineering Support Branch
> Data Stewardship Division
> NOAA National Centers for Environmental Information (NCEI)
> Ph. 303-497-6507 <(303)%20497-6507>
>
> Note:
> The opinions expressed in this email are those of the author. They do not
> necessarily reflect the official views or policies of the University of
> Colorado, NOAA, Department of Commerce, or the US Government.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170125/0718a69f/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/20170125/0718a69f/attachment-0001.png>