[Geotools-gt2-users] Unethical use of GeoAPI library in Geotools

[Stephane F. <ste...@im...>]

Hi,

I would like to express my frustration to the Geotools community about the
unethical use of GeoAPI in the library. I have been a user and big fan of
Geotools for many years, but I am also using other libraries such Apache
SIS and Geotookit to explore new way to use OpenGIS services and
standards.  For example Geotookit and Apache SIS have an excellent support
for parsing ISO 19139 and Geotools has a mature support for handling the
different versions of WMS and WFS. I ran into serious issue recently about
jar dependencies when I try to use all these libraries together. The main
issue is the usage of GeoAPI.

Geotools has a library called gt-opengis that uses the same domain than
GeoAPI (org.opengis).  Here is an example of issue I ran  into:

I am using gtk-metadata-4.0-M1 which uses geoapi-pending-3.1-M04 (for
parsing ISO 19139) and I have another plugin for parsing WMS that uses
Geotools gt-wms-12.1 and depends on gt-opengis-12.1.
When I run my parser for ISO 19139, I run into library conflict on the
signature for CodeList.

Caused by: java.lang.NoSuchMethodError:
org.opengis.util.CodeList.valueOf(Ljava/lang/Class;Lorg/opengis/util/CodeList$Filter;)Lorg/opengis/util/CodeList;
at org.apache.sis.util.iso.Types.forCodeName(Types.java:526)
at
org.apache.sis.internal.jaxb.gmd.CodeListAdapter.unmarshal(CodeListAdapter.java:120)
at
org.apache.sis.internal.jaxb.gmd.CodeListAdapter.unmarshal(CodeListAdapter.java:52)
at
com.sun.xml.bind.v2.runtime.reflect.AdaptedAccessor.set(AdaptedAccessor.java:85)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.receive(Accessor.java:171)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:523)
at
com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:160)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)

The issue comes from the fact the gt-opengis-12.1 takes precedence in the
classloader (it uses the same class name).  There is no simple solution to
solve this problem, either writing your own classloader or using a
framework like OGSI. Both requires extensive work and expertise.

Geotools has copied some early version of GeoAPI using the namespace
org.opengis that GeoAPI owns and created a fork of the API that is
incompatible with the current GeoAPI version. I think the appropriation of
the namespace org.opengis and making modification of the API that are not
compliant with the standard is unethical (and probably in breach with the
OGC licensing terms).

I see two solutions to this problem:

1) Rename the package org.opengis to org.geotools.opengis and they do
whatever you want with it
2) Align with the standard GeoAPI 3.0.0, which was voted and approved by
OGC and then participate to the SWG at OGC to drive future developments of
GeoAPI based on the requirements of Geotools community.

I would favor the second solution, but I can understand that may require
more work to refactor. So in the meantime, the quick solution would be
apply solution 1 (changing package name), until a plan to align to GeoAPI
is put in place for future version.

Best regards


-- 
Stephane Fellah
Chief  Knowledge Scientist
Image Matters LLC
Office: +(703) 669 5510
Cell: 703 431 9420