[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes

Wed Feb 25 16:07:45 EST 2015

Aaron, please understand that ACDD, like CF, is a standard. Successive
versions of the standard are hammered out by seemingly endless discussions
and numerous votes (with the hope of reaching consensus) by people in the
community. Once a version of a standard is ratified (as ACDD 1.3 is), you
should treat it as if that version were written in stone. Software (like
ncISO, THREDDS, ERDDAP) is written to work according to the standard, not
the other way around (unless it is something new that is being added to the
standard). And if you don't like an attribute's name, (to be blunt) tough.
It is what it is. You could have lobbied for some other name before the
attribute first made it into ACDD. But now that it is in ACDD, please don't
advocate changing it just because you think a slightly different name is
more appropriate. Lots of software and thousands of datasets have been
written to follow the ACDD standard. They shouldn't have to change just
because you think a slightly different name is more appropriate. That's why
we try hard to get standards right the first time. That's why we try very
hard not to make changes to successive versions of ACDD (and other
standards) that conflict with previous versions.

On Wed, Feb 25, 2015 at 12:29 PM, Aaron Sweeney via Esip-documentation <
esip-documentation at lists.esipfed.org> wrote:

>  Hi, John,
>
>      Why are these attributes not called
> "geospatial_[lat|lon|vertical]_spacing", rather than
> "geospatial_[lat|lon|vertical]_resolution", if, in fact, the intention, as
> indicated in their Descriptions, is to capture the "targeted spacing of
> points"?
>
>      My first inclination, upon reading the name of the attribute
> "geospatial_[lat|lon|vertical]_resolution", was to interpret it to mean
> "how well the numerical value of [lat|lon|vertical] is resolved."
>
> Cordially,
> Aaron
>
>
>
>
> On 02/25/2015 01:19 PM, John Graybeal via Esip-documentation wrote:
>
> I am trying to find a good ncISO rep to be a part of this discussion --
> with luck David Neufeld will jump in soon, or people can suggest another
> rep, perhaps from Unidata?
>
>  Not sure yet if we're having a call tomorrow, for now I am assuming we
> are.
>
>  I'm not sure that many current users are using this value the way it is
> documented: "Information about the targeted spacing of points". That does
> not mean either the accuracy or precision of the value, but the (intended)
> distance between points in a grid of values -- but often these values
> appear in data sets for single fixed stations, which seems invalid.
>
>  And as Jim B points out (thank you), the original ISO mapping assumes
> the grid sizes are georectified -- but some/many grids in earth science are
> laid out in non-angular constant steps (meters). I assumed we want to
> support those cases, and no one found fault with the examples -- but maybe
> they are flawed, if georectified is a constraint. Alternatively, units of
> meters (or plain, non-geo degree) could be mapped to non-georectified ISO
> grid resolution terms.
>
>  John
>
>  On Feb 25, 2015, at 10:59, Jim Biard via Esip-documentation <
> esip-documentation at lists.esipfed.org> 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> <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'
>
>
>
> --
> Aaron D. Sweeney
> Water Level Data Manager
>
> Cooperative Institute for Research in Environmental Sciences (CIRES)
> University of Colorado at Boulder
> and
> NOAA National Geophysical Data Center
> Marine Geology and Geophysics Division
> 325 Broadway, E/GC3
> Boulder, CO 80305-3328
>
> Phone: 303-497-4797, Fax: 303-497-6513
>
> DISCLAIMER: The contents of this message are mine personally and do not
> necessarily reflect any position of NOAA.
>
>
> _______________________________________________
> Esip-documentation mailing listEsip-documentation at lists.esipfed.orghttp://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>
> --
> Aaron D. Sweeney
> Water Level Data Manager
>
> Cooperative Institute for Research in Environmental Sciences (CIRES)
> University of Colorado at Boulder
> and
> NOAA National Geophysical Data Center
> Marine Geology and Geophysics Division
> 325 Broadway, E/GC3
> Boulder, CO 80305-3328
>
> Phone: 303-497-4797, Fax: 303-497-6513
>
> DISCLAIMER: The contents of this message are mine personally and do not necessarily reflect any position of NOAA.
>
>
>
> _______________________________________________
> Esip-documentation mailing listEsip-documentation at lists.esipfed.orghttp://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>
> --
>       <igjdgbcb.png> <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
>
>
>
>  _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>
>
>
> _______________________________________________
> Esip-documentation mailing listEsip-documentation at lists.esipfed.orghttp://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>
> --
> Aaron D. Sweeney
> Water Level Data Manager
>
> Cooperative Institute for Research in Environmental Sciences (CIRES)
> University of Colorado at Boulder
> and
> NOAA National Geophysical Data Center
> Marine Geology and Geophysics Division
> 325 Broadway, E/GC3
> Boulder, CO 80305-3328
>
> Phone: 303-497-4797, Fax: 303-497-6513
>
> DISCLAIMER: The contents of this message are mine personally and do not necessarily reflect any position of NOAA.
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>
>

-- 
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone: (831)333-9878            (New!)
Fax:   (831)648-8440
Email: bob.simons at noaa.gov

The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150225/4927a0d4/attachment-0001.html>