[Proj] Use of C++

[Even Rouault]

Hi,

As announced previously, and given that the SQLite related thread has calmed 
down (except license related discussions that aren't directly related to it), 
this is the second potentially controversial topic I wanted to discuss.

To be able to handle WKT v1 and WKT v2, relying on the
object modeling of CRS, coordinate transformations and related concepts,
detailed in the ISO 19111:2018 / OGC 18-005r1 "OGC Abstract Specification: 
Topic 2: Referencing by coordinates" seems an appropriate start.
See http://www.opengeospatial.org/standards/requests/166 (note: access to the 
draft docx requires OGC membership currently)

ISO 19111:2018 will soon replace the current ISO 19111:2007 / OGC 08-015r2 :
http://portal.opengeospatial.org/files/?artifact_id=39049

This updated specification brings new concepts, particularly the
concept of dynamic geodetic reference frames (dynamic datums) that are going 
to be fundamental for current (ITRF, WGS84) or future datums (NATRF2022 that 
will replace NAD83 in the USA, ATRF in Australia ...)
In the coming months, there will be revision of WKT 2 to catch up with this 
evolution of ISO 19111.
Future versions of the EPSG database will also later adapt to this.
ISO 19111 exposes the concepts with UML modelling. We also have GeoAPI 
( http://www.opengeospatial.org/standards/geoapi ) that
offers Java (and in progress Python) class hierarchies. In the PROJ context, 
it seems natural to opt for C++. Part of that new API will be exposed to C , 
the exact scope remains to be determined depending on the needs. To be clear, 
this would not impact the status of existing proj C API, and the already 
announced retirement plans of projects.h and proj_api.h.

On a more practical note, this is also the opportunity to reuse existing C++ 
code from GDAL (WKT tree node building).

I know that this choice of C++ could be perceived as an obstacle for 
portability of PROJ, but I don't think this is an actual concern in practice. 
Compilers most of us use today (gcc / mingw, clang, Visual Studio, ICC) are 
all C++ capable. To build current versions of gcc, you even need a C++98 
compatible compiler. For CLang, a C++11 capable one. So platforms that aren't 
legacy have all a C++ compiler available. And I believe people that will be 
ready to adopt proj 6 are unlikely to do so on legacy systems where no C++ 
compiler would be available.

Regarding which C++ flavour, I'd like to push for C++11. It brings upon C++98 
a number of useful features. A few that come to mind for the work to come 
would be the override keyword (to make sure virtual functions are properly 
deriving from their base defintions), std::unique_ptr (to simplify memory 
management).
C++11 means gcc >= 4.8, clang >= 3.3 and Visual Studio >= 2015.
We switched to C++11 requirement for GDAL for the latest GDAL 2.3.0 version, 
and up to now, I haven't heard strong complaints related to that.

As the functional scope of PROJ is extended (historically proj was a 
'projection calculator', which was enriched with early-binding datum 
transformation capabilities, reworked with all the new PROJ 5 capabilities 
paving the road for late-binding capabilities, and, with the planned work, 
becoming a kind of 'libcrs'), it seems natural to use the appropriate tools to 
implement those enhanced capabilities.

I think allowing C++ could be an opportunity to modernize other parts of the 
existing code base: like the implementation of transformations/projections as 
C++ objects instead of the current function pointer approach. But that's a bit 
beyond my current objectives. Just wanted to mention this as an opportunity.

Thoughts ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com