<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<p>Hello Even
</p>
<p>Le 15/05/2018 à 19:42, Even Rouault a écrit :</p>
</div>
<blockquote type="cite" cite="mid:5494637.lyT8hx8tha@even-i700">
<meta name="qrichtext" content="1">
<style type="text/css">
p, li { white-space: pre-wrap; }</style>Python bindings over what ?<br>
</blockquote>
<p>Over a standard API. Not any particular implementation. To make a comparisons with databases:
</p>
<ol>
<li>The C/C++ language has ODBC as a neutral API for accessing various databases. When accessing a database through ODBC, a C/C++ software does not need to care if the database is MS-Access, PostgreSQL, etc.</li>
<li>Java has JDBC for the same purpose. When accessing a database through JDBC, a Java software does not need to care if the database is PostgreSQL, Derby, etc. JDBC is strongly inspired by ODBC, so both APIs are similar.</li>
<li>Then there is JDBC-ODBC bridge. This bridge allows Java software to access any ODBC-compliant database as if it was a JDBC-compliant database. The JDBC-ODBC bridge was extensively used in early Java day, when few JDBC drivers were available.
</li>
</ol>
<p>Likewise, the Python binding is between Java interfaces of GeoAPI and Python abstract classes of GeoAPI. It is not between Apache SIS or GDAL or any particular implementation. The intent is to allow interoperability between any Python implementation of GeoAPI and any Java implementation of GeoAPI, in a way similar to JDBC-ODBC bridge.</p>
<p>But I guess this would be the topic for another mailing list.
</p>
<p>
</p>
<blockquote type="cite" cite="mid:5494637.lyT8hx8tha@even-i700">
<p>I guess the GeoAPI tests would be needed to be ported/adapted to whatever solution is adopted for proj testing. I don't really feel like using the proj JNI wrapper through Apache SIS would be an ideal solution : too many components aggegated, and I'm not sure if JNI wrapper will have all the new capabilities exposed.</p>
</blockquote>
<p>My proposal is independent of Apache SIS. GeoAPI is an OGC project, and as such is independent of any implementation - OGC is very strict about vendor neutrality. GeoAPI is an API derived from OGC/ISO standards. For example ISO 19111 defines an object named <tt>SC_GeographicCRS</tt> which contains an association to another object named <tt>CS_EllipsoidCS</tt>, which itself contains associations to axes, which have associations to units of measurements, <i>etc.</i> GeoAPI translates this abstract model into Java interfaces and Python abstract classes, not into implementation. In C, it could be structures with only pointer to functions but no code; providing the code would be up to Proj.</p>
<p>Having a common API allows to run the same tests with different implementations, in the same way that ODBC/JDBC allow to use different databases with the same code. So it would allow Proj and Apache SIS to run the same tests - it does not establish any dependency of one to the other.</p>
<p>This is not theoretical - GeoAPI implementation backed by Proj.4 through the JNI already exists for 5~10 years at <a class="moz-txt-link-freetext" href="http://www.geoapi.org/geoapi-proj4/index.html">http://www.geoapi.org/geoapi-proj4/index.html</a> and has been used for testing Proj.4. At least one Proj bug has been identified by this test suite.</p>
<p> Martin</p>
<p>
</p>
</body>
</html>