[Proj] [gdal-dev] Coordinate system improvements - GDAL, libgeotiff, PROJ barn raising

[Martin Desruisseaux]

Le 15/05/2018 à 23:02, Even Rouault a écrit :

> 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
> https://github.com/opengeospatial/geoapi/tree/master/geoapi-java-python
> , which seems to be Java code calling Python classes, right ?
>
Yes, and conversely (this is bi-directional).

> For the sake of my curiousity, are there such (public) implementations
> of GeoAPI in Python ?
>
We started a wrapper around GDAL at
https://github.com/opengeospatial/geoapi/tree/master/geoapi-gdal using
the GDAL-Python bindings (yes, this result in wrappers around wrappers).
Current version handles only metadata, but raster data should come later.

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
http://openeo.org/openeo/news/2018/03/17/poc.html

Real use case: since I have not yet been able to compile GDAL with the
"--with-java=yes" 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):

    (GeoAPI in Java) → (GeoAPI in Python) → (GDAL in Python) → (GDAL in C)

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.

Note that using a standard API does not prevent the use of GDAL-specific
API when interoperability is not a goal.

> 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.

GeoAPI interfaces are derived from ISO 19111, which is available from
OGC there:

    http://portal.opengeospatial.org/files/?artifact_id=39049

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 GeodeticDatum will be renamed
GeodeticReferenceFrame. The WKT 2 format (ISO 19162) is also going to be
updated accordingly. Those changes have not yet been reflected in GeoAPI.

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.

> > This is not theoretical - GeoAPI implementation backed by Proj.4
> through
>
> > the JNI already exists for 5~10 years at
>
> > http://www.geoapi.org/geoapi-proj4/index.html and has been used for
>
> > testing Proj.4. At least one Proj bug has been identified by this test
>
> > suite.
>
>  
>
> Interesting. And besides testing, do you know if that is used in
> production as well ?
>
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.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180516/3a268bb1/attachment.html>