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

Re: GDP/NetCDF Spatial relationship trouble.

Subject: Re: GDP/NetCDF Spatial relationship trouble.
Date: Fri, 21 May 2010 08:59:37 -0600

Hi John,

I'm one of the USGS points of contact w/ESRI. I will submit a request/some noise encouraging them to get up to date.

Roland

From:	John Caron <address@hidden>
To:	Richard Signell <address@hidden>
Cc:	David Blodgett <address@hidden>, Roland Viger <address@hidden>, Tom Kunicki <address@hidden>, Nathaniel L Booth <address@hidden>, Unidata netCDF Java Support <address@hidden>
Date:	05/21/2010 07:44 AM
Subject:	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 >> >> > > >

References:
- Re: GDP/NetCDF Spatial relationship trouble.
  - From: John Caron

Prev by Date: Re: [netcdf-java] Rotated-pole data
Next by Date: Re: Pure Java reader/writer
Previous by thread: Re: GDP/NetCDF Spatial relationship trouble.
Next by thread: Re: GDP/NetCDF Spatial relationship trouble.
Index(es):
- Date
- Thread