Also, would it be possible to get commit access to the gt-dem plugin as
well as a branch created for the ImageMosaic API work?
Thanks,
Devon
On Thu, Jun 2, 2016 at 4:19 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:
> Hi Andrea,
>
> Thanks for the questions.
>
> On Wed, Jun 1, 2016 at 11:02 AM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> Hi Jody,
>> at present I cannot vote on the proposal because I have troubles getting
>> a grip on it.
>>
>> Here are a few things that might help understanding, section by section:
>>
>> - *Description*: this is fine, makes sense, no questions (one thing,
>> the recursive file loading during indexing is already the default behavior
>> as far as I know)
>> - *Index Generation: *quite a bit lost here, how are
>> MosaicIndexConfiguration and GranuleCatalogManager going to be used by the
>> existing classes? Or are they replacing it? I'd need to understand how the
>> existing code is going to get reshuffled into a generic machiner plus
>> default implementations of the two above objects? Also, can you provide an
>> example of an alternate implementation (being the refactor targeted to
>> extensibility)
>> - *Harvesting: *same as above, how is the code going to be moved
>> around, and examples of alternate implementations
>>
>>
> I hope to clarify these parts soon. To be honest, these parts were done
> earlier in the project and we've zig-zagged multiple times since then, so
> even I need to revisit to solidify and clarify this section. To give some
> perspective on the original motivations behind this part, at the time we
> were:
>
> - Performing some pre-processing on rasters before indexing them (adding
> overlays, creating alpha bands, generating elevation outlier footprints)
> - Collecting custom properties from rasters during indexing (resolution,
> date stamps, various tiff metadata, sample date, etc.)
> - Looking at harvesting granules on demand either via. rest or the
> geoserver UI.
> - Exposing more of this configuration through a custom store and layer
> config in GeoServer.
> - Index generation code is very isolated as it stands. It's tough to
> programmatically configure index generation.
>
>
>>
>> - *Delegate coverage acceptance/rejection to a predicate object*:
>> makes sense I guess, so the reason to have this plugable is because you
>> might roll a collector that has less limitations than the default ones?
>>
>> Exactly.
>
>>
>> - *Pre-process Granule Footprint Before Indexing*: makes sense,
>> thinking out loud is the footprint the only thing that needs reprocessing?
>>
>> No, it's not really the only thing that need reprocessing. In fact
> PropertyCollectors have a tangentially related responsibility (and are used
> in roughly the same spot). Maybe this functionality could be combined
> somehow, and make monolithic some sort of monolithic visitor which would be
> responsible for:
>
> - Collecting properties from granules
> - Pre-processing the granule footprint if needed
> - Populating the index feature
>
> And so on. I'll have to think about this one a bit more, but as the
> proposal stands at least FootprintProcessor has a very clear responsibility.
>
>>
>> - *Generalize Mosaicking per GranuleCollector and Update
>> GranuleCollector to a tree-like hierarchy*: an example would be useful
>>
>> I can do an example for this. The motivation here is to delegate the
> actual mosaicking to an object which may internally be delegating to other
> mosaicking objects. For example, the default implementation would have the
> logic for mosaicking per-resolution first, then resampling and mosaicking
> those results.
>
>>
>> - *Enhance the GranuleDescriptor and GranuleCatalogVisitor
>> interfaces: *same as above, examples of these "arbitrary properties"
>> to be used would be useful
>>
>> I will provide examples for this as well. In our RnD it was necessary to
> set the CRS on each granule descriptor.
>
> Hope this clarifies a bit. I expect to be working on this the rest of the
> week and be able to answer remaining questions.
>
> Cheers
>
> Cheers
>> Andrea
>>
>>
>> On Wed, Jun 1, 2016 at 2:48 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Proposal is updated:
>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>>
>>> I reworded the API change section with clear BEFORE/AFTER descriptions
>>> making it easier to follow. After this I am far more comfortable with the
>>> proposal as a whole. I have some specific class naming doubts (is
>>> GranuleCatalogManager really a manager) but they can be sorted out during
>>> the refactor.
>>>
>>> +1
>>>
>>> A couple feedbacks:
>>>>
>>> - (done) go ahead and merge back to master, we can edit there as a group
>>>> :)
>>>> - (done) for the API change on MosaicIndexConfiguration - can you take
>>>> the cometary out to some bullet points so we can see the proposed class in
>>>> one go
>>>> - (done) the tasks section seems incomplete, we mostly use this to
>>>> check that you have enough resources/time to get the work done
>>>> - loadGranuleCatalogFromDataStore seems a bit odd to make, taking a
>>>> properties file (I guess of connection parameters) rather than a DataStore?
>>>> We have the Repository API that meets this need for app-schema and
>>>> pregeneralized datastore (I do not think you will have scope to address
>>>> this one)
>>>> - MosaicIndexConfiguration <-- is this really a configuration? It looks
>>>> to be more of a strategy
>>>> - (done) I am not familiar with this codebase so a diagram (say from
>>>> objectaid ) could help
>>>> - (done) Consider moving your before and after code examples, and a
>>>> diagram up to the description section :)
>>>> --
>>>> Jody Garnett
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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.
>>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>> _______________________________________________
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>>
>> --
>> ==
>> 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
>>
>> *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.
>>
>> -------------------------------------------------------
>>
>
>
------------------------------------------------------------------------------
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
