<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Figured I’d chime in on this subject as well. As one of the co-signers of <a href="http://gdalbarn.com/" class="">gdalbarn.com</a>
<div class="">I am obviously on board with the switch to include the use of C++ in PROJ. And from</div>
<div class="">the responses so far it seems the community is largely behind the effort as well,</div>
<div class="">apart from a few skeptics. I agree that the inclusion of C++ in the project is not as</div>
<div class="">“dangerous" as it might initially sound like. The only real issue that’s been highlighted</div>
<div class="">so far is complications with compilation on microcontrollers but those claims still haven’t</div>
<div class="">been backed up by real world examples, so I would say we are good to go on this.</div>
<div class=""><br class="">
</div>
<div class="">Like Thomas, I am not particularly well-versed in C++ so I am not one to talk about</div>
<div class="">best practices. For this reason I would ask that some of the C++ experts in the</div>
<div class="">community come up with a set of coding guidelines for the C++ parts of the code</div>
<div class="">base. Lately the lack of code formatting conventions in PROJ has been frustrating</div>
<div class="">to several contributors. With the addition of the new C++ parts of the code we have</div>
<div class="">the chance to at least include conventions for the C++ code. I know this has been</div>
<div class="">a topic for GDAL recently and since we have a big overlap with the GDAL community</div>
<div class="">perhaps we can benefit from their experiences. Kurt and Even, I believe you’ve been</div>
<div class="">involved in improving the GDAL code formatting rules, would one of you be willing to</div>
<div class="">suggest something that we can use in PROJ? A good starting point, I guess, would</div>
<div class="">be <a href="https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting" class="">https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting</a>. </div>
<div class=""><br class="">
</div>
<div class="">I know this is poking the hornets nest and there’s a risk that my request can result in</div>
<div class="">yet another heated discussion about code style. Please keep the discussion civil</div>
<div class="">and keep in mind that this is meant as a preemptive strike to avoid future flame</div>
<div class="">wars.</div>
<div class="">
<div><br class="">
</div>
<div>/Kristian</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 23 May 2018, at 12:25, Even Rouault <<a href="mailto:even.rouault@spatialys.com" class="">even.rouault@spatialys.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi,<br class="">
<br class="">
As announced previously, and given that the SQLite related thread has calmed <br class="">
down (except license related discussions that aren't directly related to it), <br class="">
this is the second potentially controversial topic I wanted to discuss.<br class="">
<br class="">
To be able to handle WKT v1 and WKT v2, relying on the<br class="">
object modeling of CRS, coordinate transformations and related concepts,<br class="">
detailed in the ISO 19111:2018 / OGC 18-005r1 "OGC Abstract Specification: <br class="">
Topic 2: Referencing by coordinates" seems an appropriate start.<br class="">
See <a href="http://www.opengeospatial.org/standards/requests/166" class="">http://www.opengeospatial.org/standards/requests/166</a> (note: access to the
<br class="">
draft docx requires OGC membership currently)<br class="">
<br class="">
ISO 19111:2018 will soon replace the current ISO 19111:2007 / OGC 08-015r2 :<br class="">
<a href="http://portal.opengeospatial.org/files/?artifact_id=39049" class="">http://portal.opengeospatial.org/files/?artifact_id=39049</a><br class="">
<br class="">
This updated specification brings new concepts, particularly the<br class="">
concept of dynamic geodetic reference frames (dynamic datums) that are going <br class="">
to be fundamental for current (ITRF, WGS84) or future datums (NATRF2022 that <br class="">
will replace NAD83 in the USA, ATRF in Australia ...)<br class="">
In the coming months, there will be revision of WKT 2 to catch up with this <br class="">
evolution of ISO 19111.<br class="">
Future versions of the EPSG database will also later adapt to this.<br class="">
ISO 19111 exposes the concepts with UML modelling. We also have GeoAPI <br class="">
( http://www.opengeospatial.org/standards/geoapi ) that<br class="">
offers Java (and in progress Python) class hierarchies. In the PROJ context, <br class="">
it seems natural to opt for C++. Part of that new API will be exposed to C , <br class="">
the exact scope remains to be determined depending on the needs. To be clear, <br class="">
this would not impact the status of existing proj C API, and the already <br class="">
announced retirement plans of projects.h and proj_api.h.<br class="">
<br class="">
On a more practical note, this is also the opportunity to reuse existing C++ <br class="">
code from GDAL (WKT tree node building).<br class="">
<br class="">
I know that this choice of C++ could be perceived as an obstacle for <br class="">
portability of PROJ, but I don't think this is an actual concern in practice. <br class="">
Compilers most of us use today (gcc / mingw, clang, Visual Studio, ICC) are <br class="">
all C++ capable. To build current versions of gcc, you even need a C++98 <br class="">
compatible compiler. For CLang, a C++11 capable one. So platforms that aren't <br class="">
legacy have all a C++ compiler available. And I believe people that will be <br class="">
ready to adopt proj 6 are unlikely to do so on legacy systems where no C++ <br class="">
compiler would be available.<br class="">
<br class="">
Regarding which C++ flavour, I'd like to push for C++11. It brings upon C++98 <br class="">
a number of useful features. A few that come to mind for the work to come <br class="">
would be the override keyword (to make sure virtual functions are properly <br class="">
deriving from their base defintions), std::unique_ptr (to simplify memory <br class="">
management).<br class="">
C++11 means gcc >= 4.8, clang >= 3.3 and Visual Studio >= 2015.<br class="">
We switched to C++11 requirement for GDAL for the latest GDAL 2.3.0 version, <br class="">
and up to now, I haven't heard strong complaints related to that.<br class="">
<br class="">
As the functional scope of PROJ is extended (historically proj was a <br class="">
'projection calculator', which was enriched with early-binding datum <br class="">
transformation capabilities, reworked with all the new PROJ 5 capabilities <br class="">
paving the road for late-binding capabilities, and, with the planned work, <br class="">
becoming a kind of 'libcrs'), it seems natural to use the appropriate tools to <br class="">
implement those enhanced capabilities.<br class="">
<br class="">
I think allowing C++ could be an opportunity to modernize other parts of the <br class="">
existing code base: like the implementation of transformations/projections as <br class="">
C++ objects instead of the current function pointer approach. But that's a bit <br class="">
beyond my current objectives. Just wanted to mention this as an opportunity.<br class="">
<br class="">
Thoughts ?<br class="">
<br class="">
Even<br class="">
<br class="">
-- <br class="">
Spatialys - Geospatial professional services<br class="">
http://www.spatialys.com<br class="">
_______________________________________________<br class="">
Proj mailing list<br class="">
Proj@lists.maptools.org<br class="">
http://lists.maptools.org/mailman/listinfo/proj<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>