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.
I strongly dont think this is the error source as it is also visible in the
test file. 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.
For the date-observation, indeed my conclusion came from the summary in the
log. Thank you for claryfying this. Good to hear, therion uses fractions
here, and 1/12 is perfectly good.
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?
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 main issue here is, that we have surveys which were taken in the 1950s
and extended with an additional centerline in 2000s.
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-9
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
[email protected]
https://mailman.speleo.sk/listinfo/therion
