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

Tue Jan 24 14:47:53 EST 2017

Thanks, Jim. I'm accustomed to lon lat order in the BBOX parameter of WMS
requests using EPSG:4326, which is what brought this to my attention to
begin with. I did some further research, and I've clearly fallen down the
rabbit hole here. This issue has a history of reversal and mass confusion.
I think the this page
<http://docs.geotools.org/latest/userguide/library/referencing/order.html>
summarizes it well (quoted below). Sadly, for something so fundamental, the
fallout of this is that it's anybody's guess and different tools and
services expect different coordinate orders. :( In a "strict" sense, ACDD
has the "correct" answer so the Wiki example does not require modification.
Sorry to rehash this with you all.
Cheers,
John

> The problem
>
> In the EPSG database, 4326 maps to a geographic CRS with (latitude,
> longitude) axis order. However, most software in the field understand
> EPSG:4326 as a geographic CRS with (longitude, latitude) axis order,
> because legacy OGC specifications were designed that way. The problem is
> not limited to EPSG:4326; it applies to most geographic CRS defined in the
> EPSG database. The axis order understood by currently existing software is
> in violation with what the EPSG database said.
>
> Prior to the June 2005 meetings, there was considerable email dialogue
> between OGC members regarding axis order and coordinate reference systems.
> After some discussion, the members in attendance agreed that going forward,
> for new specifications, coordinate values shall be listed in the axis order
> specified by the referenced coordinate reference system (CRS). However no
> clarification was ever gained on what the situation with existing
> specifications was. The reality-on-the-ground is that every WFS 1.0
> implementation tested that advertised EPSG:4326 as its CRS returned data on
> (longitude, latitude) order.
>
> Starting in WMS 1.1, the specification actually explicitly states that the
> EPSG axis order is to be used, while making a special case exception for
> EPSG:4326, which was to be in (longitude, latitude) order. Oddly, they did
> not make exceptions for all geographic coordinate systems (like, say
> EPSG:4269) just for EPSG:4326. Finally in WMS 1.3, that exception was
> dropped as well, to consternation all around. From WMS 1.3.0 / ISO
> 19128:2005, published by ISO on 2005-11-23:
>
>    - EXAMPLE: EPSG:4326 refers to WGS 84 geographic latitude, then
>    longitude. That is, in this CRS the x axis corresponds to latitude, and the
>    y axis to longitude.
>
> The GeoTools referencing module can not guess by itself when to returns a
> coordinate reference system (CRS) exactly as specified in the EPSG
> database, and when to returns a CRS with axis order forced to (longitude,
> latitude) no matter what the database said. The decision is left to the
> users or to the DataStore implementers. The choice may changes among
> different versions of the same standard.
>
> Because GeoTools is designed for handling data from different sources,
> users need to choose between “strict EPSG axis order” and “modified axis
> order” on a case-by-case basis. A consequence is that a running Java
> Virtual Machine may contains two different instances of a CRS, one with
> (latitude, longitude) axis order and the other one with (longitude,
> latitude) axis order, and both claiming to be EPSG:4326. Experience has
> show that the coexistence of such conflicting CRS in the same application
> can lead to some error like StackOverflowError in non-cautious code.
>

On Tue, Jan 24, 2017 at 9:24 AM, Jim Biard <jbiard at cicsnc.org> wrote:

> If you go to the EPSG website - https://www.epsg-registry.org/ - and
> search for code 4326, you will find the full definition. It is quite
> explicit that the order is lat, lon. The WKT generated for the CRS is
>
> GEODCRS["WGS 84",
>   DATUM["World Geodetic System 1984",
>     ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]],
>   CS[ellipsoidal,2],
>     AXIS["latitude",north,ORDER[1]],
>     AXIS["longitude",east,ORDER[2]],
>     ANGLEUNIT["degree",0.01745329252],
>   ID["EPSG",4326]]
>
>
> The ellipsoidal CS that specifies this is EPSG::6422. If you look it up,
> it is in agreement. There's no place I can find where this coordinate
> system is properly represented as lon,lat. If you can find an authoritative
> source I'd love to hear about it. I'd love to be able to do the sensible
> thing in code (right-hand coordinate systems should rule the day!) and not
> feel guilty.
>
> Grace and peace,
>
> Jim
>
>
> On 1/24/17 1:47 PM, John Maurer 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 <%28303%29%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 <%28828%29%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
>
> --
> [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>. *
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170124/0140a925/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/0140a925/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20170124/0140a925/attachment-0003.png>