So, should we consider loosening the standard name definitions for
projection_x/y_coordinate? That is one solution.
On 4/17/18 5:55 AM, Daniel Lee wrote:
>
> Dear group,
>
> but I'd like to add that EUMETSAT also will be depending on using
> radians as units for our products using geostationary projections. We
> have the same issue that Randy notes - the scan characteristics of the
> instrument mean that it steps its view along an axis which changes its
> angle to the viewed point, and thus there's a non-linear relationship
> between length between view centroids on the ground and the grid. m vs
> rad is dependent on the angular distance from the satellite's nadir
> view. For us, switching to another standard name would also be very
> difficult, and switching to another unit would be impossible whilst
> preserving the integrity of the data.
>
> Best regards,
>
> Daniel
>
> > -----Original Message-----
>
> > From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf
>
> > Of Randy Horne
>
> > Sent: 11 April 2018 19:02
>
> > To: j.m.gregory at reading.ac.uk
>
> > Cc: cf-metadata at cgd.ucar.edu
>
> > Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
>
> > "Geospatial projection"
>
> >
>
> > Dear All:
>
> >
>
> > Unfortunately, for this projection, the relationship between m and
> rad is
>
> > non-linear, (not tho mention that angular measure / radians is a
> fundamental
>
> > characteristic of the projection).
>
> >
>
> > v/r
>
> >
>
> > randy
>
> >
>
> >
>
> > > On Apr 11, 2018, at 12:10 PM, Jonathan Gregory
>
> > <jonathan.gregory at ncas.ac.uk <mailto:jonathan.gregory at ncas.ac.uk>>
> wrote:
>
> > >
>
> > > Dear Ethan
>
> > >
>
> > > It wouldn't be nice to allow this name to have two different canonical
>
> > > units (I mean not interconvertible). No doubt there is other software
>
> > > that wouldn't like that situation, and it's a principle of standard
>
> > > names that they specify the canonical unit, so that we need distinct
>
> > > names for two quantities which have different canonical units. If the
>
> > > coordinates are truly in radians, I think the right solution is to
> define a new
>
> > standard name and change App F.
>
> > >
>
> > > However, I realise that you need some workrounds to use during the
>
> > > (possibly
>
> > > infinite) time before this change is thoroughly implemented, and for
>
> > > archived data. Would it be practical to patch the software that
>
> > > processes this data so that it doesn't object to the erroneous units?
>
> > > If a conversion can be done between m and rad by making some standard
>
> > > assumption about distances, then you could relabel the existing
>
> > > numbers, which are actually in microradians, with units="m" and a
>
> > > scale_factor, or which units="X m", where X is the scale factor,
> so that the
>
> > numbers themselves don't have to be changed.
>
> > >
>
> > > Best wishes
>
> > >
>
> > > Jonathan
>
> > >
>
> > > ----- Forwarded message from Ethan Davis <edavis at ucar.edu
> <mailto:edavis at ucar.edu>> -----
>
> > >
>
> > >> Date: Tue, 10 Apr 2018 11:59:55 -0600
>
> > >> From: Ethan Davis <edavis at ucar.edu <mailto:edavis at ucar.edu>>
>
> > >> To: Jonathan Gregory <j.m.gregory at reading.ac.uk
> <mailto:j.m.gregory at reading.ac.uk>>
>
> > >> Cc: CF metadata <cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>>
>
> > >> Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
>
> > >> ????? "Geospatial projection"
>
> > >>
>
> > >> Hi Jonathan,
>
> > >>
>
> > >> Yes, the change of units is unfortunate. However, there are now
>
> > >> operational platforms generating data using this projection as it
>
> > >> stands. It will be years (if ever) before a change like this would
>
> > >> propagate through those operational systems.
>
> > >>
>
> > >> This means software would have to support two variants and I am very
>
> > >> hesitant to move in that direction.
>
> > >>
>
> > >> There is much discussion in Trac #72 comments 12
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:12>, 13
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:13>, 14
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:14> on the whys and
>
> > >> wherefores around the transformation between radians and meters for
>
> > >> these coordinates. I wonder if there is an alternate path forward
>
> > >> that would allow us to keep projection_{x|y}_coordinate for this
>
> > >> projection. Maybe add (a very brief) discussion of how radians maps
>
> > >> in this case to linear distance. Not perfect but perhaps better
> than the
>
> > alternative.
>
> > >>
>
> > >> Cheers,
>
> > >>
>
> > >> Ethan
>
> > >>
>
> > >>
>
> > >> On Tue, Apr 10, 2018 at 11:30 AM, Jonathan Gregory <
>
> > >> j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> wrote:
>
> > >>
>
> > >>> Dear all
>
> > >>>
>
> > >>> Metres and radians are not interconvertible, so
>
> > >>> projection_[xy]_coordinate should not be used as a standard name for
>
> > >>> a quantity in radians. I think that a defect ticket is needed to
>
> > >>> change App F for this projection. Possibly we might need new
>
> > >>> standard names if there aren't appropriate ones.
>
> > >>>
>
> > >>> Best wishes
>
> > >>>
>
> > >>> Jonathan
>
> > >>>
>
> > >>>
>
> > >>> ----- Forwarded message from Jim Biard <jbiard at cicsnc.org
> <mailto:jbiard at cicsnc.org>> -----
>
> > >>>
>
> > >>>> Date: Tue, 10 Apr 2018 12:32:00 -0400
>
> > >>>> From: Jim Biard <jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
>
> > >>>> To: CF metadata <cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>>
>
> > >>>> Subject: Re: [CF-metadata] Units of projection_x_coordinate
> values in
>
> > >>>>????? "Geospatial projection"
>
> > >>>>
>
> > >>>> Hi.
>
> > >>>>
>
> > >>>> It sounds like perhaps we should avoid the word "canonical".
>
> > >>>> Perhaps we should change the relevant bit of the definition to read
>
> > >>>>
>
> > >>>> The x (abscissa) and y (ordinate) rectangular coordinates are
>
> > >>>> identified
>
> > >>> by
>
> > >>>> the standard_name attribute values projection_x_coordinate and
>
> > >>>> projection_y_coordinate respectively. In the case of this
>
> > >>>> projection, the projection coordinates in this projection are
>
> > >>>> directly related to the scanning angle of the satellite instrument
>
> > >>>> - typically an angular
>
> > >>> quantity.
>
> > >>>>
>
> > >>>>
>
> > >>>> Software shouldn't assume the units. Microradians, degrees, grads,
>
> > >>>> etc should all be fine. Does anyone think there is a problem with
>
> > >>>> storing an angle in a variable with the standard name
>
> > >>>> projection_x_coordinate? Do we need different standard names for
>
> > these?
>
> > >>>>
>
> > >>>> This may indicate that projections that have specific requirements
>
> > >>>> about units in the coordinates need to declare that information in
>
> > >>>> the grid_mapping variable attributes. We tend to gloss over that,
>
> > >>>> but there
>
> > >>> are
>
> > >>>> projections that expect the coordinates to be latitude and
>
> > >>>> longitude instead of x and y. In addition, spherical or cylindrical
>
> > >>>> coordinate systems would expect at least one coordinate to be
> angular.
>
> > Thoughts?
>
> > >>>>
>
> > >>>> Grace and peace,
>
> > >>>>
>
> > >>>> Jim
>
> > >>>>
>
> > >>>> [image: 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
>
> > >>>> <http://www.facebook.com/NOAANCEIclimate> and ocean and
>
> > geophysics
>
> > >>>> <http://www.facebook.com/NOAANCEIoceangeo> information, and
>
> > follow
>
> > >>>> us on Twitter at _at_NOAANCEIclimate
>
> > >>>> <http://www.twitter.com/NOAANCEIclimate>and _at_NOAANCEIocngeo
>
> > >>>> <http://www.twitter.com/NOAANCEIocngeo>.*
>
> > >>>>
>
> > >>>>
>
> > >>>> On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne
>
> > >>>> <rhorne at excaliburlabs.com <mailto:rhorne at excaliburlabs.com>>
>
> > >>>> wrote:
>
> > >>>>
>
> > >>>>> Ethan:
>
> > >>>>>
>
> > >>>>> What you suggest is fine.
>
> > >>>>>
>
> > >>>>> As an aside ?.
>
> > >>>>> If you look at the CF standard name table, the canonical units for
>
> > >>>>> standard name ? projection_x_coordinate? and
>
> > ?projection_y_coordinate?
>
> > >>> are
>
> > >>>>> meters (not radians).
>
> > >>>>>
>
> > >>>>> The GOES-R designers (specifically me) inadvertently used these
>
> > >>>>> two standard names, not realizing they should NOT have used them
>
> > >>>>> because a standard name can not have two different canonical
> units.
>
> > >>>>>
>
> > >>>>> Now, because the GOES-R system is already operational and in use,
>
> > >>>>> it
>
> > >>> would
>
> > >>>>> be major rework for GOES-R to use a yet to be defined standard
>
> > >>>>> name
>
> > >>> (such
>
> > >>>>> as projection_x_angilar_coordinate and projection_y_angular_
>
> > >>> coordinate).
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> Not sure what to d about this ?.
>
> > >>>>>
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> v/r
>
> > >>>>>
>
> > >>>>> randy
>
> > >>>>>
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> On Apr 9, 2018, at 3:54 PM, Ethan Davis <edavis at ucar.edu
> <mailto:edavis at ucar.edu>> wrote:
>
> > >>>>>
>
> > >>>>> Hi all,
>
> > >>>>>
>
> > >>>>> The "Geostationary projection" section of Appendix F "Grid
>
> > Mappings"
>
> > >>> says
>
> > >>>>>
>
> > >>>>> The x (abscissa) and y (ordinate) rectangular coordinates are
>
> > >>> identified
>
> > >>>>> by the standard_name attribute values projection_x_coordinate and
>
> > >>>>> projection_y_coordinate respectively. In the case of this
>
> > >>>>> projection,
>
> > >>> the
>
> > >>>>> projection coordinates in this projection are directly related to
>
> > >>>>> the scanning angle of the satellite instrument, and their units
>
> > >>>>> are
>
> > >>> radians.
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> To more explicitly fit CF expectations for units of variables with
>
> > >>>>> a standard_name attribute, I believe the last bit should read:
>
> > >>>>>
>
> > >>>>> ... and their *canonical* units are radians.
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> This came up because the GOES-16 Full Disk data (example below
>
> > >>>>> [1]) is stored with the projection_{x|y}_coordinate values in
>
> > >>>>> microradians
>
> > >>> and, it
>
> > >>>>> turns out, the netCDF-Java code didn't like that as it expected
>
> > >>> radians.
>
> > >>>>> (Oops!)
>
> > >>>>>
>
> > >>>>> Unless anyone disagrees, I will open a CF Trac ticket for this
>
> > >>>>> change later this week.
>
> > >>>>>
>
> > >>>>> Thanks,
>
> > >>>>>
>
> > >>>>> Ethan
>
> > >>>>>
>
> > >>>>> [1]
>
> > >>>>> http://thredds-test.unidata.ucar.edu/thredds/dodsC/
>
> > >>>>> satellite/goes16/GOES16/FullDisk/Channel08/20180406/
>
> > >>>>> GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W.nc4.html
>
> > >>>>>
>
> > >>>>> netcdf GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W {
>
> > >>>>> dimensions:
>
> > >>>>> x = 1808 ;
>
> > >>>>> y = 1808 ;
>
> > >>>>> variables:
>
> > >>>>> int time ;
>
> > >>>>> time:units = "seconds since 2017-01-01" ; time:standard_name =
>
> > >>>>> "time" ; time:long_name = "The start date / time that the
>
> > >>>>> satellite began
>
> > >>> capturing
>
> > >>>>> the scene" ;
>
> > >>>>> time:axis = "T" ;
>
> > >>>>> time:calendar = "standard" ;
>
> > >>>>> short y(y) ;
>
> > >>>>> y:standard_name = "projection_y_coordinate" ; y:units =
>
> > >>>>> "microradian" ; y:scale_factor = -167.999999999971 ; y:add_offset
>
> > >>>>> = 151788. ; short x(x) ; x:standard_name =
>
> > >>>>> "projection_x_coordinate" ; x:units = "microradian" ;
>
> > >>>>> x:scale_factor = 167.999999999971 ; x:add_offset = -151788. ; int
>
> > >>>>> fixedgrid_projection ; fixedgrid_projection:grid_mapping_name =
>
> > >>>>> "geostationary" ;
>
> > >>>>> fixedgrid_projection:latitude_of_projection_origin = 0. ;
>
> > >>>>> fixedgrid_projection:longitude_of_projection_origin = -75. ;
>
> > >>>>> fixedgrid_projection:semi_major = 6378137. ;
>
> > >>>>> fixedgrid_projection:semi_major_axis = 6378137. ;
>
> > >>>>> fixedgrid_projection:semi_minor = 6356752.31414 ;
>
> > >>>>> fixedgrid_projection:semi_minor_axis = 6356752.31414 ;
>
> > >>>>> fixedgrid_projection:perspective_point_height = 35785831. ;
>
> > >>>>> fixedgrid_projection:sweep_angle_axis = "x" ; short
>
> > >>>>> Sectorized_CMI(y, x) ; Sectorized_CMI:_FillValue = 0s ;
>
> > >>>>> Sectorized_CMI:standard_name = "brightness_temperature" ;
>
> > >>>>> Sectorized_CMI:units = "kelvin" ; Sectorized_CMI:grid_mapping =
>
> > >>>>> "fixedgrid_projection" ; Sectorized_CMI:add_offset = 138.05f ;
>
> > >>>>> Sectorized_CMI:scale_factor = 0.04224986f ;
>
> > >>>>> Sectorized_CMI:valid_min = 0s ; Sectorized_CMI:valid_max = 4095s ;
>
> > >>>>> Sectorized_CMI:coordinates = "time y x" ;
>
> > >>>>>
>
> > >>>>> // global attributes:
>
> > >>>>> :title = "Sectorized Cloud and Moisture Imagery for the EFD
>
> > >>>>> region." ; :ICD_version = "GROUND SEGMENT (GS) TO ADVANCED
>
> > WEATHER
>
> > >>>>> INTERACTIVE PROCESSING SYSTEM (AWIPS) INTERFACE CONTROL
>
> > DOCUMENT (ICD) Revision B"
>
> > >>> ;
>
> > >>>>> :Conventions = "CF-1.6" ;
>
> > >>>>> :channel_id = 8 ;
>
> > >>>>> :central_wavelength = 6.19f ;
>
> > >>>>> :abi_mode = 3 ;
>
> > >>>>> :source_scene = "FullDisk" ;
>
> > >>>>> :periodicity = 15.f ;
>
> > >>>>> :production_location = "RBU" ;
>
> > >>>>> :product_name = "EFD-060-B12-M3C08" ; :satellite_id = "GOES-16" ;
>
> > >>>>> :product_center_latitude = 0. ; :product_center_longitude = -75. ;
>
> > >>>>> :projection = "Fixed Grid" ; :bit_depth = 12 ;
>
> > >>>>> :source_spatial_resolution = 2.f ; :request_spatial_resolution =
>
> > >>>>> 6.f ; :start_date_time = "2018096201540" ; :number_product_tiles =
>
> > >>>>> 4 ; :product_tile_width = 1024 ; :product_tile_height = 1024 ;
>
> > >>>>> :product_rows = 1808 ; :product_columns = 1808 ; :pixel_x_size =
>
> > >>>>> 6. ; :pixel_y_size = 6. ; :satellite_latitude = 0. ;
>
> > >>>>> :satellite_longitude = -75. ; :satellite_altitude = 35785831. ;
>
> > >>>>> :created_by = "ldm-alchemy" ; :product_tiles_received = 4 ; }
>
> > >>>>>
>
> > >>>>> _______________________________________________
>
> > >>>>> 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
>
> > >>>>>
>
> > >>>>>
>
> > >>>>>
>
> > >>>>>
>
> > >>>>> _______________________________________________
>
> > >>>>> 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
>
> > >>>>>
>
> > >>>>>
>
> > >>>
>
> > >>>> _______________________________________________
>
> > >>>> 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
>
> > >>>
>
> > >>>
>
> > >>> ----- End forwarded message -----
>
> > >>> _______________________________________________
>
> > >>> 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
>
> > >>>
>
> > >
>
> > > ----- End forwarded message -----
>
> > > _______________________________________________
>
> > > 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
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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
>
>
> 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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
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/20180417/a06cec48/attachment.html>
Received on Tue Apr 17 2018 - 07:04:21 BST
