<div dir="ltr">Even, regarding simplification by elimination:<div><br></div><div>Obviously Kristian will want to answer this himself, but I would like to mention at least one thing (or perhaps rather aspect) that will buy us simplification by eliminating projects.h and proj_api.h:</div><div><br></div><div>We would get rid of the type-punning-by-preprocessor-defs that destroyed Gerald's classic PROJ.4 core API, (pj_init, pj_fwd, pj_inv, and pj_free), by turning XY and LP into UV behind the back of the user, such that XY xy is no longer adressed xy.x and xy.y, but xy.u and xy.v</div><div><br></div><div>We would also get rid of the half baked namespacing-and-information-hiding-by-misleading-typedef, implemented by e.g.</div><div><div>typedef void *projPJ, and typedef void *projCtx, rather than by forward declarations.</div></div><div><br></div><div>This kind of stuff has been hell to work around (see the text in the top of proj.h for rationale for the work). This is not said to belittle Frank's work, which has been of immense value for PROJ.4, and has kept it afloat and in constant evolution, for more than 15 years: His work is admirable, but has, naturally, been focused on whatever (or whom-ever) paid the bills.</div><div><br></div><div>This has given us support for vertical datums, support for NTv2, support for a "failrly accurate for the needs when it was introduced 15 years ago" interface function as pj_transform, which to a large degree succeeds in "giving the user what (s)he wants without asking too many annoying geodetic questions".</div><div><br></div><div>It has, however, also given us the, largely superfluous contexts, and the fileapi, which, apart form missing a fgetc- style function, also in general suffer from a feeling of "work made for hire" for a specific customer, using it for in house stuff (only since it is largely unknown by search engines) - but now we have to maintain this stuff,without even knowing what the rationale behind was.</div><div><br></div><div>So yes - we could certainly benefit from skipping projects.h and proj_api.h : It will buy us some simplifications - I'm just not sure that this is the right way to do things. More about this later.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-11 20:06 GMT+01:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-family:'Sans Serif';font-size:9pt;font-weight:400;font-style:normal"><span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> territory". With this in mind I think we should consider only supporting</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> the new API in proj.h and dropping the other APIs. This will allow us to</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> simplify the code immensely. </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
</span><p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Can you sketch a bit what would be simplified in doing so ?</p><span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> At the moment we jump through a bunch of hoops</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> to keep backwards compatibility. We'd probably still do that for the next</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> release, but not having projects.h and proj_api.h as part of the public API</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> we can change things behind the scenes in future releases.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
</span><p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">If I remember the analysis of Debian packages, while dropping projects.h would have a moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause proj 5 to take months to years before being available in distributions due to many packages not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be done by upstream projects. not a quick&dirty hack that the packager can do)</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Thus in this context of software distributions, applications that would be adapted to use the new API wouldn't be able to use it in practice for a long time. Worse, applications that would do the changes to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 in a transition period if they want their new releases to be packaged. To make their life easier by avoiding to have them to support both API, a proj 5 should be available as packaged as fast as possible.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would use the new API behind the scene ? The projPJ struct could be something different than the PJ one, for example just storing the text. And when doing pj_transform() you would build a pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this compatibility layer (assuming this is possible) would be worth it</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Or alternate plan :</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">- for proj 5.0, add at top of proj_api.h</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_<wbr>BE_REMOVED_IN_PROJ_5_1</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_<wbr>REMOVED_IN_PROJ_5_1, but you should strongly consider using proj.h now"</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">#endif</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">- for proj 5.1, remove proj_api.h (and projects.h)</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Benefits:</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">* this would make proj 5 easy to be packaged, by avoiding a flag day</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">* applications would be clearly warned they have to do something, and have time to do the changes</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">* after proj 5.0 release, proj master could benefit from the needed cleanups.</p><span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Even</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">-- </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Spatialys - Geospatial professional services</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a></p></span></div><br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br></blockquote></div><br></div>