[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes
Nan Galbraith
ngalbraith at whoi.edu
Mon Mar 2 15:20:29 EST 2015
Thanks, that's what I'll do. I'll pass this along to the OceanSITES team
and add it to our manual.
Nan
On 2/27/15 9:57 AM, Jim Biard via Esip-documentation wrote:
> 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 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150302/8ea2a4ca/attachment-0001.html>
More information about the Esip-documentation
mailing list