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

Wed Oct 15 17:52:14 EDT 2014

I understand your desire to get it right Bob, so I have no personal 
problem with waiting. But I guess it can't hurt to try and see what we 
can understand before tomorrow afternoon, can it?

Regarding your comments and issues, I think you touch on an important 
point in your question about 2D vs 3D WKT polygons. 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? It seems to me that we should limit the WKT polygon to 2D 
horizontal x/y (in whatever coordinate system is specified). The default 
coordinate system would be the 3D WGS84 (EPSG:4979), but we would 
explicitly state that z values are assumed to be zero unless vertical 
upper and/or lower bounds are defined. The crs attribute is used to 
specify a non-default CRS for the WKT polygon. If a different vertical 
CS is to be used for the vertical bounds, it is to be specified with the 
vertical_crs attribute, and an appropriate horizontal CS should be 
specified along with it.

I see two remaining issues with this approach. This approach would 
prevent using a geocentric Cartesian CRS (ECF or ECI) for the bounding 
polygon, since 3D points would be disallowed. (I don't see this as being 
a deal breaker, myself, since that would be an incredibly awkward way to 
specify a bounding polygon for anything related in any meaningful way to 
the Earth's surface.)

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. Underlying datums 
must be compatible, for one thing. We can't provide enough guidance to 
cover all the potential pitfalls, except to warn people that 'here lie 
dragons'. As an example of the difficulty here, there is no EPSG code 
that I can find that represents a vertical ellipsoidal CS. If you want 
3D WGS84, the only option seems to be EPSG:4979.

I expect that the five main sets that will be used will be 2D WGS84, 3D 
WGS84, 2D WGS84 with a vertical CS, a 2D sphere (e.g. EPSG:4047), or a 
2D sphere with a vertical CS.

Regarding the WGS84 bounds, a drill-down on the EPSG web site gets to 
area code EPSG:1262, which states bounds of -180 to 180 for longitude. 
This code is found in the domainOfValidity element for EPSG:6326, which 
is the WGS84 horizontal datum, which is in turn found in the 
geodeticDatum element of EPSG:4947, which is the WGS84 3D CRS. Whew!

Grace and peace,

Jim

On 10/15/14, 4:07 PM, Bob Simons - NOAA Federal via Esip-documentation 
wrote:
> 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.
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-- 
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> 	*Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/2c4d948f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: djaiejdi.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141015/2c4d948f/attachment-0001.png>