[Proj] GitHub "project" for the next release

[Duncan Agnew]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170809/b000f5a7/attachment.html>