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....@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 a proposal 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-boun...@cgd.ucar.edu 
> <mailto:cf-metadata-boun...@cgd.ucar.edu>] On Behalf Of Jim Biard
> Sent: 19 April 2018 15:32
> To: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@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-boun...@cgd.ucar.edu 
> <mailto:cf-metadata-boun...@cgd.ucar.edu>] On Behalf Of Ethan Davis
> Sent: 19 April 2018 05:40
> To: CF metadata <cf-metadata@cgd.ucar.edu> <mailto:cf-metadata@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@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata 
> <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: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org> 
> o: +1 828 271 4900 
> 
> Connect with us on Facebook forclimate 
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics 
> <https://www.facebook.com/NOAANCEIoceangeo>information, and follow us on 
> Twitter at@NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> 
> and@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@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata 
> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>

_____________________________________

Randy C Horne (rho...@excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
cell: (321) 693.1074
url: http://www.excaliburlabs.com



_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to