On Sat, Feb 18, 2017 at 9:20 AM, Benedikt Hallinger via Therion <therion@speleo.sk> wrote:
If therion calculates the average position of all fixed points this is fine. the cave spans about 5km w/e and about 3km n/s.
The change in declination over 5 km distance in your area is about 1' which is completely negligible for compass surveys.
I strongly dont think this is the error source as it is also visible in the test file.
The problem with your test file is that the declination on 2013-12-31 should be 3.08 degrees, not 3.8. If you use 3.08 (or more precisely 3.083333), than the error in the test file is less than 20 cm on 2 km legs. You should also take into account that the declination value at GFZ Potsdam is rounded to the nearest minute.
Also, calculating the igrf for each station should not be neccessary unless there are some strong amd small local anomalys which is not the case here.
IGRF model does not take local anomalies into account anyway.
However i have seen that it looks like the calculated declination is maybe rounded to full degrees? Or is this just an display thing in aven viewer?
No rounding in therion here.
Based on what you have said, i would assume that the problem source lies in therion itself summarizing all centreline dates into one survey average date, and not just by centerline as i would assume, when each centerline has a date specification.
The automatic declination is bound to centreline. You can check it also in your example if you change the date of the first centerline to e.g. 1950. Maybe there is some other source of error in the data? Martin
Am 2017-02-17 23:26, schrieb Olly Betts:
On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
i found out that the declination handling seems to be somewhat inaccurate. The produced error is marginal and negligible with small caves, however i am currently working on a system with >100km and this produces errors of
10m there.
Therion calculates all declination values at the same location (the average location of all the fixed points), which is potentially problematic if your survey spans that sort of distance. I wonder if this might actually be the source of your problems.
Survex requires specifying the location to calculate declination values at, and you can use different locations for different parts of the survey hierarchy. So keeping your centreline data in Survex format and feeding therion a 3d file would be one solution if this is the issue you're hitting.
(Using the actual location of the station the reading was taken at is hard as you need the declination value to calculate that location. It would also be fairly slow to evaluate the IGRF model at every station where a compass was read.)
What i observe is the following: - Therion seems to use the first day of any given year referenced by "date" command.
If that's from looking at therion's log file, the "geomag declinations (deg)" table there is just a summary. It indeed shows the values on January 1st of each "interesting" year, but doesn't reflect the dates actually being used to calculate declinations for surveys.
Or was that from looking at the source code? The get_start_year() and get_end_year() methods actually return a fractional year value, not just the year of the survey. The fraction is calculated assuming each month is 1/12 of the year - not quite right, but probably not a significant error in practice.
- If a survey was taken at the end of a year it seems that the 1.1 of the following year will be used (i assume this happens at mid-year). - This approach looses at most half a years magnetic drift. This alone is acceptable as the data by itself is already not that accurate.
However if you have several centerlines in the survey, each with different date-commands, therion seems to calculate the average of all dates and then uses the calculated declination for that date (applying the rule above, so taking the "closest 1.1."). This is then applied to all shots of the whole survey.
Not sure - I don't know therion's code that well.
A possible solution to this seems, to get the correct declination for each date and explicitely write suitable "declination" commands that override the "date"-calculated values. This then gives the proper results.
This approach is less than ideal, and not just because it's a significant effort.
Each generation of the IGRF model is necessarily predictive for dates after it was issued and only declared to be definitive for dates more than 5 years before it was issued. So each new generation of the model can change the declination figures reported for the last 10 years compared to the previous generation.
In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give different answers for all dates in 2010 and later (not hugely different one would hope, but your motivation here is to avoid introducing unnecessary errors).
See table 1 here for the date information for each IGRF model generation:
http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228...
So unless you're dealing with historic data, you really want your software to calculate the declination automatically so that you get the benefit of improvements when the IGRF model is updated.
Cheers, Olly
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion