incubator-sis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Desruisseaux <>
Subject Exploring possible contribution
Date Tue, 17 Jul 2012 15:14:02 GMT
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 
(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 ( 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 ( 
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 
( 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...



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message