I'll second Simone's comments completely. Very nice summary. The right
dependency would, indeed, be GeoAPI. The other points are also well taken.
John I'd suggest revisiting this?
gerry
Simone Giannecchini wrote:
Quick follow up for what Andrea Antonello said.
My group and I have been reading/processing netCDF files in GeoTools
for a long time, therefore I am a bit worried about a straight
dependences on geotoolkit.
Besides, a few things that have not been mentioned in this discussion
(I am not going to dive deep into the reason of the fork)
-1- GeoTools and GeoToolkit referencing should implement the same
interface as dictated by the GeoApi project, therefore if we had to
introduce a dependency I would probably introduce it against GeoApi
interface rather than this or that implementation. If I am right the
whole reason behind the GeoApi project was to avoid this kind of
situation, that is, being bound to implementation A rather than
implementation B.
Now the problem is that as far as I can see one of the consequences of
the fork is that the GeoApi interfaces has started to drift away,
therefore I am pretty sure that GeoTools and GeoToolkit are not
aligned anymore.
-2- If the focus is on porting proj4 projection while retaining a
small footprint I would consider the proj4j project that has been
created by Martin Davis, the guy behind JTS.
http://lin-ear-th-inking.blogspot.com/2010/01/announcing-proj4j.html
http://trac.osgeo.org/proj4j/
-3- I guess that someone on this list from unidata should talke a look
at the MetaCRS initiative from OSGEO.
http://trac.osgeo.org/metacrs/
Long story short, I would avoid straight dependencies, being it
GeoTools, GeoToolkit or whatever large framework.
Regards,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
On Wed, Mar 24, 2010 at 11:32 PM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:
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/
_______________________________________________
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/
--
Gerry Creager -- gerry.creager@xxxxxxxx
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843
