Hello Tom
Le 27/11/11 05:12, Tom Kunicki a écrit :
How will this affect those of us with projects with dependencies on GeoTools?
It appears that GeoTools through 2.7 implements a version of GeoAPI 2.x and
that with GeoTools 8 the developers are utilizing there own copy of the
GeoTools API [1].
If NetCDF-Java were to include GeoAPI 3.0 as a dependency would those of us
with GeoTools dependencies be subject to API clashes (assuming some package
and interface names are shared) with the differing versions required? This
could be a huge headache.
I think that the ball is on the GeoTools side. The org.opengis namespace is
owned by OGC, and GeoAPI development is ruled by a OGC Standard Working Group
(by the way, we have a GeoAPI session at OGC meeting this week in Brussels).
GeoAPI 3.0.0 has been formally adopted as an OGC standard
(http://www.opengeospatial.org/standards/geoapi). Since the license is BSD-like,
GeoTools or any other projects are allowed to create their own derivative work.
However is such case, it is usually appreciated that the derivative project uses
a different package name.
So I would said that GeoTools should either adopt GeoAPI 3.0.0 "as-is", or
rename their "org.opengis" package name to something else (note: "net.opengis"
and "org.opengeospatial" are owned by OGC too). However even if they don't take
any of those actions now, I don't think that it would impact the NetCDF +
GeoTools users in short term since the proposal is not to add GeoAPI dependency
in NetCDF core, but rather in some kind of "NetCDF / ISO 19115 metadata mapping"
modules.
In medium term, maybe it would be worth to convince GeoTools developpers to
adopt GeoAPI 3.0.0. Some arguments for that are:
* While I'm currently the main GeoAPI developer, GeoAPI is not under my own
control. It is under the control of any OGC member who wish to participate
to the GeoAPI Standard Working Group. Since OpenGeo is an OGC member, the
choice to participate or not is only OpenGeo (or any other member) decision.
* The ony part which is standardized by GeoAPI 3.0.0 is ISO 19115 metadata and
ISO 19111 referencing by coordinates. Those parts have been stable for many
years. So even if OpenGeo has different view about how to represent an ISO
19123 coverage, they would not be tied to any such decision by adopting
GeoAPI 3.0.0.
* GeoAPI provides a robust test suite, which become stronger every months and
include elements from the Geospatial Integrity of Geoscience Software (GIGS)
program (http://www.epsg.org/gigs.html). GeoTools would get those test
suites "for free" if they adopt GeoAPI.
* In longer term, given that I'm not sure that the GeoTools referencing module
get lot of developments, GeoTools could eventually choose to rely on an
other library for the referencing part. Wrappers for the C/C++ Proj4 library
are already available. I'm pretty sure that some GeoTools developers are
interrested in the JProj.4 library too (while the later does not yet
implement GeoAPI interfaces). In addition, the Geotoolkit.org referencing
module got a very large amount of bug fixes and improvements compared to the
original GeoTools one. Using GeoAPI 3.0.0 would give them more freedom.
However I think that GeoTools would take such move only if a significant amount
of users ask for it...
Regards,
Martin
