<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<p>Le 15/05/2018 à 23:02, Even Rouault a écrit :</p>
</div>
<blockquote type="cite" cite="mid:1960914.6Ngjhn0EcI@even-i700">
<p>OK, I think I understand better what you meant. From my C/C++ perspective, when folks talk about a Python binding, this is a Python wrapper over some C/C++ code. I guess that here you are thinking to <a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/geoapi/tree/master/geoapi-java-python">https://github.com/opengeospatial/geoapi/tree/master/geoapi-java-python</a> , which seems to be Java code calling Python classes, right ?</p>
<meta name="qrichtext" content="1">
<style type="text/css">
p, li { white-space: pre-wrap; }</style></blockquote>
<p>Yes, and conversely (this is bi-directional).</p>
<p>
</p>
<blockquote type="cite" cite="mid:1960914.6Ngjhn0EcI@even-i700">
<p>For the sake of my curiousity, are there such (public) implementations of GeoAPI in Python ?</p>
</blockquote>
<p>We started a wrapper around GDAL at <a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/geoapi/tree/master/geoapi-gdal">https://github.com/opengeospatial/geoapi/tree/master/geoapi-gdal</a> using the GDAL-Python bindings (yes, this result in wrappers around wrappers). Current version handles only metadata, but raster data should come later.</p>
<p>The reason for this approach is that GDAL API is unique to GDAL. Applications using GDAL can not easily switch to another library when they need to. The purpose of a standard API is to reduce vendor lock-in. More specifically, our goal here is to explore the possibility to allow Open DataCube (a Python project using GDAL) to also work with Apache SIS as an alternative to GDAL. This is desirable when one library has features than the other does not have. A similar discussion in cloud environment can be seen at <a class="moz-txt-link-freetext" href="http://openeo.org/openeo/news/2018/03/17/poc.html">http://openeo.org/openeo/news/2018/03/17/poc.html</a>
</p>
<p>Real use case: since I have not yet been able to compile GDAL with the "<tt>--with-java=yes</tt>" option on MacOS (maybe it is an issue on my side), I already use all above-cited wrappers for my tests as below (where each → is a set of wrappers; the first → is implementation-neutral and the last → is from GDAL project):</p>
<blockquote>
<p>(GeoAPI in Java) → (GeoAPI in Python) → (GDAL in Python) → (GDAL in C)</p>
</blockquote>
<p>Of course so many indirections is not ideal, but it unblocks my situation for now. It also illustrates the power of standard API for using a library when no direct wrappers are available.</p>
<p>Note that using a standard API does not prevent the use of GDAL-specific API when interoperability is not a goal.</p>
<p>
</p>
<blockquote type="cite" cite="mid:1960914.6Ngjhn0EcI@even-i700">For
the CRS modelling, in the technical proposal of gdalbarn, I
mentionned I will probably take inspiration from GeoAPI to
transpose that to a C++ class hierarchy. That said, I'm not
completely sure at that point to exactly follow the Java class
hiearachy as it is pretty "verbose" (lots of interfaces at first
sight [1]), but that needs to be studied further.</blockquote>
<p>GeoAPI interfaces are derived from ISO 19111, which is available from OGC there:</p>
<blockquote>
<p><a class="moz-txt-link-freetext" href="http://portal.opengeospatial.org/files/?artifact_id=39049">http://portal.opengeospatial.org/files/?artifact_id=39049</a></p>
</blockquote>
<p>I suggest to use ISO 19111 as the primary source. GeoAPI interfaces may be used for saving time (e.g. with copy-and-paste) or for filling holes in areas not covered by ISO 19111, but in case of doubt the above OGC/ISO document should be the authoritative reference. Note however that ISO 19111 is going to change - its revision process is nearly completed. For example <tt>GeodeticDatum</tt> will be renamed <tt>GeodeticReferenceFrame</tt>. The WKT 2 format (ISO 19162) is also going to be updated accordingly. Those changes have not yet been reflected in GeoAPI.</p>
<p>If you consider defining a C/C++ API derived from ISO 19111, directly or indirectly (through current GeoAPI interfaces), I would be very interested in including this C/C++ API in GeoAPI if you agree, and propose them as an OGC standard. That way, there would be no need to define JNI wrappers for Proj anymore. JNI wrappers for the C/C++ API would be sufficient to handle any implementation of that API, with Proj being one of them, and the test suite mentioned in my previous email could be run on Proj with no additional effort.</p>
<p>
</p>
<blockquote type="cite" cite="mid:1960914.6Ngjhn0EcI@even-i700">>
This is not theoretical - GeoAPI implementation backed by Proj.4
through
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> the JNI already exists for 5~10 years at</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <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</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> testing Proj.4. At least one Proj bug has been identified by this test</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> suite.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Interesting. And besides testing, do you know if that is used in production as well ?</p>
</blockquote>
<p>I don't know. The above-cited wrappers have never been formally released, because GeoAPI has been dormant until last year (we restarted the group at OGC). A variant of those wrappers are released in Apache SIS 0.8, which allow users to use Proj or SIS own implementation transparently.</p>
<p> Martin</p>
<p>
</p>
</body>
</html>