Hi all,
Based on discussions with Simone and Jody we have made a few changes to
this proposal:
- CatalogManager gets deleted, its methods moved either to
ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations
- Instead of delegating granule acceptance to CatalogManager, as was
originally proposed, this functionality is broken out into its own
interface + factory SPI.
- I changed the granule envelope handling to just use the existing
PropertiesCollector API, since it already sets attributes on the index
feature, I don't really see why not? Not sure if anyone would object to
this.
Also there's a new branch with most of this implemented:
<https://github.com/dvntucker/geotools/tree/granule_acceptors>
<https://github.com/dvntucker/geotools/tree/granule_acceptors>
https://github.com/dvntucker/geotools/tree/granule_acceptors
As usual, let me know if there's any questions or feedback.
On Wed, Jun 15, 2016 at 5:38 AM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:
> 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://sdm.link/zohomanageengine
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
