[Therion] What is going on with these survey legs?
On Mon, Sep 08, 2014 at 01:47:57PM -0500, Bill Gee wrote: > The starting point is two azimuth readings. Call them FOR1 and BACK1. > > 1) FOR2 = BACK1 + 180 > 2) FOR2 = FOR2 MOD 360.0 > 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0 > 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0) For 1 and 179, that gives me 180, rather than 0. What Survex does is more complex, as the foresight and backsight may have different standard deviations specified, and it's working in radians at this point, but in the case where the two instruments are the same specified accuracy (which seems likely to be by far the most common), it boils down to this (fabs() is the absolute floating point value - i.e. drop any minus sign): backcomp -= 180; diff = comp - backcomp; adj = fabs(diff) > 180 ? 180 : 0; final = (comp + backcomp) / 2 + adj; You can see the full version here: https://github.com/ojwb/survex/blob/master/src/datain.c#L893 That's pretty close to what you have - I think the key difference is the fabs() on the wrap-around check. I believe I proved that the averaging algorithm Survex uses was correct back when I implemented this, though unhelpfully I didn't add the proof as a comment in the code. Though looking at the code now, I think it should be wrapping the two bearings to the range [0,360) after it corrects for zero errors and declination and before it does the actual averaging. I'll take a look at that. Footleg's idea of averaging vectors is interesting - I'd not thought about that before. One nice feature is that it naturally extends to more than 2 bearings. It also helpfully gives "invalid" for trying to average bearings which completely oppose (whereas feeding the same bearing in as foresight and backsight above will give you a bearing that's 90 degrees away to one side or the other, arbitrarily). Cheers, Olly
[Therion] What is going on with these survey legs?
This is a classic problem, and since I ran foul of it in my own cave data processing software ( http://wscc.darkgem.com/caveconverter/ ) I have heard of two other cases of cave survey software falling into the same trap. The answer is to treat the bearings as vector forces and average the vectors. This works for all cases. I have written a function (averageCompassBearings) to implement this angle averaging in the UtilityFunctions.java source file in my Cave Converter (released under GNU General Public License). See this article for a discussion of the problem and the maths: http://stackoverflow.com/questions/491738/how-do-you-calculate-the-average-of-a-set-of-angles This will give you very similar results to just averaging the bearing angles when there is no wrap around the 360=0 boundary when the angles are all within a degree or so of each other. But you get quite different answers when the angles are well spaced apart. I believe the average vectors answer is more applicable in the case of bearings. It is not an issue either way for cave survey cases where I hope the bearings being averaged are all of very similar values. But in the case of vector forces pulling on an object, if three equal forces were pulling at angles of 0, 5, and 180 degrees, then the 0 and 180 vectors would cancel each other out, and the remaining vector at 5 degrees would be dominant giving a vector average of 5 degrees. But the simple mean of the 3 numbers is around 61 degrees, which shows how different the results of these two averaging methods can be. Footleg On 8 September 2014 19:47, Bill Gee wrote: > Hello everyone - > > I did some skull time on this problem. I have an idea that might work. Many > numbers need to be run on this to prove that it works in all cases. Would > some of you take a glance and render an opinion? > > This algorithm depends on a floating-point MODulus (or remainder) operation > which I am not sure exists in most languages. Also, I use degree measures > here, but in a real program it would have to be adjusted to (1/2 circle) and > (1 circle) ... 200 grads or pi radians or whatever. > > The starting point is two azimuth readings. Call them FOR1 and BACK1. > > 1) FOR2 = BACK1 + 180 > 2) FOR2 = FOR2 MOD 360.0 > 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0 > 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0) > > Thanks - Bill Gee > > > On Saturday, August 16, 2014 04:38:36 Olly Betts wrote: >> On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote: >> > I am struggling with a couple of survey shots that Therion is not >> > interpretting correctly. It might be a bug in how Therion averages >> > forward >> > and backward compass when the readings are near 360 and 180 degrees. >> >> There's a bit of a gotcha when averaging compass readings, due to the >> wrap-around at 360/0 degrees. >> >> For example, if we try to average two readings: 359 and 003, then the >> correct answer (at least assuming we believe them to be equally >> accurate) would be 001. But if we naively sum and divide by the number >> of readings, we get (359+003)/2 = 362/2 = 181. >> >> The same issues affects averaging forward and back sights - the only >> different is that the back sights get altered by 180 degrees before >> averaging. >> >> I've not tried to find where in therion this is implemented, but it >> appears to explain what you are seeing here - assuming therion subtracts >> 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 = >> 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the >> second. >> >> > One of the shots (B11-B12) has compass readings of exactly 0 and 180. >> > This >> > shot displays correctly on the map. >> >> In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this >> case also fits my hypothesis. >> >> Survex is careful to get these cases right, but unfortunately it seems >> that when therion uses Survex to process the centreline data, it does >> the backreading averaging itself before it passes data to Survex, so >> that doesn't provide a way to work around this problem. >> >> You could put the centreline data in a .svx file, and tell therion to >> process that and use the .3d file. >> >> Cheers, >> Olly > > ___ > Therion mailing list > Therion at speleo.sk > http://mailman.speleo.sk/mailman/listinfo/therion
[Therion] What is going on with these survey legs?
Hello everyone - I did some skull time on this problem. I have an idea that might work. Many numbers need to be run on this to prove that it works in all cases. Would some of you take a glance and render an opinion? This algorithm depends on a floating-point MODulus (or remainder) operation which I am not sure exists in most languages. Also, I use degree measures here, but in a real program it would have to be adjusted to (1/2 circle) and (1 circle) ... 200 grads or pi radians or whatever. The starting point is two azimuth readings. Call them FOR1 and BACK1. 1) FOR2 = BACK1 + 180 2) FOR2 = FOR2 MOD 360.0 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0) Thanks - Bill Gee On Saturday, August 16, 2014 04:38:36 Olly Betts wrote: > On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote: > > I am struggling with a couple of survey shots that Therion is not > > interpretting correctly. It might be a bug in how Therion averages > > forward > > and backward compass when the readings are near 360 and 180 degrees. > > There's a bit of a gotcha when averaging compass readings, due to the > wrap-around at 360/0 degrees. > > For example, if we try to average two readings: 359 and 003, then the > correct answer (at least assuming we believe them to be equally > accurate) would be 001. But if we naively sum and divide by the number > of readings, we get (359+003)/2 = 362/2 = 181. > > The same issues affects averaging forward and back sights - the only > different is that the back sights get altered by 180 degrees before > averaging. > > I've not tried to find where in therion this is implemented, but it > appears to explain what you are seeing here - assuming therion subtracts > 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 = > 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the > second. > > > One of the shots (B11-B12) has compass readings of exactly 0 and 180. > > This > > shot displays correctly on the map. > > In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this > case also fits my hypothesis. > > Survex is careful to get these cases right, but unfortunately it seems > that when therion uses Survex to process the centreline data, it does > the backreading averaging itself before it passes data to Survex, so > that doesn't provide a way to work around this problem. > > You could put the centreline data in a .svx file, and tell therion to > process that and use the .3d file. > > Cheers, > Olly
[Therion] What is going on with these survey legs?
Hi Olly - Yep, I figured there was something in the wrap-around that is causing this. As I see it, there are two things to figure out ... 1) What are the edge cases? Is this a problem with 358/180, for example? 355/179? I think some experimenting needs to be done to figure out where the algorithm breaks down. 2) Can an algorithm be devised which is correct for all combinations of forward and backward azimuth readings? Even pathological cases such as 90/91 should be handled in a sane manner. I don't know any survey which would allow the forward and backward shots to differ by a single degree. However, there are probably occasions when a 5 or 10 degree difference has to be allowed. I don't think Therion should determine when the forward and backward shots are too far apart. That is up to the survey team and the person entering the data. Therefore Therion should provide sane handling of all possible cases. It would also be interesting to see if this is still a problem when measuring azimuth in something other than degrees. Does it also happen when using grads? It should ... but it is worth checking. I will try to find some spare time to run a bunch of trial cases. Regards - Bill Gee On Saturday, August 16, 2014 04:38:36 Olly Betts wrote: > On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote: > > I am struggling with a couple of survey shots that Therion is not > > interpretting correctly. It might be a bug in how Therion averages > > forward > > and backward compass when the readings are near 360 and 180 degrees. > > There's a bit of a gotcha when averaging compass readings, due to the > wrap-around at 360/0 degrees. > > For example, if we try to average two readings: 359 and 003, then the > correct answer (at least assuming we believe them to be equally > accurate) would be 001. But if we naively sum and divide by the number > of readings, we get (359+003)/2 = 362/2 = 181. > > The same issues affects averaging forward and back sights - the only > different is that the back sights get altered by 180 degrees before > averaging. > > I've not tried to find where in therion this is implemented, but it > appears to explain what you are seeing here - assuming therion subtracts > 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 = > 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the > second. > > > One of the shots (B11-B12) has compass readings of exactly 0 and 180. > > This > > shot displays correctly on the map. > > In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this > case also fits my hypothesis. > > Survex is careful to get these cases right, but unfortunately it seems > that when therion uses Survex to process the centreline data, it does > the backreading averaging itself before it passes data to Survex, so > that doesn't provide a way to work around this problem. > > You could put the centreline data in a .svx file, and tell therion to > process that and use the .3d file. > > Cheers, > Olly
[Therion] What is going on with these survey legs?
On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote: > I am struggling with a couple of survey shots that Therion is not > interpretting correctly. It might be a bug in how Therion averages forward > and backward compass when the readings are near 360 and 180 degrees. There's a bit of a gotcha when averaging compass readings, due to the wrap-around at 360/0 degrees. For example, if we try to average two readings: 359 and 003, then the correct answer (at least assuming we believe them to be equally accurate) would be 001. But if we naively sum and divide by the number of readings, we get (359+003)/2 = 362/2 = 181. The same issues affects averaging forward and back sights - the only different is that the back sights get altered by 180 degrees before averaging. I've not tried to find where in therion this is implemented, but it appears to explain what you are seeing here - assuming therion subtracts 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 = 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the second. > One of the shots (B11-B12) has compass readings of exactly 0 and 180. This > shot displays correctly on the map. In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this case also fits my hypothesis. Survex is careful to get these cases right, but unfortunately it seems that when therion uses Survex to process the centreline data, it does the backreading averaging itself before it passes data to Survex, so that doesn't provide a way to work around this problem. You could put the centreline data in a .svx file, and tell therion to process that and use the .3d file. Cheers, Olly
