⇐ ⇒

[CF-metadata] FW: Connecting coordinates to Grid Mapping variables

From: Hedley, Mark <mark.hedley>
Date: Wed, 26 Oct 2011 16:44:33 +0100

Hello

>Actually I am unclear, in this particular example, why we do need two grid_mapping atts.
One issue is that the GeogCS the OSGB is projected from is different from the GeogCS I would like to exchange my data on.
  
Example cdl, is below, using both syntax options, which clearly isn't valid, so please ignore one or other as appropriate when considering.

mark

dimensions:
  y = 100000 ;
  x = 100000 ;
variables:
  double x(x) ;
    x:standard_name = "projection_x_coordinate" ;
    x:long_name = "Easting"
    x:units = "m" ;
    x:reference_system = "crsOSGB" ;
  double y(y) ;
    y:standard_name = "projection_y_coordinate" ;
    y:long_name = "Northing"
    y:units = "m" ;
    y:reference_system = "crsOSGB" ;
  double lat(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
    lat:reference_system = "crsWGS84" ;
  double lon(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
    lon:reference_system = "crsWGS84" ;
  float temp(y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y GeogCS: lat lon" ;
  float pres(y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y GeogCS: lat lon" ;
  int crsOSGB ;
    crs:grid_mapping_name = "transverse_mercator";
    crs:semi_major_axis = 6377563.396 ;
    crs:inverse_flattening = 299.3249646 ;
    crs:latitude_of_projection_origin = 49.0 ;
    crs:longitude_of_projection_origin = -2.0 ;
    crs:false_easting = 400000.0 ;
    crs:false_northing = -100000.0 ;
    crs:scale_factor_at_projection_origin = 0.9996012717 ;
  int crsWGS84 ;
    crs:grid_mapping_name = "latitude_longitude";
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;



-----Original Message-----
From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
Sent: Tue 25/10/2011 15:13
To: Hedley, Mark
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Connecting coordinates to Grid Mapping variables
 
Dear Mark

Thanks for your posting. I prefer the second option

> 2. expanded syntax for grid_mapping attribute on a data variable
> - grid_mapping = "Easting:Northing:Height:OSGB Lat:Lon:geogHeight:GeogCS"

Although parsers should be tolerant about this, it would be more like other
such CF atts if it were a blank-separated list i.e. spaces after ":" Also
I would suggest that if it was like this instead

"OSGB: Easting Northing Height GeogCS: Lat Lon geogHeight"

i.e. GRID_MAPPING_VAR: COORD_VAR [COORD_VAR ...] [GRID_MAPPING_VAR: ...]

it would be more like the existing format of the grid_mapping att,
which is just "GRID_MAPPING_VAR". It would be immediately obvious which format
was being used because in the new format the first word ends in : and there
are several words. If the software didn't know about the new format, and
interpreted the string in the old format, it would give an error because it
would find the grid_mapping variable named does not exist. That would be safe.

It is also more backward-compatible because we still have the grid_mapping
att on the data variable, and thus we continue to link the coordinates and
grid_mappings var via the data variable. This is the consistent with the
general way CF works, that the data variable is the main point of reference,
which links to the metadata in various ways.

Actually I am unclear, in this particular example, why we do need two
grid_mapping atts. Wouldn't a single one be sufficient to describe the
Mercator projection and the figure of the Earth, and thus the relationship
between the lat-lon and the Mercator projection x-y coords? I'd probably
understand better if you could illustrate this with a CDL example.

Best wishes

Jonathan
Received on Wed Oct 26 2011 - 09:44:33 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