Hello all
I would like to introduce myself: My name is Martin Desruisseaux. I'm
the chair of the GeoAPI working group at OGC (Open Geospatial
Consortium) and the maintainer of the "core" of the Geotoolkit.org
(abridged Geotk) project. Years ago I was one of the GeoTools 2 project
initiators. In particular, I'm the author of the referencing engine
(coordinate transformations). I have also done a few contributions to
ISO 19111 and 19115, and I'm somewhat used to OGC meetings.
We were wondering if the Apache SIS and Geotk projects could gain mutual
benefit in merging selected portions of them. We were considering for a
while to change the license (currently LGPL 2.1) to the Apache or BSD
license. It may be possible if OSGeo agree.
The Apache project would gain a pool of more than 230000 lines of clean
code (plus 520000 lines of code in the "pending" area) in which they can
select the parts they have interest in. The Geotk project would get a
wider community, which is missing to us.
The Geotk project (http://www.geotoolkit.org/) features one of the most
powerful referencing engine available in open-source. It provides also
an extensive metadata support (ISO-19115) close to the European
regulation (INSPIRE). There is bridges between those metadata and some
formats like NetCDF.
Geotk is an implementation of GeoAPI 3.0 (http://www.geoapi.org/).
GeoAPI is a set of interfaces derived from OGC/ISO standards. The aim is
to provide for geospatial applications what JDBC interfaces provide for
database applications: an isolation layer allowing the same applications
to run with different libraries. In addition to Geotk, GeoAPI
implementations include wrappers around the NetCDF and the C/C++ Proj.4
libraries. GeoAPI provides also a conformance test suite which include
parts of the Geospatial Integrity of Geoscience Software
(http://www.epsg.org/gigs.html) tests. Using those interfaces as an
isolation, it is possible to keep large parts of Geotk as internal
mechanic and expose mostly the interfaces as committed API.
Where the project would be hosted (current servers vs Apache servers),
which part of the project would be eventually hosted by Apache, which
package name, integration with existing SIS code are all open questions.
With this email, I'm just exploring if there is any interest. The main
requests I would have on my side are:
* Distributed Version Control (DVS) like Mercurial or Git rather than
centralized one like SVN, because we may which to maintain a branch
on our side (while doing merges, of course).
* A commit right policy with emphasis on quality (e.g. complete
javadoc, new code does not duplicate existing code, equals/hashCode
consistency, etc.), maybe using branches with DVS for pending works.
I would like to known if there is any though/interest...
Regards,
Martin
