Chris et al.,
I looked at this today and I’m pretty sure the problem had been resolved in the
current version of Hyrax.
Here’s what I did:
1) Retrieved the NcML file:
curl
"http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml”;
> ota.ncml
2) Read the file and saw that the aggregation is formed by scanning a top level
directory called /ORWA.
<netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2";>
<aggregation dimName="ocean_time" type="joinExisting" >
<scan location="/ORWA/" suffix=".nc" subdirs=“false” />
</aggregation>
3) Looked in that directory: http://ingria.coas.oregonstate.edu/opendap/ORWA/
4) Checked the DDS of the first file:
http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.dds
5) Tried to get data for variable “ntimes":
http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc.ascii?ntimes
This returns an error with an informative message:
##BESError##Type# 1##Message# libdap exception building response#
error_code # #111# Failed to read data# Could not read the variable
#ntimes####Administrator# admin#email#address#your#domain#name##
Well, modulo the abundant # characters ;)
This means that Hyrax can’t read the file (from which the aggregation is
built) for some reason.
6) I downloaded the file:
curl
"http://ingria.coas.oregonstate.edu/opendap/ORWA/ocean_his_4226_27-Jul-2016.nc”;
> ocean_his_4226_27-Jul-2016.nc
7) And dropped into into my current Hyrax and where I am able to retrieve the
data:
curl
"http://localhost:8080/opendap/ingria/ocean_his_4226_27-Jul-2016.nc.ascii?ntimes";
Dataset: ocean_his_4226_27-Jul-2016.nc
ntimes, 2283930
My suspicion is that the 1.9.0 server is linked to a very out of date version
of the NetCDF-C library.
Upgrade the server!
Sincerely,
Nathan
> On Oct 19, 2016, at 8:46 AM, Chris Barker <chris.barker@xxxxxxxx> wrote:
>
> Thanks EMilio,
>
> I'll reach out to Alexandre.
>
> -Chris
>
>
> On Wed, Oct 19, 2016 at 8:39 AM, Emilio Mayorga <emiliomayorga@xxxxxxxxx>
> wrote:
> Just to clarify, I made references to potential misconfigurations on the
> hyrax server only b/c I saw statements to that effect in the previous emails
> on this thread. I'm not in a position to make assessments myself. And as I
> mentioned, NANOOS is also not in a real position to offer significant changes
> to that hyrax server.
>
> Any recommendations to upgrade to a more recent version should be made
> directly to the server maintainer; I don't remember her name, but the model
> PI is Alexandre Kurapov, kurapov@xxxxxxxxxxxxxxxxxxxx. Please cc me.
>
> Also, Chris Barker replied separately saying that their needs our almost
> always met by THREDDS servers, so he thought our operational and actively
> maintained NANOOS THREDDS server may meet his needs. If the hyrax server in
> question was in fact originally deployed only to meet NOAA ORR needs, and
> those needs can now be met by our THREDDS server, the decision might be to
> discontinue the hyrax server. But that'll be up to Alexandre.
>
> Cheers,
> -Emilio
>
>
> On Wed, Oct 19, 2016 at 5:34 AM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
>
> I would appreciate knowing what part of the behavior/output of the
> ingria.coas.oregonstate.edu Hyrax server has led to the comments that it is
> not configured correctly.
>
> - Is it simply that the server is producing an error when trying to transmit
> the “ntimes” variable?
> - Is there something specific in the NcML content that speaks directly to
> this?
> - In the context of this thread does “configuration problem/issue” mean an
> improperly constructed NcML file?
>
> Can anyone provide some insight?
>
> By asking these questions I am trying to understand, and not in anyway
> dispute, the assertion that the server is “misconfigured”. I just want to
> tease apart the possibility that we are seeing a fundamental bug problem from
> a configuration issue.
>
> I do know that at NASA’s request and expense a significant number of changes
> and improvements have been made to Hyrax’s NcML features, but this work
> happened long after the release of version 1.9.0.
>
> In light of this I think the first step should be to instigate upgrading the
> server, as version 1.9.0 is a long way back and not only does the latest
> release (1.13.1) offer an improved NcML implementation it also contains
> numerous security updates.
>
> Regardless, any clarification that could be offered w.r.t. the
> mis-configuration assertion would be very helpful to me.
>
>
> Sincerely,
>
> Nathan
>
>
>
>
> > On Oct 18, 2016, at 11:30 PM, Emilio Mayorga <emiliomayorga@xxxxxxxxx>
> > wrote:
> >
> > I'm afraid I don't have much helpful insight to bring into this. The model
> > behind that Hyrax server is indeed a NANOOS model, but the hyrax server
> > itself was not set up and is not maintained by one of us in the NANOOS DMAC
> > team. In fact, if I remember correctly the server is somewhat duplicative
> > of a THREDDS server we do maintain for the same model output; it was setup
> > about two years ago, I think to support an application at NOAA ORR that
> > took advantage of some specific hyrax capability missing in THREDDS'
> > OPeNDAP (Chris Barker would know better than me), partly through help and
> > persuasion from Rich Signell; again, sketchy memory here. I was never
> > thrilled with the idea of having a hyrax server in the mix when none of us
> > had the capacity to invest in learning how to properly maintain it, and
> > already had a THREDDS server for the same model. I'm not surprised to hear
> > it's an old version, too.
> >
> > Sorry ...
> >
> > -Emilio
> >
> >
> > On Mon, Oct 17, 2016 at 5:36 PM, Chris Barker <chris.barker@xxxxxxxx> wrote:
> > Folks,
> >
> > I manged to do a tcpdump, and can (sortof) see what's going on -- though I
> > can't really make sense of it -- maybe one of you can?
> >
> > This is running the enclosed script, to it first does the successful pydap
> > request, then the unsuccessful netCDF4 request.
> >
> > (though it looking like this is a poorly configured server...)
> >
> > -CHB
> >
> >
> > On Mon, Oct 17, 2016 at 4:49 PM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
> > By which I meant - just deference the URL:
> >
> >
> > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> >
> > To get the NcML file:
> >
> > curl
> > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> >
> >
> >
> > Nathan
> >
> >
> >
> > > On Oct 17, 2016, at 4:37 PM, Nathan Potter <ndp@xxxxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > Seems like no one has tried to actually ask for the NcML file:
> > >
> > > http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml
> > >
> > >
> > > N
> > >
> > >
> > >> On Oct 17, 2016, at 4:35 PM, Roy Mendelssohn - NOAA Federal
> > >> <roy.mendelssohn@xxxxxxxx> wrote:
> > >>
> > >> Hi Emilio:
> > >>
> > >> I believe this is a NaNOOS server. If you can read over the thread,,
> > >> any insight would be appreciated, What is in the .ncml file could be of
> > >> interest.
> > >>
> > >> Thanks,
> > >>
> > >> -roy
> > >>
> > >>> On Oct 17, 2016, at 4:20 PM, Chris Barker <Chris.Barker@xxxxxxxx> wrote:
> > >>>
> > >>> On Mon, Oct 17, 2016 at 3:57 PM, Roy Mendelssohn - NOAA Federal
> > >>> <roy.mendelssohn@xxxxxxxx> wrote:
> > >>> I find that if you go to the html page, many of the variables at the
> > >>> top can't be accessed requesting ascii, so there are clearly problems
> > >>> with how this is set up
> > >>>
> > >>> that does point to server issues.
> > >>>
> > >>> I am wondering if these are defined in the .ncml. It would be
> > >>> interesting to see what the .ncml file looks like.
> > >>>
> > >>> One thing to consider also is pydap does not call the C library IIRC,
> > >>> it is a pure python implementation
> > >>>
> > >>> Exactly -- so it takes the netcdf C lib out of the picture -- which
> > >>> means there is a protocol that pydap and hyrax are speaking that lets
> > >>> the data be accessed...
> > >>>
> > >>> If anyone knows how to see what actual requests are being made by the
> > >>> two, we might be able to figure out where the failure is...
> > >>>
> > >>> -CHB
> > >>>
> > >>>
> > >>> -Roy
> > >>>
> > >>>> On Oct 17, 2016, at 3:33 PM, dmh@xxxxxxxx wrote:
> > >>>>
> > >>>> The difference with pydap is probably that you adding a constraint
> > >>>> that is causing the server to ignore whatever variable
> > >>>> is causing the problem. If you ask pydap for the whole
> > >>>> dataset, does it fail?
> > >>>> (e.g. something like:
> > >>>> http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml.ascii
> > >>>> =Dennis Heimbigner
> > >>>> Unidata
> > >>>>
> > >>>> On 10/17/2016 4:16 PM, Chris Barker wrote:
> > >>>>> On Mon, Oct 17, 2016 at 2:36 PM, dmh@xxxxxxxx <mailto:dmh@xxxxxxxx>
> > >>>>> <dmh@xxxxxxxx <mailto:dmh@xxxxxxxx>> wrote:
> > >>>>>
> > >>>>> The log and show=fetch appear to not work under python
> > >>>>> for some reason; stdout/stderr redirect?
> > >>>>>
> > >>>>>
> > >>>>> I don't think so -- and I do get a lot of "Log:prefetch" messages, so
> > >>>>> stdout.stderr seems to be working.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> In any case I can duplicate the error using wget e.g.
> > >>>>> wget
> > >>>>>
> > >>>>> 'http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods
> > >>>>>
> > >>>>> <http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods>'
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> hmm, I don't seem to have wget, but with curl, I get the below
> > >>>>> results,
> > >>>>> ending in:
> > >>>>>
> > >>>>> Data:
> > >>>>>
> > >>>>> Error {
> > >>>>>
> > >>>>> code = -111;
> > >>>>>
> > >>>>> message = "libdap error transmitting DataDDS: Could not read the
> > >>>>> variable `ntimes'.";
> > >>>>>
> > >>>>> -- if that's the fatal error, then yup -- not the netcdf lib -- and
> > >>>>> yet,
> > >>>>> we can get the data with PyDAP, and if I put this:
> > >>>>>
> > >>>>>
> > >>>>> http://ingria.coas.oregonstate.edu/opendap/aggregation/ocean_time_aggregation.ncml.ascii?u[0][0][0:10][0:10]
> > >>>>>
> > >>>>> into my browser, I do get data.
> > >>>>>
> > >>>>> I have asked this on support@xxxxxxxxxxx <mailto:support@xxxxxxxxxxx>
> > >>>>> --
> > >>>>> and they have pointed out that that is a pretty old version of Hyrax
> > >>>>> --
> > >>>>> _maybe_ that's the problem.
> > >>>>>
> > >>>>> -CHB
> > >>>>>
> > >>>>>
> > >>>>> $ curl
> > >>>>> 'http://ingria.coas.oregonstate.edu:80/opendap/aggregation/ocean_time_aggregation.ncml.dods'
> > >>>>>
> > >>>>> Dataset {
> > >>>>>
> > >>>>> Int32 ntimes;
> > >>>>>
> > >>>>> Int32 ndtfast;
> > >>>>>
> > >>>>> Float64 dt;
> > >>>>>
> > >>>>> Float64 dtfast;
> > >>>>>
> > >>>>> Float64 dstart;
> > >>>>>
> > >>>>> Int32 nHIS;
> > >>>>>
> > >>>>> Int32 ndefHIS;
> > >>>>>
> > >>>>> Int32 nRST;
> > >>>>>
> > >>>>> Int32 ntsAVG;
> > >>>>>
> > >>>>> Int32 nAVG;
> > >>>>>
> > >>>>> Int32 ndefAVG;
> > >>>>>
> > >>>>> Float64 Falpha;
> > >>>>>
> > >>>>> Float64 Fbeta;
> > >>>>>
> > >>>>> Float64 Fgamma;
> > >>>>>
> > >>>>> Float64 nl_tnu2[tracer = 2];
> > >>>>>
> > >>>>> Float64 nl_visc2;
> > >>>>>
> > >>>>> Float64 Akt_bak[tracer = 2];
> > >>>>>
> > >>>>> Float64 Akv_bak;
> > >>>>>
> > >>>>> Float64 Akk_bak;
> > >>>>>
> > >>>>> Float64 Akp_bak;
> > >>>>>
> > >>>>> Float64 rdrg;
> > >>>>>
> > >>>>> Float64 rdrg2;
> > >>>>>
> > >>>>> Float64 Zob;
> > >>>>>
> > >>>>> Float64 Zos;
> > >>>>>
> > >>>>> Float64 Znudg;
> > >>>>>
> > >>>>> Float64 M2nudg;
> > >>>>>
> > >>>>> Float64 M3nudg;
> > >>>>>
> > >>>>> Float64 Tnudg[tracer = 2];
> > >>>>>
> > >>>>> Float64 FSobc_in[boundary = 4];
> > >>>>>
> > >>>>> Float64 FSobc_out[boundary = 4];
> > >>>>>
> > >>>>> Float64 M2obc_in[boundary = 4];
> > >>>>>
> > >>>>> Float64 M2obc_out[boundary = 4];
> > >>>>>
> > >>>>> Float64 Tobc_in[boundary = 4][tracer = 2];
> > >>>>>
> > >>>>> Float64 Tobc_out[boundary = 4][tracer = 2];
> > >>>>>
> > >>>>> Float64 M3obc_in[boundary = 4];
> > >>>>>
> > >>>>> Float64 M3obc_out[boundary = 4];
> > >>>>>
> > >>>>> Float64 rho0;
> > >>>>>
> > >>>>> Float64 gamma2;
> > >>>>>
> > >>>>> Int32 LtracerSrc[tracer = 2];
> > >>>>>
> > >>>>> Int32 spherical;
> > >>>>>
> > >>>>> Float64 xl;
> > >>>>>
> > >>>>> Float64 el;
> > >>>>>
> > >>>>> Int32 Vtransform;
> > >>>>>
> > >>>>> Int32 Vstretching;
> > >>>>>
> > >>>>> Float64 theta_s;
> > >>>>>
> > >>>>> Float64 theta_b;
> > >>>>>
> > >>>>> Float64 Tcline;
> > >>>>>
> > >>>>> Float64 hc;
> > >>>>>
> > >>>>> Float64 s_rho[s_rho = 40];
> > >>>>>
> > >>>>> Float64 s_w[s_w = 41];
> > >>>>>
> > >>>>> Grid {
> > >>>>>
> > >>>>> Array:
> > >>>>>
> > >>>>> Float64 Cs_r[s_rho = 40];
> > >>>>>
> > >>>>> Maps:
> > >>>>>
> > >>>>> Float64 s_rho[s_rho = 40];
> > >>>>>
> > >>>>> } Cs_r;
> > >>>>>
> > >>>>> Grid {
> > >>>>>
> > >>>>> Array:
> > >>>>>
> > >>>>> Float64 Cs_w[s_w = 41];
> > >>>>>
> > >>>>> Maps:
> > >>>>>
> > >>>>> Float64 s_w[s_w = 41];
> > >>>>>
> > >>>>> } Cs_w;
> > >>>>>
> > >>>>> Float64 user[Nuser = 25];
> > >>>>>
> > >>>>> Float64 h[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 f[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 pm[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 pn[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 lon_rho[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 lat_rho[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 lon_u[eta_u = 522][xi_u = 309];
> > >>>>>
> > >>>>> Float64 lat_u[eta_u = 522][xi_u = 309];
> > >>>>>
> > >>>>> Float64 lon_v[eta_v = 521][xi_v = 310];
> > >>>>>
> > >>>>> Float64 lat_v[eta_v = 521][xi_v = 310];
> > >>>>>
> > >>>>> Float64 lon_psi[eta_psi = 521][xi_psi = 309];
> > >>>>>
> > >>>>> Float64 lat_psi[eta_psi = 521][xi_psi = 309];
> > >>>>>
> > >>>>> Float64 angle[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 mask_rho[eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float64 mask_u[eta_u = 522][xi_u = 309];
> > >>>>>
> > >>>>> Float64 mask_v[eta_v = 521][xi_v = 310];
> > >>>>>
> > >>>>> Float64 mask_psi[eta_psi = 521][xi_psi = 309];
> > >>>>>
> > >>>>> Float64 ocean_time[ocean_time = 1026];
> > >>>>>
> > >>>>> Float32 zeta[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 ubar[ocean_time = 1026][eta_u = 522][xi_u = 309];
> > >>>>>
> > >>>>> Float32 vbar[ocean_time = 1026][eta_v = 521][xi_v = 310];
> > >>>>>
> > >>>>> Float32 u[ocean_time = 1026][s_rho = 40][eta_u = 522][xi_u = 309];
> > >>>>>
> > >>>>> Float32 v[ocean_time = 1026][s_rho = 40][eta_v = 521][xi_v = 310];
> > >>>>>
> > >>>>> Float32 w[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 temp[ocean_time = 1026][s_rho = 40][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 salt[ocean_time = 1026][s_rho = 40][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 AKv[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 AKt[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 AKs[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 tke[ocean_time = 1026][s_w = 41][eta_rho = 522][xi_rho =
> > >>>>> 310];
> > >>>>>
> > >>>>> Float32 shflux[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 latent[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 sensible[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 lwrad[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> Float32 swrad[ocean_time = 1026][eta_rho = 522][xi_rho = 310];
> > >>>>>
> > >>>>> } ocean_time_aggregation.ncml;
> > >>>>>
> > >>>>> Data:
> > >>>>>
> > >>>>> Error {
> > >>>>>
> > >>>>> code = -111;
> > >>>>>
> > >>>>> message = "libdap error transmitting DataDDS: Could not read the
> > >>>>> variable `ntimes'.";
> > >>>>>
> > >>>>> };
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> Christopher Barker, Ph.D.
> > >>>>> Oceanographer
> > >>>>>
> > >>>>> Emergency Response Division
> > >>>>> NOAA/NOS/OR&R (206) 526-6959 voice
> > >>>>> 7600 Sand Point Way NE (206) 526-6329 fax
> > >>>>> Seattle, WA 98115 (206) 526-6317 main reception
> > >>>>>
> > >>>>> Chris.Barker@xxxxxxxx <mailto:Chris.Barker@xxxxxxxx>
> > >>>>
> > >>>> _______________________________________________
> > >>>> NOTE: All exchanges posted to Unidata maintained email lists are
> > >>>> recorded in the Unidata inquiry tracking system and made publicly
> > >>>> available through the web. Users who post to any of the lists we
> > >>>> maintain are reminded to remove any personal information that they
> > >>>> do not want to be made public.
> > >>>>
> > >>>>
> > >>>> netcdfgroup mailing list
> > >>>> netcdfgroup@xxxxxxxxxxxxxxxx
> > >>>> For list information or to unsubscribe, visit:
> > >>>> http://www.unidata.ucar.edu/mailing_lists/
> > >>>
> > >>> **********************
> > >>> "The contents of this message do not reflect any position of the U.S.
> > >>> Government or NOAA."
> > >>> **********************
> > >>> Roy Mendelssohn
> > >>> Supervisory Operations Research Analyst
> > >>> NOAA/NMFS
> > >>> Environmental Research Division
> > >>> Southwest Fisheries Science Center
> > >>> ***Note new address and phone***
> > >>> 110 Shaffer Road
> > >>> Santa Cruz, CA 95060
> > >>> Phone: (831)-420-3666
> > >>> Fax: (831) 420-3980
> > >>> e-mail: Roy.Mendelssohn@xxxxxxxx www: http://www.pfeg.noaa.gov/
> > >>>
> > >>> "Old age and treachery will overcome youth and skill."
> > >>> "From those who have been given much, much will be expected"
> > >>> "the arc of the moral universe is long, but it bends toward justice"
> > >>> -MLK Jr.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Christopher Barker, Ph.D.
> > >>> Oceanographer
> > >>>
> > >>> Emergency Response Division
> > >>> NOAA/NOS/OR&R (206) 526-6959 voice
> > >>> 7600 Sand Point Way NE (206) 526-6329 fax
> > >>> Seattle, WA 98115 (206) 526-6317 main reception
> > >>>
> > >>> Chris.Barker@xxxxxxxx
> > >>
> > >> **********************
> > >> "The contents of this message do not reflect any position of the U.S.
> > >> Government or NOAA."
> > >> **********************
> > >> Roy Mendelssohn
> > >> Supervisory Operations Research Analyst
> > >> NOAA/NMFS
> > >> Environmental Research Division
> > >> Southwest Fisheries Science Center
> > >> ***Note new address and phone***
> > >> 110 Shaffer Road
> > >> Santa Cruz, CA 95060
> > >> Phone: (831)-420-3666
> > >> Fax: (831) 420-3980
> > >> e-mail: Roy.Mendelssohn@xxxxxxxx www: http://www.pfeg.noaa.gov/
> > >>
> > >> "Old age and treachery will overcome youth and skill."
> > >> "From those who have been given much, much will be expected"
> > >> "the arc of the moral universe is long, but it bends toward justice"
> > >> -MLK Jr.
> > >>
> > >
> > > = = =
> > > Nathan Potter ndp at opendap.org
> > > OPeNDAP, Inc. +1.541.231.3317
> > >
> >
> > = = =
> > Nathan Potter ndp at opendap.org
> > OPeNDAP, Inc. +1.541.231.3317
> >
> >
> >
> >
> > --
> >
> > Christopher Barker, Ph.D.
> > Oceanographer
> >
> > Emergency Response Division
> > NOAA/NOS/OR&R (206) 526-6959 voice
> > 7600 Sand Point Way NE (206) 526-6329 fax
> > Seattle, WA 98115 (206) 526-6317 main reception
> >
> > Chris.Barker@xxxxxxxx
> >
>
> = = =
> Nathan Potter ndp at opendap.org
> OPeNDAP, Inc. +1.541.231.3317
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker@xxxxxxxx
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
