I am not the original author, although I did revise yesterday for each api
change to have a motivation/before/after story.
Additional comments inline:
On 1 June 2016 at 11:02, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
>
> - *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)
>
> Okay, not sure I am that close to it.
>
> - *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)
>
> They will be used by the existing classes, the logic has been isolated
into MosaicIndexConfiguration rather than dispersed across the codebase.
CatalogMangaer is an example of how this is done (it was also renamed to
GranuleCatalogManager because I found the name rather generic).
>
> - *Harvesting: *same as above, how is the code going to be moved
> around, and examples of alternate implementations
>
> We may be able to pull together an example of an alternate implementation
from the RnD fork, but the RnD fork has this logic scattered across the
codebase so it would not be definitive.
>
> - *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?
>
> Only reprocessing that was identified in RnD fork, however I suspect that
properties collectors may of been used to reprocess (but that is just an
educated guess based on the API rather than proof).
>
> - *Generalize Mosaicking per GranuleCollector and Update
> GranuleCollector to a tree-like hierarchy*: an example would be useful
>
>
> - *Enhance the GranuleDescriptor and GranuleCatalogVisitor interfaces:
> *same as above, examples of these "arbitrary properties" to be used
> would be useful
>
> data collection metadata from the geotiff header, file creation /
modification dates, resolution ... or assumptions of sensor (and thus
accuracy) based on file naming convention).
Thanks for feedback.
------------------------------------------------------------------------------
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
