Re: GDP/NetCDF Spatial relationship trouble.

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
>>
>>
> 
> 
>