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

Mike McCann mccann at mbari.org
Fri Mar 7 16:21:12 EST 2014


I treat any global metadata delivered by an aggregator or subsetter with suspicion.

I have also purposely not built aggregations that would be useful because of the default behavior of passing on the attributes (more that just the spatial temporal ones) that don't make sense for the aggregated data. 

-Mike

--
Mike McCann
Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: 831.775.1769  Fax: 831.775.1736 http://www.mbari.org

On Mar 7, 2014, at 1:02 PM, Nan Galbraith wrote:

> 
> 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
> 
> 
> 
> _______________________________________________
> 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/20140307/a44f8d3b/attachment-0001.html>


More information about the Esip-documentation mailing list