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