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> -----
> Date: Tue, 10 Apr 2018 11:59:55 -0600
> From: Ethan Davis <edavis at ucar.edu>
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Cc: CF metadata <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> 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> -----
> >
> > > Date: Tue, 10 Apr 2018 12:32:00 -0400
> > > From: Jim Biard <jbiard at cicsnc.org>
> > > To: CF metadata <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
> > > 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>
> > > 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> 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
> > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > >
> > > >
> > > > _____________________________________
> > > >
> > > > Randy C Horne (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
> > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > > >
> > > >
> >
> > > _______________________________________________
> > > CF-metadata mailing list
> > > 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
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
----- End forwarded message -----
Received on Wed Apr 11 2018 - 10:10:37 BST
