[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes
Nan Galbraith
ngalbraith at whoi.edu
Thu Feb 26 14:50:20 EST 2015
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 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150226/8a0e76fd/attachment.html>
More information about the Esip-documentation
mailing list