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.
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, AndreaJust 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@xxxxxxxxxxxxxxxxFor 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
netcdf-java archives: