[Esip-documentation] Geospatial Bounds

Tue Oct 7 18:02:05 EDT 2014

Ruling from the co-chair: since the lon/lat ordering is the WKT standard, it would preclude the use of CRS that forces lat/lon ordering. So far I haven't heard anyone argue *against* requiring lon/lat coordinates, nor have I heard anyone arguing against a lon, lat ordering. So let's declare the lon/lat requirement in the definition (I'll update attribute definition text to this effect in a little bit.) 

Adding to that the support each of you has expressed for an optional _srid attribute, seems to put everyone on the same page with regard to the critical issues. Thank you.

John

On Oct 7, 2014, at 14:26, Bob Simons - NOAA Federal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> 
> 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
>> 
>> -- 
>> <Mail Attachment.png>                                Visit us on 
>> Facebook	 Jim Biard 
>> Research Scholar 
>> Cooperative Institute for Climate and Satellites NC 
>> North Carolina State University 
>> NOAA's National Climatic Data Center 
>> 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. 
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
> 
> _______________________________________________
> 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/20141007/86108f33/attachment.html>