Mark,
Thanks for pointing out the TRAC ticket. I was not aware of it. The proposed change moves in a good direction, in that it makes the associations explicit and allows different coordinate systems to coexist, but still makes the association between coordinates and coordinate systems in/through the data variable, as opposed to in the coordinates (or auxiliary coordinates) themselves. A given coordinate is always associated with a given coordinate system, regardless of whether or not a data variable makes use of it. Why are we pulling the data variable into the association "loop"?
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
On Oct 15, 2012, at 10:24 AM, "Hedley, Mark" <mark.hedley at metoffice.gov.uk> wrote:
>
> Hello Jim
>
> If I have caught your sense correctly, I think this was the objective for the change proposed in
>
> https://cf-pcmdi.llnl.gov/trac/ticket/70
>
> This ticket has been accepted and is waiting for the next version of the CF conventions for NetCDF files to be put forward.
>
> Do you think this ticket captures the need and a tractable solution to your satisfaction?
>
> all the best
> mark
>
> -----Original Message-----
> From: CF-metadata on behalf of Jim Biard
> Sent: Thu 11/10/2012 20:23
> To: cf-metadata at cgd.ucar.edu
> Subject: [CF-metadata] Coordinate systems
>
> Hi.
>
> I mentioned I thought/concern I had about coordinate systems in CF as an aside a while back, and I didn't much response, so I'm writing it now as a standalone post.
> When I look at the way geographic coordinate systems are implemented in CF, I keep getting the feeling that the associations (in a UML sense) don't make good sense.
>
> What we have right now is that a variable has coordinates associated with it, and also has a grid_mapping (a definition of a geographic coordinate system) associated with it. Here's a cheap ASCII picture of that.
>
> [coordinate]2------>*[variable]*<------1[grid_mapping]
> *
> ^
> |
> |
> 2
> [lon/lat]
>
> I'm on purpose limiting myself for the sake of this discussion to the case of 2 coordinates (X/Y, lon/lat, etc) for any given variable. I know there can be more, but we are still fuzzy on Z, and other coordinates that might be present aren't geographic. I have also shown the longitude and latitude auxiliary coordinates smashed together into a single element for compactness. I hope it's not overly confusing.
>
> Based on this model, the coordinates don't have a coordinate system except by relation through a variable. As a result, the same coordinates could be associated with different geographic coordinate systems in different variables. You could two different grid_mappings defined (UTM zone 8 and Polar Stereographic, for example) associate one with variable 1 and the other with variable 2, yet have the same coordinates associated with both variable 1 and variable 2. Furthermore, the longitude and latitude are assumed to relate (via dimensionality) with the coordinates as defined by the grid_mapping, which could (again) be different for each variable. This model seems more than a bit fragile and unnatural to me.
>
> The thing is, coordinates are meaningless without the definition of the coordinate system they belong to. Starting from scratch, the natural approach to this would be to associate coordinate systems with coordinates, which can then be associated with variables. The diagram would be:
>
> [grid_mapping]1----->*[(aux) coordinate]*------>*[variable]
>
> Each coordinate would have a geographic coordinate system associated with it. A variable could have any number of (pairs of) coordinates associated with it. Longitude/latitude or other auxiliary coordinates would fit into this model in just the same way.
>
> Written as CDL, what you would see is:
>
> netcdf {
> dimensions:
> xt = 50;
> yt = 50;
> variables:
> float xt(xt=50);
> :grid_mapping = "TM";
> :units = "m";
> float yt(yt=50);
> :grid_mapping = "TM";
> :units = "m";
> float temperature(xt=50, yt=50);
> :coordinates = "lon lat xp yp";
> :units = "K";
> float lon(xt=50, yt=50);
> :units = "degrees_east";
> :grid_mapping = "LonLat";
> float lat(xt=50, yt=50);
> :units = "degrees_north";
> :grid_mapping = "LonLat";
> float xp(xt=50, yt=50);
> :units = "m";
> :grid_mapping = "PolarStereo";
> float yp(xt=50, yt=50);
> :coordinates = "xt yt";
> :units = "m";
> :grid_mapping = "PolarStereo";
> char LonLat;
> :grid_mapping_name = "latitude_longitude";
> char PolarStereo;
> :grid_mapping_name = "polar_stereographic";
> char TM;
> :grid_mapping_name = "transverse_mercator";
> }
>
> I left out the details of the grid_mapping variables for brevity.
>
> So, having said all that, I'm curious to know if there is any particular reason why geographic coordinate systems are being done the way they are right now, and wondering if what I have described makes sense to anyone else.
>
> Grace and peace,
>
> Jim
>
> Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites
> Remote Sensing and Applications Division
> National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801-5001
>
> jim.biard at noaa.gov
> 828-271-4900
>
>
>
> _______________________________________________
> 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/20121016/a7d845a8/attachment.html>
Received on Tue Oct 16 2012 - 08:06:17 BST
