[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes
Nan Galbraith
ngalbraith at whoi.edu
Wed Feb 25 15:16:21 EST 2015
Interesting, point, Jim. Is the particular problem with
geospatial_lon_resolution
attributes only for grids based on distance, where the
geospatial_lon/lon_min/max
are (naturally) expressed in degrees? Because it's consistent for
lat/lon grids
to express geospatial extents *and* resolutions in degrees.
The resolution will almost always be approximate - this is even more true
for the vertical axis for in situ data sets, where instruments are spaced
very differently in some depth areas. All we can ask this attribute to
convey
is an average - does this dataset represent a 10 degree grid, or something
more detailed - or, are there instruments only at the top and bottom of the
mooring, or spaced along the line?
For our mooring data, all we can only hope for from this attribute is to
not
misrepresent the contents of the data set; using the center point, we might
say the geospatial_vertical_resolution is 100 meters, where it really varies
from 1m near the surface to maybe 2500 between the bottom 2 instruments.
I suppose the same could be done for distance-based grid data.
I also want to point out that the attribute time_coverage_resolution is a
string, so it seems somewhat consistent, to me, to have all the resolutions
expressed this way.
Cheers - Nan
On 2/25/15 1:59 PM, Jim Biard via Esip-documentation wrote:
> Hi.
>
> I checked this as well, and there should clearly be both a
> floating-point number and a units for a resolution entry. As Aaron
> showed in his email, the units go in a 'uom' attribute on the
> gco:Measure element, and the number is the value of the element. If
> ncISO isn't doing this, then that sure appears to be an ncISO bug.
>
> There is another issue, of a sort, that this points up. The
> geospatial_(lat/lon)_resolution attributes in the documentation Aaron
> listed allow for units that are nonsensical (to me, anyway), such as
> meters for a quantity that should be restricted to angular units. You
> can get away with it for latitude, but there is no way to create a
> longitude axis on a grid that has constant steps in non-angular units.
>
> Grace and peace,
>
> Jim
>
> On 2/25/15 12:32 PM, Aaron Sweeney via Esip-documentation 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> 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/20150225/1d63e55e/attachment-0001.html>
More information about the Esip-documentation
mailing list