NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Martin, 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. Tom Kunicki Center for Integrated Data Analytics U.S. Geological Survey 8505 Research Way Middleton, WI 53562 [1] http://slashgeo.org/2011/04/27/GeoAPI-30-Interface-Standard-Becomes-OGC-Standard#comment-296 On Nov 26, 2011, at 1:41 PM, Martin Desruisseaux wrote: > Hello Jon > > I'm glad this ISO 19115-2 / NetCDF metadata mapping can be of interest :-) > > Le 26/11/11 18:49, John Caron a écrit : >> >> Sorry, this got lost in the cracks. We would be interested in incorporating >> this. The main issue is handling the GeoAPI dependencies, which we are ready >> to try to solve. Is this ready to try incorporating? We would do it for 4.3. > > Yes, this is ready to incorporate at any time at your convenience. The > dependencies issue can probably be isolated by providing the functionality in > a separated module, so you can select which dependencies is acceptable for > which module. > > Some decisions that need to be done regarding dependencies are: > > Which GeoAPI version: 3.0.0 (the officially released version), or > 3.1-SNAPSHOT (still under development). Normally I would recommand 3.0.0. > However in 3.1-SNAPSHOT, we are in process of removing the JSR-275 unit > dependencies (which has been rejected by the JCP) by a Unit interface, so you > can use the Unit implementation of your choice. Because the NetCDF library > has its own unit package, maybe the Unit interface would be more suitable... > GeoAPI provides ISO 19115-2 metadata interfaces, but no implementation. So > you would need to choose whatever you prefer to use an existing > implementation, or write your own. Current choices are: > Geotoolkit.org metadata module. Advantages: can marshal/unmarshal ISO 19139 > XML, nice 'toString()' formatting, can provide dynamic view as java.util.Map. > Inconvenient: this is a dependency of about 1 Mb. > Use the GeoAPI metadata demo as a starting point: Advantages: very light, > public domain (so you can put that under NetCDF license with no obligation at > all). Inconvenient: No ISO 19139 XML marshal/unmarshalling. > > Then, the ISO 19115-2 / NetCDF metadata mapping code would use the library > selected above. > > Thats the main items to put in balance that popup from my mind for now... > > Martin > > _______________________________________________ > netcdf-java mailing list > netcdf-java@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
netcdf-java archives: