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.
I think Simone's suggestion of using the Java Proj.4 port is very good. That could be the ideal solution, avoiding the large dependencies. Including a dependency *even on GeoAPI* within nj4 could be dangerous, since it would make it hard to use nj4 in environments that use different GeoAPI versions. Having said that, the required parts of GeoAPI (CoordinateReferenceSystems and MathTransforms) are pretty stable between versions (which might argue for factoring them out... but that's another story). Anyway, what nj4 needs (it seems to me) is a private "engine" for coordinate transforms. It would be desirable to pollute the user's classpath as little as possible with unnecessary classes. There's no need for the user to see how the transformations work. (BTW I've used the forerunner of Martin Davis' library, from JHLabs, and it seemed to work well.) Jon -----Original Message----- From: netcdf-java-bounces@xxxxxxxxxxxxxxxx [mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Simone Giannecchini Sent: 24 March 2010 22:56 To: John Caron Cc: netcdf-java@xxxxxxxxxxxxxxxx Subject: Re: [netcdf-java] ncWMS and ellipsoid-support in CF-1.2 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/
netcdf-java archives: