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

Re: GDP/NetCDF Spatial relationship trouble.

Hi all:

I think Rich is correctly characterizing the situation. I will add a few 
details.

Weve been beating on data providers to add better georeferencing metadata to 
netCDF for a long time. We have managed to get standard CF parameters to 
describe the ellipsoidal earth, and some datasets use those. In a TDS, such 
information can be added on the server to correct problems, without having to 
rewrite the files.

Data stored in GRIB is generally better in specifying this information. We essentially 
turn it into netcdf-CF "on the fly" when we serve it.

As a rule, we generally don't do reprojections on the server. The exception is 
the WMS server, developed by Jon Blower, which does. We may eventually do more 
of this in other services like WCS. Theres no standard way to do this in 
OPeNDAP, where we just remotely serve the original data.

On a client using the netCDF-Java (aka CDM) library, like the IDV, we have a 
limited set of projections, but a mechanism for users to add their own at 
runtime. Of the ones we have, the UTM projection is inherently ellipsoidal, and 
the Albers and LCC projections use an ellipsoidal earth if the parameters are 
specified. We recently been made aware that the geotoolkit has been refactored 
to be easier to reuse than previous versions, so we could get access to their 
much larger set of projections with some work, that perhaps someone other than 
us could do.

But if you are using a different client, then you have to evaluate what it can 
and cant do. ESRI does its own implementation of reading netCDF, not based on 
the CDM library I think (although we tried to convince them to use it long ago).

"The CF conventions specifies some elements of the coordinate system but it does not 
state how to include the geographic coordinate system (datum) portion. Because of this, 
it is always assumed to be the WGS 1984"

is really about ESRI's implementation, and CF as it was 7 or 8 years ago. If 
you are an ESRI customer, tell them (squeaky wheels!) about what you need from 
them. Eg, use the ellipsoidal parameters when those are present.

John

Richard Signell wrote:

Dave,


I actually think netCDF is doing all we need in terms of projections. The
issue is that whether data is projected from a datum using an elliptical or
spherical spheroid.


Well, if Albers and LCC is all we need, then I agree.


Please correct me if I'm wrong, I believe that netCDF
doesn't do the geocentric transformation from geocentric to geodetic
latitude, so we may have to check for metadata in the netCDF archive and
perform the transformation between netCDF grid and intersecting geometry.


When you say "netCDF", I'm assuming you mean "netCDF-Java" or perhaps
"Thredds Data Server"?   If we want to access geospatial data from
NetCDF or OpenDAP in a specific CRS, then yes, we have to do the CRS
transformation somehow -- it's not automatic.


I found this fun fact on ESIR's page "Understanding the spatial reference of
netCDF data" help page.
"The CF conventions specifies some elements of the coordinate system but it
does not state how to include the geographic coordinate system (datum)
portion. Because of this, it is always assumed to be the WGS 1984, whether
the data is referenced to a projected or geographic coordinate system. A
projected coordinate system is based upon a geographic coordinate system and
must always be specified. Because of the assumption of WGS 1984, data which
is actually referenced to a particular sphere or another spheroid
(ellipsoid) may not align with other data layers."
However, it seems that this is not true, to a point. The CF convention,
Appendix F, has specific parameters for projections and earth shape. But, I
have come across a number of netCDF files that have grids given in
latitude/longitude with no indication of whether it is geodetic or
geocentric latitude.



Given such a situation, do we make an assumption? Ask the user to specify
the earth shape parameters? If it is truly unknown, there can be quite large
geo-location errors, ~2-5km from my investigation using grib-1 Radar data.


If the information isn't provided (spherical earth params, WGS84, etc)
yes, we have to track down the actual parameters from the providers,
or just guess and see if it looks bad, and then fix.

-Rich


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 May 21, 2010, at 7:09 AM, Richard Signell wrote:

David,

CF originated in the climate community, where a spherical earth was
all they needed.   So originally in NetCDF-Java all the projections
assumed a spherical earth.   John Caron, on our request, added the
ability of Albers and LCC to handle ellipsoidal earth, and either John
or someone familiar with NetCDF-Java could add others relatively
easily.  What other projections do we need to handle ellipsoidal
parameters ASAP?
If there are problems with the projection or ellipsoid metadata in
NetCDF files, they can be fixed using NcML on the TDSserver backend.

-Rich

On Thu, May 20, 2010 at 3:28 PM, David Blodgett <address@hidden> wrote:

We have two functional problems that arise from the following fact:

netCDF has very limited and sometimes wrong metadata related to the

spheroid/datum and treats lat/lon the same regardless of the spheroid/datum

a dataset is indicated to reside on.

Boiled down, the two hurdles are:

1) We need to account for the differences between lat/lon on a spherical

datum and lat/lon on common spheroidal datums.

A reasonable summary of the problem we face is

here: 
http://www.crwr.utexas.edu/gis/gishydro06/SpaceAndTime/SphereVsSperoid2006.htm

2) We need to establish a way of handling datasets with ambiguous or wrong

spherical radii.

There is some good information here: http://www.arl.noaa.gov/faq_ms1.php

I will work with Tom to establish a method to ensure 1 is being completed. 2

is going to be difficult. Rich, do you have ideas here? References you would

recommend?

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










--
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598