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