The GDAL/Proj.4 community has raised $142,000 for improving the map projection library behind major Open Source geospatial softwares. The issues to be fixed require an architectural change. Proj.4 is moving away from the early-binding approach (where WGS 84 is used as a pivot system) to a late-binding approach (with no fixed pivot system and with parameters that may depend on the geographic area). This change is required for accurate transformations in some situations. Implementing the late-binding approach requires a more complete EPSG geodetic dataset than the CSV files bundled in Proj.4. SQLite is the proposed alternative. Finally expressing this richer information in a Well Known Text (WKT) format requires ISO 19162 support (also known as « Well Known Text 2 »). The new WKT 2 standard fixes some ambiguities that caused the apparition of non-standard interpretations of WKT 1 standard, and can describe reference systems that can not be described in the previous standard (for example projections over pole).
Those improvements to be implemented in Proj.4 were already implemented for more than 10 years in Apache Spatial Information System (SIS) project or its predecessor GeoTools, except WKT 2 which has been implemented in 2014. Indeed the GDAL Coordinate System Barn Raising cites GeoAPI and Apache SIS has inspiration sources. But if Apache SIS was a precursor, it was not because of clever developers. Apache SIS chooses to follow closely the ISO 19111 conceptual model for its design. While apparently overly complex at first sight (developers are often prompt to judge someone’s else model as « unnecessary complexity »), complying with OGC/ISO models allowed Apache SIS to benefit from the insight of the experts who designed those standards. With more than 15 years of experience with this approach, we feel that its long-term benefit has been largely demonstrated since ISO/TC211 experts anticipate in their models many real-world complexities that are not immediately apparent to developers. However this benefit exists only provided that we use the right standards, which are the UML in abstract models (ISO 19115, ISO 19111, etc.). The standards designed for web technologies (WCS, XML, etc.) are usually not suitable for designing the API of a library.
Proj.4 is now following a similar path, with a proposed API very similar to ISO 19111 model. If Proj.4 continue on this path, its API would naturally be close to the Java interfaces defined in GeoAPI (and implemented in Apache SIS) since they would share the same conceptual model. This may open an opportunity to use implementation-neutral parts of Proj.4 API for defining a C++ version of GeoAPI, with Proj.4 being one implementation. It would make easier to share tests, or allow users to depend more transparently on the library of their choice.