[Esip-documentation] ACDD-1.3 documentation change request: Descriptions of "resolution" attributes
John Graybeal
jbgraybeal at mindspring.com
Wed Feb 25 19:13:03 EST 2015
On Feb 25, 2015, at 12:29, Aaron Sweeney <aaron.sweeney at noaa.gov> wrote:
> 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"?
Short answer: For historical reasons (the earlier ACDD versions used 'resolution', and as Bob said, changing names is tough). Going back, this was the term used by ISO, and it is (in this context) a description of the grid, rather than the measurements. While I totally agree with you on the word choice, ISO has a lot of international participants, and (judging from their code lists) may see extensive arguments about word selections as futile.
On Feb 25, 2015, at 13:07, Bob Simons - NOAA Federal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> That's why we try very hard not to make changes to successive versions of ACDD (and other standards) that conflict with previous versions.
To be fair, we had long exchanges about this when working on ACDD 1.3. A few of us believe strongly that a new version might need to break practices in a previous version, and that this does not represent a conflict (because no one *has* to use the new version). In the case of ACDD 1.3, we conceded the point, ironically enough because this argument lost the day:
> Software (like ncISO, THREDDS, ERDDAP) is written to work according to the standard, not the other way around
For ACDD 1.3, the argument was put forward that a lot of work went into existing software and data sets, and we shouldn't have to make people change their programs and their data to match the new standard. Of course they wouldn't have to change their data (existing data could still follow 1.1), but we still didn't want to make this update break existing software. (Although, arguably it does.)
On Feb 25, 2015, at 13:02, David Neufeld - NOAA Affiliate <david.neufeld at noaa.gov> wrote:
> the resolution will always refer to units of the axis.
Thanks for weighing in David. Your rewording satisfies one issue, but leaves a question.
Referencing the line above: I can't find this constraint declared anywhere previously. Is there a specific basis for it? (Perhaps that the name of the attribute implies the units have to be georectified?) Otherwise I would expect to support equidistant units also, since that's the organization of many observing grids.
John
On Feb 25, 2015, at 13:02, David Neufeld - NOAA Affiliate <david.neufeld at noaa.gov> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-documentation/attachments/20150225/95916270/attachment-0001.html>
More information about the Esip-documentation
mailing list