[Esip-documentation] ACDD geospatial_bounds

Wed Oct 15 13:04:35 EDT 2014

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 (R2, R3 or R4). 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.
<>< <>< <>< <>< <>< <>< <>< <>< <>< <><

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/ce515662/attachment-0001.html>