[Esip-documentation] ACDD 1.3 issue: geospatial_bounds, geospatial_vertical_units

[John Graybeal via Esip-documentation]

Hi everyone,

We may have run out of time to complete refinement of the geospatial_bounds attribute, and related issues.  This definition is my attempt to summarize/address most of the recent conversation.

> Describes geospatial extent using geometric objects (2D or 3D) defined in the Well-Known Text (WKT) format. geospatial_bounds points are always space-separated values for latitude (decimal degrees_north), longitude (decimal degrees_east), and, for 3D objects, altitude (meters, up), in that order; each point is followed by a comma. By default in the WGS-84 coordinate reference system (specifically EPSG:4326 for 2D objects and EPSG:4979 for 3D objects) is used. If a coordinate reference system is specified in geospatial_srid and/or geospatial_vertical_srid attributes, these take precedence for locations in the horizontal and vertical axes, respectively. This attribute's values may be approximate. Note that longitude values are not restricted to the [-180, 180] range. Example: 'POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))'

As it stands, geospatial_*_units do not apply to the geospatial founds, and the two attributes that are proposed to be added, geospatial_bounds_srid and geospatial_vertical_srid, will address only geospatial bounds. The above text, and the *_srid attributes and definitions, will be written up in the Version Changes table shortly.

John







On Oct 7, 2014, at 13:37, John Graybeal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> I'm fine with geospatial_vertical_srid.  But note that geospatial_vertical_unit was explicitly mapped to the ISO CRS attribute in 1.1, so this concept was definitely not left out entirely. (Just out of the definition. ;->)  So at a minimum, a little clarifying text somewhere to distinguish the applicability of the *_units vs *_srid attributes is probably necessary.  I do like the idea that *_srid attributes apply to both bounds and min/max.
> 
> I'm not sure what 'sr' represents, though; and if we are just using a number, it has to be a CRS, right? (Because EPSG has 'cs' and 'crs' identifiers with the same number, and they are not the same thing). So would *_crsid be better?
> 
> I'll fix the nonexistent attribute, thanks.
> 
>> The geospatial_*_min/max attributes specify a bounding box; the geospatial_bounds attribute enables much more precise definition of the data's discovery geospatial extent and the values are to be expected to be different.
> 
> Of course, sorry I skipped over the whole polygon concept (hence the freudian reference to geospatial_bounding_box!). But I assume (a) the default behavior of simple systems will be to generate geospatial_bounds with the same info as the limits, (b) many indexing systems would only be able to index/search by the min/max info anyway, and (c) consistency checks should be possible (no point in the WKT should be outside the min/max ranges). So in the end using the same CRSs seems essential.
> 
> John
> 
> On Oct 7, 2014, at 13:07, Aleksandar Jelenak via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> 
>> On 10/3/14, 3:53 PM, "ESIP Documentation LIst"
>> <esip-documentation at lists.esipfed.org> wrote:
>>> 1) Is the way it uses geospatial_vertical_units OK for specifying
>>> vertical CRSs other than the default?
>> 
>> Vertical unit is not the same kind of information as vertical CRS. Thus I
>> propose to have a new attribute, geospatial_vertical_srid, for vertical
>> CRS. The whole issue of coordinate reference systems was left out from the
>> previous ACDD versions so a new attribute here allows for a fresh new
>> start. Allowing CRS codes in geospatial_vertical_units is not backward
>> compatible and that seems to be one of the guiding design principles for
>> this ACDD version.
>> 
>> Note also that the current definition of geospatial_vertical_units
>> mentions a nonexistent attribute geospatial_bounding_box.
>> 
>>> If not, is it a problem that the geospatial_*_min/max attributes may be
>>> different than the ones in the geospatial_bounds?
>> 
>> Different in what way? The geospatial_*_min/max attributes specify a
>> bounding box; the geospatial_bounds attribute enables much more precise
>> definition of the data's discovery geospatial extent and the values are to
>> be expected to be different. If using both, ACDD should recommended that
>> the extent in the geospatial_bounds be fully enclosed in the bounding box.
>> 
>> 	-Aleksandar
>> 
>> _______________________________________________
>> Esip-documentation mailing list
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141009/70fd3eb4/attachment.html>