On Fri, Dec 11, 2009 at 10:34 AM, Daniele Romagnoli <daniele.romagn...@geo-solutions.it> wrote: > Hi Andrea, > sorry for the late reply. Please, read below.... > > > On Thu, Dec 10, 2009 at 11:54 AM, andrea antonello > <andrea.antone...@gmail.com> wrote: >> >> Hi Daniele, >> I am browsing through your netcdf plugin sources and have a couple of >> questions about opendap support. >> >> As we talked it is not supported now, but there seems to be support >> for http/ftp, download and read. >> >> I tried to add the opendap support by assuming that http and dods are >> opendap connections. I got quite far and part of the test works out >> well. >> That is mainly because all in the end goes down and is hidden to the >> NetcdfDataset. >> >> But at a certain point I am stuck: In NetCDFSource, method >> addCoverage, there is a conversion from url to file: >> GridCoverage gc = >> Utilities.compute(BaseFileDriver.urlToFile(access.getInput()), ... >> >> which obviously breaks, since the url is something like: >> >> http://ensemblesrt3.dmi.dk/cgi-bin/nph-dods/data/prudence/monthly/DMI/ECC/precip.CRU.DMI.ECC.nc.gz >> >> I am not sure why here the imagestreams are again being used. Is it >> possible to bring in there the netcdf dataset abstraction? >> How could this be achieved? >> I think opendap support is really too important to get rid of it. > > Basically, in the beginning we only worked with datasets referenced by files > (even by means of URL, String,...). Therefore the Utilities class worked on > top of File. Anyway, we can change it to handle Object and do the proper > checks ("instance of" and similar) in the underlying logic. > Note that the JAI imageRead works on top of an ImageInputStream on its > operations. For your case we can adapt the code by using custom classes of > the imageio-ext-customstreams to leverages on URLInputStream as an instance. > >> >> If you want, I can commit the changes done so far, since they anyways >> do not break anything for the local files stuff, in case we should >> find a moment to review them together. > > These days, some of us are using these plugins in testing some applications. > Although I'm pretty sure you did all tests and your changes don't break > anything, could you please send me a patch for this? > Anyway, we are about to do TAGs to handle this. >
I would say go ahead and commit, Daniele, please keep our own version updated once you have tested the changes. Simone. >> >> Ciao >> Andrea >> >> >> PS: I had to add the opendap jar to the dependencies to try that out. >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > ------------------------------------------------------- > Eng. Daniele Romagnoli > Software Engineer > > GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 328 0559267 > > > http://www.geo-solutions.it > > ------------------------------------------------------- > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
