GitHub "project" for the next release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

GitHub "project" for the next release

Kristian Evers-2

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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

support-2

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
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Kristian Thy
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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Thomas Knudsen
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 <[hidden email]>:
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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

rgreenwood
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

strebe
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 <[hidden email]>
To: PROJ.4 and general Projections Discussions <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Waldo Tobler
Contrary to expectations there is a new projection worth adding:
The Tobler-Mercator
Waldo

On Wed, Aug 9, 2017 at 7:16 PM, <[hidden email]> 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 <[hidden email]>
To: PROJ.4 and general Projections Discussions <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Duncan Agnew
All:

I pretty much agree with Dan. For clarity (lacking in my previous entry),
there are two things, easily conflated, to talk about:

    A. proj the program that people use (often on the command line)
to go between lat-long and projection coordinates. Most of these users
don't care about which lat/long they are using: certainly not important
if making a map, and probably not if using it to set up a grid system
for your own use (I've used it for both).

    B. PROJ the package, which includes not just projections
but all the additional machinery to handle different datums--and
in the future heights and temporal changes.

    I completely agree that PROJ needs to keep evolving; but at the
same time I (and probably many other users) would like to have proj
stay the same. This ought to be relatively easy since it is almost all
mathematics, the only parameters being the size and shape of the
ellipsoid--and I don't imagine there will be new values of this being
produced. But it depends on allowing the functionality of proj (not
PROJ) to not require the user who just wants a projection to have to
master the additional features needed to do datum transformations.

    Of course grids are just projections, so it was easy for Gerald
to add things like SPCS, blurring the line a bit; but, with Daan (and
Gerald) I'd argue that it would be helpful to many users to have things
somewhat distinct.

    And, I'd like to raise a question (I'm genuinely curious) about how
