Dear Devon, a few things: -0- we should really get rid of this CatalogManager as is (a class with only static methods as its state its spread over N other classes) -1- we can already mosaick images with different colormodels (to a certain extent, it does not make sense to mosaick a float raster with an RGB). RGB, Gray and Palette can be mosaicked as of today -4- I would add some UML diagrams to your proposal to show what we have now and what we have afterwards
I noticed that you are half-way through with your refactor and its probably too early to look into it but I have two things I wanted to bring up. First of all, I believe you shuold look at the refactor of the indexing together with this, I would not split them otherwise your refactor in this case could be too narrow. Let me explain, your goal here is to improve the harvesting process allowing implementors to change how harvested elements are discarded as well as how they are preprocessed or manipulated and this is not isolated from the harvesting itself. I believe catalogmanager (although) the nice name, might go away and this kind of behavior could be isolated into smaller API likewise we did with the properties collector so that one can drop them inside the imagemosaic and ask it through the indexmanager to apply them. Ideally one could rather write its one harvester and completely customize how we put things inside the GranuleCatalog. Let me know what you think about this. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. On Tue, Jun 14, 2016 at 8:09 PM, Devon Tucker <devonrtuc...@gmail.com> wrote: > Hi all, > > After discussions about the ImageMosaic API proposal we have decided to > break it up into a few smaller pieces that are hopefully both more > manageable to implement and easier to understand. First up is a proposal to > refactor the ImageMosaic CatalogManager to allow parts of it to be > overridden. The first new proposal is here: > > https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility > > I've been doing the work on my own branch here: > > https://github.com/dvntucker/geotools/tree/im_api_refactor > > Further to that, I have another branch where I've been storing R&D work done > against that branch. Most of that work was done much earlier, but I've been > porting my previous test cases to the new branch as I go along for > verification purposes. > > Please take a look and let me know if there's anything that isn't clear. > This proposal is much simpler than the previous one. > > Cheers > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports. > http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
