[Esip-documentation] ACDD geospatial_bounds
John Graybeal via Esip-documentation
esip-documentation at lists.esipfed.org
Wed Oct 15 14:23:09 EDT 2014
Thanks Jim. I think this is a usable approach, and your examples are consistent with the cases I had to deal with for one of my projects. It satisfies my desire to let people 'just specify a stupid WKT already' without all the complications, while also supporting those people who need to specify something specific.
I will work on corresponding wording for all 3 attributes for review, unless there is strenuous objection.
John
On Oct 15, 2014, at 11:03, Jim Biard via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> 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> 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.
>>>> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> <cjheiiib.png> Visit us on
> Facebook Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org
> o: +1 828 271 4900
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/e37a108d/attachment-0001.html>
More information about the Esip-documentation
mailing list