Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Dear CF list,

I took a bit longer to write down the proposed definitions of these 3 standard 
names.


standard name: sea_water_temperature_difference 
units: K
description:
Sea water temperature is the in situ temperature of the sea water. The standard 
name "sea_water_temperature_difference" can be used (as an auxiliary 
coordinate) together with the standard name 
"ocean_mixed_layer_thickness_defined_by_temperature" to define its temperature 
criterion.


standard name: sea_water_sigma_theta_difference
units: kg/m3
description:
Sigma-theta of sea water is the potential density (i.e. the density when moved 
adiabatically to a reference pressure) of water having the same temperature and 
salinity, minus 1000 kg m-3. The standard name 
"sea_water_sigma_theta_difference" can be used (as an auxiliary coordinate) 
together with the standard name 
"ocean_mixed_layer_thickness_defined_by_sigma_theta" to define its sigma_theta 
criterion.

standard name: sea_water_sigma_t_difference
units: kg/m3
description:
Sigma-t of sea water is the density of water at atmospheric pressure (i.e. the 
surface) having the same temperature and salinity, minus 1000 kg m-3. The 
standard name "sea_water_sigma_t_difference" can be used (as an auxiliary 
coordinate) together with the standard name  
"ocean_mixed_layer_thickness_defined_by_sigma_t" to define its sigma_t 
criterion.


Alternatively, we could move the last sentence of each description to the 
respective "ocean_mixed_layer_thickness_defined_by_*" standard names to make 
that specific usage more explicit. We then keep a more general description for 
the new "*_difference" standard names.

/Sébastien

- Original Message -
> From: "Jonathan Gregory" 
> To: "Sebastien Villaume" 
> Cc: cf-metadata@cgd.ucar.edu, "Lowry, Roy K." 
> Sent: Friday, 6 April, 2018 14:24:18
> Subject: Re: [CF-metadata] how to use 
> ocean_mixed_layer_thickness_defined_by_*

> Dear Sebastien and Roy
> 
> Thanks. I agree that it's a good idea to include sea_water_.
> 
> Best wishes
> 
> Jonathan
> 
> On Thu, Apr 05, 2018 at 07:04:26PM +, Sebastien Villaume wrote:
>> Date: Thu, 5 Apr 2018 19:04:26 + (GMT-00:00)
>> From: Sebastien Villaume 
>> To: cf-metadata@cgd.ucar.edu
>> Cc: Jonathan Gregory , "Lowry, Roy K."
>>  
>> Subject: Re: [CF-metadata] how touse
>>  ocean_mixed_layer_thickness_defined_by_*
>> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF59
>>  (Linux)/8.6.0_GA_1200)
>> 
>> Dear Jonathan and Roy,
>> 
>> thank you for your suggestions.
>> 
>> I am happy to go with a set of general standard names if it is fine with
>> everyone. I find it actually useful to make the standard names reusable by 
>> not
>> hard-coding one of the reference. It is pretty clear from the mixed layer
>> definition that it is a difference with respect to the sea surface.
>> 
>> I am also happy to prefix sigma_theta and sigma_t with sea_water:
>> 
>> sea_water_temperature_difference (K)
>> sea_water_sigma_theta_difference (kg/m3)
>> sea_water_sigma_t_difference (kg/m3)
>> 
>> I will draft some definitions for tomorrow.
>> 
>> thanks!
>> 
>> /Sébastien
>> 
>> - Original Message -
>> > From: "Lowry, Roy K." 
>> > To: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" 
>> > 
>> > Sent: Thursday, 5 April, 2018 18:34:48
>> > Subject: Re: [CF-metadata] how to  use 
>> > ocean_mixed_layer_thickness_defined_by_*
>> 
>> > Dear Jonathan and Sebastien,
>> > 
>> > 
>> > 
>> > 
>> > I was initially thinking of not including ' _defining_mixed_layer' in my
>> > suggestion and am certainly happy with leaving it out. However, I still 
>> > think
>> > sigma_t and sigma_theta should be prefixed with 'sea_water'. This would 
>> > give:
>> > 
>> > 
>> > 
>> > 
>> > 
>> > sea_water_temperature_difference
>> > sea_water_sigma_theta_difference
>> > sea_water_sigma_t_difference
>> > 
>> > Cheers, Roy.
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > Please note that I partially retired on 01/11/2015. I am now only working 
>> > 7.5
>> > hours a week and can only guarantee e-mail response on Wednesdays, my day 
>> > in
>> > the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk.
>> > Please also use this e-mail if your requirement is urgent.
>> > 
>> > 
>> > 
>> > From: CF-metadata  on behalf of Jonathan
>> > Gregory 
>> > Sent: 05 April 2018 18:28
>> > To: cf-metadata@cgd.ucar.edu
>> > Subject: Re: [CF-metadata] how to use 
>> > ocean_mixed_layer_thickness_defined_by_*
>> > Dear Sebastien
>> > 
>> > It's interesting that this question hasn't been raised before. Thanks for 
>> > doing
>> > so now. I agree that new standard names would be appropriate. There are 
>> > already
>> > some standard names containing "difference" in various 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Randy Horne]

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  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.9971 ;
>   y:add_offset = 151788. ;
>   short x(x) ;
>   x:standard_name = "projection_x_coordinate" ;
>   x:units = "microradian" ;
>   x:scale_factor = 167.9971 ;
>   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 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Jonathan Gregory]

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  -

