Thanks for contacting us Stephane.
GeoAPI is an original outreach project of the GeoTools library (many of the
interfaces originally started in our project). We did indeed stay behind
with an earlier version to preserve backward compatibility (projects using
GeoTools could not keep up with the API change involved in tracking the
latest standards).
If sponsors are available to fund the update we would be happy to make use
of a newer copy of GeoAPI. This is why we have not changed the package
names. Indeed yours is the first request on the user list to upgrade and I
am happy to hear from you :)
If you know of any group willing to volunteer/sponsor the work we would be
glad to hear from them. If it helps we can write up your proposal formally
and estimate the level of effort involved.
--
Jody
--
Jody Garnett
On 19 February 2015 at 08:48, Stephane Fellah <stepha...@imagemattersllc.com
> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> GeoTools-GT2-Users mailing list
> GeoTools-GT2-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
