Martin Desruisseaux
2009-03-24 09:37:56 UTC
Hello all
Following on the JAI operation discussion, I mentioned that I'm working on
Operation2D / OperationJAI right now. Actually I'm porting them to geotidy. In
the process I rewrote yesterday the way the result of GridCoverage2D operations
can be cached (I realised that the implementation in GeoTools 2 is broken). But
as far as Operation2D / OperationJAI are concerned, I do not envision API change
at this time.
This bring the question about when geotidy can be offered for a merge with
GeoTools. Currently the referencing module is done, except for Oracle and HSQL
plugins of EPSG (I'm doing my test on PostgreSQL for now) and the builder
package, maybe to move in an other module.
I'm porting key classes from the coverage module right now (not all of them - I
will delay some of them to a later time). GridCoverage2D is alreay ported; the
main class left are Operation2D and OperationJAI, which I'm doing today.
We already have a Mercurial clone of GeoTools SVN:
http://hg.geomatys.com/geotools/trunk/. Later this week or at the beging of next
week, we will create a clone of this clone in which we will delete the following
modules:
* metadata
* referencing
* referencing3D
* epsg-*
* coverage
* coverageio
* widgets-swing
* widgets-swing-pending
* openoffice
and replace them by dependencies toward geotidy modules. At this stage the goal
will be to get GeoTools to compile and pass its tests, without consideration for
Java 5. Only after that point, we will downgrate geotidy to Java 5 on a "geotidy
for geotools" clone (or something like that). At this point the work will be
ready for offering to the community. If accepted, we can merge to SVN the
changes applied on the GeoTools Mercurial clone. The "geotidy for geotools" code
can be merged to the SVN, or we can left it on Mercurial. I would recommand the
later (Mercurial commands look like a lot SVN commands); anyone in the community
can take the initiative to declare his Mercurial clone as the "official" one for
GeoTools, with agreement of the others.
The space for the Mercurial clones is already in place:
http://hg.geomatys.com/
Just a note in order to avoid diplomatic incident: the name "geomessy" applies
to *our* (at geomatys) code, not to GeoTools code. The comment said "Modules
*for* GeoTools", not "Modules *from* GeoTools".
Regards,
Martin
Following on the JAI operation discussion, I mentioned that I'm working on
Operation2D / OperationJAI right now. Actually I'm porting them to geotidy. In
the process I rewrote yesterday the way the result of GridCoverage2D operations
can be cached (I realised that the implementation in GeoTools 2 is broken). But
as far as Operation2D / OperationJAI are concerned, I do not envision API change
at this time.
This bring the question about when geotidy can be offered for a merge with
GeoTools. Currently the referencing module is done, except for Oracle and HSQL
plugins of EPSG (I'm doing my test on PostgreSQL for now) and the builder
package, maybe to move in an other module.
I'm porting key classes from the coverage module right now (not all of them - I
will delay some of them to a later time). GridCoverage2D is alreay ported; the
main class left are Operation2D and OperationJAI, which I'm doing today.
We already have a Mercurial clone of GeoTools SVN:
http://hg.geomatys.com/geotools/trunk/. Later this week or at the beging of next
week, we will create a clone of this clone in which we will delete the following
modules:
* metadata
* referencing
* referencing3D
* epsg-*
* coverage
* coverageio
* widgets-swing
* widgets-swing-pending
* openoffice
and replace them by dependencies toward geotidy modules. At this stage the goal
will be to get GeoTools to compile and pass its tests, without consideration for
Java 5. Only after that point, we will downgrate geotidy to Java 5 on a "geotidy
for geotools" clone (or something like that). At this point the work will be
ready for offering to the community. If accepted, we can merge to SVN the
changes applied on the GeoTools Mercurial clone. The "geotidy for geotools" code
can be merged to the SVN, or we can left it on Mercurial. I would recommand the
later (Mercurial commands look like a lot SVN commands); anyone in the community
can take the initiative to declare his Mercurial clone as the "official" one for
GeoTools, with agreement of the others.
The space for the Mercurial clones is already in place:
http://hg.geomatys.com/
Just a note in order to avoid diplomatic incident: the name "geomessy" applies
to *our* (at geomatys) code, not to GeoTools code. The comment said "Modules
*for* GeoTools", not "Modules *from* GeoTools".
Regards,
Martin