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

Armstrong, Edward M (398M) Edward.M.Armstrong at jpl.nasa.gov
Wed Mar 12 18:03:17 EDT 2014


I think that is an excellent idea.

The output of the PO.DAAC HiTIDE subsetter that I mentioned in a previous email does exactly that and includes some useful information about the granule and the wrapped subsetting request via OPeNDAP. Below is a snapshot of some of the global attributes from  a subsetted AVHRR SST granule (look at the naiad_ attributes):

  :southernmost_latitude = -89.72987f; // float
  :northernmost_latitude = 89.80405f; // float
  :westernmost_longitude = -179.9997f; // float
  :easternmost_longitude = 179.99994f; // float
  :file_quality_index = 1S; // short
  :comment = "none";
  :naiad_download_date = "2014-03-10 21:25:47";
  :naiad_granule_url = "http://podaac-opendap.jpl.nasa.gov/opendap/allData/ghrsst/data/L2P/AVHRR19_G/NAVO/2013/358/20131224-AVHRR19_G-NAVO-L2P-SST_s0827_e1009-v01.nc.bz2";
  :naiad_constraint_expression = "lat[8000:1:9200][104:1:408],lon[8000:1:9200][104:1:408],time[0:1:0],sst_dtime[0:1:0][8000:1:9200][104:1:408],rejection_flag[0:1:0][8000:1:9200][104:1:408],SSES_bias_error[0:1:0][8000:1:9200][104:1:408],aod_dtime_from_sst[0:1:0][8000:1:9200][104:1:408],DT_analysis[0:1:0][8000:1:9200][104:1:408],brightness_temperature_11um[0:1:0][8000:1:9200][104:1:408],aerosol_optical_depth[0:1:0][8000:1:9200][104:1:408],sources_of_aod[0:1:0][8000:1:9200][104:1:408],confidence_flag[0:1:0][8000:1:9200][104:1:408],brightness_temperature_4um[0:1:0][8000:1:9200][104:1:408],SSES_standard_deviation_error[0:1:0][8000:1:9200][104:1:408],sea_surface_temperature[0:1:0][8000:1:9200][104:1:408],brightness_temperature_12um[0:1:0][8000:1:9200][104:1:408],proximity_confidence[0:1:0][8000:1:9200][104:1:408],satellite_zenith_angle[0:1:0][8000:1:9200][104:1:408]";
}

I did misspeak earlier when I indicated that the spatial bounds were also updated, in this case southernmost_latitude etc. They are the original (global) bounds.  I have requested to the developer that these bounds be updated for every subset request. Hopefully it will get in the next version.



On Mar 8, 2014, at 3:13 AM, Nan Galbraith <ngalbraith at whoi.edu> wrote:

> Hows about adding an attribute that contains the URL of the data
> file to which the bounds apply? If your aggregator/sub-setter
> has misled you by failing to update the bounds attribute, he's also
> provided you with the link to the data you actually wanted.
> 
> For programs that collect lots of data and don't molest it, this would
> let them continue to use the bounds atts; for programs that slice
> and dice, they'd be motivated to either update the fields dynamically
> or remove them.
> 
> Cheers - Nan
> 
> Is it really Friday? I'm at sea (yes, people still do that, sometimes)
> and I've lost all sense of time and place (no geospatial and temporal
> bounds information).
> 
> 
> 
> 
> On 3/7/14 6:47 PM, David Neufeld - NOAA Affiliate wrote:
>> 
>> Ok, since it's Friday and we are in rant mode, I'm going to have a little fun with this one...
>> 
>> Recommended Attribute Disclaimer:
>> 
>> Suggested text: "When using geospatial and temporal bounds information in your global attributes, please know that it introduces a likely source of error and that you are far better off reading these values from the data stored in the file.  If you do choose to use the attributes please also include a global checksum attribute that humans can look at to decide whether the file has changed since you originally recorded these values."
>> 
>> On Fri, Mar 7, 2014 at 2:02 PM, Nan Galbraith <ngalbraith at whoi.edu <mailto:ngalbraith at whoi.edu>> wrote:
>> 
>> 
>> 
>>    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.
>> 
>> 
> 
> 
> -- 
> *******************************************************
> * Nan Galbraith                        (508) 289-2444 *
> * Upper Ocean Processes Group            Mail Stop 29 *
> * Woods Hole Oceanographic Institution                *
> * Woods Hole, MA 02543                                *
> *******************************************************
> 
> 
> _______________________________________________
> Esip-documentation mailing list
> 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





More information about the Esip-documentation mailing list