[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes
Jim Biard
jbiard at cicsnc.org
Fri Feb 27 09:57:11 EST 2015
Nan,
I'd think you should feel free to omit them if there isn't a reasonably
constant value that you can calculate for your grid, and definitely omit
them if you don't have a grid.
Grace and peace,
Jim
On 2/26/15 2:50 PM, Nan Galbraith via Esip-documentation wrote:
> I agree with this, with the caveat that we really should add some
> guidance
> for data sets that are not regularly spaced. This includes data on
> distance-
> based grids, where geospatial_lon_units are NOT the same as the units
> of the grid, and data that is not uniformly spaced on a vertical axis.
>
> For those of us who have these types of data, should we omit the
> _resolution
> attributes, provide a mean value, or ... give up?
>
> Thanks -
> Nan
>
>
> On 2/26/15 2:05 PM, Armstrong, Edward M (398G) via Esip-documentation
> wrote:
>> I second this recommendation. This is the way our GHRSST GDS2
>> granules are using ACDD attributes.
>>
>> On Feb 25, 2015, at 1:02 PM, David Neufeld - NOAA Affiliate via
>> Esip-documentation <esip-documentation at lists.esipfed.org
>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>
>>> Hi All,
>>>
>>> I recommend the examples for all resolutions be updated to drop
>>> embedded units, because the resolution will always refer to units of
>>> the axis.
>>>
>>> In other words the units are already described by the following
>>> attributes: geospatial_lat_units, geospatial_lon_units,
>>> geospatial_vertical_units.
>>>
>>> Duplicating units as an embedded value might minimally result in
>>> inconsistencies in the documentation.
>>>
>>> The description could be revised along the lines of:
>>> From version 1.3 - Information about the targeted vertical spacing
>>> of points. Example: '25 meters'
>>> To version 1.3.1 - Information about the targeted vertical spacing
>>> of points, units are referenced by the global attribute
>>> geospatial_vertical_units. Example: '25'
>>>
>>> Dave
>>>
>>> On Wed, Feb 25, 2015 at 11:51 AM, John Graybeal via
>>> Esip-documentation <esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>
>>> Thanks for bringing this to our attention, Aaron.
>>>
>>> Clearly this discrepancy was caused in our attempt to resolve
>>> existing ambiguity. (I for one assumed those mappings were
>>> semantic, not literal; and I didn't see any information that
>>> implied anything about the *format* of that field. There was
>>> also no guarantee that the units were specified, so that left
>>> the naked number essentially undefined.) I'm truly sorry for
>>> the trouble it's causing.
>>>
>>> Knowing now that there is a pre-existing practice means we have
>>> a dilemma. I'm not sure how heavily 1.3 has been implemented so
>>> far, but Bob implies at least one implementation, and you're
>>> seeing files with the problem. it seems to me there are two
>>> options at this point, and I'm not sure either by itself is
>>> entirely sufficient:
>>>
>>> 1) Modify the translation software (and others?) to allow for
>>> the possibility of different units in version 1.3. (Presumably
>>> the hack way is to just parse the number assuming it is in the
>>> expected units, and issue an error if that seems to not be the
>>> case; the ideal way would be to modify the number into the
>>> desired units.)
>>>
>>> 2) Modify the specification for each resolution axis to require
>>> that resolutions be specified in the units of the corresponding
>>> axis, which must be defined. This would mean a bump to 1.4, and
>>> some modification for existing 1.3 users.
>>>
>>> I propose we continue the discussion via email to see what the
>>> documentation cluster makes of this, and probably make it an
>>> agenda item at the next meeting. (Which is nominally tomorrow,
>>> though it isn't posted on the site at the moment. Maybe just a
>>> first reading of the issue tomorrow.) Any chance you could join
>>> us at 11 AM?
>>>
>>> John
>>>
>>> On Feb 25, 2015, at 09:32, Aaron Sweeney via Esip-documentation
>>> <esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>
>>>> Hi, Bob et al.,
>>>>
>>>> I believe that these resolutions are currently mapped to
>>>> ISO 19115-2 gco:Measures
>>>> <https://geo-ide.noaa.gov/wiki/index.php?title=Measure>, as in:
>>>>
>>>> geospatial_lat_resolution -->
>>>> <gco:Measure
>>>> uom="[geospatial_lat_unit]">[geospatial_lat_resolution]</gco:Measure>
>>>>
>>>> geospatial_lon_resolution -->
>>>> <gco:Measure
>>>> uom="[geospatial_lon_unit]">[geospatial_lon_resolution]</gco:Measure>
>>>>
>>>> geospatial_vertical_resolution -->
>>>> <gco:Measure
>>>> uom="[geospatial_vertical_unit">[geospatial_vertical_resolution]</gco:Measure>
>>>>
>>>> The GEO-IDE wiki page on gco:Measure (link above) indicates
>>>> that the value should be an "XML Schema double."
>>>>
>>>> Also, the earlier ACDD-1.1 documentation includes the ISO
>>>> 19115-2 path as:
>>>> /gmi:MI_Metadata/gmd:spatialRepresentationInfo/gmd:MD_Georectified/gmd:axisDimensionProperties/gmd:MD_Dimension/gmd:resolution/gco:Measure
>>>>
>>>> Cordially,
>>>> Aaron
>>>>
>>>> On 02/25/2015 10:17 AM, Bob Simons - NOAA Federal wrote:
>>>>> Is that an error in ACDD or in ncISO? (I don't know. I think it is
>>>>> debatable.) It is probably easier to change ncISO than to change ACDD
>>>>> (at least until the next version which is probably far off) and all
>>>>> datasets which follow the recommendations of the ACDD documentation.
>>>>>
>>>>> On Wed, Feb 25, 2015 at 9:11 AM, Aaron Sweeney via Esip-documentation
>>>>> <esip-documentation at lists.esipfed.org> <mailto:esip-documentation at lists.esipfed.org> wrote:
>>>>>> Hi, folks,
>>>>>>
>>>>>> I want to bring to your attention a problem with the ACDD-1.3
>>>>>> documentation that is leading to the creation of invalid ISO 19115-2
>>>>>> metadata records.
>>>>>>
>>>>>> Specifically, I am referring to the Descriptions of the following
>>>>>> Suggested global attributes: geospatial_lat_resolution,
>>>>>> geospatial_lon_resolution, and geospatial_vertical_resolution. For
>>>>>> reference and clarity, I've included these attributes (as well as their
>>>>>> related units attributes) and their descriptions from the ACDD-1.3
>>>>>> documentation below this message.
>>>>>>
>>>>>> There are two problems with the Description of these "resolutions."
>>>>>> The first is the recommendation to include both a numerical value and unit.
>>>>>> The ncISO tool expects these resolutions to be numeric only. This leads to
>>>>>> the creation of invalid ISO 19115-2 records. The second problem is that the
>>>>>> Description does not require the unit of resolution to be the same as the
>>>>>> corresponding "geospatial_[lat|lon|vertical]_unit."
>>>>>>
>>>>>> I would advocate that the Description of resolution explicitly state
>>>>>> that a numeric value is expected and that the value be expressed in the same
>>>>>> unit as specified in the corresponding "geospatial_[lat|lon|vertical]_unit"
>>>>>> attribute.
>>>>>>
>>>>>> Cordially,
>>>>>> Aaron
>>>>>>
>>>>>> ----relevant ACDD-1.3 documentation follows----
>>>>>>
>>>>>> geospatial_lat_units: Units for the latitude axis described in
>>>>>> "geospatial_lat_min" and "geospatial_lat_max" attributes. These are presumed
>>>>>> to be "degree_north"; other options from udunits may be specified instead.
>>>>>> geospatial_lat_resolution: Information about the targeted spacing of points
>>>>>> in latitude. Recommend describing resolution as a number value followed by
>>>>>> the units. Examples: '100 meters', '0.1 degree'
>>>>>> geospatial_lon_units: Units for the longitude axis described in
>>>>>> "geospatial_lon_min" and "geospatial_lon_max" attributes. These are presumed
>>>>>> to be "degree_east"; other options from udunits may be specified instead.
>>>>>> geospatial_lon_resolution: Information about the targeted spacing of points
>>>>>> in longitude. Recommend describing resolution as a number value followed by
>>>>>> units. Examples: '100 meters', '0.1 degree'
>>>>>> geospatial_vertical_units: Units for the vertical axis described in
>>>>>> "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The
>>>>>> default is EPSG:4979 (height above the ellipsoid, in meters); other vertical
>>>>>> coordinate reference systems may be specified. Note that the common
>>>>>> oceanographic practice of using pressure for a vertical coordinate, while
>>>>>> not strictly a depth, can be specified using the unit bar. Examples:
>>>>>> 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831'
>>>>>> (instantaneous depth below sea level).
>>>>>> geospatial_vertical_resolution: Information about the targeted vertical
>>>>>> spacing of points. Example: '25 meters'
>>>>>>
>
>
> --
> *******************************************************
> * Nan Galbraith Information Systems Specialist *
> * Upper Ocean Processes Group Mail Stop 29 *
> * Woods Hole Oceanographic Institution *
> * Woods Hole, MA 02543 (508) 289-2444 *
> *******************************************************
>
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150227/732ad2be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efiaigjc.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150227/732ad2be/attachment-0001.png>
More information about the Esip-documentation
mailing list