<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"Sans Serif";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Even,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">As far as I know in the FOSS ecosystem, projects.h use is very marginal, or accidental. The only occurence I've in mind is in the OGDI project that uses nad_init() in one place.
</span><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">But I wouldn't mind too much about OGDI...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Sans Serif","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Good, that makes it a bit easier. There might be users outside of FOSS and I think it is fair to give them some time to bring their things in order
if/when we break stuff.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">I'm not completely sure but I think the main driver for the context system was to remove / deprecate use of pj_errno as a global error variable. errno is now attached to the
context.<o:p></o:p></span></p>
<p class="MsoNormal" style="-qt-paragraph-type:empty;-qt-block-indent:0"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yeah, I believe the idea was to make it thread-safe. Why regular errno is not used I can understand though.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">We should probably make sure it is in a clean enough way before releasing it to the world<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree. I think we have time to get it in a reasonable state before august.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">I'm wondering: is there a reason for having a new proj.h ?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The idea was to produce a new clean API with more sensible types, better namespace, etc. It has been discussed earlier both
here and on GitHub (for instance here <a href="https://github.com/OSGeo/proj.4/pull/388">
<span style="color:#1F497D;text-decoration:none">https://github.com/OSGeo/proj.4/pull/388</span></a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif";color:#1F497D"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""> > On the other hand, having the new header and removing the old one will be an obvious way of signaling "eh, breaking changes have occured
!" :-) <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That was exactly what I had in mind! Along with a giant leap forward in version number it should raise all the flags of
people using PROJ.4. <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It was also why I suggested to keep a maintenance version based on 4.9.4 for a few years. So developers have time to absorb
the changes in their own time.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif""><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">> Actually one of the point of having a dedicatd proj.h would be to make sure that people don't accidentally
use old API that will be removed. But I see that proj.h includes proj_api.h, so this risk still exists. Why proj.h couldn't avoid the proj_api.h depedency ?<o:p></o:p></span></p>
<p class="MsoNormal" style="-qt-paragraph-type:empty;-qt-block-indent:0"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think it should be possible to remove the dependency of proj_api.h in proj.h. Perhaps by putting the parts that are dependant on proj_api.h in
a proj_internal.h as suggested in your GitHub issue?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Kristian<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Fra:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Even Rouault [mailto:even.rouault@spatialys.com]
<br>
<b>Sendt:</b> 22. juni 2017 18:48<br>
<b>Til:</b> proj@lists.maptools.org<br>
<b>Cc:</b> Kristian Evers<br>
<b>Emne:</b> Re: [Proj] Coming releases of PROJ.4<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">Kristian,<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> The projects.h interface has a long history and exposes<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> most of the inner workings of PROJ.4.
<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">As far as I know in the FOSS ecosystem, projects.h use is very marginal, or accidental. The only occurence I've in
mind is in the OGDI project that uses nad_init() in one place. But I wouldn't mind too much about OGDI...<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> That is also why the<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> proj_api.h interface exists. It was created in an effort of simplifying<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> things and making a more modern API. That was now roughly 15 years ago, and<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> On top of that it has some unfortunate<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> design choices, for instance the context-system which is rather hard to<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> work with and comprehend. Unfortunately it is also completely undocumented<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> and the original ideas behind it seem to be lost.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">I'm not completely sure but I think the main driver for the context system was to remove / deprecate use of pj_errno
as a global error variable. errno is now attached to the context.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">While just reviewing proj.h, I had a few questions/observations :<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif""><a href="https://github.com/OSGeo/proj.4/issues/529"><span lang="EN-US">https://github.com/OSGeo/proj.4/issues/529</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Sans Serif","serif"">
(I see you've began to answer to some questions while I was still editing it ;-))<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">We should probably make sure it is in a clean enough way before releasing it to the world<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">>
<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> PROJ.4 also has three different build-systems: Autotools, nmake and CMake.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> Autotools is the authoritative build-system which the other two try to<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> mimic as best as possible. Nmake was introduced in order to build PROJ.4 on<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> Windows and lately CMake has also been introduced as there was a demand for<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> it.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">>
<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> Due to the above I suggest that we focus our efforts entirely on the proj.h<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">> API and CMake from the next release and onwards.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">Adoption of the new API and deprecation of proj_api.h will show greater resistance than dropping autoconf/nmake.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">I'm wondering: is there a reason for having a new proj.h ? (we perhaps discussed that, but I already forgot) Imagine
that I want to write code that is compatible of old and new proj versions (I'm pretty sure that a number of proj users will have to do that at some point). It could be convenient to still include proj_api.h and depending on the value of PJ_VERSION decide which
API are available. Whereas if you have a new header, that make you also change your autoconf/cmake logic detection of proj4.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">In the transition period, proj_api.h could have two sections : a section with the new API and with the ancient API
clearly separated. At some point ancient API would be removed.<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">On the other hand, having the new header and removing the old one will be an obvious way of signaling "eh, breaking
changes have occured !" :-) <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">Actually one of the point of having a dedicatd proj.h would be to make sure that people don't accidentally use old
API that will be removed. But I see that proj.h includes proj_api.h, so this risk still exists. Why proj.h couldn't avoid the proj_api.h depedency ?<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">Even<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-paragraph-type:empty;-qt-block-indent:0">
<span style="font-size:9.0pt;font-family:"Sans Serif","serif""> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">--
<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif"">Spatialys - Geospatial professional services<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt;-qt-block-indent:0;-qt-user-state:0"><span style="font-size:9.0pt;font-family:"Sans Serif","serif""><a href="http://www.spatialys.com">http://www.spatialys.com</a><o:p></o:p></span></p>
</div>
</body>
</html>