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/
