That sounds great, Roland. Ill be interested in hearing when they
actually implement it.
On 5/24/2010 1:33 PM, Roland Viger wrote:
Hi John,
Just thought you might be interested
to know that we've logged an enhancement request w/ESRI on this,
included
it in the list of questions for an annual high-level technical briefing
that the USGS has w/ESRI, and that folks on the the relevant ESRI
development
teams have stated that this issue on their radar. Support is expected
for
the first maintenance/service pack release after the new version comes
out (in July?).
Thanks for your help.
Roland
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
>>
>>
>
>
>
|