[Esip-documentation] Let's get rid of spatial and temporal bounds in ACDD

[Nan Galbraith]

Like a lot of systems, we use the geo/temporal bounds on the
oceansites servers to maintain an inventory of our holdings and
help people find what they're looking for, without having to load
the coordinate variables from all the files in real time.

Since this is a pretty common need, it makes sense for ACDD
to provide a standard way to encode this info.

Maybe we should add some text about which attributes should be
considered fragile and under what conditions they need to be
recalculated or removed, but I'm not in favor of removing the
terms from ACDD.

As someone pointed out, almost all the fields in ACDD metadata
can be degraded by subsetting/aggregation - add keywords to the
list, as they can easily be wrong when only some variables are
exported.

- Nan


Quoting "Armstrong, Edward M (398M)" <Edward.M.Armstrong at jpl.nasa.gov>:

> I would rather keep the onus on tools developers to properly update  
> these attributes.  Our subsetting tools at the PO.DAAC do (L2  
> subsetting, not sure about LAS) do update.  The attributes  
> themselves have tremendous value before the subsetting stage.
>
> For one, they are very human readable. And for L2 data the elegantly  
> set the bounds?.something you have to be a little clever about if  
> you work with just coord variables.
>
>
> On Mar 7, 2014, at 10:19 AM, David Neufeld - NOAA Affiliate  
> <david.neufeld at noaa.gov<mailto:david.neufeld at noaa.gov>> wrote:
>
> Second!  I've seen this issue enough times to recognize that the  
> benefit of a human configured/readable attribute is outweighed by  
> the maintenance and generally error prone nature of this approach  
> (aka copy paste mistakes).
>
> -Dave
>
>
> On Fri, Mar 7, 2014 at 11:09 AM, Signell, Richard  
> <rsignell at usgs.gov<mailto:rsignell at usgs.gov>> wrote:
> Gang,
> I was just burned by gespatial and temporal bounds in ACDD again, and
> it took us a while to find, so I'm irritated enough to get up from my
> Friday afternoon office nap and write this message.  ;-)
>
> The problem is that as soon as someone subsets or aggregates data from
> netcdf or opendap datasets that use ACDD, the ACDD attributes in the
> resulting dataset are wrong.   Since we subset and aggregate data all
> the time, the ACDD metadata is often wrong.   The only way to correct
> this would be to ensure that *all* clients that subset or aggregate
> NetCDF or OpenDAP data modify the ACDD attributes in the output
> datasets.   Yeah, right! ;-)
>
> Since we already have CF compliant data, we have the information to
> calculate the bounds from the coordinate variables.  So the temporal
> and geospatial bounds can be accurately calculated by tools like
> ncISO, which generates ISO metadata.   And if we subset or aggregate
> the data and serve *that* up, ncISO will still generate the proper
> bounds.
>
> So I propose we stop saying that these properties at:
> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-1
> are "Recommended" and start saying "Not Recommended" for all
> attributes that involve coordinate variables:
>
> geospatial_bounds
> geospatial_lat_min
> geospatial_lat_max
> geospatial_lon_min
> geospatial_lon_max
> geospatial_vertical_min
> geospatial_vertical_max
> time_coverage_start
> time_coverage_stop
> time_coverage_duration
> time_coverage_resolution
>
> Do I have a second?   :-)
>
> -Rich
> --
> Dr. Richard P. Signell   (508) 457-2229<tel:%28508%29%20457-2229>
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org<mailto: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<mailto:Esip-documentation at lists.esipfed.org>
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
> -ed
>
> Ed Armstrong
> JPL Physical Oceanography DAAC
> 818 519-7607