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
