<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>
    &nbsp;&nbsp;&nbsp; Regards,<br>
    <br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Martin<br>
    <br>
  </body>
</html>