[Esip-documentation] Request for ACDD global attributes for geospatial data resolution
Nan Galbraith
ngalbraith at whoi.edu
Thu Aug 9 13:08:34 EDT 2018
Hi Mary Jo -
I agree with Bob, to some extent; when the last ACDD rev included
changes that
my group couldn't support, we 'froze' our implementation at a previous
version,
and continued to add 'our own' fields to our files, using the syntax we
preferred.
On the other hand, it would be great if you provided comments on the
ACDD discussion
pages for any additional metadata that you need that's relevant to ACDD.
There's no
reason the group wouldn't consider the approach you use, if and when new
fields are
added to ACDD, though your syntax might not be adopted.
By the way, I don't think there are any 'official' members of the ACDD
working
group.
Speaking for myself, I think resolution is a poor choice of terms
(although we do
use it for time_coverage, since it's part of ACDD) because it can mean
either
density of coverage OR be a measure of uncertainty. It's part of OGC,
and it is
used to mean exactly what you need - interval. Apparently it's also used
in ISO,
however I can find it only for georectified (regular) grids, per
wiki.esipfed.org/index.php/ISO_Spatial_Representation.
The syntax for the value of time_coverage_resolution is taken from an
ISO standard (e.g.
"P1.00M") , but I'm not sure if there's a preferred method of stating
the spatial interval
between points. Your geospatial_x_resolution = "3125.00 meters" ; would
probably
be fine.
Regards -
Nan Galbraith
On 8/7/18 11:19 AM, Bob Simons - NOAA Federal via Esip-documentation wrote:
> I love agile software development. But in that situation, the group
> doing the development is in charge of everything and presumably in
> touch will all the stake holders.
>
> The problem with an agile approach (as outlined here) for standards is
> that the proposal isn't getting the full range of comments (or any
> comments) from the group that will be approving the changes. Most of
> the proposals in the last round of ACDD changes were modified in a
> large or small way after comments by the group. With the described
> "agile" approach, one active person could (to some extent) run away
> with the standard. The system of group discussions and consensus is
> admittedly slow and difficult, but it yields a result we all accept.
>
> As always, anyone is free to add any metadata they want to their
> datasets. But allowing people to essentially write their own standard
> (or have expectations that they are) seems like looking for trouble.
>
>
> On Mon, Aug 6, 2018 at 10:22 PM, John Graybeal
> <jbgraybeal at mindspring.com <mailto:jbgraybeal at mindspring.com>> wrote:
>
> Mary Jo and everyone,
>
> Yes, your approach can be reasonably expected to be tracked.
>
> for these interim requests and proposals, I would encourage the
> maintenance of ad-hoc pages on the wiki, perhaps all with a common
> category, and referenced in email to this documentation list.
>
> At a minimum, that creates is a list where people can research to
> see what has been suggested. And in the meantime, people can see
> how others are solving similar problems, which itself encourages
> common usage patterns.
>
> I will say, based on the sometimes-painful past experience, that
> those who long for a more dynamic and perhaps more radical
> approach to updating standards like this, might want to initiate
> their own agile process, to see if it catches on. Such a process
> could be along the lines of what you are proposing, with comments
> made to the wiki page for consideration by the group. If/when the
> main standard got updated, it could sift through those for things
> it is willing to adopt, and ignore those it considers
> counterproductive. But the agile adopters could choose the new
> path if they preferred.
>
> While I’m bouncing around ideas for a standards effort I don’t
> have time to support right now (sorry!), I think a github
> repository should be considered when there is time. That would be
> a far easier way to collect requests in one place, without
> requiring list parsing later on. (I just spent an hour
> list-parsing a single thread in CF. Github sure would have been nice!)
>
> john
> ---------------------------------------
> John Graybeal
> jbgraybeal at mindspring.com <mailto:jbgraybeal at mindspring.com>
>
>
>> On Aug 6, 2018, at 11:56, Mary Jo Brodzik via Esip-documentation
>> <esip-documentation at lists.esipfed.org
>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>
>>
>> Bob, thanks for the background, it's helpful to know.
>>
>> Would there be any value in my editing that wiki page with
>> proposed term definitions? Would it be reasonable to expect that
>> anyone working on the next version of ACDD would even know that
>> it's there?
>>
>> Mary Jo
>>
>> On Mon, 6 Aug 2018, Bob Simons - NOAA Federal wrote:
>>
>>> Date: Mon, 6 Aug 2018 11:41:19 -0700
>>> From: Bob Simons - NOAA Federal <bob.simons at noaa.gov
>>> <mailto:bob.simons at noaa.gov>>
>>> To: Mary Jo Brodzik <brodzik at nsidc.org <mailto:brodzik at nsidc.org>>
>>> Cc: ESIP Documentation <esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>>
>>> Subject: Re: [Esip-documentation] Request for ACDD global
>>> attributes for
>>> geospatial data resolution
>>> Just speaking for myself (not officially for the group):
>>> In the past, this group has periodically worked on a new version
>>> of ACDD. In
>>> between those efforts, we don't work on the next version, partly
>>> because
>>> creating a new version takes a lot of time and effort from a lot
>>> of people.
>>> Currently, we are not working on the next version and have no
>>> specific
>>> timetable for doing so. I believe that someone is collecting
>>> topics to be
>>> discussed when another round starts up.
>>> Thank you for your attribute suggestion. We will consider it
>>> when we work on
>>> the next version of ACDD. (It looks reasonable to me.) But you
>>> shouldn't
>>> expect/hope that it will be adopted and included in a ratified
>>> version of
>>> ACDD any time soon.
>>> Note that both CF and ACDD metadata standards allow for other
>>> attributes to
>>> be included in a dataset's metadata. So, from the CF and ACDD
>>> standpoint, it
>>> is fine for you to include these attributes in your dataset.
>>> I hope that helps.
>>> Best wishes.
>>> On Mon, Aug 6, 2018 at 8:53 AM, Mary Jo Brodzik via
>>> Esip-documentation
>>> <esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>
>>> Dear Esip-documentation members,
>>>
>>> I am trying to follow-up on any action that may have been taken
>>> regarding my request for geospatial data resolution attributes.
>>> See my message below for potential definitions for the new
>>> attributes you discussed.
>>>
>>> I see the page you created has not been updated. Has any other
>>> action been take to move this along? I know this is a
>>> volunteer
>>> community, I would be happy to add my definitions to the
>>> page if
>>> that would move things along, I didn't do it at the time
>>> because
>>> I wasn't sure what protocol would be if I'm not an official
>>> member of your working group. But after that, I wouldn't know
>>> what the next steps would need to be.
>>>
>>> If some action has been taken and I just don't see it on-line,
>>> please let me know where I can find it.
>>>
>>> Thank you again for the thoughtful consideration you have given
>>> to my request.
>>>
>>> Mary Jo
>>>
>>> On Thu, 26 Jan 2017, Mary Jo Brodzik via Esip-documentation
>>> wrote:
>>>
>>> Date: Thu, 26 Jan 2017 15:32:42 -0700 (MST)
>>> From: Mary Jo Brodzik via Esip-documentation
>>> <esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>>
>>> Reply-To: Mary Jo Brodzik <brodzik at nsidc.org
>>> <mailto:brodzik at nsidc.org>>
>>> To: esip-documentation at lists.esipfed.org
>>> <mailto:esip-documentation at lists.esipfed.org>
>>> Subject: [Esip-documentation] Request for ACDD
>>> global attributes for
>>> geospatial data resolution
>>>
>>> Dear Esip-documentation members,
>>>
>>> Thank you for the discussion of my request at
>>> Monday's telecon, I apologize for missing the
>>> telecon. I just listened to the youtube recording
>>> of it, which was useful.
>>>
>>> In the time since my request, I had to start
>>> producing data, so I took the existing
>>> geospatial_lat/lon_resolution practices as my model.
>>>
>>> I actually created my files with the attributes you
>>> suggested at the meeting, e.g.:
>>>
>>> geospatial_x_resolution = "3125.00 meters" ;
>>> geospatial_y_resolution = "3125.00 meters" ;
>>>
>>> It did not occur to me to populate and set
>>> geospatial_x_min/max or geospatial_y_min/max; I
>>> reasoned that these were covered by the x/y
>>> dimension variable bounds. However, in the spirit
>>> of giving the user of my data set some intelligible
>>> information in the global attributes, I also
>>> populated the lat/lon bounds like this:
>>>
>>> geospatial_bounds_crs = "EPSG:6931"
>>> geospatial_lat_min = 0.
>>> geospatial_lat_max = 90.
>>> geospatial_lon_min = -180.
>>> geospatial_lon_max = 180.
>>>
>>> I realized that this mixed mensurations a bit, since
>>> I did not populate attributes for (nonsensical, in
>>> my case) geospatial_lat/lon_resolution.
>>>
>>> I think that your proposed new attributes
>>> geospatial_x/y_resolution/min/max would definitely
>>> meet my use case.
>>>
>>> As for definitions for your minutes page at:
>>>
>>> http://wiki.esipfed.org/index.php/Documentation_Cluster_Minutes_2017-01-23
>>> <http://wiki.esipfed.org/index.php/Documentation_Cluster_Minutes_2017-01-23>
>>>
>>> may I suggest the following definitions for a
>>> beginning point (modified from the analogous ACDD
>>> lat/lon attributes):
>>>
>>> geospatial_x_min: Describes leftmost limit for
>>> projected data x dimension in a left-handed
>>> Cartesian plane; specifies the lowest x dimension
>>> value covered by the dataset.
>>>
>>> geospatial_x_max: (replace leftmost/lowest with
>>> rightmost/highest)
>>>
>>> geospatial_y_min: Describes bottommost limit for
>>> projected data y dimension in a left-handed
>>> Cartesian plane; specifies the lowest y dimension
>>> value covered by the dataset.
>>>
>>> geospatial_y_max: (replace bottommost/lowest with
>>> uppermost/highest)
>>>
>>> geospatial_x_resolution: Information about the
>>> targeted spacing of projected data points in x
>>> dimension. Recommend describing resolution as a
>>> number value followed by the units. Example:
>>> '3125.00 meters'
>>>
>>> geospatial_y_resolution: (replace x with y)
>>>
>>> Regarding your question about how similar the
>>> projected data case is to the swath data case: I
>>> would say that a rectangular array of projected data
>>> is different from swath data, because the spacing
>>> between adjacent pixels across the array is fixed in
>>> map coordinates, e.g. from one pixel to the next in
>>> my data, the spacing is always 3.125 km in the map
>>> coordinates (the projected plane). Depending on the
>>> projection, the correspond location distances can
>>> and will be different on the sphere, and in terms of
>>> latitute or longitude, but in map coordinates it is
>>> a single number and does have meaning for a user.
>>> I'm using the term "map coordinates" as in the
>>> left-handed Cartesian plane in the second figure of
>>> this document:
>>> https://nsidc.org/support/41976964-Points-Pixels-Grids-and-Cells-A-Mapping-
>>> <https://nsidc.org/support/41976964-Points-Pixels-Grids-and-Cells-A-Mapping->
>>> and-Gridding-Primer-
>>>
>>> Thank you for your time and consideration, I will be
>>> happy to answer any other questions about my use
>>> case if they arise.
>>>
>>> Mary Jo
>>>
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Mary Jo Brodzik, Senior Associate Scientist,
>>> 303-492-8263
>>> NSIDC/CIRES, Univ. of Colo. at Boulder, 449 UCB,
>>> Boulder, CO 80309-0449
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> "We cannot solve our problems with the same thinking
>>> we used
>>> when we created them." --Albert Einstein
>>> _______________________________________________
>>> Esip-documentation mailing list
>>> Esip-documentation at lists.esipfed.org
>>> <mailto:Esip-documentation at lists.esipfed.org>
>>> http://lists.deltaforce.net/mailman/listinfo/esip-documentation
>>> <http://lists.deltaforce.net/mailman/listinfo/esip-documentation>
>>>
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Mary Jo Brodzik, Senior Associate Scientist, 303-492-8263
>>> NSIDC/CIRES, Univ. of Colo. at Boulder, 449 UCB, Boulder, CO
>>> 80309-0449
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> _______________________________________________
>>> Esip-documentation mailing list
>>> Esip-documentation at lists.esipfed.org
>>> <mailto:Esip-documentation at lists.esipfed.org>
>>> https://lists.esipfed.org/mailman/listinfo/esip-documentation
>>> <https://lists.esipfed.org/mailman/listinfo/esip-documentation>
>>> --
>>> Sincerely,
>>> Bob Simons
>>> IT Specialist
>>> Environmental Research Division
>>> NOAA Southwest Fisheries Science Center
>>> 99 Pacific St., Suite 255A
>>> <https://maps.google.com/?q=99+Pacific+St.,+Suite+255A++%28New%21%29+Monterey,+CA+93940&entry=gmail&source=g>
>>> (New!)
>>> <https://maps.google.com/?q=99+Pacific+St.,+Suite+255A++%28New%21%29+Monterey,+CA+93940&entry=gmail&source=g>
>>> Monterey, CA 93940
>>> <https://maps.google.com/?q=99+Pacific+St.,+Suite+255A++%28New%21%29+Monterey,+CA+93940&entry=gmail&source=g>
>>> (New!) Phone: (831)333-9878 (New!)Fax:
>>> (831)648-8440
>>> Email: bob.simons at noaa.gov <mailto:bob.simons at noaa.gov>
>>> The opinions in this message are mine personally and do not
>>> necessarily reflect any position of the U.S. Government
>>> or the National Oceanic and Atmospheric Administration.
>>> <>< <>< <>< <>< <>< <>< <>< <>< <><
>>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Mary Jo Brodzik, Senior Associate Scientist, 303-492-8263
>> NSIDC/CIRES, Univ. of Colo. at Boulder, 449 UCB, Boulder, CO
>> 80309-0449
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> "We cannot solve our problems with the same thinking we used
>> when we created them." --Albert
>> Einstein_______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> <mailto:Esip-documentation at lists.esipfed.org>
>> https://lists.esipfed.org/mailman/listinfo/esip-documentation
>> <https://lists.esipfed.org/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 <mailto:bob.simons at noaa.gov>
>
> The opinions in this message are mine personally and do
> not necessarily reflect any position of the U.S. Government
> or the National Oceanic and Atmospheric Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> https://lists.esipfed.org/mailman/listinfo/esip-documentation
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
More information about the Esip-documentation
mailing list