[Esip-documentation] Request for ACDD global attributes for geospatial data resolution

Mon Aug 6 14:41:19 EDT 2018

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_Minu
>> tes_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      (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/20180806/7d869f26/attachment.html>