NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
thredds archives: