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

[John Graybeal via Esip-documentation]

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