[Esip-documentation] proposed new wording for geospatial bounds attributes

Wed Oct 15 16:07:22 EDT 2014

My vote is to not add these attributes (with any of their definitions) 
to ACDD 1.3.   (Maybe some future version, but not 1.3.)
1) As a software developer, I have learned (through painful lessons) not 
to make significant changes right before a release. It is the same thing 
here. We are trying to create a standard that will stand the test of 
time.  Changes to standards have real consequences for the people who 
tried to follow the standard. We need to get it right the first time.
2) The options before us are vastly different: support OGC's standards 
100% vs. use the name of the standard but largely ignore the standard.
3) All of the versions have significant problems, so I don't support any 
of them, even the one below that I wrote the first draft of, because I'm 
not sure of it and because I know it is insufficient.
4) The definition below demands absolute correctness of usage so that it 
can be dealt with by software (because the calculations are so complex 
they can only be dealt with by software) and yet begs for incorrect use 
because everyone thinks they understand the CRSs and the usage and few 
people do. Haven't we all had misunderstandings about WKT and CRSs? 
Heck, even OGC massively bungled the lon lat vs lat lon ordering issue 
which is partly why WKT has such a troubled history and is used so 
different by different software programs.

Please, let's pass on these attributes for now.

---
Or, John, here are my comments about this proposed definition:

On 2014-10-15 12:07 PM, John Graybeal via Esip-documentation wrote:
> Per the recent exchanges, I'd like to propose the following wordings 
> for geospatial bounds attributes.
>
> I think that EITHER (a) this wording addresses all the issues raised 
> to date, and is likely to be largely acceptable, OR (b) there will 
> remain some fundamental disagreement, in which case we needn't 
> consider this one further. But I wanted to get it on the table, as I 
> think it represents a workable conclusion to the issues/discussion to 
> date.
>
> geospatial_bounds:
>
> Describes the data's 2D or 3D geospatial extent in OGC's Well-Known 
> Text (WKT) Geometry format (reference the OGC Simple Feature Access 
> (SFA) specification 
> <http://www.opengeospatial.org/standards/sfa>). The meaning and order 
> of values for each coordinate point depends on the coordinate 
> reference system (CRS). In ACDD the default CRS is EPSG:4326 for 
> 2-dimensional geometries, and EPSG:4979 for 3-dimensional geometries;
Please give the software that is going to interpret this a break. With 
this definition, the software has to parse the WKT to see how many 
coordinates there are in each point, then parse it again to interpret 
it. Please just define one default CRS (EPSG:4326).

> the default may be overridden using geospatial_bounds_crs and/or 
> geospatial_bounds_vertical_crs (see those attributes). The values may 
> be approximate. Example: EPSG:4326 
> <http://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4326> coordinate 
> values are latitude (decimal degrees_north) and longitude (decimal 
> degrees_east), in that order, thus: "POLYGON ((40.26 -111.29, 41.26 
> -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))".
So if the coordinates are 3D the default CRS is EPSG:4979.
But if geospatial_bounds_vertical_crs is specified, then the Z part of 
that CRS replaces the Z part of EPSG:4979.
That is awkward.  Stick to a 2D default CRS, which can be overridden 
with the other attributes, or augmented with geospatial_bounds_vertical_crs.

> (Note that neither default CRS restricts longitude values to the 
> [-180, 180] range.)
I'm trusting Aleksandar on this, but I'm not sure. The definitions say 
(and my interpretation was) that the longitude "bounds" are -180 to 
180.  See http://spatialreference.org/ref/epsg/wgs-84/

And if the bounds aren't restricted to -180 to 180 for 4326 and 4979, 
isn't it true for all other CRSs that use longitude?

>
> geospatial_bounds_crs:
>
> The coordinate reference system (CRS) used by the coordinates in the 
> geospatial_bounds attribute.  This CRS may be 2-dimensional or 
> 3-dimensional, but (together with geospatial_bounds_vertical_crs, if 
> that attribute is supplied) must match the dimensionality, order, and 
> meaning of point values in the geospatial_bounds attribute. EPSG CRS's 
> are strongly recommended.. If this attribute is not specified, the CRS 
> is assumed to be EPSG:4326 for 2-dimensional geometries, and EPSG-4979 
> for 3-dimensional geometries. Examples: "EPSG:4326" (the 2D WGS84 CRS) 
> and "EPSG:4979" (the 3D WGS84 CRS).
>
> geospatial_bounds_vertical_crs:
>
> The vertical coordinate reference system used by the Z coordinates in 
> the geospatial_bounds attribute; may not be used if the CRS in 
> geospatial_bounds_crs is a 2-dimensional CRS. EPSG CRSs are strongly 
> recommended. The default if unspecified is the vertical component of 
> EPSG:4979 (height above the ellipsoid, in meters). Examples: 
> "EPSG:5829" (instantaneous height above sea level), "EPSG:5831" 
> (instantaneous depth below sea level), or "EPSG:5703" (NAVD88 height).
>
So we are limited to predefined CRSs or combinations of predefined 2D + 
predefined Z CRSs.
Are there cases where users need to define custom/composite/derived 
CRSs? (If "no", are you sure?)
If "yes", don't we need a way to specify custom/composite/derived CRSs 
(e.g., via OGC WKT SRS)?

---
I shouldn't have so many questions and suggestions for an attribute that 
will be part of a standard that we hope to ratify in <24 hours. Let's 
wait until a future version of ACDD.
(Or:
This attribute isn't going to be used to connect to some other standard 
(e.g., ISO 19115), so Aleksandar, maybe you should just do what you want 
for your datasets, separate from ACDD.)

>
> John
>
> /
> /
>
>
>
> _______________________________________________
> 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/c5834c1e/attachment-0001.html>