[Proj] [gdal-dev] Coordinate system improvements - GDAL, libgeotiff, PROJ barn raising
even.rouault at spatialys.com
Tue May 15 16:02:12 EST 2018
On mardi 15 mai 2018 22:21:35 CEST Martin Desruisseaux wrote:
> Hello Even
> Le 15/05/2018 à 19:42, Even Rouault a écrit :
> > Python bindings over what ?
> Over a standard API. Not any particular implementation.
> Likewise, the Python binding is between Java interfaces of GeoAPI and
> Python abstract classes of GeoAPI.
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 ?
> 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.
For the sake of my curiousity, are there such (public) implementations of GeoAPI in Python ?
> > 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
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 ), but that needs to be studied further.
> 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
Interesting. And besides testing, do you know if that is used in production as well ?
 Or perhaps I was confused when also looking at the Apache SIS javadoc where there's the
implementation of the interfaces, and the mix of interface classes + implementation classes
give the classic headaches of dealing with Java API. OK I know I'm getting controversial here
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj