[Esip-documentation] Request for ACDD global attributes for geospatial data resolution
John Graybeal
jbgraybeal at mindspring.com
Sun Sep 16 19:25:33 EDT 2018
> On Aug 9, 2018, at 10:08, Nan Galbraith via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
>
> 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.
This is exactly what I meant when I floated the idea of agile approaches. I don’t think encouraging what Nan’s team did is 'looking for trouble', nor is it 'defining a new standard’ all by itself. But yes, it definitely represents a different vision for what makes a useful standard. Even if this represents a fork in the standard's direction (as Nan described it), I think it reflects important information about what works and doesn’t work for some members of the community. If that creates momentum for a new specification, it would simply suggest the world needs more than one standard for this particular type of data.
I would like to see alternate approaches such as the one Nan describes documented and explained as part of the ACDD web site and history, so that more members of the community can understand how the ACDD standard will work for them, and can find each other if they share common problems. I think that’s a more open way forward, it creates opportunity for new directions and collaborations. (I feel comfortable saying this as the co-chair of the previous effort, when I found two things equally frustrating, our inability to set a new direction that many of us wanted, *and* our inability to find consensus on the final agreement. But the changes we made still brought value, and I’d like to see more needs captured in the dialog going forward.)
Regarding members of the ACDD working group, if I recall discussions at the time correctly, the adoption of ACDD by the ESIP Documentation cluster was understood to mean the people participating in the Documentation cluster had the ball on requests for changes to ACDD. To the extent that membership changes over time, it may be necessary for more experts to join the documentation cluster, or for some other group to offer to adopt the specification. But I claim that the Documentation cluster chairs inherit the responsibility to lead the discussion of how to proceed, if/when requests for ACDD changes are made.
John
---------------------------------------
John Graybeal
jbgraybeal at mindspring.com
650-450-1853
skype: graybealski
linkedin: http://www.linkedin.com/in/johngraybeal/
> On Aug 9, 2018, at 10:08, Nan Galbraith via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
>
> 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 *
> *******************************************************
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> https://lists.esipfed.org/mailman/listinfo/esip-documentation
More information about the Esip-documentation
mailing list