time-dependent motion will be added. Having been professionally engaged in
measuring and modeling crustal motion for the last 30+ years, I can say that it
is going to be a lot more complicated to keep track of. proj (as above) needs
only the -le parameters (a fixed set); once you add the rigid-body motions for
datum transformations there are a lot more parameters, many conventional (and
so unchanging), which EPSG fortunately collects; adding grids for distortion
(HARN) needs more information yet. But once you get into temporal changes,
things are even worse: models will keep changing either because of better data
or earthquakes (cf HTDP). This seems like a progression from a package
dominated by algebra to a small algebraic component attached to a large
and ever-growing database of parameters. I'm not arguing against it, at
all, just saying that it is going to be quite a challenge beyond modifying
the programs. (I completely lack the expertise to contribute to the code,
but if anyone has any geophysics questions I'm happy to try to answer them).

Thanks
Duncan Agnew

On Wed, Aug 9, 2017 at 8:39 PM, Waldo Tobler <[hidden email]> wrote:
Contrary to expectations there is a new projection worth adding:
The Tobler-Mercator
Waldo

On Wed, Aug 9, 2017 at 7:16 PM, <[hidden email]> 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 <[hidden email]>
To: PROJ.4 and general Projections Discussions <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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, [hidden email] 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
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
>
> --
> MNS Support
> NNS Master Navigator Software
> Copyright (c) Sapper Oy
> www.mnspoint.com [1]
> [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Thomas Knudsen
Duncan (and daan),

Yes, map projections are mathematical functions, while reference frame shifts are geophysical/geodetical transformations.

The latter are, however, also *in practice* represented by sequential application of parameterized mathematical functions, drawn from a rather limited gamut - basically consisting of Helmert, Horner, Molodensky, Grid interpolation and ellipsoidal/cartesian transformation.

All of these fundamental operations are architecturally similar to the map projection functions of the original libproj, and are implemented in a similar way.

Hence, what Kristian Evers and I have done over the last 18 months is technically to add 5 (or so) new projections to the original libproj.

To string the stuff together, we designed the pipeline metaphor, which is also materialized as just another projection.

So we have added what amounts to a few more projections to the library. These can be used or ignored, in the same way you may ignore the Transverse Mercator implementation if you are only interested in the Lambert Conformal Conic (You can probably even compile a version of the library leaving most of the “pseudoprojections” out).

All parameters for implementing actual reference frame transformations *are stored in parameter files, not in the library per se*.

If you are *not interested* in reference frame shifts, the code supporting reference frame shifts will *not affect you*. And the parameter files will only affect you through the (limited) disk space required. But you are not forced to install them anyway.

So if you are *not interested* in reference frame shifts, please *ignore the matter* and stop arguing against stuff that will *not affect you*. This stuff is certainly useful for a range of other people.

Should we want to follow daan’s recipe of splitting the reference frame handling entirely from the projection library, we would have to duplicate most of the well tested libproj infrastructural architecture into another library, which would, in most cases, be used in applications also depending on libproj.

Simply leveraging the existing infrastructure and adding a handful of pseudoprojections was definitely the way to go. Especially since the libproj architecture makes it possible to do so in a neat and non-intrusive way.

Regarding the new API:

The new API emerged as a by-product of attempts to make the libproj internals more maintainable, by improving namespacing and introducing new internal data types in order to reduce type-punning. This makes it more clear exactly what kind of coordinate is expected at each spot in the code.

The new API exposes these data types, simplifies a wide field of operations, and provides a unified interface to 2D, 3D and 4D transformations.

The new API does not replace the old API, but obviously the designers hope that it will become the preferred one for new applications. The old API may some day gain a “deprecated” status, but will only rot entirely away if no one is interested in maintaining it. So if anyone needs it badly enough to sponsor its maintenance, it will live on forever.

In a limited number of cases, software pre-dating the original API, described in proj-api.h, may experience breakage, since the original projects.h file does not describe an actual interface (API), but rather exposes every single function and data structure in the library.

So there is only one way to ensure that each-and-every program, using projects.h to do calls to libproj internals, would keep working with new versions of libproj: That would be to freeze both development and maintenance of the PROJ system. And anyone wishing for that may get theirs by just sticking with proj 4.3.0.

I personally believe, though, that we should make efforts not to hamper more well disciplined programs using projects.h just to do calls to the “obvious API” of projects.h (pj_init, pj_fwd, pj_inv, pj_free, and probably a few more).

The proj and cs2cs filters will live on as long as anyone wants to maintain them. But they definitely need some tlc, so test cases involving some of your more esoteric use cases of proj and cs2cs would be very welcome, and would greatly reduce the risk of regressions during maintenance.

/thomas

2017-08-10 6:56 GMT+02:00 Duncan Agnew <[hidden email]>:
All:

I pretty much agree with Dan. For clarity (lacking in my previous entry),
there are two things, easily conflated, to talk about:

    A. proj the program that people use (often on the command line)
to go between lat-long and projection coordinates. Most of these users
don't care about which lat/long they are using: certainly not important
if making a map, and probably not if using it to set up a grid system
for your own use (I've used it for both).

    B. PROJ the package, which includes not just projections
but all the additional machinery to handle different datums--and
in the future heights and temporal changes.

    I completely agree that PROJ needs to keep evolving; but at the
same time I (and probably many other users) would like to have proj
stay the same. This ought to be relatively easy since it is almost all
mathematics, the only parameters being the size and shape of the
ellipsoid--and I don't imagine there will be new values of this being
produced. But it depends on allowing the functionality of proj (not
PROJ) to not require the user who just wants a projection to have to
master the additional features needed to do datum transformations.

    Of course grids are just projections, so it was easy for Gerald
to add things like SPCS, blurring the line a bit; but, with Daan (and
Gerald) I'd argue that it would be helpful to many users to have things
somewhat distinct.

    And, I'd like to raise a question (I'm genuinely curious) about how
time-dependent motion will be added. Having been professionally engaged in
measuring and modeling crustal motion for the last 30+ years, I can say that it
is going to be a lot more complicated to keep track of. proj (as above) needs
only the -le parameters (a fixed set); once you add the rigid-body motions for
datum transformations there are a lot more parameters, many conventional (and
so unchanging), which EPSG fortunately collects; adding grids for distortion
(HARN) needs more information yet. But once you get into temporal changes,
things are even worse: models will keep changing either because of better data
or earthquakes (cf HTDP). This seems like a progression from a package
dominated by algebra to a small algebraic component attached to a large
and ever-growing database of parameters. I'm not arguing against it, at
all, just saying that it is going to be quite a challenge beyond modifying
the programs. (I completely lack the expertise to contribute to the code,
but if anyone has any geophysics questions I'm happy to try to answer them).

Thanks
Duncan Agnew


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

rgreenwood
Computationally datum transformations are completely separable from map projections, but from the end users perspective they are inextricably combined in the modern era. A user should reasonably expect to get the same results in QGIS and ArcMap given the same ESPG codes, but in many cases they do not because of datum differences. I know Gerald disagreed with me on this in the past and obviously others still disagree with me. I do not believe that moving Proj into the 21st century threatens users who do not care about datum transformations. But ignoring datum transformations will make Proj irrelevant in the future.

Rich


On Thu, Aug 10, 2017 at 5:44 AM, Thomas Knudsen <[hidden email]> wrote:
Duncan (and daan),

Yes, map projections are mathematical functions, while reference frame shifts are geophysical/geodetical transformations.

The latter are, however, also *in practice* represented by sequential application of parameterized mathematical functions, drawn from a rather limited gamut - basically consisting of Helmert, Horner, Molodensky, Grid interpolation and ellipsoidal/cartesian transformation.

All of these fundamental operations are architecturally similar to the map projection functions of the original libproj, and are implemented in a similar way.

Hence, what Kristian Evers and I have done over the last 18 months is technically to add 5 (or so) new projections to the original libproj.

To string the stuff together, we designed the pipeline metaphor, which is also materialized as just another projection.

So we have added what amounts to a few more projections to the library. These can be used or ignored, in the same way you may ignore the Transverse Mercator implementation if you are only interested in the Lambert Conformal Conic (You can probably even compile a version of the library leaving most of the “pseudoprojections” out).

All parameters for implementing actual reference frame transformations *are stored in parameter files, not in the library per se*.

If you are *not interested* in reference frame shifts, the code supporting reference frame shifts will *not affect you*. And the parameter files will only affect you through the (limited) disk space required. But you are not forced to install them anyway.

So if you are *not interested* in reference frame shifts, please *ignore the matter* and stop arguing against stuff that will *not affect you*. This stuff is certainly useful for a range of other people.

Should we want to follow daan’s recipe of splitting the reference frame handling entirely from the projection library, we would have to duplicate most of the well tested libproj infrastructural architecture into another library, which would, in most cases, be used in applications also depending on libproj.

Simply leveraging the existing infrastructure and adding a handful of pseudoprojections was definitely the way to go. Especially since the libproj architecture makes it possible to do so in a neat and non-intrusive way.

Regarding the new API:

The new API emerged as a by-product of attempts to make the libproj internals more maintainable, by improving namespacing and introducing new internal data types in order to reduce type-punning. This makes it more clear exactly what kind of coordinate is expected at each spot in the code.

The new API exposes these data types, simplifies a wide field of operations, and provides a unified interface to 2D, 3D and 4D transformations.

The new API does not replace the old API, but obviously the designers hope that it will become the preferred one for new applications. The old API may some day gain a “deprecated” status, but will only rot entirely away if no one is interested in maintaining it. So if anyone needs it badly enough to sponsor its maintenance, it will live on forever.

In a limited number of cases, software pre-dating the original API, described in proj-api.h, may experience breakage, since the original projects.h file does not describe an actual interface (API), but rather exposes every single function and data structure in the library.

So there is only one way to ensure that each-and-every program, using projects.h to do calls to libproj internals, would keep working with new versions of libproj: That would be to freeze both development and maintenance of the PROJ system. And anyone wishing for that may get theirs by just sticking with proj 4.3.0.

I personally believe, though, that we should make efforts not to hamper more well disciplined programs using projects.h just to do calls to the “obvious API” of projects.h (pj_init, pj_fwd, pj_inv, pj_free, and probably a few more).

The proj and cs2cs filters will live on as long as anyone wants to maintain them. But they definitely need some tlc, so test cases involving some of your more esoteric use cases of proj and cs2cs would be very welcome, and would greatly reduce the risk of regressions during maintenance.

/thomas

2017-08-10 6:56 GMT+02:00 Duncan Agnew <[hidden email]>:
All:

I pretty much agree with Dan. For clarity (lacking in my previous entry),
there are two things, easily conflated, to talk about:

    A. proj the program that people use (often on the command line)
to go between lat-long and projection coordinates. Most of these users
don't care about which lat/long they are using: certainly not important
if making a map, and probably not if using it to set up a grid system
for your own use (I've used it for both).

    B. PROJ the package, which includes not just projections
but all the additional machinery to handle different datums--and
in the future heights and temporal changes.

    I completely agree that PROJ needs to keep evolving; but at the
same time I (and probably many other users) would like to have proj
stay the same. This ought to be relatively easy since it is almost all
mathematics, the only parameters being the size and shape of the
ellipsoid--and I don't imagine there will be new values of this being
produced. But it depends on allowing the functionality of proj (not
PROJ) to not require the user who just wants a projection to have to
master the additional features needed to do datum transformations.

    Of course grids are just projections, so it was easy for Gerald
to add things like SPCS, blurring the line a bit; but, with Daan (and
Gerald) I'd argue that it would be helpful to many users to have things
somewhat distinct.

    And, I'd like to raise a question (I'm genuinely curious) about how
time-dependent motion will be added. Having been professionally engaged in
measuring and modeling crustal motion for the last 30+ years, I can say that it
is going to be a lot more complicated to keep track of. proj (as above) needs
only the -le parameters (a fixed set); once you add the rigid-body motions for
datum transformations there are a lot more parameters, many conventional (and
so unchanging), which EPSG fortunately collects; adding grids for distortion
(HARN) needs more information yet. But once you get into temporal changes,
things are even worse: models will keep changing either because of better data
or earthquakes (cf HTDP). This seems like a progression from a package
dominated by algebra to a small algebraic component attached to a large
and ever-growing database of parameters. I'm not arguing against it, at
all, just saying that it is going to be quite a challenge beyond modifying
the programs. (I completely lack the expertise to contribute to the code,
but if anyone has any geophysics questions I'm happy to try to answer them).

Thanks
Duncan Agnew


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

Stefanos Beligiannis
In reply to this post by Thomas Knudsen
Dear gentlemen,

I read with great interest your discussions. Most of your proposals are very constructive while other even are innovative, they lack of strategy and  this is the point I want to focus on, as a survey and geodetic engineer with more than 40 years experience. 
First let's make a distinguish between some different issues :
- Geoid is our target object (the earth MSL) with an arbitrary shape which unfortunatelly is not either static or completely defined.
- Geodetic Transformations like 7 params Helmert or 9 params Molodensky Badekas, that are applied on different ellipsoids to translate and rotate the ellipsoid in use in order to best fit on a certain area the Geoid.
- Spheroid is a mathematic sphere fiting the ellipsoid on an area with center a certain point.
- Projection is the spreads of the spheroid surface we mathematically do with origin  a certain line or a point
- Transformations like similarity, affine, 2D Helmert etc are planar and are applied only on projections ie planar datums or image rectifications. 
- The procedure to make a transformation is:
Projection A -> Datum A -> Datum B (applying geodetic transformation with certain params) -> Projection B
This procedure is not error free. Usually bulk errors even 10 m are experienced and here the problem starts!
1. To my opinion NGA standards must be respected and never allow for the shake of our program's completeness not professionals to change these parameters or evaluate their owns and establish them for the shake of better local accuracy achievent.
I experienced such a case in Riyadh where there are two AinAlAbd systems because a GIS "expert" decided to change for Riyadh the Helmert 7 parameter values NGA gives with an accuracy of 10m for whole Saudi Arabia with other calculated with LSM inverse Helmert to achieve 2 m accuracy. Result? Chaos!! So are you going to make a product devoted to these standards or something open?
2. I hear about calculations accuracy improvement. What do you really mean and what would be the interest of this? I see you use 10bytes double precision instead ieee 8. Do you plan to go further with special math libraries that use "unlimited" significant decimal digits against the calculation speed etc.
3. Do you plan to re-design the UI?
4. Do you plan to make any tools that will permit inexperienced users to deal with the core?
I really look forward to learn more about these isues

Best Regards

Stefanos Beligiannis
Rural & Survey Engineer MSc



On Thursday, August 10, 2017, 3:01:11 PM GMT+3, Thomas Knudsen <[hidden email]> wrote:


Duncan (and daan),

Yes, map projections are mathematical functions, while reference frame shifts are geophysical/geodetical transformations.

The latter are, however, also *in practice* represented by sequential application of parameterized mathematical functions, drawn from a rather limited gamut - basically consisting of Helmert, Horner, Molodensky, Grid interpolation and ellipsoidal/cartesian transformation.

All of these fundamental operations are architecturally similar to the map projection functions of the original libproj, and are implemented in a similar way.

Hence, what Kristian Evers and I have done over the last 18 months is technically to add 5 (or so) new projections to the original libproj.

To string the stuff together, we designed the pipeline metaphor, which is also materialized as just another projection.

So we have added what amounts to a few more projections to the library. These can be used or ignored, in the same way you may ignore the Transverse Mercator implementation if you are only interested in the Lambert Conformal Conic (You can probably even compile a version of the library leaving most of the “pseudoprojections” out).

All parameters for implementing actual reference frame transformations *are stored in parameter files, not in the library per se*.

If you are *not interested* in reference frame shifts, the code supporting reference frame shifts will *not affect you*. And the parameter files will only affect you through the (limited) disk space required. But you are not forced to install them anyway.

So if you are *not interested* in reference frame shifts, please *ignore the matter* and stop arguing against stuff that will *not affect you*. This stuff is certainly useful for a range of other people.

Should we want to follow daan’s recipe of splitting the reference frame handling entirely from the projection library, we would have to duplicate most of the well tested libproj infrastructural architecture into another library, which would, in most cases, be used in applications also depending on libproj.

Simply leveraging the existing infrastructure and adding a handful of pseudoprojections was definitely the way to go. Especially since the libproj architecture makes it possible to do so in a neat and non-intrusive way.

Regarding the new API:

The new API emerged as a by-product of attempts to make the libproj internals more maintainable, by improving namespacing and introducing new internal data types in order to reduce type-punning. This makes it more clear exactly what kind of coordinate is expected at each spot in the code.

The new API exposes these data types, simplifies a wide field of operations, and provides a unified interface to 2D, 3D and 4D transformations.

The new API does not replace the old API, but obviously the designers hope that it will become the preferred one for new applications. The old API may some day gain a “deprecated” status, but will only rot entirely away if no one is interested in maintaining it. So if anyone needs it badly enough to sponsor its maintenance, it will live on forever.

In a limited number of cases, software pre-dating the original API, described in proj-api.h, may experience breakage, since the original projects.h file does not describe an actual interface (API), but rather exposes every single function and data structure in the library.

So there is only one way to ensure that each-and-every program, using projects.h to do calls to libproj internals, would keep working with new versions of libproj: That would be to freeze both development and maintenance of the PROJ system. And anyone wishing for that may get theirs by just sticking with proj 4.3.0.

I personally believe, though, that we should make efforts not to hamper more well disciplined programs using projects.h just to do calls to the “obvious API” of projects.h (pj_init, pj_fwd, pj_inv, pj_free, and probably a few more).

The proj and cs2cs filters will live on as long as anyone wants to maintain them. But they definitely need some tlc, so test cases involving some of your more esoteric use cases of proj and cs2cs would be very welcome, and would greatly reduce the risk of regressions during maintenance.

/thomas

2017-08-10 6:56 GMT+02:00 Duncan Agnew <[hidden email]>:
All:

I pretty much agree with Dan. For clarity (lacking in my previous entry),
there are two things, easily conflated, to talk about:

    A. proj the program that people use (often on the command line)
to go between lat-long and projection coordinates. Most of these users
don't care about which lat/long they are using: certainly not important
if making a map, and probably not if using it to set up a grid system
for your own use (I've used it for both).

    B. PROJ the package, which includes not just projections
but all the additional machinery to handle different datums--and
in the future heights and temporal changes.

    I completely agree that PROJ needs to keep evolving; but at the
same time I (and probably many other users) would like to have proj
stay the same. This ought to be relatively easy since it is almost all
mathematics, the only parameters being the size and shape of the
ellipsoid--and I don't imagine there will be new values of this being
produced. But it depends on allowing the functionality of proj (not
PROJ) to not require the user who just wants a projection to have to
master the additional features needed to do datum transformations.

    Of course grids are just projections, so it was easy for Gerald
to add things like SPCS, blurring the line a bit; but, with Daan (and
Gerald) I'd argue that it would be helpful to many users to have things
somewhat distinct.

    And, I'd like to raise a question (I'm genuinely curious) about how
time-dependent motion will be added. Having been professionally engaged in
measuring and modeling crustal motion for the last 30+ years, I can say that it
is going to be a lot more complicated to keep track of. proj (as above) needs
only the -le parameters (a fixed set); once you add the rigid-body motions for
datum transformations there are a lot more parameters, many conventional (and
so unchanging), which EPSG fortunately collects; adding grids for distortion
(HARN) needs more information yet. But once you get into temporal changes,
things are even worse: models will keep changing either because of better data
or earthquakes (cf HTDP). This seems like a progression from a package
dominated by algebra to a small algebraic component attached to a large
and ever-growing database of parameters. I'm not arguing against it, at
all, just saying that it is going to be quite a challenge beyond modifying
the programs. (I completely lack the expertise to contribute to the code,
but if anyone has any geophysics questions I'm happy to try to answer them).

Thanks
Duncan Agnew


______________________________ _________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mail man/listinfo/proj


______________________________ _________________
Proj mailing list
[hidden email]
http://lists.maptools.org/ mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: GitHub "project" for the next release

mike thomas
Hi all.

It sounds to me as a long term watcher and user of the library, that it's time for proj5, from both technological and system architecture perspectives.

Cheers,

Mike Thomas

On 11 Aug 2017 5:18 am, "Stefanos Beligiannis" <[hidden email]> wrote:
Dear gentlemen,

I read with great interest your discussions. Most of your proposals are very constructive while other even are innovative, they lack of strategy and  this is the point I want to focus on, as a survey and geodetic engineer with more than 40 years experience. 
First let's make a distinguish between some different issues :
- Geoid is our target object (the earth MSL) with an arbitrary shape which unfortunatelly is not either static or completely defined.
- Geodetic Transformations like 7 params Helmert or 9 params Molodensky Badekas, that are applied on different ellipsoids to translate and rotate the ellipsoid in use in order to best fit on a certain area the Geoid.
- Spheroid is a mathematic sphere fiting the ellipsoid on an area with center a certain point.
- Projection is the spreads of the spheroid surface we mathematically do with origin  a certain line or a point
- Transformations like similarity, affine, 2D Helmert etc are planar and are applied only on projections ie planar datums or image rectifications. 
- The procedure to make a transformation is:
Projection A -> Datum A -> Datum B (applying geodetic transformation with certain params) -> Projection B
This procedure is not error free. Usually bulk errors even 10 m are experienced and here the problem starts!
1. To my opinion NGA standards must be respected and never allow for the shake of our program's completeness not professionals to change these parameters or evaluate their owns and establish them for the shake of better local accuracy achievent.
I experienced such a case in Riyadh where there are two AinAlAbd systems because a GIS "expert" decided to change for Riyadh the Helmert 7 parameter values NGA gives with an accuracy of 10m for whole Saudi Arabia with other calculated with LSM inverse Helmert to achieve 2 m accuracy. Result? Chaos!! So are you going to make a product devoted to these standards or something open?
2. I hear about calculations accuracy improvement. What do you really mean and what would be the interest of this? I see you use 10bytes double precision instead ieee 8. Do you plan to go further with special math libraries that use "unlimited" significant decimal digits against the calculation speed etc.
3. Do you plan to re-design the UI?
4. Do you plan to make any tools that will permit inexperienced users to deal with the core?
I really look forward to learn more about these isues

Best Regards

Stefanos Beligiannis
Rural & Survey Engineer MSc



On Thursday, August 10, 2017, 3:01:11 PM GMT+3, Thomas Knudsen <[hidden email]> wrote:


Duncan (and daan),

Yes, map projections are mathematical functions, while reference frame shifts are geophysical/geodetical transformations.

The latter are, however, also *in practice* represented by sequential application of parameterized mathematical functions, drawn from a rather limited gamut - basically consisting of Helmert, Horner, Molodensky, Grid interpolation and ellipsoidal/cartesian transformation.

All of these fundamental operations are architecturally similar to the map projection functions of the original libproj, and are implemented in a similar way.

Hence, what Kristian Evers and I have done over the last 18 months is technically to add 5 (or so) new projections to the original libproj.

To string the stuff together, we designed the pipeline metaphor, which is also materialized as just another projection.

So we have added what amounts to a few more projections to the library. These can be used or ignored, in the same way you may ignore the Transverse Mercator implementation if you are only interested in the Lambert Conformal Conic (You can probably even compile a version of the library leaving most of the “pseudoprojections” out).

All parameters for implementing actual reference frame transformations *are stored in parameter files, not in the library per se*.

If you are *not interested* in reference frame shifts, the code supporting reference frame shifts will *not affect you*. And the parameter files will only affect you through the (limited) disk space required. But you are not forced to install them anyway.

So if you are *not interested* in reference frame shifts, please *ignore the matter* and stop arguing against stuff that will *not affect you*. This stuff is certainly useful for a range of other people.

Should we want to follow daan’s recipe of splitting the reference frame handling entirely from the projection library, we would have to duplicate most of the well tested libproj infrastructural architecture into another library, which would, in most cases, be used in applications also depending on libproj.

Simply leveraging the existing infrastructure and adding a handful of pseudoprojections was definitely the way to go. Especially since the libproj architecture makes it possible to do so in a neat and non-intrusive way.

Regarding the new API:

The new API emerged as a by-product of attempts to make the libproj internals more maintainable, by improving namespacing and introducing new internal data types in order to reduce type-punning. This makes it more clear exactly what kind of coordinate is expected at each spot in the code.

The new API exposes these data types, simplifies a wide field of operations, and provides a unified interface to 2D, 3D and 4D transformations.

The new API does not replace the old API, but obviously the designers hope that it will become the preferred one for new applications. The old API may some day gain a “deprecated” status, but will only rot entirely away if no one is interested in maintaining it. So if anyone needs it badly enough to sponsor its maintenance, it will live on forever.

In a limited number of cases, software pre-dating the original API, described in proj-api.h, may experience breakage, since the original projects.h file does not describe an actual interface (API), but rather exposes every single function and data structure in the library.

So there is only one way to ensure that each-and-every program, using projects.h to do calls to libproj internals, would keep working with new versions of libproj: That would be to freeze both development and maintenance of the PROJ system. And anyone wishing for that may get theirs by just sticking with proj 4.3.0.

I personally believe, though, that we should make efforts not to hamper more well disciplined programs using projects.h just to do calls to the “obvious API” of projects.h (pj_init, pj_fwd, pj_inv, pj_free, and probably a few more).

The proj and cs2cs filters will live on as long as anyone wants to maintain them. But they definitely need some tlc, so test cases involving some of your more esoteric use cases of proj and cs2cs would be very welcome, and would greatly reduce the risk of regressions during maintenance.

/thomas

2017-08-10 6:56 GMT+02:00 Duncan Agnew <[hidden email]>:
All:

I pretty much agree with Dan. For clarity (lacking in my previous entry),
there are two things, easily conflated, to talk about:

    A. proj the program that people use (often on the command line)
to go between lat-long and projection coordinates. Most of these users
don't care about which lat/long they are using: certainly not important
if making a map, and probably not if using it to set up a grid system
for your own use (I've used it for both).

    B. PROJ the package, which includes not just projections
but all the additional machinery to handle different datums--and
in the future heights and temporal changes.

    I completely agree that PROJ needs to keep evolving; but at the
same time I (and probably many other users) would like to have proj
stay the same. This ought to be relatively easy since it is almost all
mathematics, the only parameters being the size and shape of the
ellipsoid--and I don't imagine there will be new values of this being
produced. But it depends on allowing the functionality of proj (not
PROJ) to not require the user who just wants a projection to have to
master the additional features needed to do datum transformations.

    Of course grids are just projections, so it was easy for Gerald
to add things like SPCS, blurring the line a bit; but, with Daan (and
Gerald) I'd argue that it would be helpful to many users to have things
somewhat distinct.

    And, I'd like to raise a question (I'm genuinely curious) about how
time-dependent motion will be added. Having been professionally engaged in
measuring and modeling crustal motion for the last 30+ years, I can say that it
is going to be a lot more complicated to keep track of. proj (as above) needs
only the -le parameters (a fixed set); once you add the rigid-body motions for
datum transformations there are a lot more parameters, many conventional (and
so unchanging), which EPSG fortunately collects; adding grids for distortion
(HARN) needs more information yet. But once you get into temporal changes,
things are even worse: models will keep changing either because of better data
or earthquakes (cf HTDP). This seems like a progression from a package
dominated by algebra to a small algebraic component attached to a large
and ever-growing database of parameters. I'm not arguing against it, at
all, just saying that it is going to be quite a challenge beyond modifying
the programs. (I completely lack the expertise to contribute to the code,
but if anyone has any geophysics questions I'm happy to try to answer them).

Thanks
Duncan Agnew


______________________________ _________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mail man/listinfo/proj


______________________________ _________________
Proj mailing list
[hidden email]
http://lists.maptools.org/ mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj