Roy,
If you run the Python servers under WSGI it should be
fairly easy to write a custom dispatcher that will do
anything you need. You could also run the Java
Servlet requests through your WSGI dispatcher using
something like Paste proxy.
-Phil
--- Roy Mendelssohn <Roy.Mendelssohn@xxxxxxxx> wrote:
> > Date: Mon, 27 Nov 2006 17:43:43 -0800
> To: thredds@xxxxxxxxxxxxxxxx
> From: "Roy Mendelssohn" <Roy.Mendelssohn@xxxxxxxx>
> Subject: Combining THREDDS and Pydap services
> CC: "Roberto De Almeida" <roberto@xxxxxxxxxxxxx>,
> lynn.dewitt@xxxxxxxx,
> bob.simons@xxxxxxxx
>
> I apologize for the double post. I got my mail
> lists confused (old
> age is setting in), I originally posted to
> support-thredds but meant
> to post it here.
>
> -Roy M.
>
>
> Hi:
>
> I am throwing out to the list a THREDDS related
> server problem that
> we are trying to figure out relatively clean ways to
> solve, in the
> hope that others may have some good ideas on how to
> accomplish this.
>
> We are heavily invested in THREDDS
>
(http://oceanwatch.pfeg.noaa.gov/thredds/catalog.html)
> in particular
> the cataloging and the data aggregation. Most of
> the links on that
> page are not single files but many files (sometimes
> in the
> thousands) being aggregated through time. This is a
> very useful
> feature for the type of data we have.
>
> Also, on an in-house server we have been testing
> Roberto De Almeida's
> pydap implementation of OPeNDAP
> (http://pydap.org/). This server
> has a lot of nice features that we are interested
> in, such as his wms
> service and kml service from an OPeNDAP URL type
> expression.
>
> So what is the issue. Clearly, on web pages that
> are developed in
> house, where a user just clicks on a link, if we
> have both Pydap and
> THREDDS running on the same machine, we can change
> the links to point
> to the appropriate server. But for the more general
> public, or for
> people using the links in scripts etc, we would like
> to have just one
> basic link that depending on the file ending would
> go to the correct
> place.
>
> So right now if I wanted the second time period,
> full extent of one
> of the files the URL would be:
>
>
http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200]
>
> If I wanted an ascii file it would be:
>
>
http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day.ascii?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200]
>
> but what I would like to do is that if I give it:
>
>
http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day.kml?0:1:2320][0:1:3200]
>
> and it would know to switch-over to the pydap server
> and produce the
> kml output (while still being able to view the file
> as a single file
> through the THREDDS aggregation).
>
> Now as given, it is unlikely to work since THREDDS
> is in the URL.
> But suppose we had something like:
>
>
http://oceanwatch.pfeg.noaa.gov/ERD_Data/satellite/AT/ssta/1day.ascii?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200]
>
> or
>
>
http://oceanwatch.pfeg.noaa.gov/ERD_Data/satellite/AT/ssta/1day.kmlATssta[1:1:1][0:1:0][0:1:2320][0:1:3200]
>
> and want it so that in the ascii case it goes to
> THREDDS and in the
> kml case it goes to Pydap.
>
> Ideas we had:
>
> 1. Monkey with the appropriate section in the
> THREDDS java to
> redirect when it recognizes the new service type,
> much as it does
> with WCS services. Downside is we would have to
> monkey with every
> revision and could mess up things in unexpected ways
> in the process.
>
> 2. At the apache or tomcat level, have the
> redirection made (is this
> possible?) based on file type.
>
> 3. Some other solution?
>
> A question I pose to Roberto (as he is copied) but
> may be of general
> interest is if there is a way for Pydap to serve
> OPeNDAP served data
> that is at another URL (even if on the same
> machine), much as
> THREDDS can. It is this that would simplify what it
> would take for us
> to use the aggregation capabilities in THREDDS with
> Pydap in our own
> internal scripts as we can still views these as one
> file - or does
> anyone else have general suggestions as how we might
> combine the
> desirable features of each.
>
> -Roy
> --
> **********************
> "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
> 1352 Lighthouse Avenue
> Pacific Grove, CA 93950-2097
>
> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail
> address)
> voice: (831)-648-9029
> fax: (831)-648-8440
> www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and
skill."
Phil Sharfstein
GODAE Project Manager
Fleet Numerical Meteorology and Oceanography Center
7 Grace Hopper Ave, Stop 1.
Monterey, CA 93943
831.656.4525
Phil.Sharfstein.ctr@xxxxxxxxxxxxxxx
==============================================================================
To unsubscribe thredds, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
