<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello all<br>
<br>
In preparation for the GeoAPI session at the FOSS4G, I wish to
provide a GeoAPI implementation on top of the C/C++ Proj.4 library
as a "proof of concept" that GeoAPI can be used for accessing
transparently existing libraries. JNI bindings <a
href="http://svn.osgeo.org/metacrs/proj/trunk/proj/jniwrap/">already
exist</a> in Proj.4, thanks to Andrea Antonello's work. However I
wish to provide the bindings in a different way:<br>
<br>
<ul>
<li>The current binding expects <i>x</i>, <i>y</i> and
optionally <i>z</i> ordinate values to be provided in 3
separated arrays, while GeoAPI - like Java2D API - expect a
single array with (<i>x</i>,<i>y</i>) or (<i>x</i>,<i>y</i>,<i>z</i>)
tupples (note that the Proj.4 C/C++ API allows both forms).<br>
</li>
<li>The current binding allocates and deallocates the <tt>PJ</tt>
C/C++ structure (which implies parsing the Proj.4 parameters)
everytime the <tt>pj_transform</tt> method is invoked. I wish a
slightly different cycle in which the <tt>PJ</tt>
C/C++structure can be allocated once, reused for many calls to <tt>pj_transform</tt>,
and deallocated when the Java peer is garbage-collected.<br>
</li>
</ul>
<br>
There is also some apparent memory leaks in the C side of current
bindings that I would like to fix. In addition, I think that the
binding code in C should also checks argument values (null pointer,
index out of bounds) in order to avoid a crash if a Java application
pass wrongs parameter values.<br>
<br>
The Java API proposal can be viewed there. Every methods in this
class are native methods:<br>
<ul>
<li><a
href="http://www.geoapi.org/geoapi-proj4/apidocs/org/proj4/PJ.html">http://www.geoapi.org/geoapi-proj4/apidocs/org/proj4/PJ.html</a></li>
</ul>
<br>
The C side of the JNI bindings (not including the old bindings):<br>
<ul>
<li><a
href="https://geoapi.svn.sourceforge.net/svnroot/geoapi/trunk/geoapi-proj4/src/main/native/jniproj.c">https://geoapi.svn.sourceforge.net/svnroot/geoapi/trunk/geoapi-proj4/src/main/native/jniproj.c</a></li>
</ul>
<br>
So my questions are:<br>
<ul>
<li>
<p>Do peoples agree to commit those new JNI bindings (without
GeoAPI dependency) straight into the Proj.4 SVN code base,
together with the existing bindings? There will be no change
in the existing configuration that enable/disable compilation
of JNI bindings.</p>
</li>
<li>
<p>What do we do with existing bindings?</p>
</li>
<ul>
<li>Taking some time for fixing the memory leaks and add
argument checks?</li>
<li>Or deprecate them, suggesting peoples to use the new JNI
bindings instead?</li>
</ul>
</ul>
I guess that the answer to my last question depends on how widely
used are the current bindings?<br>
<br>
In any case, I want to thanks Andrea Antonello since its current
bindings provided a very convenient starting point that make very
easy for me to try alternatives.<br>
<br>
Regards,<br>
<br>
Martin<br>
<br>
</body>
</html>