[Esip-documentation] ACDD geospatial_bounds

[John Graybeal via Esip-documentation]

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?  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> 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> 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 at http://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 (see http://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
>>> 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/dae7e275/attachment.html>