[Esip-documentation] ACDD geospatial_bounds

Wed Oct 15 14:03:21 EDT 2014

Hi.

To add a twist, when using either 4326 or 4979, you should specify that 
in the geospatial_bounds_crs, not in one that specifies a vertical 
datum, axis, or cs such as the proposed geospatial_bounds_vertical_crs. 
This attribute should only be used to specify a vertical CS to combine 
with a 2D horizontal CS. An example is NAD83 horizontal (EPSG:4269) with 
NAVD88 height (EPSG:5703). Or, more to the point, WGS84 horizontal 
(EPSG:4326) together with Instantaneous Water Level depth (EPSG:5831). 
If the CRS is 3D, then only the bounds_crs should be used.

We can state that if a 2D WKT polygon is specified, then the assumption 
is EPSG:4326, and if a 3D WKT polygon is specified, then EPSG:4979 is 
assumed, and state in the description of the crs attributes that both 
should be used only if 3D bounds are specified, the total CRS is a 
combination of a horizontal CS and a vertical CS, and if a single 
compound 3D CRS is not available. (As an example, my earlier NAD83 + 
NAVD88 case is specified by a compound CRS - EPSG:5498.)

Grace and peace,

Jim

On 10/15/14, 1:04 PM, Bob Simons - NOAA Federal via Esip-documentation 
wrote:
>
> On 2014-10-15 9:41 AM, John Graybeal via Esip-documentation wrote:
>> Yes, there are cases where the CRS is 3D. In fact, 4979 appears to be 
>> 4326 + the vertical GPS component (or as I think of it, 4326 is a 
>> dumbed-down version of the full GPS coordinate system). But there are 
>> also CRSs that provide only horizontal or vertical, as we've seen.
>>
>> Can someone in this group speak authoritatively about whether use of 
>> a 3D CRS in a WKT requires all 3 axes to be present in each point?
>
> Yes, for a 3D CRS, each point will have 3 values. I'll quote from
> OGC's 
> 06-103r4_Implementation_Specification_for_Geographic_Information_-_Simple_feature_access_-_Part_1_Common_Architecture_v1.2.1.pdf 
> dated 2011 and downloadable at 
> http://www.opengeospatial.org/standards/sfa
> "6.1.2.1 Description
> Geometry is the root class of the hierarchy. Geometry is an abstract 
> (non-instantiable) class.
> The instantiable subclasses of Geometry defined in this Standard are 
> restricted to 0, 1 and
> 2-dimensional geometric objects that exist in 2, 3 or 4-dimensional 
> coordinate space (ℜ2, ℜ3 or ℜ4). Geometry
> values in R2 have points with coordinate values for x and y. Geometry 
> values in R3 have points with coordinate
> values for x, y and z or for x, y and m. Geometry values in R4 have 
> points with coordinate values for x, y, z and m."
>
> I don't see anything indicating that geometry values in R3 may have 
> have points with just x, y coordinate values.
>
>> The WKT format would clearly support successful parsing of each 2D 
>> point in this case (i.e., if only lat/lon were present); and the fact 
>> the CRS is in a separate attribute makes it surprising to me that the 
>> CRS affects the parsing order at all, actually. But I digress.
>>
>> I ask because GPS is ubiquitous in sensing, and usually provides 
>> altitude, and it would be a simplifying assumption to make 4979 the 
>> default, but allow 2D or 3D bounding boxes with it.
>>
>>  If we don't have a local expert I'll go dig one up from the wider 
>> community.
>>
>> John
>>
>>
>> On Oct 15, 2014, at 09:23, Bob Simons - NOAA Federal 
>> <bob.simons at noaa.gov <mailto:bob.simons at noaa.gov>> wrote:
>>
>>> Hmmm. Well that adds a new wrinkle.
>>>
>>> EPSG:4979 covers latitude, longitude and altitude. It isn't just a 
>>> vertical crs. So specifying it as the vertical crs, in addition to a 
>>> 2D crs, seems wrong.  But I believe that there are cases where a 2D 
>>> CRS is combined with a vertical CRS.
>>>
>>> This brings up the question: should there be a way (e.g., WKT for 
>>> Spatial Reference Systems) to specify other SRS's that aren't 
>>> predefined?
>>>
>>> This brings up the question: shouldn't these attributes be defined 
>>> by one or more people who are really knowledgeable about OGC 
>>> specifications?  I am not qualified.
>>>
>>>
>>>
>>> On 2014-10-14 11:43 PM, John Graybeal wrote:
>>>> Hi Bob,
>>>>
>>>> Thank you for working on this so quickly. I find your text 
>>>> basically satisfactory (trusting you and other reviewers to sort 
>>>> out the OGC spec properly), and will put it in the table in the 
>>>> morning, with a few minor edits for consistency with other entries.
>>> When you have made the changes, please let me know.
>>>
>>>>
>>>> I ask we have the ability to specify a vertical CRS as well.
>>>>
>>>> Previously we proposed a separate attribute for that—how does 
>>>> geospatial_bounds_vertical_crs work for you? The definition would be
>>>>
>>>> /The vertical coordinate reference system used by the coordinates 
>>>> in the geospatial_bounds attribute. EPSG CRSs are strongly 
>>>> recommended. The default if unspecified is EPSG:4979 (height above 
>>>> the ellipsoid, in meters). Examples: "EPSG:5829" (instantaneous 
>>>> height above sea level) or "EPSG:5831" (instantaneous depth below 
>>>> sea level)./
>>>>
>>>> A corresponding adjustment to the geospatial_bounds definition 
>>>> would be needed. I can suggest wording if you approve in principal.
>>>>
>>>> John
>>>>
>>>> =======
>>>>
>>>> On Oct 14, 2014, at 14:08, Bob Simons - NOAA Federal via 
>>>> Esip-documentation <esip-documentation at lists.esipfed.org 
>>>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>>
>>>>> For geospatial_bounds_crs, how about:
>>>>> The Coordinate Reference System used by the coordinates in the WKT 
>>>>> in the geospatial_bounds attribute.  EPSG CRS's are strongly 
>>>>> recommended. Examples: EPSG:4326 (the 2D WGS84 CRS) and EPSG:4979 
>>>>> (the 3D WGS84 CRS). If this attribute is not specified, the CRS is 
>>>>> assumed to be EPSG:4326.
>>>>>
>>>>> For geospatial_bounds, how about:
>>>>> Describes the data's 2D or 3D geospatial extent in OGC's 
>>>>> Well-Known Text (WKT) Geometry format.  (See the specification in 
>>>>> the OGC Simple Feature Access (SFA) document 
>>>>> athttp://www.opengeospatial.org/standards/sfa.) As in the WKT 
>>>>> specification, the meaning and order of values for each coordinate 
>>>>> point is dependent on the CRS, which in ACDD is assumed to be 
>>>>> EPSG:4326 unless otherwise specified with geospatial_bounds_crs.  
>>>>> For example, EPSG:4326 coordinate values are latitude (decimal 
>>>>> degrees_north) and longitude (decimal degrees_east), in that order 
>>>>> (seehttp://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4326). 
>>>>> The values may be approximate. Note that longitude values in 
>>>>> EPSG:4326 and EPSG:4979 are not restricted to the [-180, 180] 
>>>>> range only. Example using EPSG:4326: POLYGON ((40.26 -111.29, 
>>>>> 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))
>>>>>
>>>>> I don't feel that I'm an expert with OGC standards. I'm open to 
>>>>> suggestions/corrections.
>>>>>
>>>>> --
>>>>> Sincerely,
>>>>>
>>>>> Bob Simons
>>>>> IT Specialist
>>>>> Environmental Research Division
>>>>> NOAA Southwest Fisheries Science Center
>>>>> 99 Pacific St, Suite 255A
>>>>> Monterey, CA 93940
>>>>> Phone: (831)333-9878 (Changed 2014-08-20)
>>>>> Fax: (831)648-8440
>>>>> Email:bob.simons at noaa.gov
>>>>>
>>>>> The contents of this message are mine personally and
>>>>> do not necessarily reflect any position of the
>>>>> Government or the National Oceanic and Atmospheric
>>>>> Administration.
>>>>> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>>>>>
>>>>> _______________________________________________
>>>>> Esip-documentation mailing list
>>>>> Esip-documentation at lists.esipfed.org 
>>>>> <mailto:Esip-documentation at lists.esipfed.org>
>>>>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>>>>
>>>
>>> -- 
>>> Sincerely,
>>>
>>> Bob Simons
>>> IT Specialist
>>> Environmental Research Division
>>> NOAA Southwest Fisheries Science Center
>>> 99 Pacific St, Suite 255A
>>> Monterey, CA 93940
>>> Phone: (831)333-9878 (Changed 2014-08-20)
>>> Fax: (831)648-8440
>>> Email: bob.simons at noaa.gov
>>>
>>> The contents of this message are mine personally and
>>> do not necessarily reflect any position of the
>>> Government or the National Oceanic and Atmospheric
>>> Administration.
>>> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>>>
>>
>>
>>
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
> -- 
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St, Suite 255A
> Monterey, CA 93940
> Phone: (831)333-9878 (Changed 2014-08-20)
> Fax: (831)648-8440
> Email: bob.simons at noaa.gov
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric
> Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/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's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/65b0601d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cjheiiib.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/65b0601d/attachment-0001.png>