[PROJ] Make push and pop FIFO?

[Thomas Knudsen]

Jochem, Even:

The main problem with PROJ's current push/pop functionality
is that the four-stack implementation makes it impossible
to push one dimension of a coordinate-tuple and pop it into
another, without an elaborate axisswap dance at both ends
of the push/pop-pair.

This is a consequence of the v_1 ... v_4 syntax used: Since
the order of operator arguments is not necessarily preserved
during the parsing process, a pair specified as "v_1 v_2"
may appear as "v_2 v_1" at parsing time.

A more axisswap-like syntax would have eliminated this - e.g.

    proj=push items=1,3

to push dimensions 1 and 3 of the coordinate tuple onto the
stack, and

    proj=pop items=3,1

to pop them back into swapped dimensions.

But since the obvious names of push and pop is now taken,
let's make a virtue out of necessity by adding a little
more encapsulation by introducing the "stack subsystem",
giving this syntax:

    proj=stack push=1,3

and

    proj=stack pop=3,1

The implementation will still mimick that of push/pop (i.e
being handled as part of the pipeline machinery, rather
than as ordinary proj=foo-operators), but it will not stomp
on the existing unfortunate push/pop-implementation, and it
leaves room for extension, e.g. by introducing the swap and
flip operators mused over earlier in this thread:

    proj=stack push=1,3
    proj=stack swap
    proj=stack pop=1,3

to essentially do the same as above and:

    proj=stack push=1,3
    proj=stack flip=3,1

although I believe the need for these will be limited, once
we have a push/pop pair actually working like a stack.

The wish for named registers mentioned earlier in the
thread may be introduced using a similar syntax, where:

    proj=reg save=1,3 into=first,third
    proj=reg restore=1,3 from=third,first

will do the same swapping of first and third dimension as
above, but using named registers instead of stack slots.

I see the potential for improved clarity when using named
registers instead of stack slots, by using meaningful
names for the registers (e.g. ellipsoidal_height and
orthometric_height, to take the obvious use case).

The problem, however, is when trying to interpret the
workings of a pipeline running in inverse mode:

In the inverse stack-case, we only need to flip the
abstract concepts of stack slots, and swap push for pop.

Whereas in the register case, we also need to "abstractly
swap the concrete concepts behind the concrete register
names" which, at least to my imperfect brain, is much
harder.

But while not personally seeing the need for registers,
I acknowledge the wish for them, and to make this work
in a fairly backwards compatible way, I suggest the
solution outlined above, i.e. two new, and well
encapsulated subsystems in the pipeline implementation.
And once they are well established: Deprecation of the
current push/pop pair.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240203/efc2a3ae/attachment.htm>