Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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
netcdf-java archives: