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

[Even Rouault]

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

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.

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

Even

[1] 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
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180515/0f0f8f0b/attachment-0001.htm