Hello all
I would like to reboot a discussion about a partial migration of Sedona
from GeoTools to Apache SIS [1], at least for referencing services. In
the past, this proposal was blocked by a conflict in the Java interfaces
defined in `org.opengis` packages [2]. This conflict has been resolved
two years ago with GeoTools 30, and GeoAPI wrappers for GeoTools have
been created one year ago [3] for making possible to continue to use the
`org.opengis` namespace but this time in conformance with OGC standard.
Since then, the two libraries can coexist with some degrees of
interoperability.
The referencing module of Apache SIS is the continuation of the
referencing module of GeoTools with the addition of 15 years of
development, while GeoTools got few evolution in this aspect since that
time. To my knowledge, Apache SIS offers the most advanced open-source
referencing library in the Java world. The PROJ library itself took
inspiration from Apache SIS for a large refactoring [4]. SIS could also
raise Sedona capability to handle complex data, because of SIS advanced
multi-dimensional support among others. Furthermore, the use of Apache
SIS would avoid the need to link GeoTools as an optional dependency for
licensing reasons. While GeoTools is technically optional for Sedona,
the importance of such library for a geospatial project leads to
questioning whether it is stretching the spirit of Apache licensing policy.
Apache SIS 1.6 was released last week, about 4 months after SIS 1.5. We
will try to keep a similar cadence in the future. SIS restricts itself
to a relatively old Java version (11) for complying with Sedona
requirement. A migration could be done in a progressive way, with no
need to be a big refactoring completed fully before a release. An
approach could be:
* Add Apache SIS dependency even if not used immediately, and verify
that it does not create any conflict with GeoTools.
* Start to replace some uses of `org.geotools.referencing.CRS` by
`org.apache.sis.referencing.CRS`.
* If there is a need to use a SIS's CRS with GeoTools, or conversely,
use a copy of the bidirectional wrappers at [3].
Later, the use of SIS for some data formats such as GeoTIFF could also
be done progressively. The main developer of the Apache Baremaps project
reported that the GeoTIFF pure-Java reader of Apache SIS was faster than
the Java bindings to GDAL (not saying that GDAL is slower, as there were
also the cost of Java ↔ C/C++ bindings). Apache SIS also offers its own
binding to GDAL using Panama (Java 22 `java.lang.foreign` package) if
desired.
Would it be reasonable to start a migration step by step? It could be
replacing just a few services for the next Sedona release, then having
more replacements done progressively in next releases, thus making
GeoTools progressively more effectively optional. There is no need to
remove GeoTools fully, I'm sure that there will always be services
offered by one library and not the other. But Apache SIS ambitions to be
well suited for the core part of a project such as Sedona. We would be
happy to help, but preferably on either [email protected], [email protected] or
[email protected] mailing list.
Regards,
Martin
[1]https://sis.apache.org/
[2]https://desruisseaux.github.io/history/GeoAPI.html
[3]https://github.com/Geomatys/geoapi-gt-wrappers
[4]https://web.archive.org/web/20251212013625/https://gdalbarn.com/ — search
"Apache"
