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.gregory at 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 <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 -----
> _______________________________________________
> 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
Received on Wed Apr 11 2018 - 11:01:49 BST
