still an issue Re: *cs out EPSG:3042 and *declination auto - weird interaction

[Warren Family]

Thanks again!  With the insight that it's something to do with how the 
grid convergence is being computed, the following self-contained .svx 
file seems to isolate the problem:

*cs OSGB:SD
*cs out EPSG:3042
*declination auto 97480 72608 225
*date 2005.12.15
*begin test_epsg3042
*fix 1 97480 72608 225
*data normal from to tape compass clino
1 2 25.0 000 0 ; due north, magnetic
*end test_epsg3042

The log message is
test_epsg3042.svx:3: info: Declination: -3.5° @ 2005-12-15, grid 
convergence: -90.8°
and measured in aven the 1->2 leg is pointing almost due east (bearing 
87.3°)

If I run the same but with *cs out UTM30N then the declination is the 
same but the grid convergence is reported as 0.8° (positive) and leg is 
almost due north (bearing 355.7°).  I checked that changing the *date 
doesn't seem to affect the problem.

Patrick


On 19/10/2023 01:58, Olly Betts wrote:
> On Wed, Oct 18, 2023 at 11:04:36PM +0100, Warren Family wrote:
>> Thanks for looking into this so promptly :-).
>> I updated to survex 1.4.4 - thanks for indicating how :-).
>> It's also clearer now you explain (thanks!) that :
>>   - the *cs and *cs out should be defined before *declination auto;
>>   - the *declination auto uses the co-ordinate system of the most recently
>> encountered *cs command not the *cs out command.
> More precisely, it uses that to interpret the coordinates specified in
> the command.  It uses the *cs out co-ordinate system to compute the
> grid convergence.
>
> Pedantically it might not be the "most recently encountered *cs command"
> as this is scoped by *begin/*end, e.g. here the declination auto
> coordinates are in OSGB:SD:
>
> *cs OSGB:SD
> *begin
> *cs EPSG:4326
> *end
> *cs out EPSG:3042
> *declination auto 97480 72608 225
> *include DowCave/DowCave
> *include DowbergillPassage/Dowbergill1
> *include DowbergillPassage/Dowbergill2
> *include ProvidencePot/ProvidencePot
> *equate DowCave.dow2.31 Dowbergill1.dgp1.1
> *equate Dowbergill1.dgp5.16 Dowbergill2.dgp6.46
> *equate Dowbergill2.dgp7.1 ProvidencePot.PPot6.15
>
>> $ cat test_epsg3042_fail.svx
>> [...]
>> test_epsg3042_fail.svx:3: info: Declination: -7.1° @ 1982-02-07 / -1.8° @
>> 2015-10-03, grid convergence: -90.8°
>> $ cat test_epsg3042_succeed.log
>> [...]
>> test_epsg3042_succeed.svx:2: info: Declination: -7.1° @ 1982-02-07 / -1.8° @
>> 2015-10-03, grid convergence: 0.0°
>> $ cat test_utm3on.log
>> [...]
>> test_utm3on.svx:3: info: Declination: -7.1° @ 1982-02-07 / -1.8° @
>> 2015-10-03, grid convergence: 0.8°
> I think the first two are wrong and the last right.  You probably should
> get the same value for all three, or at least a very similar value (not
> sure if WGS84 vs ETRS89 has an effect, but I can't see it making much
> difference if any).
>
>> I'm prepared to believe that the version that is still failing for me is
>> somehow working for you.
>> Maybe there is a bug in the PROJ library?
> I'm getting 0.8° for the "fail" case, so it does seem likely to be
> due to the different PROJ versions.
>
> Computing the convergence requires trickery for some older PROJ
> versions, and the exact trickery varies with version.  However for
> PROJ >= 8.2 there's a non-experimental and (as far as I know) non-buggy
> API to get it, and you said you're using 8.2.1.
>
> I'll try to test with older PROJ and see if I can work out what's going
> wrong.  If I can't fix it, we could make the PPA builds use a backport
> of a newer PROJ version.
>
> Therion takes a different approach - it converts some dummy coordinates
> then computes the convergence angle from them using arctan.  I like that
> less than using a PROJ API call intended to give the convergence, but
> I'm starting to see the appeal of this other approach.  Using that when
> built with older PROJ might be an option.
>
> Cheers,
>      Olly