Daniel,
My two thoughts were independent. I agree that parametric coordinates
are more abstract, and thus possibly more confusing, than linear
coordinates. But, as Randy pointed out in his reply, the relationship
between the angles and longitude and latitude are quite complex. The
abstraction of parametric functions and parameters avoids the problem of
making definitions that are so specific that they aren't good for
anything other than the one geostationary projection. I also am happy to
admit to having made a less-than-perfect first pass at a definition.
Grace and peace,
Jim
On 4/19/18 10:18 AM, Randy Horne wrote:
> Folks:
>
> RE: ? *Definition:*"x" indicates a vector component along the grid
> x-axis, when this is not true longitude, positive with increasing x.
> Angular projection coordinates are angular distances in the x- and
> y-directions on a plane onto which the surface of the Earth has been
> projected according to a map projection. The relationship between the
> angular projection coordinates and latitude and longitude is described
> by the grid_mapping.?
>
> specifically,
>
> "are angular distances in the x- and y-directions on a plane onto
> which the surface of the Earth has been projected?
>
> In the case of both the GOES-R and EUMETSAT, the?angular distances are
> projected onto an Earth ellipsoid, whose definition is?captured in the
> grid mapping.
>
> v/r
>
> randy
>
>
>
>> On Apr 19, 2018, at 10:06 AM, Daniel Lee <Daniel.Lee at eumetsat.int
>> <mailto:Daniel.Lee at eumetsat.int>> wrote:
>>
>> Hi Jim,
>> I for one find this more confusing than Ethan's definition, but maybe
>> it's because I'm too far gone in my discipline to see the scope for
>> misunderstanding.
>> That being said, if we're being that general my feeling says to me
>> that we may risk converging on a standard which isn't really
>> applicable to any more specific application. Currently there is
>> aproposal for CF-2 devoted specifically to swath data
>> <https://github.com/Unidata/EC-netCDF-CF/blob/master/swath/swath.adoc>,
>> and this has the potential to cover the need for a specific
>> geostationary projection as well. Maybe that would also be a good
>> path to take for other coordinate systems with non-linear
>> relationships between projection coordinates and coordinates of other
>> CRS - kind of general, but not overly abstract.
>> Cheers,
>> Daniel
>> *From:*CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu]*On
>> Behalf Of*Jim Biard
>> *Sent:*19 April 2018 15:32
>> *To:*cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>> *Subject:*Re: [CF-metadata] Fix Geostationary projection, including
>> proposal for two new standard names
>>
>> Hi.
>>
>> Here's a couple of thoughts.
>>
>> The definition that Ethan has proposed fails to note that the angles
>> are with respect to a normal to the projection surface at a point
>> along the normal. I guess the phrase "angular distance" implies this,
>> but my first read had me feeling confused about what was being
>> described. On checking, I see that this is a minimalist variation on
>> the projection_x/y_coordinate definitions. Do folks think that this
>> is clear enough as is?
>>
>> I know we tend not to follow this course, but I am wondering if we
>> might not be better served overall by taking a more generic approach
>> and defining parametric coordinates u and v (projection_u_coordinate
>> and projection_v_coordinate). The canonical units would be '1'
>> (unitless). The definition for parametric_u_coordinate would be
>> something like
>>
>> "u" indicates an independent variable, or parameter, associated
>> with an axis of a coordinate grid where this parameter is not a
>> linear distance in a projection coordinate system, a Cartesian
>> coordinate element, or a geographic latitude or longitude. The
>> geographic latitude and longitude of each point in the coordinate
>> grid are functions of the parameters associated with the grid
>> axes. The relationship between the parametric coordinates and
>> latitude and longitude is described by the grid_mapping.
>>
>> The geostationary projection is one use case covered by parametric
>> coordinates, and there are others. The native coordinates for most
>> all satellite swath data are parametric - mirror angle and time, for
>> example.
>>
>> Grace and peace,
>>
>> Jim
>>
>> On 4/19/18 5:06 AM, Daniel Lee wrote:
>>
>> Hi Ethan,
>> At first blush this looks pretty good. If we can agree on this in
>> a short-ish time frame, it might be possible for EUMETSAT to
>> publish data exclusively using these standard names - the planned
>> launch date for MTG I1 is late 2021. This sounds like it's very
>> far away, but in the space sector our planning horizons are a lot
>> longer, so there's already a lot of work being done on it right
>> now and at some point in the near future the specs will freeze.
>> Best regards,
>> Daniel
>> *From:*CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu]*On
>> Behalf Of*Ethan Davis
>> *Sent:*19 April 2018 05:40
>> *To:*CF metadata<cf-metadata at cgd.ucar.edu>
>> <mailto:cf-metadata at cgd.ucar.edu>
>> *Subject:*[CF-metadata] Fix Geostationary projection, including
>> proposal for two new standard names
>> Hi all,
>> Here's an initial proposal for fixing the geostationary
>> projection as we've been discussing.
>> Two new standard names:
>>
>> *Name:*projection_x_angular_coordinate
>> *Canonical units:*radian
>> *Definition:*"x" indicates a vector component along the grid
>> x-axis, when this is not true longitude, positive with
>> increasing x. Angular projection coordinates are angular
>> distances in the x- and y-directions on a plane onto which
>> the surface of the Earth has been projected according to a
>> map projection. The relationship between the angular
>> projection coordinates and latitude and longitude is
>> described by the grid_mapping.
>> *Name:*?projection_y_angular_coordinate
>> *Canonical units:*?radian
>> *Definition:*?"y" indicates a vector component along the grid
>> y-axis, when this is not true latitude, positive with
>> increasing y. Angular projection coordinates are angular
>> distances in the x- and y-directions on a plane onto which
>> the surface of the Earth has been projected according to a
>> map projection. The relationship between the angular
>> projection coordinates and latitude and longitude is
>> described by the grid_mapping.
>>
>> Replace the text of the current "Map coordinates:" section with
>>
>> The x (abscissa) and y (ordinate) projection coordinates are
>> identified by the `standard_name` attribute values
>> `projection_x_angular_coordinate` and
>> `projection_y_angular_coordinate` respectively. In the case
>> of this projection, the projection coordinates are directly
>> related to the scanning angle of the satellite instrument.
>>
>> Add a deprecation note below the current "Notes:"
>>
>> *Deprecation Note:*
>> The use of `projection_x_coordinate` and
>> `projection_y_coordinate` for this projection has been
>> deprecated.
>>
>> The initial definition of this projection used these standard
>> names to identify the projection coordinates even though
>> their canonical units (meters) do not mach those required for
>> this projection (radians).
>>
>> Perhaps we should include information on when the deprecated
>> feature was in effect:
>>
>> The initial definition for this projection was agreed on in
>> May 2012 though it was not in the CF document until 1.7 was
>> released in Sept 2017. It was corrected in ??? 2018.
>>
>> And do we also want to include information about large datasets
>> that use this deprecated technique:
>>
>> In that time, several satellite missions were developed and
>> launched that generate data that use this now deprecated
>> method including GOES-R (operational in Dec 2017), EUMETSAT
>> ???? ...
>>
>> That could alert people to the likelihood they (or any software
>> they develop) might run into data using this deprecated feature.
>> I'll move this to a Trac ticket (with an accompanying GitHub PR)
>> once we discuss a bit.
>> Cheers,
>> Ethan
>>
>> Any email message from EUMETSAT is sent in good faith but shall
>> neither be binding nor construed as constituting a commitment by
>> EUMETSAT, except where provided for in a written agreement or
>> contract or if explicitly stated in the email. Please note that
>> any views or opinions presented in this email are solely those of
>> the sender and do not necessarily represent those of EUMETSAT.
>> This message and any attachments are intended for the sole use of
>> the addressee(s) and may contain confidential and privileged
>> information. Any unauthorised use, disclosure, dissemination or
>> distribution (in whole or in part) of its contents is not
>> permitted. If you received this message in error, please notify
>> the sender and delete it from your system.
>>
>>
>>
>> _______________________________________________
>>
>> CF-metadata mailing list
>>
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>> --
>> *<~WRD000.jpg>* <http://www.cicsnc.org/>Visit us on
>> *Facebook* <http://www.facebook.com/cicsnc>
>>
>> *Jim Biard*
>> *Research Scholar*
>> *Cooperative Institute for Climate and Satellites NC*
>> <http://cicsnc.org/>
>> *North Carolina State University* <http://ncsu.edu/>
>> *NOAA National Centers for Environmental Information*
>> <http://ncdc.noaa.gov/>
>> /formerly NOAA?s National Climatic Data Center/
>> 151 Patton Ave, Asheville, NC 28801
>> e:jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>> o: +1 828 271 4900
>>
>> /Connect with us on Facebook forclimate
>> <https://www.facebook.com/NOAANCEIclimate>andocean and geophysics
>> <https://www.facebook.com/NOAANCEIoceangeo>information, and follow us
>> on Twitter at at NOAANCEIclimate
>> <https://twitter.com/NOAANCEIclimate>and at NOAANCEIocngeo
>> <https://twitter.com/NOAANCEIocngeo>./
>>
>>
>> Any email message from EUMETSAT is sent in good faith but shall
>> neither be binding nor construed as constituting a commitment by
>> EUMETSAT, except where provided for in a written agreement or
>> contract or if explicitly stated in the email. Please note that any
>> views or opinions presented in this email are solely those of the
>> sender and do not necessarily represent those of EUMETSAT. This
>> message and any attachments are intended for the sole use of the
>> addressee(s) and may contain confidential and privileged information.
>> Any unauthorised use, disclosure, dissemination or distribution (in
>> whole or in part) of its contents is not permitted. If you received
>> this message in error, please notify the sender and delete it from
>> your system.
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _____________________________________
>
> Randy C Horne (rhorne at excaliburlabs.com <mailto:rhorne at excaliburlabs.com>)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952.5100
> cell: (321) 693.1074
> url: http://www.excaliburlabs.com
>
>
>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180419/68c67980/attachment.html>
Received on Thu Apr 19 2018 - 09:35:03 BST
