[Esip-documentation] Geospatial Bounds

Tue Sep 23 12:31:13 EDT 2014

On 2014-09-23 7:48 AM, David Neufeld - NOAA Affiliate via 
Esip-documentation wrote:
> Round 3....
>
> geospatial_bounds:
> Describes geospatial extent using geometric objects (2D or 3D) defined 
> by the Well-Known Text (WKT) format.  geospatial_bounds values are 
> always latitude (decimal degrees_north),  longitude (decimal 
> degrees_east), altitude (meters, up).  Like the 
>  geospatial_lon/lat_min/max attributes, these are typically 
> approximate values.  If possible, it is recommended that coordinates 
> be provided using WGS84 (EPSG:4326 for 2D and EPSG:4979 for 3D); 
> Example: POLYGON ((-111.29 40.26, -110.79 41.26, -110.29 41.26, 
> -110.79 40.26, -111.29 40.26))
And now we're back to where I came in.
I could be wrong, but it is my understanding that:
* EPSG:4326 specifies lon in the range -180 to 180, but many of my 
datasets are 0 to 360 (which requires another CRS), so using EPSG:4326 
is wrong.
* Ted is correct that some CRS's use y x ordering and others use x y 
ordering.
   But I think that is irrelevant here.
   The WKT specifications (see
http://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html#gis-wkt-format
   and the OpenGIS specification
   99-049_OpenGIS_Simple_Features_Specification_For_SQL_Rev_1.1.pdf
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CDQQFjAC&url=https%3A%2F%2Fportal.opengeospatial.org%2Ffiles%2F%3Fartifact_id%3D829&ei=C5shVOeVKu_NigL8_IHwAw&usg=AFQjCNHaa38eN6n9MbnUk3ec9Ujx9UUeHg&sig2=eICP0DMznkPEBI2pDPfFMw&bvm=bv.75775273,d.cGE
)
   indicate that WKT always uses x y ordering.
* Yes, I said x y, not longitude latitude, because WKT values are tied 
to a CRS which may use projection x and y (false_easting and 
false_northing) values.
* In the WKT geometry representation, there is no place to specify a CRS.
* In the proposed ACDD 1.3 there is currently no place to specify a CRS.
   Notably, not in the definitions of geospatial_lat/lon_min/max and 
geospatial_bounds.
* Are we supplying datums, too, when they are relevant?
* Vertical CRS's are problematic. It is often difficult or impossible to 
find an official CRS which matches how the data were collected.

Summary:
So now we're requiring all data providers, all data users, and all 
software libraries (in particular) to have expert and encyclopedic 
knowledge of CRS's, WKT, and datums (which I don't have and I suspect 
few of us have) in order to understand the geospatial_bounds WKT?
That is not realistic.

Solution:
The above mess is why I proposed defining geospatial_bounds to be 
similar to geospatial_lon/lat_min/max:
* The numbers should always be longitude (decimal degrees_east), 
latitude (decimal degrees_north), and optionally, altitude (meters, up), 
in that order (because that is the WKT order, regardless of the CRS 
order).  Please say that in the definition.
* The longitude, latitude, and altitude values are not tied to a 
specific CRS. (Please say that in the definition.) They are just 
approximate values meant to be a helpful guideline to human and software 
users.

I know that is deeply offensive to the few people who both want 
everything to be exactly precise and who actually have expert and 
encyclopedic knowledge of CRS's, WKT, datums, and their dataset. But I 
think my proposal makes this attribute actually usable for the rest of 
us mere mortals.

How about this definition:
geospatial_bounds -
Describes the data's geospatial extent using geometric objects (2D or 
3D) in the Well-Known Text (WKT) format.
(http://en.wikipedia.org/wiki/Well-known_text)
geospatial_bounds points are always space-separated longitude (decimal 
degrees_east), latitude (decimal degrees_north), and optionally altitude 
(meters, up), in that order.  The points are not tied to a specific CRS, 
but instead provide users with the approximate bounds of the data.  
Example: POLYGON ((-111.29 40.26, -110.79 41.26, -110.29 41.26, -110.79 
40.26, -111.29 40.26))

>
> Dave
>
>
> On Tue, Sep 23, 2014 at 7:38 AM, Aleksandar Jelenak via 
> Esip-documentation <esip-documentation at lists.esipfed.org 
> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>
>     On 9/22/14, 11:11 PM, "Cluster Documentation"
>     <esip-documentation at lists.esipfed.org
>     <mailto:esip-documentation at lists.esipfed.org>> wrote:
>     >How about the WGS-84 CRS (EPSG code: 4326)? This CRS prescribes that
>     >order of
>     >coordinates be latitude, longitude, altitude.
>
>     Need to correct myself... there are two WGS-84 CRSs to support:
>
>     1) For 2D geometric objects the CRS is EPSG:4326
>     (http://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4326)
>
>     2) For 3D geometric objects the CRS is EPSG:4979
>     (http://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4979)
>
>
>             -Aleksandar
>
>     _______________________________________________
>     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
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
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/20140923/c365fcee/attachment.html>