incubator-sis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Exploring possible contribution
Date Tue, 17 Jul 2012 16:13:10 GMT

On Jul 17, 2012, at 11:14 AM, Martin Desruisseaux wrote:

> 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
> 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
> 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…

Hi Martin,
Thanks for the email. 

See for information about git at the ASF. Git support is
evolving. And there are expectations that there will be full-fledged support for Git within
the ASF in the (near?) future. I'll note that there is not a Git mirror for SIS, currently.
But that could be created quite easily. 

I would certainly expect that there will be interest from the SIS community. There will be
a number of aspects that would need to be explored, including: technical, community, and legal/licensing.

One initial question -- what is the provenance on the Geotk code? Are all contributors willing
to relicense from LGPL to ALv2?


View raw message