Hi Simone, Daniele, List,
Here is what we currently have for our proposal:
https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility.
This is still is discussion phase, we'd like to hear your input :)
Kind Regards
Niels
On 31-03-16 20:14, Niels Charlier wrote:
I have looked at Daniele's PR (superficially) and it looks good, but I
would expect a proposal is in order to move a lot of API from a plugin
to a core module.
As far as I can see, there is little or no overlap between the two
bodies of work at the moment. I don't expect any issues there.
Considering our proposal - will be posting this soonish - we can never
move everything that demstore depends on from imagemosaic to the
coverage module, it's nearly everything. I much prefer the idea of
creating a more public API for imagemosaic itself and documenting this
(perhaps promoting it to a core module?).
Kind Regards
Niels
On 31-03-16 19:53, Jody Garnett wrote:
Catching up with the geotools codebase for a bit ... and I also owe
Andrea an update from the gt-dem community module progress.
I see we have two teams looking at refactoring functionality into
gt-coverage:
Daniele: Your pull request #1131 Supporting vector footprints on GDAL
plugin <https://github.com/geotools/geotools/pull/1131> is moving
some functionality from gt-mosaic to gt-coverage around generating
footprints using GDAL and minor changes to CatalogManager. I would
like some feedback on how this affects the code-base stability (with
respect to upcoming release); and we could help pull together a
change proposal.
Devon & Niels: Although we have a community module, most of the work
has taken place on a branch (to hack hooks into gt-image-mosaic
classes such as CatalogManger). The next step is to regroup and
produce a change proposal. I assume this change proposal would move
some functionality from gt-moasic to gt-coverage (or depend on
gt-mosaic which would involve some clean up and documentation of the
internals as public api).
The other update is a change in scope - the multi-resolution dem is
no longer just a dem. It now has to cover both dem and imagery. The
critical difference between this and gt-moasic ends up being setting
up a processing chain (renderable graph) for each granule allowing
content from different projections to be merged (with an appropriate
speed penalty). I am not sure if the different granules have to be
coerced into the same band structure or not (something that is more
challenging for a DEM which may be measured in meters or feet).
--
Jody Garnett
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
