Re: [Geotools-devel] ImageMosaic API refactor proposal

I am not too fond on this name but as a general rule of thumb I always suggest to refrain from the renaming attitude unless the original name is _really_ bad. This is also important as we would have in some cases to keep the old one around if it was a public class or interface. Regards, Simone

Re: [Geotools-devel] ImageMosaic API refactor proposal

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

Re: [Geotools-devel] ImageMosaic API refactor proposal

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 wrote: > Thanks for all the feedback. Like Jody said, we're

Re: [Geotools-devel] ImageMosaic API refactor proposal

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

Re: [Geotools-devel] ImageMosaic API refactor proposal

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,

Re: [Geotools-devel] ImageMosaic API refactor proposal

Properly collectors are still used, think we are getting a small echo chamber of uncertainty here. This is a refactor to use existing infrastructure such as property accessors more effectively. Importer is not quite the right place as additional granules can be added over time via rest API right?

Re: [Geotools-devel] ImageMosaic API refactor proposal

Hi, Providing some additional feedbacks on my side, too. On Mon, Jun 6, 2016 at 6:34 PM, Andrea Aime wrote: > On Fri, Jun 3, 2016 at 1:19 AM, Devon Tucker > wrote: > >> Here are a few things that might help understanding, section by

Re: [Geotools-devel] ImageMosaic API refactor proposal

On Fri, Jun 3, 2016 at 1:19 AM, Devon Tucker wrote: > 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

Re: [Geotools-devel] ImageMosaic API refactor proposal

Working on it with me, and we expect some review. On Thu, Jun 2, 2016 at 4:52 PM Ben Caradoc-Davies wrote: > Devon, > > are you working on this by yourself or with others? With Git, you can > make your own branch in your own fork of the repository, then use a > GitHub pull

Re: [Geotools-devel] ImageMosaic API refactor proposal

Devon, are you working on this by yourself or with others? With Git, you can make your own branch in your own fork of the repository, then use a GitHub pull request to ask for review and merge. Justin wrote our excellent Working with Git guide:

Re: [Geotools-devel] ImageMosaic API refactor proposal

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 wrote: > Hi Andrea, > > Thanks for the questions. > > On Wed, Jun 1, 2016 at 11:02

Re: [Geotools-devel] ImageMosaic API refactor proposal

Hi Andrea, Thanks for the questions. On Wed, Jun 1, 2016 at 11:02 AM, Andrea Aime 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

Re: [Geotools-devel] ImageMosaic API refactor proposal

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 wrote: > >- *Description*: this is fine, makes sense, no questions (one

Re: [Geotools-devel] ImageMosaic API refactor proposal

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

Re: [Geotools-devel] ImageMosaic API refactor proposal

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

Re: [Geotools-devel] ImageMosaic API refactor proposal

A couple feedbacks: - go ahead and merge back to master, we can edit there as a group :) - 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 - the tasks section seems incomplete, we mostly use this to

Re: [Geotools-devel] ImageMosaic API refactor proposal

Devon, Great work, thanks for improving the explanation of my part. I'm glad to see the plan is moving forward. Kind Regards Niels On 21-05-16 01:21, Devon Tucker wrote: Hi all, I've been working on fleshing this proposal out and adding a bit to it. See the conversation on on-the-fly

Re: [Geotools-devel] ImageMosaic API refactor proposal

Hi all, I've been working on fleshing this proposal out and adding a bit to it. See the conversation on on-the-fly reprojection in ImageMosaic. My updated API proposal is on my own Wiki for now, I can update the master one but I wanted to solicit early feedback. Please let me know if something

Re: [Geotools-devel] ImageMosaic API refactor proposal

On 21-04-16 20:01, Jody Garnett wrote: Thanks for the clarification Niels, I was not aware that Prop was part of the current API. Still we have some duplication here right? Should we try running the property collectors, look at the results, and generate the schema appropriate to store the

Re: [Geotools-devel] ImageMosaic API refactor proposal

Thanks for the clarification Niels, I was not aware that Prop was part of the current API. Still we have some duplication here right? Should we try running the property collectors, look at the results, and generate the schema appropriate to store the results? -- Jody Garnett On 21 April 2016 at

Re: [Geotools-devel] ImageMosaic API refactor proposal

On 17-04-16 04:17, Jody Garnett wrote: > This proposal (and email thread) should be orthogonal to the RnD > discussion on setting up a mosaic with multiple projections. > > This mosaic is focused on creating/managing the index used. One part I > cannot wrap my head around is the workflow behind

Re: [Geotools-devel] ImageMosaic API refactor proposal

> > -1- Can you clarify this sentence? > > "to replace the default direct granule access with a renderable graph > (for reprojection)" > Replaced with "support resampling of rasters into common CRS for mosaic operation". > -2- Stupid thing but in ImageMosaic I would go for add/removeRaster >

Re: [Geotools-devel] ImageMosaic API refactor proposal

Hi Simone, Thanks for review! In response to your questions (1) Jody added this note to the proposal and Devon is working on this part, so I think either one of them are best placed to explain this part. (2) Okay, agreed. Regards Niels On 15-04-16 10:39, Simone Giannecchini wrote: > Ciao

Re: [Geotools-devel] ImageMosaic API refactor proposal

Ciao Niels, we are looking into this and comparing with some work that have in the pipeline which might extend the work you are doing with respect to harvesting. I like the general idea pretty much, I have a few quick questions/obs? -1- Can you clarify this sentence? "to replace the default

Re: [Geotools-devel] ImageMosaic API refactor proposal

Hello Devon, Directory walking is part of the harvesting process, which is at the moment implemented inside the ImageMosaicReader (see the inner class HarvestedResource). In the API, there is a separate MosaicHarvester interface, as well as a very light ImageMosaicReader with all the logic

Re: [Geotools-devel] ImageMosaic API refactor proposal

For my own part, Niels maybe you could throw in some small examples of how these API changes would be used in practice to accomplish some of the items in the description? For example, how could I customize the directory walking with the new API? Thanks, Devon On Tue, Apr 5, 2016 at 4:44 PM,

[Geotools-devel] ImageMosaic API refactor proposal

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