Re: Is there a process for answering the concerns of a "no" vote?

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Scott

Le 10/10/2017 à 14:14, Scott Simmons a écrit :

> As much time as you need! If you need a few weeks, that it also fine.
>
Thanks. I just completed a draft attached to this email as Word
document. Below is a copy inline. Please let me know if there is
anything I should change.

    Regards,

        Martin


  Notes on GeoAPI concerns


    API for use in the cloud

GeoAPI is naturally well suited for use in the cloud and serverless
environments. Programming interfaces can be seen as a set of lambda
functions. The capability to send functions that are operated directly
in a network of distant machines exists in Java since 1997 with Remote
Method Invocation (RMI). An equivalent language-neutral technology
exists since 1995 with Common Object Request Broker Architecture
(CORBA), standardized as ISO 19500:2012. The very first version of
GeoAPI (not yet under that name) was published by OGC as COM, CORBA and
Java RMI interfaces by Aided Development Corporation (Cadcorp) in 2001.
While RMI and CORBA technologies are not very popular today, the
principles that make them possible – namely the extensive use of
interfaces, virtual methods, pointer to functions or lambda functions –
still apply today. AWS Lambda functions use the same mechanism in a
different environment. Users can provide AWS Lambda in Java, C#, Node.js
or Python. In the Java case, users implement a RequestHandler interface
defined by Amazon
<http://docs.aws.amazon.com/lambda/latest/dg/java-programming-model-handler-types.html>.
This is basically the same mechanism than GeoAPI. The project as
currently defined already enables the following scenario:

Markus wants to create his own algorithm to be deployed on the cloud.
But first, he needs to develop and debug the algorithm on his local
machine. He performs data loading, map projections, /etc./ with free
software though GeoAPI interfaces. Once his algorithm is ready, he send
the code to a commercially supported cloud infrastructure. That
infrastructure provides its own data extraction and map projection
engine tuned for their storage, not based on the free software used by
Markus for his development. But if the free software and the commercial
engine implement the same GeoAPI interfaces, then Markus’s program
executes on that cloud with no code change. For example the same call to
CoordinateOperation.transform(CoordinateSet) (from ISO 19111:2017 draft)
in Markus’s program can be executed with free software on Markus local
machine and with commercially provided engine on the cloud.


    Relationship with web based API

Web APIs are not only APIs, but also imply transfer protocols based on
XML, JSON or other formats defined by OGC. In a Mercator projection (for
example), we measured the cost of encoding and decoding a Comma
Separated Values (CSV) file to 90% of the total processing time. By
contrast APIs in programming languages are free to use the protocol of
their choice, or to avoid completely data transfers by transferring only
pointers to internal data structures. For example Google Cloud APIs
<https://cloud.google.com/apis/docs/overview> is provided both as JSON
REST interfaces that users can invoke directly using any standard HTTP
client, or as client library for easier access from user’s favourite
programming languages
<https://developers.google.com/api-client-library/> (currently Java, C#,
Python, JavaScript, PHP or Objective-C). In the later case, the Google
programming APIs can use transparently another protocol – gRPC (similar
in spirit to above-cited RMI and CORBA technologies) – instead of JSON
REST APIs for better performance.

In serverless environments like AWS Lambda, web application is partially
provided by the infrastructure itself. The infrastructure responds to
events and handles some JSON messages, then invokes the user-provided
lambda functions implemented in Java, C#, Python or Node.js. In other
words, while web APIs provide high-level APIs for transferring data and
executing pre-defined processes, implementations of custom processes
still need to be done in classical programming languages.

Amazon provides a large set of Java APIs
<http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html> that
users can exploit with their lambda functions. There is API for driving
S3 storage device, for “glacier” storage, for exploiting a relational
database on the cloud (Amazon RDS), /etc./ Those APIs provide facilities
for *creating* custom web services on the cloud, which can then be used
for launching processes on distant machines. Google App Engine defines a
different set of Java APIs.
<https://cloud.google.com/appengine/docs/standard/java/javadoc/> Both
API sets are incompatible. Both Google and Amazon provide also APIs in
Python and other languages. It is of course not GeoAPI goal to define a
unified API for generic cloud services, but we hope to offer an API for
some geospatial services. If may be preferable to do so before the
market become cluttered with incompatible geospatial APIs on those
platforms.

Note that Amazon AWS, Google App Engine and the Android platform already
leverage some common standard APIs, since they all leverage at least
basic classes from the standard Java Development Kit (JDK), even if
their Java Virtual Machines are completely different. This common base
reduces the effort needed for porting a process from one cloud to
another, but does not eliminate it. GeoAPI, if adopted, could have a
similar effect of the geospatial parts.


    Adoption

GeoAPI is currently implemented by Apache Spatial Information System
(SIS) <http://sis.apache.org/>. Wrappers exist for Proj.4 and UCAR
netCDF library, admittedly created by the same author. GeoTools (and
consequently GeoServer) uses an incompatible fork of GeoAPI
<http://osgeo-org.1560.x6.nabble.com/Unethical-use-of-GeoAPI-library-in-Geotools-td5188705.html>
for non-technical reasons. The Proj.4 – Apache SIS performance and
accuracy comparison
<https://www.geomatys.com/wordpress/index.php/2017/09/20/proj-4-versus-apache-sis-an-accuracy-comparison/?lang=en>
demonstrates the value of GeoAPI. The geo-referencing test suite
proposal <https://github.com/opengeospatial/testbed14-ideas/issues/37>
for test bed 14 is an extension of above comparison methods. This
demonstration has attracted interest of current Proj4J maintainer
<https://lists.apache.org/thread.html/5f332674c86c0787b0d33218f6f539c1198a46be9817001bf0384a9d@%3Cgeospatial.apache.org%3E>,
which agreed to plan GeoAPI wrappers. Adoption is a chicken-and-egg
problem; we need more implementations for attracting interest. If the
test bed proposal is accepted, we see it as an opportunity to get the
ball rolling.

Re: Is there a process for answering the concerns of a "no" vote?

[Martin Desruisseaux <ma...@geomatys.com>]

Sorry!!! wrong email address! (I did not intended to send that email on
public geospatial@apache.org mailing list)!

Well, hopefully it is not so bad... There is no nominative information
in that email. All my apologize if it causes any issue...

    Martin