[Proj] Coming releases of PROJ.4

[Kristian Evers]

Roger,

> Is still used in the essential function by Barry Rowlingson:
> 
> #include <projects.h>
> 
> int inversetest(PJ *P){
>   return (P->inv ? 1: 0);
> 
> }

We could add an pj_has_inverse() function to proj_api.h. Would that work for you? Alternatively a similar check can be made with  the proj.h API, but that of course requires rewriting more code.



Sebastian,

> Using codesearch.debian.net shows that many of the PROJ.4 reverse
> dependencies include projects.h, so getting rid of that requires
> patching those projects.


I did the following search: https://codesearch.debian.net/search?q=%23include+%3Cprojects.h%3E&perpkg=1 

It returns 7 relevant projects. Basemap, Mapserver, Python-pyproj, Thuban, Therion, Paraview and SAGA. 

Basemap, Therion and Paraview seem to include a complete copy of the PROJ.4 code base. Presumably they won't be bothered by a change. That leaves 4 projects, of which we have good access to most and will be able to help absorb the changes. I don't think it is completely outrageous to introduce a breaking change if it doesn't affect more projects than that. Of course it is likely that my search is not catching everything. Have I missed something?

 Mike,

> Silly question: will the software have ".4" baked into the name (i.e. PROJ.4 version 10.x),

My suggestion is to keep the projects name as PROJ.4 (all caps), and eventually change the versioning to 10.y.z,
so that you use version 10.y.z of PROJ.4. It's a weird bump in version number from 4 to 10, but hey, if Microsoft 
can do that kind of thing, so can we :-) The idea behind the big jump would be to have full use of major, minor 
and patch numbers, as well as signal to the world that a larger change has happened. Makes sense? 



Howard,

> Successfully burying projects.h would be enough to declare victory, if we can do so without upsetting too much. Even's analysis shows that might be possible.

Agreed. I totally acknowledge that my viewpoint is too progressive, and others might lean a bit to the conservative side.
Settling on getting rid of projects.h is a good compromise I think.

> #1: "It's ugly, but it works, it will stay working, and it requires no more software development"
> #2: "It works more smoothly, but you have to write/update software to use it, and it does the same thing as #1"
> 
> There must be new features that incentivize the work required to do #2. For the sake of itself is not enough. Maybe access to transformation pipelines are enough for that, I don't know. It's a  frustrating reality of a very old and well-established software project with lots of implementations. The success of Proj.4 has indeed locked itself in place.

Personally I believe transformation pipelines is enough of a game-changer but I am not sure that it is apparent to most users at the moment.
But there are plenty of room for other game-changing features as well, which eventually makes it a no brainer to use the new API. 



/Kristian