[Esip-documentation] Geospatial Bounds

[Jim Biard via Esip-documentation]

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.

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'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.

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




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