[Proj] 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" <smpel at yahoo.com> 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 <
> knudsen.thomas at gmail.com> 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 <dagnew at ucsd.edu>:
>
> 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
> Proj at lists.maptools.org
> http://lists.maptools.org/mail man/listinfo/proj
>
>
>
> ______________________________ _________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/ mailman/listinfo/proj
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> 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/20170811/1d8e5183/attachment-0001.htm