Jody I'm not sure what a good name for the class is. Its chief
responsibilities (before this proposal) were collecting attributes from the
incoming granule, creating its new feature and updating the GranuleStore,
creating the index schema, and instantiating the GranuleCatalog from the
reader configuration. Now that I type all that out I don't think
CatalogManager is that bad a name?
On Tue, Jun 14, 2016 at 10:42 AM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> I note the prior proposal had CatalogManager renamed to
> GranuleCatalogManager is that still appropriate?
>
> Will you be removing the original proposal then?
>
> --
> Jody Garnett
>
> On 9 June 2016 at 16:39, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Thanks for all the feedback. Like Jody said, we're probably going to
>> break the proposal apart a bit. I've started pulling apart the
>> index/catalog management into its own proposal:
>>
>>
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-Catalog-management-for-improved-extensibility
>>
>> Still a work in progress. Will work on adding code examples for the
>> catalog manager part. In the meantime you can take a look at the WIP here:
>>
>> https://github.com/dvntucker/geotools/tree/im_api_refactor
>>
>> The biggest thing to note is that:
>>
>> - A number of methods in CatalogManager have been changed from static to
>> non-static
>> - CatalogManager has been added as a field to the ImageMosaicConfigHandler
>> - Logic that was in ImageMosaicConfigHandler for checking ColorModel and
>> CRS has been moved to CatalogManager (see the second part of the proposal)
>>
>> Cheers
>>
>> On Wed, Jun 8, 2016 at 1:08 PM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Thanks for email feedback Andrea, Daniele. Had a good chat with Simone
>>> ....
>>>
>>> Going to try and break this proposal into three small proposals on 1)
>>> index generation 2) dynamic processing 3) harvest flexibility.
>>>
>>> Some of the functionality (like data prep) is indeed already covered. I
>>> was not aware, for example, that geoserver importer could be used add
>>> granules to an *existing* mosaic (that is not functionality that can be
>>> done for vector import).
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 5 April 2016 at 16:44, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Just noticed that there wasn't a dedicated email thread for this
>>>> proposal and figured I'd kick one off since I've also been involved in it.
>>>>
>>>>
>>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>>>
>>>> I think the description gives a pretty good rationale for what we want
>>>> to accomplish with this proposal and I'd like to solicit any discussion,
>>>> advice, feedback, etc. from everyone.
>>>>
>>>> Cheers,
>>>> Devon
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> 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://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
