[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF-1.4 conventions for lat/lon datum.



Sounds good John, 

We'll need to discuss the approach here. I think there is probably a great opportunity for some cross-discipline collaboration.

It may not be as simple as refactoring the transformations to handle meteorological -> geographic grids. I have yet to get a firm answer to this, but I have a suspicion that in some cases, it may make the most sense to use the current implementation. 

My assumption is that the forcings and observations used by meteorological modelers were not necessarily converted to spherical coordinates. Calculations and model runs are performed using spherical math though. I am not certain about this, but if it is the case, the most appropriate approach would be to assume the positions are actually from the original datum of the populating data or model forcing.

Do you know, or have a contact who could definitively address this?

I'm going to be in Boulder before and after the weekend of the 17th of July, maybe a good opportunity to chat about this and other things we would like to collaborate on?

Thanks,

Dave Blodgett
Center for Integrated Data Analytics (CIDA)
USGS WI Water Science Center
8505 Research Way Middleton WI 53562
608-821-3899 | 608-628-5855 (cell)
http://cida.usgs.gov

On Jun 28, 2010, at 2:42 AM, john caron wrote:

Ethan Davis wrote:
Hi all,

First off, when you say you can "explicitly request [WGS84 and NAD83]
from the WCS server", does that mean you are getting the data on a
lat/lon grid based on the WGS84 or NAD83 datum?

Second, is the data you are using of high enough resolution that the
differences between these datums will be noticeable?

The more I read about datums and such the more I realize I don't
understand. From a quick google search, I found a few pages that are
both enlightening and baffling. From one of them:

 
http://sci.tech-archive.net/Archive/sci.geo.satellite-nav/2006-09/msg00307.html
   

it appears that WGS84 has had a number of "realizations" over the years.
One of them changed the location of the origin (center of the earth) by
a few meters and another changed the location of the PM by 100 meters.
(I'm really not sure I understand how or why the origin was changed.)
Bottom line, the reference system of the original WGS84 was very close
to that of NAD83 but the differences between current versions are more
noticeable.

Here's what the "Remarks" in the EPSG datum table says about the WGS84:

   EPSG's WGS 84 datum has been the then current realisation. No
   distinction is made between the original WGS 84 frame, WGS 84
   (G730), WGS 84 (G873) and WGS 84 (G1150). Since 1997, WGS 84
   has been maintained within 10cm of the then current ITRF.

As for describing them in CF, I'd say that if you know which realization
of the datum actually applies to your data then you should use the
appropriate numbers. On the other hand, none of us involved in writing
this part of CF really know all the ins-and-outs of datums and such and
I now wonder if there aren't some holes in the CF spec. In particular,
there is nothing in the CF spec that would allow the data reader to
figure out that the datums used on two different datasets place the
origin of the reference system 2 meters apart. Though from the above
quote it look like the EPSG doesn't either (and for that matter I'm not
sure WKT and such have places to contain that information either).

As to what defining these CF parameters actually does, basically it
captures the information in a way that hopefully allows client
applications to use it in appropriate ways.

What the netCDF-Java library does with this information John can answer
better than I. However, to give my guess, if the data is on lat/lon
coordinates, I'm not sure if it even looks at the datum information
underlying those coordinates when deciding if the data are on the same grid.
 
We dont currently use the datum. We have a rather ad-hoc collection of transformations that were adequate for global models, but less so for high resolution data. We will have to refactor this. If you have some concrete use cases, or would like to help with the refactor, let us know.