Do more sophisticated grid convergence.

[Eric C. Landgraf]

Currently, we compute grid convergence for the point specified in *declination auto. Typically, this is fine: if you're not at polar regions or at the very edge of a UTM zone, it's likely less than 1°.

However, for very large cave systems or cave regions, this method is insufficient: it requires you set *declination auto at several different points. This is ususally a sensible idea: if your cave system is large, declination is likely to change across linear space, sometimes quite agressively, and it is hard to effectively predict this behaviour as it shifts temporally and spacially.

Grid convergence (difference between grid north and true north) is "simple" in comparison, and changes less dramatically over a region. But for multi-entrance systems could still result in major shifts between entrances

We should compute it at more than a central point, especially for "large" systems. This likely will have to be a configurable knob.

Some caveats that Olly and I have discussed:

• grid convergence for any given leg both depends on and controls station location
• station location cannot be ascertained without closing loops and solving the system.

The only way to *perfectly* account for grid convergence requires iteratively re-solving the entire system (an operation which can be quite costly) with new convergence corrections based on final location. This is going to be most costly for the cave systems where it is most important. So what we want is an "approximate" solution that can be done quickly, and generally, without users having an in-depth understanding of grid convergence themselves.

Therion uses the centroid of all fixed points. Walls appears to semi-iteratively solve for grid convergence (although I may be wrong).

[Olly Betts]

Implementing anything like this seems like it's going to be a disproportionate amount of work for the benefits, and we have a lot of open tickets requesting things that would deliver more benefits for more users for less effort.

Also, just having to calculate declination and convergence at every station would add hugely to processing time - a quick hack of disabling the caching of declination and convergence simulates this and takes processing for all the CUCC Austria data from under 2 seconds to over 432 seconds (7m12). That actually forces a calculation for every leg - the number of legs is close to the number of stations unless there are a lot of loops, though if leapfrogging is used you might be able to avoid calculating for up to half the stations if you cache the convergence per station (though then that's memory overhead). A system which picked a point "near enough" to use such that the same point was use for multiple stations would reduce the number of calculations, but makes this even more complicated to implement and requires a data structure to store these points and their convergence values and provide a way to look the nearest one efficiently.

So I think we should keep it simple and stick with the current approach of calculating at the specified location(s). Even for Mammoth it's apparently only 0.1° different between West and East.

I think the manual explains the reason for not trying to calculate declination and convergence at the actual location of each station pretty well, but always happy to have suggestions for doc improvements.

What we could usefully do is help users to know when they should be thinking about specifying multiple locations, which we could do by reporting the actual range of convergence across the survey. We already report the convergence for each specified location, so the user can see how much deviation there is from the value(s) actually being used.

We clearly don't want to calculate convergence at every station to report this, but calculating it at the east- and west-most stations should give a pretty close approximation to the full range for typical projections, and we already find those extreme stations. We might as well check north- and south-most too, which might give a wider range for projections used at the poles.

(It'd be nice to do the same for declination too but that seems trickier as the extreme values may well not be near the edges, and also declination varies by date so it's harder to usefully compare.)

[Olly Betts]

a quick hack of disabling the caching of declination and convergence simulates this and takes processing for all the CUCC Austria data from under 2 seconds to over 432 seconds (7m12)

I wondered how much of this was declination and how much convergence - if I only turn off caching of declination then it takes 2.2 seconds, so it's almost all convergence it seems.