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: [email protected] 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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > _____________________________________ > > Randy C Horne ([email protected]) > Principal Engineer, Excalibur Laboratories Inc. > voice & fax: (321) 952.5100 > cell: (321) 693.1074 > url: http://www.excaliburlabs.com > > > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
