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-boun...@cgd.ucar.edu] On Behalf
> Of Randy Horne
> Sent: 11 April 2018 19:02
> To: j.m.greg...@reading.ac.uk
> Cc: cf-metadata@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.greg...@ncas.ac.uk <mailto:jonathan.greg...@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 <eda...@ucar.edu
<mailto:eda...@ucar.edu>> -----
> >
> >> Date: Tue, 10 Apr 2018 11:59:55 -0600
> >> From: Ethan Davis <eda...@ucar.edu <mailto:eda...@ucar.edu>>
> >> To: Jonathan Gregory <j.m.greg...@reading.ac.uk
<mailto:j.m.greg...@reading.ac.uk>>
> >> Cc: CF metadata <cf-metadata@cgd.ucar.edu
<mailto:cf-metadata@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.greg...@reading.ac.uk <mailto:j.m.greg...@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 <jbi...@cicsnc.org
<mailto:jbi...@cicsnc.org>> -----
> >>>
> >>>> Date: Tue, 10 Apr 2018 12:32:00 -0400
> >>>> From: Jim Biard <jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>>
> >>>> To: CF metadata <cf-metadata@cgd.ucar.edu
<mailto:cf-metadata@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: jbi...@cicsnc.org <mailto:jbi...@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 @NOAANCEIclimate
> >>>> <http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo
> >>>> <http://www.twitter.com/NOAANCEIocngeo>.*
> >>>>
> >>>>
> >>>> On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne
> >>>> <rho...@excaliburlabs.com <mailto:rho...@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 <eda...@ucar.edu
<mailto:eda...@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@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>>
> >>>>>
> >>>>> _____________________________________
> >>>>>
> >>>>> Randy C Horne (rho...@excaliburlabs.com
<mailto: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 <mailto:CF-metadata@cgd.ucar.edu>
> >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>>>
> >>>>>
> >>>
> >>>> _______________________________________________
> >>>> CF-metadata mailing list
> >>>> CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >>>
> >>> ----- End forwarded message -----
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _____________________________________
>
> Randy C Horne (rho...@excaliburlabs.com
<mailto: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 <mailto:CF-metadata@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@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
