<div dir="ltr">All:<br><br>I pretty much agree with Dan. For clarity (lacking in my previous entry),<br>there are two things, easily conflated, to talk about:<br><br> A. proj the program that people use (often on the command line)<br>to go between lat-long and projection coordinates. Most of these users<br>don't care about which lat/long they are using: certainly not important<br>if making a map, and probably not if using it to set up a grid system<br>for your own use (I've used it for both).<br><br> B. PROJ the package, which includes not just projections<br>but all the additional machinery to handle different datums--and<br>in the future heights and temporal changes.<br><br> I completely agree that PROJ needs to keep evolving; but at the<br>same time I (and probably many other users) would like to have proj<br>stay the same. This ought to be relatively easy since it is almost all<br>mathematics, the only parameters being the size and shape of the<br>ellipsoid--and I don't imagine there will be new values of this being<br>produced. But it depends on allowing the functionality of proj (not<br>PROJ) to not require the user who just wants a projection to have to<br>master the additional features needed to do datum transformations.<br><br> Of course grids are just projections, so it was easy for Gerald<br>to add things like SPCS, blurring the line a bit; but, with Daan (and<br>Gerald) I'd argue that it would be helpful to many users to have things<br>somewhat distinct.<br><br> And, I'd like to raise a question (I'm genuinely curious) about how<br>time-dependent motion will be added. Having been professionally engaged in<br>measuring and modeling crustal motion for the last 30+ years, I can say that it<br>is going to be a lot more complicated to keep track of. proj (as above) needs<br>only the -le parameters (a fixed set); once you add the rigid-body motions for<br>datum transformations there are a lot more parameters, many conventional (and<br>so unchanging), which EPSG fortunately collects; adding grids for distortion<br>(HARN) needs more information yet. But once you get into temporal changes,<br>things are even worse: models will keep changing either because of better data<br>or earthquakes (cf HTDP). This seems like a progression from a package<br>dominated by algebra to a small algebraic component attached to a large<br>and ever-growing database of parameters. I'm not arguing against it, at<br>all, just saying that it is going to be quite a challenge beyond modifying<br>the programs. (I completely lack the expertise to contribute to the code,<br>but if anyone has any geophysics questions I'm happy to try to answer them).<br><br>Thanks<br>Duncan Agnew<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 8:39 PM, Waldo Tobler <span dir="ltr"><<a href="mailto:tobler@geog.ucsb.edu" target="_blank">tobler@geog.ucsb.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Contrary to expectations there is a new projection worth adding:<div>The Tobler-Mercator</div><div><a href="http://dx.doi.org/10.1080/15230406.2017.1308837" target="_blank">http://dx.doi.org/10.1080/<wbr>15230406.2017.1308837</a></div><div>Waldo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 7:16 PM, <span dir="ltr"><<a href="mailto:strebe@aol.com" target="_blank">strebe@aol.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="3" color="black" face="Georgia, Times New Roman, Times, Serif"><font size="3">I don’t support Janne’s presentation. He does have a point, though. Actually, I think it’s Gerald Evenden’s point: Datum transformation is completely separable from map projections. Both functions could exist independently but interoperate smoothly with only light coordination. There is little benefit in conflating them and much benefit to keeping them separate.<br>
<br>
Why can’t Janne, Duncan and others just stick with old versions? Because then they don’t get bug fixes, security fixes, new projections, performance enhancements, or other maintenance. Why don’t they just fork out the parts they need and go their separate ways? Because then the code bases diverge such that effort relevant to both is duplicated or ignored.<br>
<br>
It’s probably too late to shove that toothpaste back into the tube, although, if the proj4 community were motivated to make it happen, it seems like it could.<br>
<br>
Best,<br>
— daan Strebe<br>
</font><div><div class="m_9211520834529266641h5">
<div> <font size="3"><br>
</font></div>
<div> <font size="3"><br>
</font></div>
<div><font size="3"> </font><br>
</div>
<div style="font-family:helvetica,arial;font-size:10pt;color:black">-----Original Message-----<br>
From: Richard Greenwood <<a href="mailto:richard.greenwood@gmail.com" target="_blank">richard.greenwood@gmail.com</a>><br>
To: PROJ.4 and general Projections Discussions <<a href="mailto:proj@lists.maptools.org" target="_blank">proj@lists.maptools.org</a>><br>
Sent: Wed, Aug 9, 2017 5:36 pm<br>
Subject: Re: [Proj] GitHub "project" for the next release<br>
<br>
<div id="m_9211520834529266641m_-7785321975750488325AOLMsgPart_1.2_204052c9-6ff9-46fb-9fb8-04bd7cef1ca3">
<div class="m_9211520834529266641m_-7785321975750488325aolReplacedBody">
<div dir="ltr">Remarks like Janne's lower the level of the whole list and do not belong here.
<div><br>
</div>
<div>Proj4 needs to move forward. Proj4 users, and users of software that depend on Proj4, need to get transformation results that are accurate and match other software. That requires better support of temporal datums which Kristian and Thomas are laying the ground work for. In the United States, Proj4 is still producing results that are 1 -2 meters off for coordinate systems based on datums newer than ~1996, so from my perspective, Proj4 is 20 years behind. I am very happy to see the recent efforts to make Proj4 more accurate and keep it relevant.</div>
<div><br>
</div>
<div>I don't understand why folks like Janne can't just hang on to what ever version of Proj4 they like and why they feel the need to discourage progress and make personal attacks.</div>
<div><br>
</div>
<div>Rich</div>
<div> </div>
</div>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_extra"><br>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote">On Wed, Aug 9, 2017 at 8:50 AM, Thomas Knudsen <span dir="ltr"><<a rel="noopener noreferrer" href="mailto:knudsen.thomas@gmail.com" target="_blank">knudsen.thomas@gmail.com</a>></span> wrote:<br>
<blockquote class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Duncan,</div>
<div><br>
</div>
<div>1: You may not see any personal comments in Janne’s latest rant, but however much I would prefer to be able to agree with you, I cannot. Janne’s closing remark is a direct, personal threat directed towards proj developers in general and, probably, myself and Kristian Evers in particular.</div>
<div><br>
</div>
<div>2: proj and cs2cs functionality does not change as a consequence of introducing an additional API in the underlying library.</div>
<div><br>
</div>
<div>3: You WILL definitely see accidental, but also deliberate, functionality changes in the future. A lot of effort has been put into making libproj more maintainable, through refactoring, general cleanup, and documentation. This is necessary to keep things maintainable. A large number of regression tests keep the accidental functionality changes minimal, but you can help by submitting additional tests.</div>
<div><br>
</div>
<div>4: You indicate that you “value proj as a simple and accurate way to go between lat/long and x/y, *without* needing to know the mathematics of (e.g.) how some projection is done”. While this statement definitely makes sense in cases where you can afford to ignore your reference frame, the “simple and accurate” statement reduces to “simple” in cases where you can not. The Earth is dynamic, and you need kinematic reference frames to obtain even decimetric accuracy over time spans of even just a few years. This is one of the reasons for our current work on another API for libproj.</div>
<span class="m_9211520834529266641m_-7785321975750488325aolmail_HOEnZb"><font color="#888888">
<div><br>
</div>
<div>/Thomas</div>
</font></span></div>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_HOEnZb">
<div class="m_9211520834529266641m_-7785321975750488325aolmail_h5">
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_extra"><br>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote">2017-08-09 15:23 GMT+02:00 Duncan Agnew <span dir="ltr"><<a rel="noopener noreferrer" href="mailto:dagnew@ucsd.edu" target="_blank">dagnew@ucsd.edu</a>></span>:<br>
<blockquote class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">All:<br>
<br>
I do not see any personal comments in Jenne's latest, the closing<br>
aside, though those planning the new activities no doubt feel otherwise. But<br>
let me say, as a long-time user, that whatever new features are added are fine<br>
by me, PROVIDED that the final product is fully backwards-compatible, even if<br>
that means retaining something that would now be done differently.<br>
<br>
I can give two examples in which this rule has not been followed,<br>
and as a result of which I have had to rewrite scripts that no longer<br>
worked. One, which seems to apply in general, is the need to specify<br>
an ellipsoid rather than being able to omit it and just have it<br>
default to WGS84. The other is that at some point someone rewrote the<br>
Oblique Mercator option in a way that required the command-line parameters <br>
to be different. (I asked about this, on this list, when I first encountered<br>
this problem, and got a response that indicated that it wasn't completely<br>
clear what had happened--and yes, I realize that this is an argument for<br>
the kind of systematic procedures for modification that are being proposed).<br>
I'm sure that whoever made these changes thought they were fixing something<br>
that should have been done differently from the beginning; but barring<br>
actual errors, I'd say, please don't.<br>
<br>
Going forward, I can accept the rationales (as the package has<br>
evolved into a datum-conversion tool) to include heights and time-dependent<br>
coordinates, though the latter will raise a whole new level of complications<br>
just to keep up as models for these evolve. But if this is going to mean<br>
that (say) heights need to be included for all conversions, then this should<br>
be something done using a different function, not proj or cs2cs. I (and<br>
probably many others) value proj as a simple and accurate way to go between<br>
lat/long and x/y, *without* needing to know the mathematics of (e.g.) how some<br>
projection is done on the ellipsoid--and likewise for going to (say) SPCS<br>
and back using cs2cs.<br>
<br>
So change all you want, but make sure that existing features,<br>
inelegant or not, remain.<br>
<br>
Thanks<span class="m_9211520834529266641m_-7785321975750488325aolmail_m_259201539394499091HOEnZb"><font color="#888888"><br>
Duncan Agnew<br>
<br>
</font></span></div>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_m_259201539394499091HOEnZb">
<div class="m_9211520834529266641m_-7785321975750488325aolmail_m_259201539394499091h5">
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_extra"><br>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote">On Wed, Aug 9, 2017 at 12:58 AM, Kristian Thy <span dir="ltr"><<a rel="noopener noreferrer" href="mailto:thy@42.dk" target="_blank">thy@42.dk</a>></span> wrote:<br>
<blockquote class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is it possible to vote someone off the list? It's getting tiresome to<br>
read Janne's inane diatribes, and I think this crosses the line from<br>
generally unhelpful into personal attacks.<br>
<br>
(Janne: if progress really bothers you that much, nobody's forcing you<br>
to use the new, improved proj library. Your website has auto-playing<br>
audio, so you seem to be pretty comfortable living in the 1990s.)<br>
<br>
Cheers,<br>
Kristian<br>
<br>
On Wed, Aug 09, <a rel="noopener noreferrer" href="mailto:support@mnspoint.com" target="_blank">support@mnspoint.com</a> wrote:<br>
> Hello,<br>
><br>
> The Proj.4 library is more a standard nowadays! You don't start to<br>
> rewrite it - it is already written! -- You just add new projections and<br>
> fix possible old bugs etc.<br>
><br>
> Take for example GNU gcc .. they have lot of material which is coming<br>
> from the 1970's - string libraries for example! They NEVER touch those!!<br>
> NEVER .. I repeat.<br>
><br>
> Or how about OpenGL libraries .. they also NEVER change anything old ..<br>
> they just keep adding new features (if anything). And that is called<br>
> stability of the library. A good library is very stable and does NOT<br>
> change 3 times a year .. unless something new is added. And since good<br>
> projections are not very often discovered anymore .. the Proj.4 stays as<br>
> it is. Nobody wants to see some random madness there when he is trusting<br>
> for example his life somewhere navigating using that projection on his<br>
> navigation display or maps.<br>
><br>
> Or maybe some picture file libraries .. like JPG standard or PNG<br>
> standard. All those libraries are VERY old and nobody moves a finger!<br>
> Since those all are now standard<br>
><br>
> Or let's see how zlib is nowadays .. it is exactly the same as it was 20<br>
> years ago. Nobody makes changes there since it works very well and<br>
> modern compilers can very well handle all that "old" or "new" stuff all<br>
> together.<br>
><br>
> So why all want to keep libraries stable? Because then they can trust<br>
> that it does its work as it used to do. Nobody wants to have new<br>
> versions unless that really adds something useful, like a new (useful)<br>
> projection.<br>
><br>
> (So go to hell .. and stay there!)<br>
><br>
> Janne.<br>
><br>
> ------------------------------<wbr>---------------------------<br>
><br>
> Kristian Evers kirjoitti 2017-07-10 12:09:<br>
><br>
> > All,<br>
> ><br>
> > I've set up a project on GitHub in an effort to organize the work that needs to be done before the next release. A GitHub project is nothing fancy, it's just a Kanban-board of already existing tickets from the issue tracker. Find it at:<br>
> ><br>
> > <a rel="noopener noreferrer" href="https://github.com/OSGeo/proj.4/projects/1" target="_blank">https://github.com/OSGeo/proj.<wbr>4/projects/1</a><br>
> ><br>
> > If you would like to contribute this is a good place to start. If there is something you would like to see fixed, added or changed in the next version now is the time to say so. Please use the GitHub issue tracker for that, either by adding new tickets or leaving a comment in existing ones you would like to get prioritized. I'll make sure to add them to the relevant list in the GitHub project.<br>
> ><br>
> > /Kristian<br>
> > ______________________________<wbr>_________________<br>
> > Proj mailing list<br>
> > <a rel="noopener noreferrer" href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
> > <a rel="noopener noreferrer" href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br>
><br>
> --<br>
> MNS Support<br>
> NNS Master Navigator Software<br>
> Copyright (c) Sapper Oy<br>
> <a rel="noopener noreferrer" href="http://www.mnspoint.com" target="_blank">www.mnspoint.com</a> [1]<br>
> <a rel="noopener noreferrer" href="mailto:support@mnspoint.com" target="_blank">support@mnspoint.com</a><br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a rel="noopener noreferrer" href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a rel="noopener noreferrer" href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br>
</blockquote></div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a rel="noopener noreferrer" href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a rel="noopener noreferrer" href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br>
</blockquote></div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a rel="noopener noreferrer" href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a rel="noopener noreferrer" href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br>
</blockquote></div>
<br>
<br clear="all"><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
-- <br>
<div class="m_9211520834529266641m_-7785321975750488325aolmail_gmail_signature">
<div dir="ltr">Richard W. Greenwood, PLS<br>
<a rel="noopener noreferrer" href="http://www.greenwoodmap.com" target="_blank">www.greenwoodmap.com</a></div>
</div>
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a></font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div></div></font><span class="HOEnZb"><font color="#888888"><br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br></font></span></blockquote></div><br></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>