Hello all
The joint OGC/ASF/OSGeo code sprint was this week near Lausanne [1]. A
joint report of activity will be published later. For the part specific
to Apache projects, below is a small summary of what we did.
Apache Sedona
Sedona did a presentation about their background and architecture. The
ST_Distance function was taken as an example for showing how it is used
in a query, and what kind of geodetic calculations it requires under the
hood. The geodetic services in Sedona are currently handled by GeoTools,
which is a LGPL library. The licensing issue that it poses for an Apache
project was discussed, as well as concerns about whether GeoTools
referencing services are maintained. A proposal to migrate to Apache SIS
was presented.
We did not had the time to start actual coding work on a migration
experiment. Anyway such work could not be completed before either Apache
SIS offers all features that Sedona needs (SIS currently misses a
GeoTIFF writer and a ShapeFile reader), or before GeoTools resolves its
conflict with GeoAPI (see "GeoAPI" section below) for allowing the two
projects to coexist. Both issues are expected to be at least partially
resolved by this autumn.
Apache Baremaps
Baremaps did a 5-minutes pitch showing the project features. Bertil was
physically present at the event, which has been a great opportunity for
discussions.
Bertil: would you like to expand more on what happened on Baremaps side
during those 3 days?
Apache SIS / GeoAPI
We did not had the time to work on Apache SIS directly. But on the
GeoAPI side (which SIS implements), we had an announcement concerning
the resolution of "org.opengis" package name collision with GeoTools
[2]. A GeoTools PMC representative announced that they were going to
work on this issue in August, by stopping to use the "opengis" name on
their side. My expectation is that this issue will be resolved for next
GeoTools release. This is a significant announcement for any Apache
projects that could benefit from SIS services, such as Apache Sedona and
Baremaps.
During the code sprint, we completed the full migration of PROJ-JNI [3]
and GIGS [4] to Java 11. Actually those two projects were already Java
11 compatible, but the service providers were still registered in the
Java 8 way. Service providers are the Java standard mechanism by which
an application such as GIGS can detect automatically which GeoAPI
implementation is available at runtime, without any previous knowledge
of GIGS about those implementations. Before Java 9, services were
registered by putting files in the META-INF/services directory, and
third-party JAR files were loaded dynamically at runtime using
ClassLoader. Since Java 9, services are registered by declaring them in
the module-info.java file, and third-party JAR files are loaded
dynamically at runtime using ModuleLayer. Upgrading GIGS code base to
use ModuleLayer worked well on the Java side. The biggest difficulty was
not with Java, but with Maven. The problem is that even if a project is
fully modularized in the Java 9+ way, Maven exec:java goal still
launches the application using "java --classpath" when it should use
"java --modulepath". The consequence is that Maven systematically
launches Java in a kind of Java 8 compatibility mode, which causes
difficulties in finding services declared in the Java 9+ way.
Apache SIS has not yet been migrated to a fully Java 9+ modularized
project. Consequently, GIGS tests may temporarily not work anymore on
SIS. We will try to fix that issue before next SIS release, by finishing
the Jigsaw modularisation of SIS.
Martin
[1]https://github.com/opengeospatial/developer-events/wiki/Open-Standards-and-Open-Source-Software-Code-Sprint
[2]https://desruisseaux.github.io/history/GeoAPI.html
[3]https://github.com/OSGeo/PROJ-JNI
[4]https://github.com/IOGP-GIGS/GIGSGeoAPI