> Date: Tue, 10 Apr 2018 12:32:00 -0400
> From: Jim Biard 
> To: CF metadata 
> 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] Visit us on
> Facebook  *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC  
> North Carolina State University  
> NOAA National Centers for Environmental Information  
> *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
>  and ocean and geophysics
>  information, and follow us on
> Twitter at @NOAANCEIclimate
> and @NOAANCEIocngeo
> .*
> 
> 
> On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne 
> 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  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 ;
> > 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Jim Biard]

Hi.

Is it possible that we just need to loosen the definition of
projection_x_coordinate and projection_y_coordinate?

Jim

[image: CICS-NC] Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC  
North Carolina State University  
NOAA National Centers for Environmental Information  
*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
 and ocean and geophysics
 information, and follow us on
Twitter at @NOAANCEIclimate
and @NOAANCEIocngeo
.*


On Tue, Apr 10, 2018 at 1:33 PM, Ethan Davis  wrote:

> Hi Randy,
>
> This projection was added to CF with Trac #72
> . There's some discussion
> around the x,y coordinates. I think comment 12
>  from John Caron
> addresses the issue of using radians instead of meters:
>
> "Ideally they would be something like "km on the projection plane", but
> then (I think) you need scaling factors that depend on the instrument. If
> you include the scaling factors into the coordinates, then you have (I
> guess) radians."
>
>
> Cheers,
>
> Ethan
>
> On Tue, Apr 10, 2018 at 8:09 AM, Randy Horne 
> 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  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.9971 ;
>> y:add_offset = 151788. ;
>> short x(x) ;
>> x:standard_name = "projection_x_coordinate" ;
>> x:units = "microradian" ;
>> x:scale_factor = 167.9971 ;
>> 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 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Jim Biard]

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] Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC  
North Carolina State University  
NOAA National Centers for Environmental Information  
*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
 and ocean and geophysics
 information, and follow us on
Twitter at @NOAANCEIclimate
and @NOAANCEIocngeo
.*


On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne 
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  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.9971 ;
> y:add_offset = 151788. ;
> short x(x) ;
> x:standard_name = "projection_x_coordinate" ;
> x:units = "microradian" ;
> x:scale_factor = 167.9971 ;
> 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 = 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

Hi Randy,

This projection was added to CF with Trac #72
. There's some discussion around
the x,y coordinates. I think comment 12
 from John Caron
addresses the issue of using radians instead of meters:

"Ideally they would be something like "km on the projection plane", but
then (I think) you need scaling factors that depend on the instrument. If
you include the scaling factors into the coordinates, then you have (I
guess) radians."


Cheers,

Ethan

On Tue, Apr 10, 2018 at 8:09 AM, Randy Horne 
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  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.9971 ;
> y:add_offset = 151788. ;
> short x(x) ;
> x:standard_name = "projection_x_coordinate" ;
> x:units = "microradian" ;
> x:scale_factor = 167.9971 ;
> 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 ;
> 

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

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
, 13
, 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  -
>
> > Date: Tue, 10 Apr 2018 12:32:00 -0400
> > From: Jim Biard 
> > To: CF metadata 
> > 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] Visit us on
> > Facebook  *Jim Biard*
> > *Research Scholar*
> > Cooperative Institute for Climate and Satellites NC   >
> > North Carolina State University  
> > 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
> >  and ocean and geophysics
> >  information, and follow us on
> > Twitter at @NOAANCEIclimate
> > and @NOAANCEIocngeo
> > .*
> >
> >
> > On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne 
> > 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  wrote:
> > >
> > > Hi all,
> > >
> > > The "Geostationary projection" section of Appendix F "Grid Mappings"
> says
> >