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

Thu Oct 16 12:02:07 EDT 2014

I'm sorry for not writing more clearly.
The point I was trying to make with my comments about "Do not make 
significant changes before a release" was not that I want to stop 
discussion or changes to geospatial_bounds or other attributes.
My point is that I think we should delay the vote on ratification of 
ACDD 1.3.
Things are not settled with geospatial_bounds and other topics.
There has been far too little time for people to review and think about 
the document we will be voting on.
Just as deadlines are a bad idea when writing software, I think they are 
a bad idea for writing standards.
We need to get ACDD 1.3 right.
There are real consequences to poorly worded definitions and poor decisions.
Please, let's give ACDD 1.3 a little more time, thought, and consideration.

On 2014-10-15 10:01 PM, John Graybeal via Esip-documentation wrote:
> As I mentioned in my summary, one person proposes to ask for a vote on 
> these definitions at tomorrow's meeting, as we have put in a lot of 
> effort to get to this stage. I therefore wanted to update this text to 
> address the comments received (which are listed, with dispositions, 
> after the definitions).
>
> I believe all the specific technical issues were addressed in some 
> way; but there are clearly questions of judgment that are for the team 
> to decide.
>
> *Updated Definitions*
>
> /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 point's coordinates 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; 
> the default may be overridden using geospatial_bounds_crs and/or 
> geospatial_bounds_vertical_crs (see those attributes). 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))".
>
> /geospatial_bounds_crs/:
>
> The coordinate reference system (CRS) of the point 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 coordinate 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 point 
> coordinates in the geospatial_bounds attribute; may not be used if the 
> CRS in geospatial_bounds_crs is a 3-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).
>
>
> *Comments Received and Dispositions*
>
> "Remove this sentence ['The values may be approximate'] because I 
> think it will mostly confuse users."
>  -> DONE
>
> Wording changes around point coordinates: "points' coordinates" 
> instead of "coordinate point"; "of the point coordinates" instead of 
> "used by the coordinates"; "point coordinate values" instead of "point 
> values"; "Z point coordinate" instead of "Z coordinates".
> -> DONE
>
> "Do not make significant changes before a release"
> /and/
> "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."
> -> I recognize the validity of this concern, but defer to 
> Documentation Cluster to evaluate whether the improvements are worth 
> the risk.
>
> "support OGC's standards 100% vs. use the name of the standard but 
> largely ignore the standard"
> -> Changed the above definitions to make them align with the WKT 
> standard. Note that the existing 1.1 definition is arguably not OGC 
> compliant, since no CRS is specified.
>
> "All of the versions have significant problems"
> -> I have attempted to address or respond to all specific problems 
> raised with this version. I view all of this work as an attempt to 
> address the significant problems in the original definition, which 
> seems very unlikely to be interoperable (and impossible to code for 
> interoperably) as written.
>
> "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. "
> -> I think the issue of incorrect use exists already in ACDD version 
> 1.1, which specifies geospatial_bounds with a WKT. The alternative to 
> this change---sticking with the 1.1 version---is the complete absence 
> of guidance, which seems guaranteed to produce incompatibility 
> (thereby making 'correctness of usage' a non-problem).
>
> " *geospatial_bounds_vertical_crs* 'may not be used if the CRS in 
> geospatial_bounds_crs is a 2-dimensional CRS' --
> What? I thought the point was to allow the creation of composites by 
> specifying a 2D geospatial_bounds_crs and
> a Z CRS in geospatial_bounds_vertical_crs."
> -> DONE. Good catch, you are correct, this should have read 
> '3-dimensional CRS' is incompatible. Fixed it.
>
> "The WKT polygon isn't a parallelepiped, so what value is there in 
> specifying 3D vertices in the first place? Aren't we really wanting to 
> provide a 2D footprint that would be extended into a volume by upper 
> and lower vertical bounds values?"
> -> I believe WKTs can be used to specify 3D (solid) regions of 
> arbitrary shape, both from a careful reading of the SFA standard (see 
> section 6.1.10, Surface) *and* the reference in the original 1.1 
> definition to a 3D bounding region. (I haven't included or responded 
> to the detailed proposal that was introduced to address the above 
> issue; it could be discussed if we agree the issue needs to be addressed.)
>
> "This approach still requires people to be smart about handling CRSs. 
> I see this as being an irreducible problem, since not all combinations 
> of horizontal and vertical coordinate systems are valid. "
> -> Concur. If the original use of geospatial_bounds is to be 
> interoperable, the same problem obtains.
>
> "The definitions say (and my interpretation was) that the longitude 
> "bounds" are -180 to 180.  See 
> http://spatialreference.org/ref/epsg/wgs-84/"
> /and/ ""a drill-down on the EPSG web site gets to area code EPSG:1262, 
> which states bounds of -180 to 180 for longitude."
> -> DONE. Concur that the default CRSs being proposed seem to require 
> (in their definitions) values between -180 and 180. Therefore removed 
> the text '(Note that neither default CRS restricts longitude values to 
> the [-180, 180] range.)'
>
> "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 software only has to parse a single point; all points are 
> obligated to be part of the same geometry. Further, the geodetic 
> geometries of 4326 and 4979 are identical; if you see a third value in 
> your point, you know that the third axis applies (and that you need to 
> check the geospatial_bounds_vertical_crs, so you already have to check 
> for a third point to see if your points need a vertical_crs). This 
> does not seem hard to me, and when implemented it could be simpler 
> than the alternative, all details considered.
>
> "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."
> -> I don't find it any more awkward then allowing 
> geospatial_bounds_crs to override the X/Y part of the default CRS. 
> Both follow the exact same pattern, which is fundamentally simpler 
> than creating a custom pattern for the vertical case.
>
> "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)?"
> -> If the user needs a composite CRS, they can compose it using the 
> two *_crs attributes. If they need a custom/derived CRS, they can 
> propose it to EPSG (a good practice anyway, and one EPSG readily 
> supports). Alternatively, they are not precluded from specifying it in 
> whatever way they think appropriate. (Automated software parsing this 
> attribute should simply give up if the value doesn't begin 'EPSG' -- 
> just store the value and don't try to do computations with the 
> bounds.) Anyway, if this case happens more than one time in the next 
> 10 years, and there seems to be an issue, the ACDD convention team of 
> that era can consider standardizing it.
>
> "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.)"
> -> I think it bears mentioning that the attribute has existed since 
> ACDD 1.0, but has not been described in a very interoperable or easily 
> adopted way (and in fact is incompatible with the OGC approach, since 
> it currently has no default CRS). The reason for the proposal is to 
> improve upon the existing situation, not give Aleksandar something 
> only he has ever wanted. Of course, if we can't agree to an 
> improvement, then all of us who want to use this attribute will get to 
> do what we want---but then it isn't clear that the attribute should be 
> in ACDD at all, if it can't serve discovery interoperability.
>
> That's enough from me now. Thank you for the feedback to potentially 
> improve this attribute. I promise not to advocate further on it during 
> the meeting, unless someone asks me for clarification.
>
> John
>
>
>
>
> /
> /
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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/20141016/396a071f/attachment-0001.html>