*cs out EPSG:3042 and *declination auto - weird interaction

[Olly Betts]

On Wed, Oct 18, 2023 at 12:03:53PM +0100, Warren Family wrote:
> I'm getting a weird result depending on the order of *cs out EPSG:3042 and
> *declination auto in the survex file, for my standard test dataset for Dow
> Cave / Providence Pot.  There is something about the interaction between
> these two commands which I don't understand.
> 
> I know that *declination auto should be preceded by a command defining the
> input co-ordinate system (in this case *cs OSGB:SD) -- this problem is about
> the interplay of *declination auto and the output co-ordinate system
> declaration.

The coordinates are computed in the output coordinate system, so you
actually also need to define the *OUTPUT* coordinate system first, as
the documentation for `*declination` in the manual indicates:

| If you have specified the output coordinate system (using *cs out)
| then you can use *declination auto (and we recommend that you do).

(You do need to set an input coordinate system as well, which is used to
interpret the coordinates specified in the `*declination auto` command.)

So your "fail" version is actually the correct one, and it's a bug that
cavern doesn't complain about the "succeed" version - currently it only
complains if the input coordinate system isn't set.

The declination values aren't computed until later because they depend
on the survey date, but the convergence only depends on the output
coordinate system so when I added support for that I just calculated it
once up front (but failed to add a check that the output coordinate
system is actually set).  We could probably delay calculating the
convergence too (but still cache it once computed for efficiency) which
would make both versions work.

> So to summarise - if *cs out EPSG:3042 precedes *declination auto in the
> survex file, the centreline (outside of *fix stations) is screwed up.  But
> this co-ordinate system is quite a common one isn't it (?) since it's for
> the European datum equivalent for WGS84, with the western European UTM zone.
> 
> Version info:
> os-release: Ubuntu 22.04.3 LTS (Jammy Jellyfish)
> survex: 1.4.1
> proj: release 8.2.1

Your Survex release is nearly 2 years old - 1.4.5 is the latest.  You
should be able to easily install 1.4.4 on Ubuntu from the PPA (the main
change in 1.4.5 was a fix for a crash in aven's export dialog which
doesn't affect Linux):

https://launchpad.net/~survex-devs/+archive/ubuntu/ppa

Testing with a build from git and PROJ 9.3.0, neither version gives a
"screwed up" centre line - visually I can't tell them apart in aven,
though `diffpos *.3d` shows stations have moved by up for ~5m.

Cavern now reports the applied corrections for each `*declination auto`
and that output is interesting:

test_epsg3042_succeed.svx:2: info: Declination: -7.1° @ 1982-02-07 / -1.8° @ 2015-10-03, grid convergence: 0.0°

test_epsg3042_fail.svx:3: info: Declination: -7.1° @ 1982-02-07 / -1.8° @ 2015-10-03, grid convergence: 0.8°

This also suggests the "succeed" version is the one that's wrong as the
grid convergence is unlikely to be "0.0°".

I can't explain why you see screwed up coordinates from the "fail"
version though.  A NULL coordinate system name will get passed to PROJ
for the "succeed" case, so that's the one which I'd expect might be
screwed up (though it seems at least with the newer PROJ I'm using that
this just result in no correction for grid convergence).

Cheers,
    Olly