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

Thu Oct 16 12:42:11 EDT 2014

Bob,

Please let us know, now or on the call, of any other topics that are of active concern. The only other one I am aware of is cdm_data_type, and I'm the principal one keeping it unsettled.

Of course, many topics have only recently been adjudicated, and so the whole specification is, shall we say, vibrating from the residual excitement. In that sense it is all a bit unsettled, yes.

John

On Oct 16, 2014, at 09:02, Bob Simons - NOAA Federal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> 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). 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 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
>> 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. 
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
> 
> _______________________________________________
> 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/20141016/3fa097b9/attachment-0001.html>