[Esip-documentation] Geospatial Bounds

[John Graybeal via Esip-documentation]

Thanks Aleksandar! I also prefer #1 or #2. And defining it as 'the EPSG code' seems appropriately deterministic and simple. 

Continuing along the 'simple' line, I prefer #1 over #2 because it doesn't make the existing WKT *less* interoperable. That is, if any software currently depends on the standard WKT, it would be unfortunate if #2's extended WKT format forced software modifications to avoid breakage. 

I will hold any other detailed thoughts until we agree on the approach.

John

On Oct 7, 2014, at 10:14, Aleksandar Jelenak via Esip-documentation <esip-documentation at lists.esipfed.org> 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