[Esip-documentation] Geospatial Bounds

Tue Oct 7 17:26:57 EDT 2014

On 2014-10-07 1:49 PM, Jim Biard via Esip-documentation wrote:
> Hi.
>
> I'm a believer in having well-defined coordinate systems in our netCDF 
> files. Even so, I'm not sure what we gain by allowing the geospatial 
> bounds information to be represented in a variety of coordinate 
> systems. I'd be more in favor of specifying that all of the geospatial 
> boundary attributes (including the old ones) are to be specified using 
> longitude and latitude without worrying about what coordinate system 
> is used. The worst case error (model spherical Earth vs WGS84 
> elliptical Earth) is on the order of 0.3%, or ~300 meters. I think 
> this is likely to be well within the accuracy needs of file-level 
> bounds information.
I agree.  I understand that CRSs allow the data provider to be very 
precise. But I'm not convinced this precision is necessary/useful for 
the metadata. For example, when we ask a catalog system for datasets 
with data within a given lon lat region, do we really expect it to have 
a knowledge of all CRSs and to do the conversions between the different 
CRSs?

Also, in ISO 19115/19139, gmd:EX_GeographicBoundingBox is always 
specified with longitude and latitude (gmd:(east|west)BoundLongitude, 
gmd:(north|south)BoundLatitude) (never projection x, y values) and no 
CRS. (Am I missing one? If so, please tell me where it is.)
http://www.datypic.com/sc/niem21/e-gmd_EX_GeographicBoundingBox.html

>
> If you want to be able to specify this more accurately, then I'm OK 
> with having an optional 'srid' attribute, but we should still require 
> the bounds to be in longitude and latitude.
I agree. It is useful that the values of these attributes for different 
datasets be easily comparable. And again, gmd:EX_GeographicBoundingBox 
uses longitude and latitude.

>
> I'm good with the idea of using WKT polygons, but longitude should 
> come first, then latitude. That is the right-hand coordinate system 
> form. In fact, I believe that is the WKT standard.
I agree. The lon, lat ordering agrees with my reading of the WKT 
standard.  If we open up using CRSs and the possibility that some CRSs 
prefer a latitude longitude ordering, than interpreting WKT by a human 
or a computer program requires access to extensive, detailed knowledge 
of every CRS (and even then, allowing different ordering invites errors).

>
> Grace and peace,
>
> Jim
>
> On 10/7/14, 1:14 PM, Aleksandar Jelenak via Esip-documentation wrote:
>> Hello all!
>>
>> The latest round of comments about the geospatial_bounds attribute
>> requested the flexibility in specifying the coordinate reference system.
>> Fine. Below are three alternative approaches:
>>
>> 1) New Attribute for CRS
>>
>> A new attribute, geospatial_bounds_srid, will hold the EPSG code of the
>> CRS. Example:
>>
>> geospatial_bounds = "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26
>> -110.29, 40.26 -110.29, 40.26 -111.29))"
>>
>> geospatial_bounds_srid = 4326
>>
>> The new attribute's name could also be "geospatial_srid" to provide CRS
>> information for the currently CRS-less attributes like
>> geospatial_lat|lon_min|max.
>>
>> 2) Extended WKT
>>
>> The EPSG code of the CRS is included in the value of the
>> geospatial_bounds. This is the Extended WKT format. Although the most
>> compact form, it is non-standard. Example:
>>
>> geospatial_bounds = "SRID=4326;POLYGON ((40.26 -111.29, 41.26 -111.29,
>> 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))"
>>
>> 3) No CRS
>>
>> Instead of specifying a CRS, several geospatial attributes --- some new,
>> some old --- specify the most relevant CRS information. For example, new
>> attributes like:
>>
>> geospatial_bounds_x_axis ::= "latitude"  | "longitude"
>>
>> geospatial_bounds_y_axis ::= "longitude" | "latitude"
>>
>> with perhaps some old ones: geospatial_lat_units, geospatial_lon_units,
>> etc.
>>
>> Let's agree on the most appropriate approach first and then fix the
>> definitions. My preference: #1 or #2.
>>
>> 	-Aleksandar
>>
>> _______________________________________________
>> 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
>
>
>
>
>
>
> _______________________________________________
> 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/20141007/2780e6d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141007/2780e6d2/attachment-0001.png>