[Proj] GitHub "project" for the next release

Wed Aug 9 22:39:41 EST 2017

Contrary to expectations there is a new projection worth adding:
The Tobler-Mercator
http://dx.doi.org/10.1080/15230406.2017.1308837
Waldo

On Wed, Aug 9, 2017 at 7:16 PM, <strebe at aol.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> Best,
> — daan Strebe
>
>
>
> -----Original Message-----
> From: Richard Greenwood <richard.greenwood at gmail.com>
> To: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>
> Sent: Wed, Aug 9, 2017 5:36 pm
> Subject: Re: [Proj] GitHub "project" for the next release
>
> Remarks like Janne's lower the level of the whole list and do not belong
> here.
>
> 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.
>
> 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.
>
> Rich
>
>
> On Wed, Aug 9, 2017 at 8:50 AM, Thomas Knudsen <knudsen.thomas at gmail.com>
> wrote:
>
> Duncan,
>
> 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.
>
> 2: proj and cs2cs functionality does not change as a consequence of
> introducing an additional API in the underlying library.
>
> 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.
>
> 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.
>
> /Thomas
>
> 2017-08-09 15:23 GMT+02:00 Duncan Agnew <dagnew at ucsd.edu>:
>
> All:
>
>     I do not see any personal comments in Jenne's latest, the closing
> aside, though those planning the new activities no doubt feel otherwise.
> But
> let me say, as a long-time user, that whatever new features are added are
> fine
> by me, PROVIDED that the final product is fully backwards-compatible, even
> if
> that means retaining something that would now be done differently.
>
>     I can give two examples in which this rule has not been followed,
> and as a result of which I have had to rewrite scripts that no longer
> worked. One, which seems to apply in general, is the need to specify
> an ellipsoid rather than being able to omit it and just have it
> default to WGS84. The other is that at some point someone rewrote the
> Oblique Mercator option in a way that required the command-line parameters
> to be different. (I asked about this, on this list, when I first
> encountered
> this problem, and got a response that indicated that it wasn't completely
> clear what had happened--and yes, I realize that this is an argument for
> the kind of systematic procedures for modification that are being
> proposed).
> I'm sure that whoever made these changes thought they were fixing something
> that should have been done differently from the beginning; but barring
> actual errors, I'd say, please don't.
>
>     Going forward, I can accept the rationales (as the package has
> evolved into a datum-conversion tool) to include heights and time-dependent
> coordinates, though the latter will raise a whole new level of
> complications
> just to keep up as models for these evolve. But if this is going to mean
> that (say) heights need to be included for all conversions, then this
> should
> be something done using a different function, not proj or cs2cs. I (and
> probably many others) 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 on the ellipsoid--and likewise for going to (say) SPCS
> and back using cs2cs.
>
>     So change all you want, but make sure that existing features,
> inelegant or not, remain.
>
> Thanks
> Duncan Agnew
>
>
> On Wed, Aug 9, 2017 at 12:58 AM, Kristian Thy <thy at 42.dk> wrote:
>
> Is it possible to vote someone off the list? It's getting tiresome to
> read Janne's inane diatribes, and I think this crosses the line from
> generally unhelpful into personal attacks.
>
> (Janne: if progress really bothers you that much, nobody's forcing you
> to use the new, improved proj library. Your website has auto-playing
> audio, so you seem to be pretty comfortable living in the 1990s.)
>
> Cheers,
> Kristian
>
> On Wed, Aug 09, support at mnspoint.com wrote:
> > Hello,
> >
> > The Proj.4 library is more a standard nowadays! You don't start to
> > rewrite it - it is already written! -- You just add new projections and
> > fix possible old bugs etc.
> >
> > Take for example GNU gcc .. they have lot of material which is coming
> > from the 1970's - string libraries for example! They NEVER touch those!!
> > NEVER .. I repeat.
> >
> > Or how about OpenGL libraries .. they also NEVER change anything old ..
> > they just keep adding new features (if anything). And that is called
> > stability of the library. A good library is very stable and does NOT
> > change 3 times a year .. unless something new is added. And since good
> > projections are not very often discovered anymore .. the Proj.4 stays as
> > it is. Nobody wants to see some random madness there when he is trusting
> > for example his life somewhere navigating using that projection on his
> > navigation display or maps.
> >
> > Or maybe some picture file libraries .. like JPG standard or PNG
> > standard. All those libraries are VERY old and nobody moves a finger!
> > Since those all are now standard
> >
> > Or let's see how zlib is nowadays .. it is exactly the same as it was 20
> > years ago. Nobody makes changes there since it works very well and
> > modern compilers can very well handle all that "old" or "new" stuff all
> > together.
> >
> > So why all want to keep libraries stable? Because then they can trust
> > that it does its work as it used to do. Nobody wants to have new
> > versions unless that really adds something useful, like a new (useful)
> > projection.
> >
> > (So go to hell .. and stay there!)
> >
> > Janne.
> >
> > ---------------------------------------------------------
> >
> > Kristian Evers kirjoitti 2017-07-10 12:09:
> >
> > > All,
> > >
> > > 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:
> > >
> > > https://github.com/OSGeo/proj.4/projects/1
> > >
> > > 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.
> > >
> > > /Kristian
> > > _______________________________________________
> > > Proj mailing list
> > > Proj at lists.maptools.org
> > > http://lists.maptools.org/mailman/listinfo/proj
> >
> > --
> > MNS Support
> > NNS Master Navigator Software
> > Copyright (c) Sapper Oy
> > www.mnspoint.com [1]
> > support at mnspoint.com
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
>
>
> --
> Richard W. Greenwood, PLS
> www.greenwoodmap.com
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170809/73c37c32/attachment.htm 