Yes, it's ready for review :D
On Tue, Jun 21, 2016 at 5:01 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> We can always squash the commits when merging to master.
>
> Is the proposal ready for review now?
>
> --
> Jody Garnett
>
> On 21 June 2016 at 16:55, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Ok so after going down the road of using the PropertiesCollector
>> interface for doing the granule geometry handling and decided to go with my
>> original plan of creating a separate interface for this. I have updated the
>> proposal accordingly.
>>
>> Also, I created a pull request for reference, since it might be easier to
>> follow these changes that way.
>>
>> <https://github.com/geotools/geotools/pull/1220>
>> <https://github.com/geotools/geotools/pull/1220>
>> https://github.com/geotools/geotools/pull/1220
>>
>> I can spend some time cleaning up those commits, since I notice now that
>> there's a few checkpoint commits in there.
>>
>> Cheers
>>
>> On Mon, Jun 20, 2016 at 5:06 PM, Devon Tucker <devonrtuc...@gmail.com>
>> wrote:
>>
>>> The GranuleAcceptor stuff is done on that branch. I have the
>>> PropertiesCollector stuff done locally, but there's some iffy stuff there.
>>> Handling the granule envelope in a PropertiesCollector should be fine, but
>>> there is an issue with how StructuredGridCoverages are handled:
>>>
>>>
>>> https://github.com/dvntucker/geotools/blob/granule_acceptors/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/ImageMosaicConfigHandler.java#L512
>>>
>>> For StructuredGCs all the feature attributes are copied right off the
>>> feature from the input reader, then the properties collectors are called.
>>> I'm not really sure how this would tie in to using a PropertiesCollector
>>> the pre-process the incoming coverage envelope, which makes me wonder if
>>> it's a good idea at all.
>>>
>>>
>>>
>>> On Mon, Jun 20, 2016 at 2:53 PM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Reviewing
>>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility
>>>> it appears up to date (with a remove CatalogManager heading). Are you going
>>>> to verify the approach (on that branch) and then send us an email for the
>>>> completed proposal?
>>>>
>>>> It is hard to leap into this proposal and provide any useful feedback
>>>> as a PMC member, I think the productive conversation is with Simone as
>>>> module maintainer.
>>>> --
>>>> Jody
>>>>
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On 20 June 2016 at 13:48, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
