Ahh ok, cool I'll look into that a bit more closely. I've got the code to the point where basic mosaicing is working and it can handle all of the time series stuff and now am going to circle back and clean a few things up.
I'll definitely put this into a community module. I've already had someone from the community reach out expressing interest in the code. I'll start a separate through on geotools-devel for that soon. Thanks again for the all of the feedback and help! On Thu, Nov 29, 2018 at 9:32 AM Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Thu, Nov 29, 2018 at 5:27 PM Justin Deoliveira <jdeol...@gmail.com> > wrote: > >> Thanks Andrea. >> >> So yeah, re managing the connections the current implementation I have >> allows you to specify the the connection params directly, ie the reader >> would manage it's own connection pool. But also allow for grabbing the >> connection from JNDI. Basically what the JDBC datastores do. For the >> project I am going to deploy this in the JNDI option will be what we use to >> optimize the connection usage. >> >> Passing in a connection pool via a hint would also work nicely, basically >> the same way it works when an ExecutorService is passed in. I am not sure >> what the GeoServer side of that looks like though... >> > > Yeah, that would need to be "invented". Like some setting to pick the > connection pool from some other existing store for example. > To be honest, I have been itching to add to GeoServer connection pool as > first class catalog objects that can then be passed around to various > stores, but never got around to do it. > > >> It would also be nice to utilize the apis in coverage for serving up >> multiple coverages from a single reader. I went down that route but was a >> little confused as to how well this is supported. >> AbstractGridCoverage2DReader seems to be written to maintain state about >> multiple coverages which is good. But on the GeoServer side I am unsure if >> the relationship between coverage store and coverage has to be 1:1... has >> this changed at all recently? Or maybe it was always possible... not sure. >> Anyways, if it was possible to use a single reader instance for multiple >> coverages from the same coverage store storing a connection pool in that >> reader would also be a good way to share the connection pool. >> > > We do manage multilple rasters per reader with mosaic and netcdf without > particular problems. If memory serves me right, ResourcePool wraps the > readers with a renaming class that gives the rest of the code the illusion > there is a single raster in the reader. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
