Great work guys. Yes, I changed the API a little since the last ncWMS/THREDDS
integration and will have to think about this when we do the next one. Sounds
like you've done most of the work already so Ethan and I should have an easy
job!
Cheers, Jon
-----Original Message-----
From: Matthias Müller [mailto:Matthias_Mueller@xxxxxxxxxxxxx]
Sent: 30 June 2011 14:53
To: Marcos Hermida
Cc: ncwms-users@xxxxxxxxxxxxxxxxxxxxx; thredds
Subject: Re: [Ncwms-users] Integrating ncWMS trunk into THREDDS
Hi Marcos,
I got your solution working - good job! I only applied the thredds patch and
adjusted our ncWMS a little different (with the same effect obviously ;-) ).
Seems that all the read methods (horizontal, vertical) in
uk.ac.rdg.resc.edal.cdm.CdmUtils had been changed to take a NetCdfDataset as an
argument which is hard to get out of THREDDS at the ScalarLayer level.
Re-implementing some of the older methods is a convenient way to make the two
compatible again.
Thanks,
Matthias
Am 23.06.2011 10:03, schrieb Matthias Müller:
> Hi Marcos,
>
> thank you very much for posting this solution! I will try to adopt
> your modifications for our THREDDS server.
>
>
> Cheers,
> Matthias
>
> Am 17.06.2011 19:02, schrieb Marcos Hermida:
>> Hi Matthias (and all),
>>
>> I've followed your work integrating ncWMS trunk into THREDDS and
>> after adding a few more changes to both ncWMS trunk and TDS code I
>> got it working.
>>
>> I've worked on 919 code revision of ncWMS trunk and on 13794 revision
>> of TDS. The features added to TDS are the Kyle Wilcox's styles for
>> vector layers (the styles weren't added to the capabilities_xml.jsp
>> and capabilities_xml_1_1_1.jsp files yet so they aren't announced in
>> the capabilities documents) and the GetVerticalProfile and
>> GetVerticalSection requests.
>>
>> Besides the code changes, I had to update the
>> geotk-bundle-referencing.jar from version 3.04 to version 3.17 and
>> add the prtree.jar on TDS third party libraries needed for runtime.
>>
>> I understand these changes aren't the best way to do the integration
>> but at least are a workaround while there isn't a new TDS version
>> with an updated ncWMS and in case someone else is interested.
>>
>>
>> Cheers!
>>
>> On May 9, 2011 at 8:50 AM "Matthias Müller"
>> <Matthias_Mueller@xxxxxxxxxxxxx> wrote:
>>
>> > Hi Jon and Kyle,
>> >
>> > here are the results of my integration efforts with thredds-trunk
>> > and ncwms-trunk. There's one missing method (from ncwms
>> > ScalarLayer) in ThreddsScalarLayer and ThreddsVectorLayer:
>> >
>> > @Override
>> > public List<List<Float>> readVerticalSection(DateTime arg0,
>> > List<Double> arg1, Domain<HorizontalPosition> arg2) throws
>> > InvalidDimensionValueException, IOException {}
>> >
>> > I don't have a good idea how to implement the missing logic. Maybe
>> > you can use the attached diff to prepare the next release or a
>> > preliminary patch. This is what I've done so far:
>> >
>> > - set up a combined project from the thredds and ncwms svn
>> > - copied Kyles new ncwms modifications from the git repository
>> >
>> (https://github.com/asascience/THREDDS/commit/53987775e1bdd31b533f516
>> 383226ac3b77e5b58)
>>
>> > - removed everything that had to do with "nearest time" (in favour
>> > of a first "clean" integration)
>> > - updated some method names in the thredds classes that had changed
>> > in the current ncwms
>> >
>> > Cheers,
>> > Matthias
>> >
>> > Am 04.05.2011 20:24, schrieb Jon Blower:
>> > > Matthias,
>> > >
>> > > Yes, the TDS trunk is a bit out of sync with the ncWMS trunk so
>> > > you
>> can't easily port a custom ncWMS into TDS. (In theory, the
>> "jar-for-THREDDS" ant target in ncWMS will generate the right JAR
>> file, but as it stands it won't drop into THREDDS.)
>> > >
>> > > Kyle's work below might fix the issue, but Ethan and I need to
>> > > work
>> this up properly for a near-future THREDDS release.
>> > >
>> > > Cheers, Jon
>> > >
>> > > -----Original Message-----
>> > > From: Kyle Wilcox [mailto:KWilcox@xxxxxxxxxxxxxx]
>> > > Sent: 04 May 2011 14:30
>> > > To: 'Matthias Müller'
>> > > Cc: 'ncwms-users@xxxxxxxxxxxxxxxxxxxxx'
>> > > Subject: Re: [Ncwms-users] [thredds] Simple fix => much smaller
>> > > TDS
>> WMS GetCapabilities size (for model output)
>> > >
>> > > I don't know if anyone has tested this, but try this:
>> > >
>> > > https://github.com/asascience/ToolsUI
>> > >
>> > > These are NetBeans projects for TDS and ToolsUI. It includes the
>> TRUNK NetCDF-Java codebase as a git submodule (see README). The
>> NetCDF-Java codebase is here: https://github.com/asascience/THREDDS.
>> I update the THREDDS codebase weekly to the trunk.
>> > >
>> > > There are issues with the maven and ant files in NetCDF-Java...
>> some don't generate the JARs in the correct places or with the
>> correct version numbers. You may have to play with this a bit.
>> > >
>> > > I also gave a small shot at getting NcWMS trunk into TDS trunk
>> > > last
>> December:
>> > >
>> > >
>> https://github.com/asascience/THREDDS/commit/53987775e1bdd31b533f5163
>> 83226ac3b77e5b58
>>
>> > >
>> > > If you get it working, please send me the patch or a pull request!
>> > >
>> > > ---------
>> > > Kyle Wilcox, Engineer
>> > > Applied Science Associates
>> > > 55 Village Square Drive
>> > > South Kingstown, RI 02879
>> > > p: (401) 789-6224
>> > > e: kwilcox@xxxxxxxxxxxxxx
>> > >
>> > >
>> > >> -----Original Message-----
>> > >> From: Matthias Müller [mailto:Matthias_Mueller@xxxxxxxxxxxxx]
>> > >> Sent: Wednesday, May 04, 2011 8:30 AM
>> > >> To: ncwms-users@xxxxxxxxxxxxxxxxxxxxx
>> > >> Subject: Re: [Ncwms-users] [thredds] Simple fix => much smaller
>> > >> TDS WMS GetCapabilities size (for model output)
>> > >>
>> > >> Hello Jon, all,
>> > >>
>> > >> this issue (see below) was discussed earlier his year on the
>> > >> thredds mailing list. Is there any documentation on how to set
>> > >> up a combined ncwms/thredds project (e.g. in eclipse or
>> > >> netbeans?) to
>> incoporate the
>> > >> changes into a current thredds distribution? I've modified the
>> > >> old ncwms classes that were used for THREDDS 4.2 and
>> > >> re-integrated them, but some cross-dependencies keep raising errors at
>> > >> runtime.
>> > >>
>> > >> Thanks,
>> > >> Matthias
>> > >>
>> > >>
>> > >> Am 04.01.2011 16:28, schrieb Jon Blower:
>> > >>> Hi Kyle,
>> > >>>
>> > >>> Great that you've had a go at #1. I'll chew it over and merge
>> > >>> it
>> > >> when I get a chance.
>> > >>>
>> > >>> Regarding the custom URL parameter - generally I agree that
>> > >>> non-
>> > >> standard params are to be avoided if possible, but actually in
>> > >> the case of a Capabilities doc I don't think it's so bad. A GIS
>> > >> will often ask for the full Capabilities URL, in which case you
>> > >> can
>> simply
>> > >> add the custom parameter to the URL that's given. If the GIS
>> > >> asks
>> for
>> > >> the "base" URL, it can still work, i.e. you pass it:
>> > >>>
>> > >>> http://myserver.com/wms?CUSTOM_PARAM=foo
>> > >>>
>> > >>> instead of
>> > >>>
>> > >>> http://myserver.com/wms.
>> > >>>
>> > >>> ncWMS does this already, in fact, with the DATASET parameter
>> > >>> (which
>> > >> isn't used in TDS-WMS).
>> > >>>
>> > >>> Cheers, Jon
>> > >>>
>> > >>> -----Original Message-----
>> > >>> From: Kyle Wilcox [mailto:KWilcox@xxxxxxxxxxxxxx]
>> > >>> Sent: 04 January 2011 15:10
>> > >>> To: 'Jon Blower'; thredds@xxxxxxxxxxxxxxxx
>> > >>> Subject: RE: [thredds] Simple fix => much smaller TDS WMS
>> > >> GetCapabilities size (for model output)
>> > >>>
>> > >>> I'd prefer a configurable setting rather than a custom URL
>> parameter.
>> > >> I try to avoid extending specifications if at all possible. No
>> > >> existing clients will know about the additional parameter, and
>> > >> some datasets won't benefit from start/stop/step. On the
>> > >> downside, the GetCap could list all of the times for some
>> > >> datasets, and use start/stop/step for some others. At least with
>> > >> a URL parameter, it would be consistent.
>> > >>>
>> > >>>
>> > >>>
>> > >>> I took a simple stab at #1 a few weeks ago. The rounding isn't
>> > >> triggered by a flag in the GetCapabilities request, it is
>> > >> instead enabled by using a checkbox in the admin panel on each
>> > >> dataset
>> > >>>
>> > >>> It finds the smallest interval between all timesteps in the
>> > >>> dataset
>> > >> and then assumes that this interval is consistent throughout the
>> > >> dataset. It steps through all of the timesteps and if the
>> > >> interval between two adjacent timesteps is greater than the
>> > >> smallest found interval, it ends the current "start/stop/step" and
>> > >> starts another.
>> > >>>
>> > >>>> From what I've seen, it works, but I haven't tested it at all.
>> > >>>
>> > >>>
>> > >>
>> https://github.com/asascience/ncWMS/commit/9e2925fc607a05d6484299e017
>> d
>> > >> b
>> > >> 0180a2200fa4
>> > >>>
>> > >>>
>> > >>> ---------
>> > >>> Kyle Wilcox, Engineer
>> > >>> Applied Science Associates
>> > >>> 55 Village Square Drive
>> > >>> South Kingstown, RI 02879
>> > >>> p: (401) 789-6224
>> > >>> e: kwilcox@xxxxxxxxxxxxxx
>> > >>>
>> > >>> -----Original Message-----
>> > >>> From: thredds-bounces@xxxxxxxxxxxxxxxx [mailto:thredds-
>> > >> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jon Blower
>> > >>> Sent: Tuesday, January 04, 2011 5:54 AM
>> > >>> To: thredds@xxxxxxxxxxxxxxxx
>> > >>> Subject: Re: [thredds] Simple fix => much smaller TDS WMS
>> > >> GetCapabilities size (for model output)
>> > >>>
>> > >>> Hi all,
>> > >>>
>> > >>> I can certainly see that there is a problem that needs to be
>> > >> addressed here (explicit lists of all individual TIME values
>> cause the
>> > >> Capabilities document to blow up). There are actually two
>> > >> approaches to this, which could be used individually or in combination:
>> > >>>
>> > >>> 1) Use the syntax start/stop/period, potentially multiple
>> > >>> times, to
>> > >> define the TIME values instead of listing them explicitly.
>> > >>>
>> > >>> 2) Use Layer inheritance properties to define the time
>> > >>> dimension once
>> > >> only, if the same time axis is shared by all the children of a
>> parent
>> > >> layer:
>> > >>>
>> > >>> <Layer>
>> > >>> <Title>My Model Output</Title>
>> > >>> <!-- Non-displayable parent Layer --> <Dimension name="time">
>> > >>> ... values ...</Dimension> <Layer>
>> > >>> <Title>sea_water_temperature</Title>
>> > >>> <Name>TMP</Name>
>> > >>> <!-- Inherits time axis from parent --> </Layer>
>> > >>> <!-- More child layers -->
>> > >>> <!-- Children can override the time axis if theirs is different
>> > >> for some reason --> </Layer>
>> > >>>
>> > >>> The most concise possible Capabilities doc would be achieved by
>> > >> combining both approaches.
>> > >>>
>> > >>> I feel that we should ensure that only those time values that
>> > >>> are
>> > >> actually present should appear in the Capabilities doc - I think
>> > >> things get a bit confusing if the Capabilities doc advertises
>> > >> "missing" times (what would the returned image from a missing
>> > >> time look like?). I also agree with Bob Simons that the use of "nearest"
>> > >> values is dangerous, even though it's in the spec (sorry Kyle) -
>> > >> the client can always perform the nearest-neighbour calculation
>> > >> if
>> this is
>> > >> required, given the server's advertised capabilities. (Feel free
>> > >> to disagree with me of course!)
>> > >>>
>> > >>> I can see two potential problems:
>> > >>>
>> > >>> 1. Solution 1 above is a bit tricky to implement in the general
>> > >>> case,
>> > >> avoiding the corner cases. (Solution 2 would actually be pretty
>> > >> easy to implement.)
>> > >>>
>> > >>> 2. As Ethan and Roy have pointed out, third-party client
>> > >>> support
>> for
>> > >> multidimensional WMS is, er, generally not great. It's hard
>> enough to
>> > >> find a client that supports TIME at all, never mind all the
>> > >> possible syntaxes. I'm torn on this - in one respect it's not
>> > >> our problem,
>> but
>> > >> we don't want to cut out portions of the user base.
>> > >>>
>> > >>> So, after all this, I propose a solution:
>> > >>>
>> > >>> 1. Implement one or both measures above, ensuring that the
>> > >> Capabilities document is accurate. This may involve being
>> > >> conservative. The default Capabilities doc would be much smaller.
>> > >>>
>> > >>> 2. Allow clients to specify a URL parameter to GetCapabilities
>> > >>> that
>> > >> triggers the generation of a Capabilities document that *does*
>> > >> list all the time values explicitly, allowing compatibility with
>> > >> some GIS clients. (Clients usually require a URL to the Cap doc,
>> > >> which could include this non-standard URL parameter. Or the
>> > >> parameter could be considered part of the "base URL").
>> > >>>
>> > >>> Does anyone have any thoughts on this before I start an
>> > >> implementation? It's tempting to implement the "layer inheritance"
>> > >> solution first since it's easiest; I think this would be
>> effective in
>> > >> TDS, where each Cap doc usually represents a single model run,
>> > >> which will usually have a single time axis, shared among all variables.
>> > >>>
>> > >>> Happy New Year!
>> > >>> Jon
>> > >>>
>> > >>> --
>> > >>> Dr Jon Blower
>> > >>> Technical Director, Reading e-Science Centre Environmental
>> > >>> Systems
>> > >> Science Centre University of Reading, UK
>> > >>> Tel: +44 (0)118 378 5213
>> > >>> http://www.resc.reading.ac.uk
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> thredds mailing list
>> > >>> thredds@xxxxxxxxxxxxxxxx
>> > >>> For list information or to unsubscribe, visit:
>> > >> http://www.unidata.ucar.edu/mailing_lists/
>> > >>>
>> > >>> _______________________________________________
>> > >>> thredds mailing list
>> > >>> thredds@xxxxxxxxxxxxxxxx
>> > >>> For list information or to unsubscribe, visit:
>> > >> http://www.unidata.ucar.edu/mailing_lists/
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Matthias Müller
>> > >> Dipl.-Geogr. | Research Associate
>> > >>
>> > >> Technische Universität Dresden
>> > >> Geoinformation Systems
>> > >> 01062 Dresden
>> > >>
>> > >> Phone: +49 351 463-31953
>> > >> Fax: +49 351 463-35879
>> > >> Mail: Matthias_Mueller@xxxxxxxxxxxxx
>> > >>
>> > >> www: http://tu-dresden.de/fgh/geo/gis
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> -
>> > >> -
>> > >> -------
>> > >> WhatsUp Gold - Download Free Network Management Software The
>> > >> most intuitive, comprehensive, and cost-effective network
>> > >> management toolset available today. Delivers lowest initial
>> > >> acquisition cost
>> and
>> > >> overall TCO of any competing solution.
>> > >> http://p.sf.net/sfu/whatsupgold-sd
>> > >> _______________________________________________
>> > >> Ncwms-users mailing list
>> > >> Ncwms-users@xxxxxxxxxxxxxxxxxxxxx
>> > >> https://lists.sourceforge.net/lists/listinfo/ncwms-users
>> > >
>> > >
>> ---------------------------------------------------------------------
>> ---------
>>
>> > > WhatsUp Gold - Download Free Network Management Software The most
>> intuitive, comprehensive, and cost-effective network management
>> toolset available today. Delivers lowest initial acquisition cost and
>> overall TCO of any competing solution.
>> > > http://p.sf.net/sfu/whatsupgold-sd
>> > > _______________________________________________
>> > > Ncwms-users mailing list
>> > > Ncwms-users@xxxxxxxxxxxxxxxxxxxxx
>> > > https://lists.sourceforge.net/lists/listinfo/ncwms-users
>> > >
>> >
>> >
>> > --
>> > Matthias Müller
>> > Dipl.-Geogr. | Research Associate
>> >
>> > Technische Universität Dresden
>> > Geoinformation Systems
>> > 01062 Dresden
>> >
>> > Phone: +49 351 463-31953
>> > Fax: +49 351 463-35879
>> > Mail: Matthias_Mueller@xxxxxxxxxxxxx
>> >
>> > www: http://tu-dresden.de/fgh/geo/gis
>> >
>
>
>
> ----------------------------------------------------------------------
> -------- Simplify data backup and recovery for your virtual
> environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe, secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
>
>
>
> _______________________________________________
> Ncwms-users mailing list
> Ncwms-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/ncwms-users
--
Matthias Müller
Dipl.-Geogr. | Research Associate
Technische Universität Dresden
Geoinformation Systems
01062 Dresden
Phone: +49 351 463-31953
Fax: +49 351 463-35879
Mail: Matthias_Mueller@xxxxxxxxxxxxx
www: http://tu-dresden.de/fgh/geo/gis
