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
