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/
