<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>ok,</p>
<p><br /></p>
<p>... but NO thanks! .. if it does not add anything new .. for example a new projection .. we do NOT want to have it!! --- it is just some rewriting which forces all users to do some tricks and hours of extra work etc. with their working code without actually adding anything usable.</p>
<p>Please, do not make such changes that are not required!! -- fix bugs and add some **useful** features ... but do not play with the coding ... since that already works! (We actually PREFER to have it old fashion than anything new and stupid!) --- if you like to make a "clean" Proj.4 for yourself just rename it something else and use it! --- but do not mess with the current version ... we have had enough about those idiots that believe they have some KING ideas how everybody should write programs. And then after next 10 years comes the next one ... and the next one ... and the next one ... all are pushing some strange ideas to play with other programmers and make lot of work that is not at all required! Let it be!!</p>
<p><br /></p>
<p>Rename it and do what ever you like but stop ***playing*** with the original Proj.4 source code, thanks!</p>
<p><br /></p>
<p>Janne.</p>
<p><br /></p>
<p>------------------------------------------------------------</p>
<p><br /></p>
<p>Kristian Evers kirjoitti 2016-11-03 16:40:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --> <!-- head ignored --><!-- meta ignored --> <!-- meta ignored -->
<div class="WordSection1">
<p class="MsoNormal"><span>Hello everybody,<!-- o ignored --></span></p>
<p class="MsoNormal"><span><!-- o ignored --> </span></p>
<p class="MsoNormal"><span>I want to direct your attention to the work Thomas Knudsen is doing on a new and more homogenous API for PROJ.4. Thomas presented his first ideas about a new API earlier this year when talk about transformation pipelines first started. Since then the initial pipeline pull request has been withdrawn and the changes needed to make transformation pipelines happen are broken into smaller more logical chunks. A new API being one of those smaller chunks. Before anyone gets their knickers in a twist, let me just stress the fact that this DOES NOT change the behavior of the old API (projects.h/proj_api.h), it merely adds a cleaner interface that will make usage of PROJ.4 a lot easier in the future. <!-- o ignored --></span></p>
<p class="MsoNormal"><span>Thomas has already typed up a description of his work but until now it has only been available on the GitHub page. This is his introduction to the new API:<!-- o ignored --></span></p>
<p class="MsoNormal"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">The original proj API (defined in projects.h) has grown organically<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">over the years, but it has also grown somewhat messy.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">The same has happened with the newer high level API (defined in<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">proj_api.h): To support various historical objectives, proj_api.h<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">contains a rather complex combination of conditional defines and<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">typedefs. Probably for good (historical) reasons, which are not<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">always evident from today's perspective.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">This is an evolving attempt at creating a re-rationalized API<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">with primary design goals focused on sanitizing the namespaces.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Hence, all symbols exposed are being moved to the pj_ namespace,<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">while all data types are being moved to the PJ_ namespace.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Please note that this API is *orthogonal* to the previous APIs:<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Apart from some inclusion guards, projects.h and proj_api.h are not<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">touched - if you do not include proj.h, the projects and proj_api<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">APIs should work as they always have.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">A few implementation details:<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Apart from the namespacing efforts, I'm trying to eliminate three<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">proj_api elements, which I have found especially confusing.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">FIRST and foremost, I try to avoid typedef'ing away pointer<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">semantics. I agree that it can be occasionally useful, but I<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">prefer having the pointer nature of function arguments being<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">explicitly visible.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Hence, projCtx has been replaced by PJ_CONTEXT *.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">SECOND, I try to eliminate cases of information hiding implemented<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">by redefining data types to void pointers.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">I prefer using a combination of forward declarations and typedefs.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Hence:<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"> typedef void *projCtx;<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">Has been replaced by:<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"> struct projCtx_t;<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"> typedef struct projCtx_t PJ_CONTEXT;<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">This makes it possible for the calling program to know that the<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">PJ_CONTEXT data type exists, and handle pointers to that data type<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">without having any idea about its internals.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">(obviously, in this example, struct projCtx_t should also be moved<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">to struct pj_ctx some day...)<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">THIRD, I try to eliminate implicit type punning. Hence this API<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">introduces the OBSERVATION data type, for generic coordinate and<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">ancillary data handling.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">It includes the PJ_SPATIOTEMPORAL and PJ_TRIPLET unions<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">making it possible to make explicit the previously used<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">"implicit type punning", where a XY is turned into a LP by<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">re#defining both as UV, behind the back of the user.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">The bare essentials API presented here follows the PROJ.4<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">convention of sailing the coordinate to be reprojected, up on<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">the stack ("call by value"), and symmetrically returning the<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">result on the stack. Although the OBSERVATION object is 4 times<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">as large as the traditional XY and LP objects, timing results<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">have shown the overhead to be very reasonable.<!-- o ignored --></span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal" style="margin-left: 65.2pt;"><span style="font-size: 10.0pt; font-family: Consolas;">See pj_proj_test.c for an example of how to use the API.<!-- o ignored --></span></p>
<p class="MsoNormal"><span style="font-size: 10.0pt; font-family: Consolas;"><!-- o ignored --> </span></p>
<p class="MsoNormal"><span>The pull request is found at <a href="https://github.com/OSGeo/proj.4/pull/445"> https://github.com/OSGeo/proj.4/pull/445</a> and the example code can be found here: <a href="https://github.com/busstoptaktik/proj.4/blob/pipeline_plus_api/examples/pj_proj_test.c"> https://github.com/busstoptaktik/proj.4/blob/pipeline_plus_api/examples/pj_proj_test.c</a><!-- o ignored --></span></p>
<p class="MsoNormal"><span><!-- o ignored --> </span></p>
<p class="MsoNormal"><span>Please share your thoughts on the new API that Thomas has been working on. There has already been some discussion about how to expose the thread-contexts of the PJ-objects. In the current incarnation they are somewhat hidden to the user compared the what’s in proj_api.h. On top of that, Thomas and I have personally discussed the projFileAPI which does not seem to be used outside of PROJ.4 itself (at least nothing shows up on google, closed source we have no idea about). Is this something people actually need?<!-- o ignored --></span></p>
<p class="MsoNormal"><span><!-- o ignored --> </span></p>
<p class="MsoNormal"><span>/Kristian<!-- o ignored --></span></p>
</div>
<!-- html ignored --><br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<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">http://lists.maptools.org/mailman/listinfo/proj</a></div>
</blockquote>
<p><br /></p>
<div>-- <br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">MNS Support<br /> NNS Master Navigator Software<br /> Copyright © Sapper Oy<br /> <a href="http://www.mnspoint.com" target="_blank" rel="noreferrer">www.mnspoint.com</a><br /> <a href="mailto:support@mnspoint.com">support@mnspoint.com</a></div>
</div>
</body></html>