[Esip-documentation] geospatial_bounds: how to show 3-D bbox?
Jim Biard
jbiard at cicsnc.org
Tue Jan 24 16:25:57 EST 2017
John,
It is a horrible mess. And, like Ted mentioned in the other sub-thread,
you probably should use a 3D coordinate system for your two polygons. If
you give the two polygons different z values, you could go with the
assumption that the volume between them is the bounds. The 3D geographic
CRS EPSG::7665 is one example.
As I read more (it's been a while since I messed with this issue), I see
that the OGC WKT spec defines Extent as "the spatial applicability of a
CRS..." The standard says that this comes from ISO19115:2003, but that
it expressly prohibits using polygons because they could get too long.
It describes using a bounding box (lat and lon min and max) and a
vertical extent (z min and max). Would a single polygon along with the
vertical extent be sufficient for your needs?
Grace and peace,
Jim
On 1/24/17 2:47 PM, John Maurer wrote:
> 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
> <mailto: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
>> <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
> <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>. /
>
--
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/9566d3e5/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/9566d3e5/attachment-0003.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/9566d3e5/attachment-0004.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/9566d3e5/attachment-0005.png>
More information about the Esip-documentation
mailing list