On Tue, Feb 23, 2010 at 10:38 PM, Andrea Aime <[email protected]> wrote: > Hi all, > these days I've been working on resurrecting the OGR > datastore functionality. > It is now compiling and passing tests. > > There are two main issues that needs solving to move forward > and push the datastore into supported land: > - synchronization with imageio-ext > - exposed factories > > Keeping the datastore in synch with imageio-ext is kind > of important for any application that might use both, that > is going to be possible only if the two share the same > jars and the same native libraries. > The datastore has been fixed and ported towards GDAL 1.7.1, > afaik imageio-ext is going in the same direction?
yes, imageio-ext 1.1 uses gdal 1.7.1 > We have to agree on a groupId/artifact for the GDAL 1.7.1 > java bindings jar and push it onto some repo. > not sure I am following here, can you explain? > The current GDAL 1.7.1 build is simple enough, I hope that > will make it easier for people to build their own customized > OGR that still works with our stores/coverage readers (GDAL/OGR > supports a ton of formats and we cannot really build them all). > In particular I'm thinking about the GRASS formats, which > I would very much like to see but that I understand would > be a nuisance to build on all platforms (assuming imageio-ext > keeps on building the native libraries, that is). > we still have a small patch to apply for managing colormapped raster data. I just asked daniele to check if this patch can be accepted into the gdal codebase so that we don't have to bring it with us. Anyway, baseline is, yes, I agree we need to coordinate here but I would really like to avoid more work coming from building the OGR countepart, unless it is really small. Ciao, Simone > The other issue is about the factories. OGR exposes a ton > of formats, at the same time we're not sure which one > are actually built into the set at hand. > At the moment there is just a generic, two params one: > - ogr driver name > - ogr source name (whatever that is, it's format dependent) > Not sure if we want to roll out format specific ones. > I'm kind of weary going the "one factory per format" > approach as I have no way to test them all, and no time > to figure out the params for each one. > I guess we can add specific ones as the need arises, and > keep the generic one as a fallback? > > Let me know > > Cheers > Andrea > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
