[Esip-documentation] Request for ACDD global attributes for geospatial data resolution
Bob Simons - NOAA Federal
bob.simons at noaa.gov
Tue Aug 7 11:19:47 EDT 2018
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>
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
>
>
> On Aug 6, 2018, at 11:56, Mary Jo Brodzik via Esip-documentation <
> 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>
> To: Mary Jo Brodzik <brodzik at nsidc.org>
> Cc: ESIP Documentation <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> 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>
> Reply-To: Mary Jo Brodzik <brodzik at nsidc.org>
> To: 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
>
> 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-
> 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
> 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
> 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++(New!)+Monterey,+CA+93940&entry=gmail&source=g>
> (New!)
> <https://maps.google.com/?q=99+Pacific+St.,+Suite+255A++(New!)+Monterey,+CA+93940&entry=gmail&source=g>
> Monterey, CA 93940
> <https://maps.google.com/?q=99+Pacific+St.,+Suite+255A++(New!)+Monterey,+CA+93940&entry=gmail&source=g>
> (New!) Phone: (831)333-9878 (New!)Fax:
> (831)648-8440
> Email: 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
> 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
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.
<>< <>< <>< <>< <>< <>< <>< <>< <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-documentation/attachments/20180807/fb030579/attachment-0001.html>
More information about the Esip-documentation
mailing list