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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180410/09b8ba9b/attachment.html>
Received on Tue Apr 10 2018 - 11:59:55 BST
