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

Jim Biard jbiard at cicsnc.org
Tue Jan 24 14:24:45 EST 2017


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 
> <mailto: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 <mailto:Anna.Milan at noaa.gov>, 303-497-5099
>     <tel:%28303%29%20497-5099>
>     NOAA National Centers for Environmental Information
>     (formerly NOAA’s National Geophysical Data Center)
>     http://www.ngdc.noaa.gov/metadata/emma
>     <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
>     <mailto: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/pipermail/postgis-users/2015-November/040971.html
>         <http://lists.osgeo.org/pipermail/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_Data_Discovery_1-3
>>         <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 <mailto: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 list
>>         Esip-documentation at lists.esipfed.org
>>         <mailto:Esip-documentation at lists.esipfed.org>
>>         http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>>         <http://lists.deltaforce.net/mailman/listinfo/esip-documentation>
>         -- 
>         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 <mailto:jbiard at cicsnc.org> o: +1 828 271
>         4900 <tel:%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
>         <mailto:Esip-documentation at lists.esipfed.org>
>         http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>         <http://lists.deltaforce.net/mailman/listinfo/esip-documentation> 
>
>     _______________________________________________ Esip-documentation
>     mailing list Esip-documentation at lists.esipfed.org
>     <mailto:Esip-documentation at lists.esipfed.org>
>     http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>     <http://lists.deltaforce.net/mailman/listinfo/esip-documentation> 
>
-- 
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 <mailto:jbiard at cicsnc.org> o: +1 828 271 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/b6a09dc7/attachment-0001.html>
-------------- 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/b6a09dc7/attachment-0002.png>
-------------- 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/b6a09dc7/attachment-0003.png>


More information about the Esip-documentation mailing list