[Proj] Use of C++
even.rouault at spatialys.com
Wed May 23 05:25:12 EST 2018
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 :
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
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.
Spatialys - Geospatial professional services
More information about the Proj