Hi
Thanks for your effort!
At least for me, this is already a huge improvement. Extrapolating into the future is ok for me and would have avoided my problem, so I guess the most important points have been adressed.
The only suggestion I'd have is not only issuing a warning but fail the build. In my case I'm starting it from xtherion (on Windows). Warnings do not pop out there at all, you even only see a part of the output unless you start scrolling, so it's even likely that such a warning will not be seen at all - I also only found the other warning in therion 5.4.4 by chance, as I don't usually examine the output very closely as long as it runs through.
> I would propose:
>
> 1. If a survey is dated but is newer than available correction data,
> build should fail with a message like:
> "Error determining magnetic declination for survey <name> with date
> <date>. Please specify the declination explicitly using for example
> 'declination 3 deg'"
> instead of the (completely wrong)
> "unable to determine magnetic declination for undated surveys"
We have discussed it with Stacho and the following seems to be the best approach:
IGRF models are designed to predict over the 5 year period (IGRF 13 released at the end of 2019 is intended to be used to predict the declination up to the end of 2024, when a new version, IGRF 14 will be released). In Therion, we will allow to use the model for additional 5 years (using linear extrapolation) and produce a warning (so IGRF 13 could be used until the end of 2029). After 2029, more firm warnings will be produced if Therion still uses IGRF 13, but we don't expect anybody to use such an outdated Therion.
At least for me, I don't think I have performed any surveys before 1900, or at least, I cannot remember that ;)On the other hand: is there any need to use the data older than 1900? If yes, we could implement the GUFM1 model covering the period 1590–1890.
> 2. If at least one of the imported (and thus joined) surveys has magnetic
> data but at least one does not (or cannot be determined), an error
> shall be thrown as well, because mixing corrected and uncorrected
> surveys is just plain wrong and causes a lot of confusion (as it has
> happened to me). The same error message shall be displayed and the
> build fails.
You can't always avoid mixing dated and undated surveys (sometimes the older survey data might be undated), so using the min(survey_dates) as a proxy for undated surveys (and producing a warning as well) should be a reasonable approach.
I can see your point and for me that's ok - because I don't have any undated surveys; I would just find it more consistent the other way - mainly because I'm not a huge fan of warning messages that are hard to spot.
Thanks for all your effort
Matt