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

[Martin Desruisseaux]

Hello Even

Le 15/05/2018 à 19:42, Even Rouault a écrit :

> Python bindings over what ?

Over a standard API. Not any particular implementation. To make a
comparisons with databases:

 1. 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.
 2. 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.
 3. 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.

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.

But I guess this would be the topic for another mailing list.

> 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.
>
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 SC_GeographicCRS which
contains an association to another object named CS_EllipsoidCS, which
itself contains associations to axes, which have associations to units
of measurements, /etc./ 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.

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.

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.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180515/95acc957/attachment.htm