[Proj] Time for a new release?

[Thomas Knudsen]

Even, regarding simplification by elimination:

Obviously Kristian will want to answer this himself, but I would like to
mention at least one thing (or perhaps rather aspect) that will buy us
simplification by eliminating projects.h and proj_api.h:

We would get rid of the type-punning-by-preprocessor-defs that destroyed
Gerald's classic PROJ.4 core API, (pj_init, pj_fwd, pj_inv, and pj_free),
by turning XY and LP into UV behind the back of the user, such that XY xy
is no longer adressed xy.x and xy.y, but xy.u and xy.v

We would also get rid of the half baked
namespacing-and-information-hiding-by-misleading-typedef, implemented by
e.g.
typedef void *projPJ, and typedef void *projCtx, rather than by forward
declarations.

This kind of stuff has been hell to work around (see the text in the top of
proj.h for rationale for the work). This is not said to belittle Frank's
work, which has been of immense value for PROJ.4, and has kept it afloat
and in constant evolution, for more than 15 years: His work is admirable,
but has, naturally, been focused on whatever (or whom-ever) paid the bills.

This has given us support for vertical datums, support for NTv2, support
for a "failrly accurate for the needs when it was introduced 15 years ago"
interface function as pj_transform, which to a large degree succeeds in
"giving the user what (s)he wants without asking too many annoying geodetic
questions".

It has, however, also given us the, largely superfluous contexts, and the
fileapi, which, apart form missing a fgetc- style function, also in general
suffer from a feeling of "work made for hire" for a specific customer,
using it for in house stuff (only since it is largely unknown by search
engines) - but now we have to maintain this stuff,without even knowing what
the rationale behind was.

So yes - we could certainly benefit from skipping projects.h and proj_api.h
: It will buy us some simplifications -  I'm just not sure that this is the
right way to do things. More about this later.



2017-11-11 20:06 GMT+01:00 Even Rouault <even.rouault at spatialys.com>:

> On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:
>
> > PROJ v. 5.0.0 is also good with me. It also brings us into "braking
> changes
>
> > territory". With this in mind I think we should consider only supporting
>
> > the new API in proj.h and dropping the other APIs. This will allow us to
>
> > simplify the code immensely.
>
>
>
> Can you sketch a bit what would be simplified in doing so ?
>
>
>
> > At the moment we jump through a bunch of hoops
>
> > to keep backwards compatibility. We'd probably still do that for the next
>
> > release, but not having projects.h and proj_api.h as part of the public
> API
>
> > we can change things behind the scenes in future releases.
>
>
>
> If I remember the analysis of Debian packages, while dropping projects.h
> would have a moderate impact, dropping proj_api.h would cause massive
> breakage. This would likely cause proj 5 to take months to years before
> being available in distributions due to many packages not being ready for
> it (and the proj_api.h -> proj.h port is the kind of change that needs to
> be done by upstream projects. not a quick&dirty hack that the packager can
> do)
>
> Thus in this context of software distributions, applications that would be
> adapted to use the new API wouldn't be able to use it in practice for a
> long time. Worse, applications that would do the changes to support proj >=
> 5 would still to have to support both proj < 5 and proj >= 5 in a
> transition period if they want their new releases to be packaged. To make
> their life easier by avoiding to have them to support both API, a proj 5
> should be available as packaged as fast as possible.
>
>
>
> I'm wondering if there wouldn't be a way of having a proj_api.c
> compatibiliy layer that would use the new API behind the scene ? The projPJ
> struct could be something different than the PJ one, for example just
> storing the text. And when doing pj_transform() you would build a pipeline
> from the src and dest projPJ. Things like that. I believe the cost of
> creating this compatibility layer (assuming this is possible) would be
> worth it
>
>
>
>
>
> Or alternate plan :
>
>
>
> - for proj 5.0, add at top of proj_api.h
>
>
>
> #ifndef I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1
>
> #error "proj_api.h will be removed in proj 5.1. You can still use it for
> now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1, but
> you should strongly consider using proj.h now"
>
> #endif
>
>
>
> Perhaps do the same for projects.h, if we really want proj 5 to be a
> no-brainer for packagers
>
>
>
> - for proj 5.1, remove proj_api.h (and projects.h)
>
>
>
>
>
> Benefits:
>
> * this would make proj 5 easy to be packaged, by avoiding a flag day
>
> * applications would be clearly warned they have to do something, and have
> time to do the changes
>
> * after proj 5.0 release, proj master could benefit from the needed
> cleanups.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20171113/56f1db3f/attachment.htm