well, that sounds like another good reason to make the geotoolkit library
optional, assuming we get it to hook up.
andrea antonello wrote:
Hi all,
I am not sure if this is something feasible or not, but, even if I
have great respect for Martin (hi Martin) and the geotoolkit project,
I would hope in something slightly different (even if I still do not
know what...).
I for example am using geotools and netcdf (geotools preocesses them
also) a lot for modeling in JGrass. I do not care that much about
people prefering one or the other project (that's life in forks and is
ok to me), but I really would not like be penalized to be using
geotools over geotoolkit. If this should happen I can't imagine how
many problems might rise for me (me==geotools user that need netcdf)
since the coexistence of the two fork-libs is not well feasible.
Does that make some sense? I would love to hear comments on that.
Best regards,
Andrea
Just to add my $0.02 - I think it would be great if NetCDF-Java could use
Geotoolkit (which I prefer to GeoTools) to handle
projections, ellipsoids etc. The CF projections are (I think) a small subset
of the projections that Gtk can handle so hopefully
this might not be too much work. I could probably help if required.
(perhaps the weight of the dependency could be reduced by stripping out the
stuff that isn't necessary for nj4? Might require a
special build?)
Cheers, Jon
-----Original Message-----
From: netcdf-java-bounces@xxxxxxxxxxxxxxxx
[mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John Caron
Sent: 24 March 2010 19:46
To: Martin Desruisseaux
Cc: netcdf-java@xxxxxxxxxxxxxxxx
Subject: Re: [netcdf-java] ncWMS and ellipsoid-support in CF-1.2
Wow, thats great news Martin, Ill check it out ASAP.
Martin Desruisseaux wrote:
Hello Jon
Le 24/03/10 19:43, John Caron a écrit :
Thanks for reminding me of geotools. I have it on my (long) list of
possibilities. I have looked at it in the past, but it was difficult to
see what dependencies were actually needed (thanks for the summary). The
other advantages you mention are also alluring.
Actually this is no longer GeoTools, but a fork of GeoTools created 10
months ago. The raison for the fork are out of scope of this mailing
list, but the result is that the referencing module in Geotoolkit is
cleaner, more stable and performant than it was in GeoTools and the list
of dependencies has been reduced. The module is also provided with all
its dependencies as a single JAR file for those who don't want to handle
many JAR files, and a new release is made every months.
We would have to write an adapter from our Projection interface to
whatever API geotools uses. Also translate CF parameter conventions for
each projection. Its possible we could keep it as an optional jar, for
those concerned about size.
This is already partially done. The following package contains adapters
for NetCDF API (note: this package didn't existed in GeoTools). It
should allows NetCDF users to use some of the Geotoolkit referencing
engine with NetCDF CoordinateSystem objects, while I have not yet tested
extensively that interoperability:
http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/adapters/package-summary.html
There is also code in other packages that translate some attributes from
CF conventions to ISO 19115-2 metadata.
Regards,
Martin
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
