Click here for an overview of the Compass Users Group Archives:
Authentication-Results: mta1006.groups.mail.ne1.yahoo.com from=r-schuster.de; domainkeys=neutral (no sig); from=r-schuster.de; dkim=neutral (no sig) Date: Sun, 18 Feb 2018 21:22:32 +0100 Subject: PPI changes in Inkscape From: Roger Schuster Hello all, I want to inform you about an import change in Inkscape. Compass SVG Exporter currently exports SVG files with 90 pixel per inch. According to http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape this was fine with Inkscape up to version 0.91. With version 0.92 the resolution is expected to be 96 pixel per inch. This web page https://bugs.launchpad.net/inkscape/+bug/1659489 says there is a command line option to convert "legacy" drawings to the new standard but I haven't tried it so far. Regards, Roger
Authentication-Results: mta1004.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Tue, 20 Feb 2018 16:10:08 -0700
Subject: RE: [compass-users] PPI changes in Inkscape
From: "Larry"
Hi Roger,
Thanks for the information. I've updated the SVG Exporter so it offers the
additional option of exporting using 96 dpi as one of the options. The
option is in the compatibility section of the exporter. The new version is
on the internet.
Larry Fish
_____
From: [email protected] [mailto:[email protected]]
Sent: Sunday, February 18, 2018 1:23 PM
Subject: [compass-users] PPI changes in Inkscape
Hello all,
I want to inform you about an import change in Inkscape. Compass SVG
Exporter currently exports SVG files with 90 pixel per inch. According
to
http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape
this was fine with Inkscape up to version 0.91. With version 0.92 the
resolution is expected to be 96 pixel per inch.
This web page
https://bugs.launchpad.net/inkscape/+bug/1659489
says there is a command line option to convert "legacy" drawings to the
new standard but I haven't tried it so far.
Regards,
Roger
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta1006.groups.mail.bf1.yahoo.com from=bk.ru; domainkeys=neutral (no sig); from=bk.ru; dkim=pass (ok) Date: Wed, 07 Mar 2018 11:10:45 +0300 Authentication-Results: f334.i.mail.ru; auth=pass [email protected] [email protected] From: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JDQutC40LzQvtCy?= Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1004.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Wed, 7 Mar 2018 02:01:30 -0700
Subject: RE: [compass-users] (unknown)
From: "Larry"
Thanks for your question.
There are several things that can cause Compass to display different
measurement values in the "Viewer" than what you entered n the "Editor."
Without looking at the actual data, I wouldn't know with certainty, but here
are some ideas:
1. If the shot is a part of a loop and the "Close" option is enabled,
Compass will adjust the data to compensate for any errors in the loop.
Depending on the size of the loop error, the values can be changed a
relatively large amount.
2. If the shot is a part of a loop and the "Close" option is not enabled,
you may still see changed values in the plot. This is because when loops
aren't closed, all the errors fall on the last shot in the loop. In that
case, there may be very large changes to that last shot.
3. Other things like declination values and UTM grid alignment can change
the values seen in the Viewer. However, they only cause changes in the
Compass angle and since you seeing changes in all three measurements, I
doubt that is the cause.
If you can give me more detailed information about the data, I may be able
to give you a more accurate answer.
Larry Fish
_____
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, March 07, 2018 1:11 AM
Subject: [compass-users] (unknown)
Friends, I noticed that the program COMPASS distorts data of topo . For
example I write down in a D�E�OA�IUE magazine an azimuth 280 hail,an angle
of slope is 35 degrees, length 15 meters, and at processing of data of map,
data change :Azimuth becomes 275, angle of slope - 33, long 12 meters . Do
not I understand why takes place so ?
�I�EO�E �E�IIx
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com from=bk.ru; domainkeys=neutral (no sig); from=bk.ru; dkim=pass (ok) Date: Wed, 07 Mar 2018 23:40:55 +0300 Authentication-Results: f471.i.mail.ru; auth=pass [email protected] [email protected] Subject: =?UTF-8?B?UmVbMl06IFtjb21wYXNzLXVzZXJzXSAodW5rbm93bik=?From: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JDQutC40LzQvtCy?= A� Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't present on it here, something another.????? Thanks for the help.A� D��?D�D'D�, 7 D�D��?�,D� 2018, 12:05 +03:00 D_�, 'Larry' [email protected] [compass-users] : A� Thanks for your question. There are several things that can cause Compass to display different measurement values in the �?oViewer�?? than what you entered n the �?oEditor.�?? Without looking at the actual data, I wouldn�?Tt know with certainty, but here are some ideas: 1. If the shot is a part of a loop and the �?oClose�?? option is enabled, Compass will adjust the data to compensate for any errors in the loop. Depending on the size of the loop error, the values can be changed a relatively large amount. 2. If the shot is a part of a loop and the �?oClose�?? option is not enabled, you may still see changed values in the plot. This is because when loops aren�?Tt closed, all the errors fall on the last shot in the loop. In that case, there may be very large changes to that last shot. 3. Other things like declination values and UTM grid alignment can change the values seen in the Viewer. However, they only cause changes in the Compass angle and since you seeing changes in all three measurements, I doubt that is the cause. If you can give me more detailed information about the data, I may be able to give you a more accurate answer. Larry Fish A� ---------------------------------------------------------------------- From: [email protected] [mailto: [email protected] ] Sent: Wednesday, March 07, 2018 1:11 AM To: [email protected] Subject: [compass-users] (unknown) A� A� Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1004.groups.mail.bf1.yahoo.com from=skynet.be; domainkeys=neutral (no sig); from=skynet.be; dkim=neutral (no sig) IronPort-PHdr: =?us-ascii?q?9a23:SCyrYhSh6MyrFJDH2Bq0+NmHItpsv+yvbD5Q0YIu? =?us-ascii?q?jvd0So/mwa67ZBeGt8tkgFKBZ4jH8fUM07OQ7/i7HzRYqb+681k6OKRWUBEEjc? =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo? =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjWwba98IRmssQndqtQdjJd/JKo21hbHuGZDdf? =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM? =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KhsVRHolT? =?us-ascii?q?wHNyYn/27Llsx+gqVboBe7qBx+xY7ffYWZOfV6c6/Ye94RWGhPUdtLVyFZGIOy? =?us-ascii?q?b5UBD+QDMuhFoYf9oFgAohSiCgerGOPi0SVIimP53aAizegtDQPL0Qo9FNwOqn? =?us-ascii?q?TUq9D1Ob8cXe6v1qbI0DHDZO5Y1zjj9YPFbxEhru+CUbltdsfR0VMgFx7BjlmK? =?us-ascii?q?tIPqISmZ2f8Ms2eF9OdgTuGvim4hqw5vvjij3NwjhZfQi48T11vK+yJ5wIMvKt? =?us-ascii?q?25Tk52edukH4FRtyGeLYd2WN4iT3lztyY+zb0GtoW7fDANyJQ73RLQd/uHc42Q? =?us-ascii?q?7hPjTumRITB4hHV/dL2jgBay9FCsyvbgWcauzlZFtC5Fkt7KtnwXzBPc9M6KQe? =?us-ascii?q?Z+8Ee5wTuC1ALe5vtFLE07j6bXNoItzqMqmpYOsUnOHyn7k1jsgqCMbEUr4O2o? =?us-ascii?q?5vziYrXhu5CTKZd5ihr7MqQygsy/Bvk4MhQWU2ib5+u80Lrj8FXjTrpQk/02lr? =?us-ascii?q?PXvY7CKcQaoK62HRNV354g5hu9FTur0dsVkWMaIF5ZZR6LlZXlNlHPLfzgCPew? =?us-ascii?q?mVWskDNlx/DcOb3hB43ALmDZn7f8ebZx8VNTxxQpwd9E5pJbFKoMIOnwWk7xst? =?us-ascii?q?zXEAM5PxavzOn5ENl9zJ8RWXqTAq+FN6PfqUOH5uUqI+mUfoAVoy39J+E45/71? =?us-ascii?q?k3A5g0QdcLKp3JQNaHC4GfNmI0qDYXrrn9cBCXwKshAiQ+ztjV3RGQNVfGu4Cq? =?us-ascii?q?c15zUnD9CtCoLbT5u2xaGa0T2gW4BQfX1MEVuWEH3lX5SNW/ALZziVP9d61DcD? =?us-ascii?q?UO+6VoUj2Bqy4TL80KdtNeHO+ycV5q/lz8V/su3PiQkpp3szDsKT1CecRmFzmS? =?us-ascii?q?UDQDpx2K1wqEg610zEwKF4hPsfCMBU/LRVXx0/LtmP8+svX9v1XxrIZczMVU2r? =?us-ascii?q?WM6OEDgxSdU+2dgTe107ENKn2EP50jKuEoMSwuiTDYEwtK7RmXLwKu5myGfA2b? =?us-ascii?q?VnhVRwEeVVMmjzzJZ26gybK4OBuUSU3e7+ba0B2GjB+SGJzGemp0JJVgNsF6/I? =?us-ascii?q?CyNMLnDKpMj0sxuRB4SlDq4qZ1cQxA==?Date: Wed, 7 Mar 2018 22:28:33 +0100 Subject: RE: Re[2]: [compass-users] (unknown) From: "Paul De Bie" Hi, Azimuths and inclinations are configured as GRADS (400 / 100) in your DAT file. I guess that in your other survey program (VTopo ?) they are configured as DEGREES (360 / 90). Which gives you +/- the difference you are seeing�?� HTH Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 9:41 PM Subject: Re[2]: [compass-users] (unknown) Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't present on it here, something another.????? Thanks for the help. D��?D�D'D�, 7 D�D��?�,D� 2018, 12:05 +03:00 D_�, 'Larry' [email protected] [compass-users] : Thanks for your question. There are several things that can cause Compass to display different measurement values in the �?oViewer�?? than what you entered n the �?oEditor.�?? Without looking at the actual data, I wouldn�?Tt know with certainty, but here are some ideas: 1. If the shot is a part of a loop and the �?oClose�?? option is enabled, Compass will adjust the data to compensate for any errors in the loop. Depending on the size of the loop error, the values can be changed a relatively large amount. 2. If the shot is a part of a loop and the �?oClose�?? option is not enabled, you may still see changed values in the plot. This is because when loops aren�?Tt closed, all the errors fall on the last shot in the loop. In that case, there may be very large changes to that last shot. 3. Other things like declination values and UTM grid alignment can change the values seen in the Viewer. However, they only cause changes in the Compass angle and since you seeing changes in all three measurements, I doubt that is the cause. If you can give me more detailed information about the data, I may be able to give you a more accurate answer. Larry Fish _____ From: [email protected] [mailto:[email protected] ] Sent: Wednesday, March 07, 2018 1:11 AM lto%253acompass%[email protected] Subject: [compass-users] (unknown) Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1005.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Wed, 7 Mar 2018 14:56:22 -0700
Subject: RE: Re[2]: [compass-users] (unknown)
From: "Larry"
Thanks Paul,
That saves me a lot of work. I had trouble extracting the file from the
archive and even when I finally extracted the files, they appeared to be
empty. I was in the process of finding another program to extract the files
when your email came in.
To expand on what Paul said, the Compass Viewer will display the angles as
degrees. If you've entered the angles as Grads, they won't match. Just to be
clear on what this means:
Degrees is a way of measuring angles that divides a circle into 360
increments. Gradians or Grads, is another way of measuring angles that
divides a circle up into 400 increments. In the US it is rare to see Grads
used for cave surveying. They were sometimes used in the early days of US
cave exploring because you could buy high-quality, military-surplus compass
for low prices.
The way to fix this depends on what actually happened:
1. If you actually meant to enter grads, then they won't match, even though
the plot will be correct. For the time being, you should just ignore the
discrepancy. (I probably should allow for other units, but it is very rare
for any one to use something other than degrees.)
2. If you meant to enter degrees, but had the Editor set to Grads, then you
will have to convert data. The Editor has tools to help with this. Here is a
link to documentation on how to use these tools:
http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repair.htm
http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repaircompass.h
tm
http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repairinclinati
on.htm
Let me know if you have any other questions.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, March 07, 2018 2:29 PM
Subject: RE: Re[2]: [compass-users] (unknown)
Hi,
Azimuths and inclinations are configured as GRADS (400 / 100) in your DAT
file.
I guess that in your other survey program (VTopo ?) they are configured as
DEGREES (360 / 90).
Which gives you +/- the difference you are seeing:
HTH
Paul De Bie
http://www.scavalon.be
http://scavalon.blogspot.com
From: [email protected]
Sent: Wednesday, March 7, 2018 9:41 PM
Subject: Re[2]: [compass-users] (unknown)
Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a
tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't
present on it here, something another.????? Thanks for the help.
�O��A, 7 IAOOA 2018, 12:05 +03:00 IO 'Larry' [email protected]
[compass-users] :
Thanks for your question.
There are several things that can cause Compass to display different
measurement values in the "Viewer" than what you entered n the "Editor."
Without looking at the actual data, I wouldn't know with certainty, but here
are some ideas:
1. If the shot is a part of a loop and the "Close" option is enabled,
Compass will adjust the data to compensate for any errors in the loop.
Depending on the size of the loop error, the values can be changed a
relatively large amount.
2. If the shot is a part of a loop and the "Close" option is not enabled,
you may still see changed values in the plot. This is because when loops
aren't closed, all the errors fall on the last shot in the loop. In that
case, there may be very large changes to that last shot.
3. Other things like declination values and UTM grid alignment can change
the values seen in the Viewer. However, they only cause changes in the
Compass angle and since you seeing changes in all three measurements, I
doubt that is the cause.
If you can give me more detailed information about the data, I may be able
to give you a more accurate answer.
Larry Fish
_____
From: [email protected]
[mailto:[email protected]
]
Sent: Wednesday, March 07, 2018 1:11 AM
Subject: [compass-users] (unknown)
Friends, I noticed that the program COMPASS distorts data of topo . For
example I write down in a D�E�OA�IUE magazine an azimuth 280 hail,an angle
of slope is 35 degrees, length 15 meters, and at processing of data of map,
data change :Azimuth becomes 275, angle of slope - 33, long 12 meters . Do
not I understand why takes place so ?
�I�EO�E �E�IIx
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com from=skynet.be; domainkeys=neutral (no sig); from=skynet.be; dkim=neutral (no sig) IronPort-PHdr: =?us-ascii?q?9a23:5wG+kBIO1iJFxt5/+dmcpTZWNBhigK39O0sv0rFi? =?us-ascii?q?tYgXKvjyrarrMEGX3/hxlliBBdydt6ofzbKO+4nbGkU4qa6bt34DdJEeHzQksu? =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1? =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlGiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde? =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY? =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr8zRDqi8rxrSAf2hy? =?us-ascii?q?gbKz43/mbXislqg6JaphKquhhzzoHQbY2QMvd1Y6HTcs4ARWdZRMZfVzJPAo2+? =?us-ascii?q?YIUSAeQBOuVWoIbhqFUJsRuzHhOsCP/gyjJQmHP6wa833uI8Gg/GxgwgGNcOvW? =?us-ascii?q?zaoNvvLqgSTOS1x7TGwzrdcvhbxDb955bGfhs8pvyMRah/cdfVyUU1CgzKkE+c? =?us-ascii?q?ppfkPzyLzekNqGub7upmVe2xl24rsRp+rSa2y8oql4LHiIUVylXe+iV4xoY4Pd? =?us-ascii?q?O4SElmYd6iDJtfrSCaN414Q8w4WWFnpjw2xaEBuZ6+ZCQF05AnxxnQa/yca4iI? =?us-ascii?q?5Q7jWPyNLjd/gXJpYLK+iAyy8Uinze3wTNW70FFPriZdidnDqmoC1wLJ5ciDTf? =?us-ascii?q?t9+F2t1i2R2A3V9+pKIlg0mLLYJpMj2LI9l5UevV7eEiPqhUn6lrKae0Ul9+Wu? =?us-ascii?q?9u/peK/ppoWGOI9xkgz+N6MuldGhDukgKQgOWnSb+fy71L3+4U31WLVKgeMykq? =?us-ascii?q?neqJ3UP94UprO9AwFPzIsv8xe/DzG439QEhXQKL1BIdAiGgoXmIV3CPez0Aeql? =?us-ascii?q?j1ixkDpmxujKPrj7DZXMKnjDnq3hfbF460NE0Ao8181f55ZOBr4cPv3/QFT+tN? =?us-ascii?q?3GARIiKAy0wObmCNNj2YMCQ26AGbGWPLvIsVCU/uIvP/WMZIgNtTnhLPgl4ubu? =?us-ascii?q?gmUimV8GZKWpwIAXZ26iHvR9OEiYYWDjgtcGEWcNsQo+VuvqiECaUT5IfXq9Q6? =?us-ascii?q?U85jRoQL+gFprJE4Wkgbid23WwGZhOb3tdT02XHG3zMpiCQOoGcymII8Vsui0N? =?us-ascii?q?Vb+mRJUmyAm18gT9zu18M+DW9yYE4K/lz8V//ObJlBs/pgFyFNmXhmGRU3lvzC? =?us-ascii?q?RPRjk42+ZuqEx6zRGI1q0/h/FXHNgU+ugOQw46Mpmb0vB9EJfuVxjEZZDadFHz? =?us-ascii?q?Ft6hBCk4Vcl03sQDeV1VCtyiiRfMxS23G6RTnLuOUs8O/7rYzkT2cpJlwmvCkq? =?us-ascii?q?UsyVMnT+NUNnygi7I5/QWFVKDTlEDM3Z6jaKBU8COF3maOhyLapEhFVEh8XOPP? =?us-ascii?q?XH03fUjHq9nloEnPGez9QY87OxdMnJbRYpBBbcfk2AkXSQ==?Date: Wed, 7 Mar 2018 23:02:33 +0100 Subject: RE: Re[2]: [compass-users] (unknown) From: "Paul De Bie" You�?Tre welcome Larry. I had the same problem but guessed that it was because of the Russian characterset. I renamed the dat file in �?otest.dat�?? and so I could open it dY~S Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 10:56 PM Subject: RE: Re[2]: [compass-users] (unknown) Thanks Paul, That saves me a lot of work. I had trouble extracting the file from the archive and even when I finally extracted the files, they appeared to be empty. I was in the process of finding another program to extract the files when your email came in. To expand on what Paul said, the Compass Viewer will display the angles as degrees. If you�?Tve entered the angles as Grads, they won�?Tt match. Just to be clear on what this means: Degrees is a way of measuring angles that divides a circle into 360 increments. Gradians or Grads, is another way of measuring angles that divides a circle up into 400 increments. In the US it is rare to see Grads used for cave surveying. They were sometimes used in the early days of US cave exploring because you could buy high-quality, military-surplus compass for low prices. The way to fix this depends on what actually happened: 1. If you actually meant to enter grads, then they won�?Tt match, even though the plot will be correct. For the time being, you should just ignore the discrepancy. (I probably should allow for other units, but it is very rare for any one to use something other than degrees.) 2. If you meant to enter degrees, but had the Editor set to Grads, then you will have to convert data. The Editor has tools to help with this. Here is a link to documentation on how to use these tools: http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repair.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repaircompass.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repairinclination.htm Let me know if you have any other questions. Larry _____ From: [email protected] [mailto:[email protected]] Sent: Wednesday, March 07, 2018 2:29 PM Subject: RE: Re[2]: [compass-users] (unknown) Hi, Azimuths and inclinations are configured as GRADS (400 / 100) in your DAT file. I guess that in your other survey program (VTopo ?) they are configured as DEGREES (360 / 90). Which gives you +/- the difference you are seeing�?� HTH Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 9:41 PM Subject: Re[2]: [compass-users] (unknown) Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't present on it here, something another.????? Thanks for the help. D��?D�D'D�, 7 D�D��?�,D� 2018, 12:05 +03:00 D_�, 'Larry' [email protected] [compass-users] : Thanks for your question. There are several things that can cause Compass to display different measurement values in the �?oViewer�?? than what you entered n the �?oEditor.�?? Without looking at the actual data, I wouldn�?Tt know with certainty, but here are some ideas: 1. If the shot is a part of a loop and the �?oClose�?? option is enabled, Compass will adjust the data to compensate for any errors in the loop. Depending on the size of the loop error, the values can be changed a relatively large amount.. 2. If the shot is a part of a loop and the �?oClose�?? option is not enabled, you may still see changed values in the plot. This is because when loops aren�?Tt closed, all the errors fall on the last shot in the loop. In that case, there may be very large changes to that last shot. 3. Other things like declination values and UTM grid alignment can change the values seen in the Viewer. However, they only cause changes in the Compass angle and since you seeing changes in all three measurements, I doubt that is the cause. If you can give me more detailed information about the data, I may be able to give you a more accurate answer. Larry Fish _____ From: [email protected] [mailto:[email protected] ] Sent: Wednesday, March 07, 2018 1:11 AM lto%253acompass%[email protected] Subject: [compass-users] (unknown) Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com from=bk.ru; domainkeys=neutral (no sig); from=bk.ru; dkim=pass (ok) Date: Thu, 08 Mar 2018 17:47:02 +0300 Authentication-Results: f469.i.mail.ru; auth=pass [email protected] [email protected] Subject: =?UTF-8?B?UmVbNF06IFtjb21wYXNzLXVzZXJzXSAodW5rbm93bik=?From: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JDQutC40LzQvtCy?= Thanks my friends. I will try to understand.A� DD�,D�D�?D3, 8 D�D��?�,D� 2018, 1:02 +03:00 D_�, 'Paul De Bie' [email protected] [compass-users] : A� You�?Tre welcome Larry. I had the same problem but guessed that it was because of the Russian characterset. I renamed the dat file in �?otest.dat�?? and so I could open it dY~S A� Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 10:56 PM To: [email protected] Subject: RE: Re[2]: [compass-users] (unknown) A� Thanks Paul, That saves me a lot of work. I had trouble extracting the file from the archive and even when I finally extracted the files, they appeared to be empty. I was in the process of finding another program to extract the files when your email came in. To expand on what Paul said, the Compass Viewer will display the angles as degrees. If you�?Tve entered the angles as Grads, they won�?Tt match. Just to be clear on what this means: Degrees is a way of measuring angles that divides a circle into 360 increments. Gradians or Grads, is another way of measuring angles that divides a circle up into 400 increments. In the US it is rare to see Grads used for cave surveying. They were sometimes used in the early days of US cave exploring because you could buy high-quality, military-surplus compass for low prices. A�A� A� The way to fix this depends on what actually happened: 1. If you actually meant to enter grads, then they won�?Tt match, even though the plot will be correct. For the time being, you should just ignore the discrepancy. (I probably should allow for other units, but it is very rare for any one to use something other than degrees.) 2. If you meant to enter degrees, but had the Editor set to Grads, then you will have to convert data. The Editor has tools to help with this. Here is a link to documentation on how to use these tools: http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repair.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repaircompass.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repairinclination.htm Let me know if you have any other questions. A� Larry A� A� A� A� A� A� A� ---------------------------------------------------------------------- From: [email protected] [ mailto:[email protected] ] Sent: Wednesday, March 07, 2018 2:29 PM To: [email protected] Subject: RE: Re[2]: [compass-users] (unknown) A� A� Hi, A� Azimuths and inclinations are configured as GRADS (400 / 100) in your DAT file. I guess that in your other survey program (VTopo ?) they are configured as DEGREESA� (360 / 90). Which gives you +/- the difference you are seeing�?� A� A� A� HTH A� Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 9:41 PM To: [email protected] Subject: Re[2]: [compass-users] (unknown) A� A� Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't present on it here, something another.????? Thanks for the help.A� D��?D�D'D�, 7 D�D��?�,D� 2018, 12:05 +03:00 D_�, 'Larry' [email protected] [compass-users] : A� Thanks for your question. There are several things that can cause Compass to display different measurement values in the �?oViewer�?? than what you entered n the �?oEditor.�?? Without looking at the actual data, I wouldn�?Tt know with certainty, but here are some ideas: 1. If the shot is a part of a loop and the �?oClose�?? option is enabled, Compass will adjust the data to compensate for any errors in the loop. Depending on the size of the loop error, the values can be changed a relatively large amount... 2. If the shot is a part of a loop and the �?oClose�?? option is not enabled, you may still see changed values in the plot. This is because when loops aren�?Tt closed, all the errors fall on the last shot in the loop. In that case, there may be very large changes to that last shot. 3. Other things like declination values and UTM grid alignment can change the values seen in the Viewer. However, they only cause changes in the Compass angle and since you seeing changes in all three measurements, I doubt that is the cause. If you can give me more detailed information about the data, I may be able to give you a more accurate answer. Larry Fish A� ---------------------------------------------------------------------- From: [email protected] [mailto: [email protected] ] Sent: Wednesday, March 07, 2018 1:11 AM To: [email protected] Subject: [compass-users] (unknown) A� A� Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com from=bk.ru; domainkeys=neutral (no sig); from=bk.ru; dkim=pass (ok) Date: Fri, 09 Mar 2018 20:20:24 +0300 Authentication-Results: f493.i.mail.ru; auth=pass [email protected] [email protected] Subject: =?UTF-8?B?UmVbNF06IFtjb21wYXNzLXVzZXJzXSAodW5rbm93bik=?From: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JDQutC40LzQvtCy?= Thanks friends, at me everything turned out, only corners of inclinations had in manual to be copied - the table of changes of values of inclinations works not correctly. It not terribly isn't a lot of pickets.A� DD�,D�D�?D3, 8 D�D��?�,D� 2018, 1:02 +03:00 D_�, 'Paul De Bie' [email protected] [compass-users] : A� You�?Tre welcome Larry. I had the same problem but guessed that it was because of the Russian characterset. I renamed the dat file in �?otest.dat�?? and so I could open it dY~S A� Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 10:56 PM To: [email protected] Subject: RE: Re[2]: [compass-users] (unknown) A� Thanks Paul, That saves me a lot of work. I had trouble extracting the file from the archive and even when I finally extracted the files, they appeared to be empty. I was in the process of finding another program to extract the files when your email came in. To expand on what Paul said, the Compass Viewer will display the angles as degrees. If you�?Tve entered the angles as Grads, they won�?Tt match. Just to be clear on what this means: Degrees is a way of measuring angles that divides a circle into 360 increments. Gradians or Grads, is another way of measuring angles that divides a circle up into 400 increments. In the US it is rare to see Grads used for cave surveying. They were sometimes used in the early days of US cave exploring because you could buy high-quality, military-surplus compass for low prices. A�A� A� The way to fix this depends on what actually happened: 1. If you actually meant to enter grads, then they won�?Tt match, even though the plot will be correct. For the time being, you should just ignore the discrepancy. (I probably should allow for other units, but it is very rare for any one to use something other than degrees.) 2. If you meant to enter degrees, but had the Editor set to Grads, then you will have to convert data. The Editor has tools to help with this. Here is a link to documentation on how to use these tools: http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repair.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repaircompass.htm http://www.fountainware.com/compass/HTML_Help/Compass_Editor/repairinclination.htm Let me know if you have any other questions. A� Larry A� A� A� A� A� A� A� ---------------------------------------------------------------------- From: [email protected] [ mailto:[email protected] ] Sent: Wednesday, March 07, 2018 2:29 PM To: [email protected] Subject: RE: Re[2]: [compass-users] (unknown) A� A� Hi, A� Azimuths and inclinations are configured as GRADS (400 / 100) in your DAT file. I guess that in your other survey program (VTopo ?) they are configured as DEGREESA� (360 / 90). Which gives you +/- the difference you are seeing�?� A� A� A� HTH A� Paul De Bie http://www.scavalon.be http://scavalon.blogspot.com From: [email protected] Sent: Wednesday, March 7, 2018 9:41 PM To: [email protected] Subject: Re[2]: [compass-users] (unknown) A� A� Larry Fish, in each shot an azimuth has a deviation of 28 degrees, and a tilt angle 3,5 degrees bigger. It is long shots doesn't change. Rings aren't present on it here, something another.????? Thanks for the help.A� D��?D�D'D�, 7 D�D��?�,D� 2018, 12:05 +03:00 D_�, 'Larry' [email protected] [compass-users] : A� Thanks for your question. There are several things that can cause Compass to display different measurement values in the �?oViewer�?? than what you entered n the �?oEditor.�?? Without looking at the actual data, I wouldn�?Tt know with certainty, but here are some ideas: 1. If the shot is a part of a loop and the �?oClose�?? option is enabled, Compass will adjust the data to compensate for any errors in the loop. Depending on the size of the loop error, the values can be changed a relatively large amount... 2. If the shot is a part of a loop and the �?oClose�?? option is not enabled, you may still see changed values in the plot. This is because when loops aren�?Tt closed, all the errors fall on the last shot in the loop. In that case, there may be very large changes to that last shot. 3. Other things like declination values and UTM grid alignment can change the values seen in the Viewer. However, they only cause changes in the Compass angle and since you seeing changes in all three measurements, I doubt that is the cause. If you can give me more detailed information about the data, I may be able to give you a more accurate answer. Larry Fish A� ---------------------------------------------------------------------- From: [email protected] [mailto: [email protected] ] Sent: Wednesday, March 07, 2018 1:11 AM To: [email protected] Subject: [compass-users] (unknown) A� A� Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a D�D,D�D�,D�DD��
Authentication-Results: mta1005.groups.mail.ne1.yahoo.com from=yahoogroups.com; domainkeys=neutral (no sig); from=yahoogroups.com; dkim=permerror (bad sig) Date: 10 Apr 2018 04:12:14 +0000 Subject: Please send me 3D files and several datas of Lechuguilla cave From: [email protected] Hi Everyone I am a student attending Kookmin University in Seoul, Korea. I major in space design. This semester's project is creating space through natural phenomena. My team, while studying the natural phenomena across the United States, chose this site after seeing the mysteries of the Lechuguilla cave. Further investigation will require internal detailed modelling. It would be great if you could send me 3D files and several datas of Lechuguilla cave. Any extension names are fine. It will be used for academic purposes, and there is no need to worry about distribution. Sincerely, Taeyoung plj
Authentication-Results: mta1006.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok) Date: Tue, 10 Apr 2018 05:33:13 -0600 Subject: RE: [compass-users] Please send me 3D files and several datas of Lechuguilla cave From: "Larry" Taeyoung, Lechuguilla Cave data is the property the United States Park Service and Carlsbad Cavern Nation Park and they are the only ones who can provide that data. You will need to contact them with your request. There is a contact form on this web page. https://www.nps.gov/cave/contacts.htm Let me know if you have any other questions. Larry Fish _____ From: [email protected] [mailto:[email protected]] Sent: Monday, April 09, 2018 10:12 PM Subject: [compass-users] Please send me 3D files and several datas of Lechuguilla cave Hi Everyone I am a student attending Kookmin University in Seoul, Korea. I major in space design. This semester's project is creating space through natural phenomena. My team, while studying the natural phenomena across the United States, chose this site after seeing the mysteries of the Lechuguilla cave. Further investigation will require internal detailed modelling. It would be great if you could send me 3D files and several datas of Lechuguilla cave. Any extension names are fine. It will be used for academic purposes, and there is no need to worry about distribution. Sincerely, M�����
Authentication-Results: mta1003.groups.mail.bf1.yahoo.com from=yahoo.com; domainkeys=neutral (no sig); from=yahoo.com; dkim=pass (ok) Date: Mon, 7 May 2018 15:04:02 +0000 (UTC) Content-Length: 971 Subject: DEM questions From: Tom Larry, Does the DEM program to use in Compass ONLY accept 7.5 minute or 15 minute quads? I have a dem made from lidar data of irregular size that doesn't seem to load. I'm using QGIS to create the DEM. Does projection matter? WGS84 thanks,Tom Larry,Does the DEM program to use in Compass ONLY accept 7.5 minute or 15 minute quads? I have a dem made from lidar data of irregular size that doesn't seem to load. I'm using QGIS to create the DEM. Does projection matter? WGS84thanks,Tom
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Tue, 8 May 2018 04:11:06 -0600
Subject: RE: [compass-users] DEM questions
From: "Larry"
Tom,
The DEM Reader in Compass will accept other sizes besides 7.5 and 15 minute.
However the devil is in the details:
1. The Compass DEM reader only reads DEM files that use the USGS format.
There are other DEM Formats, but Compass doesn't support them:
https://en.wikipedia.org/wiki/USGS_DEM
2. The USGS DEM format is very ridged and any errors in the format will
cause errors reading and displaying the DEM data.
3. With non-standard DEM files, there's a high probability that there will
be errors in the data. The Compass DEM reader attempts to resolve these
types of errors. It can solve many problems, however if the errors are bad,
it may not be able to fix them.
4. The easiest way to know if a DEM file will work is to load it into the
DEM reader and see what happens.
Let me know if you have any other questions.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Monday, May 07, 2018 9:04 AM
Subject: [compass-users] DEM questions
Larry,
Does the DEM program to use in Compass ONLY accept 7.5 minute or 15 minute
quads? I have a dem made from lidar data of irregular size that doesn't seem
to load. I'm using QGIS to create the DEM. Does projection matter? WGS84
thanks,
Tom
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta1006.groups.mail.bf1.yahoo.com from=yahoo.com; domainkeys=neutral (no sig); from=yahoo.com; dkim=pass (ok)
Date: Wed, 9 May 2018 02:49:26 +0000 (UTC)
Content-Length: 12010
Subject: Re: RE: [compass-users] DEM questions
From: Tom
Ok, I found the comamnd syntax, will try it.
gdal_translate -of USGSDEM .dem
On Tuesday, May 8, 2018, 3:12:01 AM PDT, 'Larry' [email protected] [compass-users] wrote:
Tom,
The DEM Reader in Compass will accept other sizes besides7.5 and 15 minute. However the devil is in the details:
1. The Compass DEM reader only reads DEM files that use theUSGS format. There are other DEM Formats, but Compass doesn�?Tt supportthem:
https://en.wikipedia.org/wiki/USGS_DEM
2. The USGS DEM format is very ridged and any errors in theformat will cause errors reading and displaying the DEM data.
3. With non-standard DEM files, there�?Ts a highprobability that there will be errors in the data. The Compass DEM readerattempts to resolve these types of errors. It can solve many problems, howeverif the errors are bad, it may not be able to fix them.
4. The easiest way to know if a DEM file will work is toload it into the DEM reader and see what happens.
Let me know if you have any other questions.
Larry
A�
From: [email protected] [mailto: [email protected] ]
Sent: Monday, May 07, 2018 9:04 AM
Subject: [compass-users] DEMquestions
A�
A�
Larry,
A�
Does the DEM program to use in Compass ONLY accept 7.5minute or 15 minute quads? I have a dem made from lidar data of irregular sizethat doesn't seem to load. I'm using QGIS to create the DEM. Does projectionmatter? WGS84
A�
thanks,
Tom
Ok, I found the comamnd syntax, will try it.gdal_translate -of USGSDEM <inputfile> <outputfile>.dem
On Tuesday, May 8, 2018, 3:12:01 AM PDT, 'Larry' [email protected] [compass-users] <[email protected]> wrote:
Tom,
The DEM Reader in Compass will accept other sizes besides
7.5 and 15 minute. However the devil is in the details:
1. The Compass DEM reader only reads DEM files that use the
USGS format. There are other DEM Formats, but Compass doesn�?Tt support
them:
https://en.wikipedia.org/wiki/USGS_DEM
2. The USGS DEM format is very ridged and any errors in the
format will cause errors reading and displaying the DEM data.
3. With non-standard DEM files, there�?Ts a high
probability that there will be errors in the data. The Compass DEM reader
attempts to resolve these types of errors. It can solve many problems, however
if the errors are bad, it may not be able to fix them.
4. The easiest way to know if a DEM file will work is to
load it into the DEM reader and see what happens.
Let me know if you have any other questions.
Larry
From: [email protected] [mailto: [email protected] ]
Sent: Monday, May 07, 2018 9:04 AM
To: Yahoogroups
Subject: [compass-users] DEM
questions
Larry,
Does the DEM program to use in Compass ONLY accept 7.5
minute or 15 minute quads? I have a dem made from lidar data of irregular size
that doesn't seem to load. I'm using QGIS to create the DEM. Does projection
matter? WGS84
thanks,
Tom
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com from=r-schuster.de; domainkeys=neutral (no sig); from=r-schuster.de; dkim=neutral (no sig) Date: Sun, 20 May 2018 10:21:30 +0200 Subject: Integer Overflow From: Roger Schuster Hello all, yesterday I updated to the latest version of compass and since then I cannot process any survey data. When I open a file (it does not matter if it is a DAT or MAK file) in "Project Manager" and press "Process and View Cave" I will get an error message saying "Integer Overflow". I also tried with some surveys from U.S. caves Larry gave to me; same result. I guess the files are fine and the problem has something to do with locales (I run Windows 10 with German locale, set to use the metric system and decimal comma). Best regards, Roger
Authentication-Results: mta1005.groups.mail.ne1.yahoo.com from=r-schuster.de; domainkeys=neutral (no sig); from=r-schuster.de; dkim=neutral (no sig) Date: Sun, 20 May 2018 10:34:43 +0200 Subject: Re: [compass-users] Integer Overflow From: Roger Schuster Hello again, an important note: When I try to work on a survey which I had processed in the past (with an older version of Compass), the existing PLT file will become damaged! After the Integer Overflow error the PLT contains 138 Bytes of data only. Roger Am Sun, 20 May 2018 10:21:30 +0200 schrieb "Roger Schuster [email protected] [compass-users]" : Hello all, yesterday I updated to the latest version of compass and since then I cannot process any survey data. When I open a file (it does not matter if it is a DAT or MAK file) in "Project Manager" and press "Process and View Cave" I will get an error message saying "Integer Overflow". I also tried with some surveys from U.S. caves Larry gave to me; same result. I guess the files are fine and the problem has something to do with locales (I run Windows 10 with German locale, set to use the metric system and decimal comma). Best regards, Roger
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Sun, 20 May 2018 03:22:19 -0600
Subject: RE: [compass-users] Integer Overflow
From: "Larry"
Hi Roger,
By coincidence, I happened to be working on the Project Manager when your
email came in and I've already found the problem.
My first thought was that it was the "decimal point/comma problem," but it
turned out to be something completely different. I had been debugging some
code last week and I had turned on a debug flag that checks for integer
overflows. When I went to process Compass, there were still libraries that
had overflow checking enabled. When Compass processed a survey file it got
an overflow error in some "Hash" routines that are *supposed* to overflow.
Rebuilding the libraries fixed the problem.
I've put a new copy of Compass on the internet. Check it out and see if it
solves your problems.
I'm currently working on some other improvements and fixes to the Project
Manager. I suspect I will be posting another new version tomorrow.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Sunday, May 20, 2018 2:35 AM
Subject: Re: [compass-users] Integer Overflow
Hello again,
an important note: When I try to work on a survey which I had processed
in the past (with an older version of Compass), the existing PLT file
will become damaged! After the Integer Overflow error the PLT contains
138 Bytes of data only.
Roger
Am Sun, 20 May 2018 10:21:30 +0200
schrieb "Roger Schuster [email protected] [compass-users]"
:
Hello all,
yesterday I updated to the latest version of compass and since then I
cannot process any survey data. When I open a file (it does not matter
if it is a DAT or MAK file) in "Project Manager" and press "Process
and View Cave" I will get an error message saying "Integer Overflow".
I also tried with some surveys from U.S. caves Larry gave to me; same
result. I guess the files are fine and the problem has something to
do with locales (I run Windows 10 with German locale, set to use the
metric system and decimal comma).
Best regards,
Roger
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta1002.groups.mail.ne1.yahoo.com from=r-schuster.de; domainkeys=neutral (no sig); from=r-schuster.de; dkim=neutral (no sig) Date: Sun, 20 May 2018 12:06:15 +0200 Subject: Re: [compass-users] Integer Overflow From: Roger Schuster Hi Larry, good news, the new version is working again. Thank you very much for the quick response! Regards, Roger Am Sun, 20 May 2018 03:22:19 -0600 schrieb "'Larry' [email protected] [compass-users]" : Hi Roger, By coincidence, I happened to be working on the Project Manager when your email came in and I've already found the problem. My first thought was that it was the "decimal point/comma problem," but it turned out to be something completely different. I had been debugging some code last week and I had turned on a debug flag that checks for integer overflows. When I went to process Compass, there were still libraries that had overflow checking enabled. When Compass processed a survey file it got an overflow error in some "Hash" routines that are *supposed* to overflow. Rebuilding the libraries fixed the problem. I've put a new copy of Compass on the internet. Check it out and see if it solves your problems. I'm currently working on some other improvements and fixes to the Project Manager. I suspect I will be posting another new version tomorrow. Larry _____ From: [email protected] [mailto:[email protected]] Sent: Sunday, May 20, 2018 2:35 AM To: [email protected] Subject: Re: [compass-users] Integer Overflow Hello again, an important note: When I try to work on a survey which I had processed in the past (with an older version of Compass), the existing PLT file will become damaged! After the Integer Overflow error the PLT contains 138 Bytes of data only. Roger Am Sun, 20 May 2018 10:21:30 +0200 schrieb "Roger Schuster [email protected] [compass-users]" : Hello all, yesterday I updated to the latest version of compass and since then I cannot process any survey data. When I open a file (it does not matter if it is a DAT or MAK file) in "Project Manager" and press "Process and View Cave" I will get an error message saying "Integer Overflow". I also tried with some surveys from U.S. caves Larry gave to me; same result. I guess the files are fine and the problem has something to do with locales (I run Windows 10 with German locale, set to use the metric system and decimal comma). Best regards, Roger
Authentication-Results: mta4002.groups.mail.ne1.yahoo.com from=ronmiller.net; domainkeys=neutral (no sig); from=ronmiller.net; dkim=pass (ok) Date: Tue, 10 Jul 2018 12:39:43 -0400 Subject: Problem printing/creating a file of blundered loops From: Ron Miller When I use the "Print" or "File" button at the bottom of the "Find Blundered Loops" page in the Project Manager, the resulting file / printout only contains information for the first loop in the list. I am using the current version (5.18.6.29.216). I have tried multiple survey files, including the Fulfords.dat file, with the same result. I tried selecting multiple loops, but that functionality does not appear to exist. Am I missing something obvious? Thanks for your help! Ron Miller
Authentication-Results: mta4002.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Tue, 10 Jul 2018 19:44:11 -0600
Subject: RE: [compass-users] Problem printing/creating a file of blundered loops
From: "Larry"
Hi Ron,
Thanks for your email. The way that feature works, you have to select one
survey from the list. Next, you press the "Analyze Loop" button. Finally,
you can press the "Print" or "File" button. This will print or save all the
blunder information for that one survey.
If you want to print or save a list of all the loops in the cave like
appears on the first page of the Blunder Tool, select the "View-Cave
Statistics" option from the menu bar. Next, select the "Loop Errors" option.
This will show a list of all of the loops in the cave along with the all the
same error information.
Let me know if that solve the problem.
Larry Fish
_____
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, July 10, 2018 10:40 AM
Subject: [compass-users] Problem printing/creating a file of blundered loops
When I use the "Print" or "File" button at the bottom of the "Find
Blundered Loops" page in the Project Manager, the resulting file /
printout only contains information for the first loop in the list. I am
using the current version (5.18.6.29.216). I have tried multiple survey
files, including the Fulfords.dat file, with the same result.
I tried selecting multiple loops, but that functionality does not appear
to exist.
Am I missing something obvious?
Thanks for your help!
Ron Miller
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta4000.groups.mail.ne1.yahoo.com from=ronmiller.net; domainkeys=neutral (no sig); from=ronmiller.net; dkim=pass (ok) Date: Wed, 11 Jul 2018 15:39:29 -0400 Subject: Re: Problem printing/creating a file of blundered loops From: Ron Miller Thanks, Larry. I was led astray by my misinterpretation of the help file, which indicates that you can "print or save to disk the currently displayed blunder information". I interpreted that to mean the entire displayed list of blundered loops, rather than the selected loop. If you'd like to make the help file less ambiguous, it could perhaps be written as "print or save to disk the blunder information for the currently selected loop". What I was trying to accomplish was to figure out how edits to survey files in Lechuguilla Cave affected the number of bad loops. So I wanted to be able to compare the compact blundered loop lists in the Find Blundered Loops page before and after changes. Unfortunately, the file created from the Loop Errors page in Cave Statistics is not conducive to simply importing that compact, spreadsheet-style list into Excel. I ultimately accomplished my objective by taking screencaps of the lists, converting them to PDF, running OCR, and then pasting the lists into Excel. But this exercise appears to have revealed another aspect of Compass, which I am hoping that you might be able to help me understand and minimize its effect. Changing the survey order in the DAT file (using the Manipulate Surveys function) can change the number of bad loops. For a cave like Lech where we are constantly resurveying to fix old blunders and then "X"ing out old shots, this is concerning to me. Can you help me understand why this would be the case, and what if anything can be done to minimize the effect of survey order to the loop closure error algorithm? If it would be helpful, I would be happy to send you two files that demonstrate this behavior. Also, while I'm at it, two (hopefully minor) requests for the next release: - Now that we are firmly in the DistoX age, it would be awesome if you could add a second distance field in the backsights section (and maybe change the names from "Tape" to "Dist1" and "Dist2" now that fiberglass measuring tapes are being supplanted by DistoXs and other laser distance measuring tools). DistoXs are awesome, but unlike measuring tapes, they are definitely prone to significant distance errors if the laser strays off the target (or partially encounters an obstruction). Our data-entry sheets for Lech now include a box for backsight distances to help catch these errors, but there is currently no way to enter these measurements in Compass. - It would also be great if you could increase the maximum character length in the Shot Comment field from 160 characters to at least 320 characters. We are using this field to help track changes, and having more characters to document those changes (and the rationale) would be very helpful! Thanks again for your excellent software! Ron
Authentication-Results: mta4002.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Wed, 11 Jul 2018 15:02:01 -0600
Subject: RE: [compass-users] Re: Problem printing/creating a file of blundered loops
From: "Larry"
Ron,
Thanks for you email.
Changing the survey order in the DAT file (using the
Manipulate Surveys function) can change the number of bad
loops.
When Compass looks for blunders, it processes loops in the order they were
surveyed. For example, in this survey:
A ------- B ------ C
| | |
| | |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
However, only two of the loops are necessary to encompass all the shots in
the loops. As a result, Compass will only use two of the possible loops in
its data processing. Which loop depends on the survey order.
If the cave was surveyed in this order:
A,B,C,D,E,F,A
B,E
Compass will see loops 1 and 2. If the cave was surveyed in this order:
A,B,E,F,A
B,C,D,E,B
Compass will see loops 2 and 3.
None of this matters for loop closures, because closing loops is a matter of
distributing the error across all adjacent surveys.
However, for blunder detection, the order will change where the errors
appear. But even that doesn't matter much. Where the errors appears is
unimportant because the error will still always show up somewhere and that
is what Compass needs to help find the error.
Let me explain:
If shot B--E has a blunder in it, the order of the surveys will make a
difference as to what the blunder tools sees. If Compass sees loops 1 and 2,
only loop 2 will contain the error. On the other hand, if Compass sees loop
2 and 3, both loops will have the error in it.
In either case, Compass will see the blunder and the blunder tools will be
able to find possible locations for the blunder.
All this gets into a complicated discussion about what are optimal loops. I
wrote a document on the finding optimal loops that you can find here:
http://www.fountainware.com/compass/Documents/FindingLoops/FindingLoops.html
It would also be great if you could increase the maximum
character length in the Shot Comment field from 160
characters to at least 320 characters.
Actually, the current length of Shot Comments is 255 characters. (Apparently
the 160 character limit is still in the documentation somewhere).
However, many of these limits don't actually apply because Compass now uses
expandable strings that can be up to 2-gigabytes long. In the case of the
survey comments, I just tested them by entering a 400 characters
shot-comment and I was able to save and reload it with no lost characters.
There may be a few places where the 255 character limit applies, but the
fact that I was able to save and load long comments means won't lose any
characters so you're safe to use longer comments.
it would be awesome if you could add a second distance field
in the backsights section (and maybe change the names from
"Tape" to "Dist1" and "Dist2"
I agree and I'm working on a bunch of changes to accommodate the new
surveying tools like the Disto. Basically, I'm working on a major rewrite of
Compass that will add a much more flexible data format that will make it
easy to add new features like the Disto data. It would be best to defer the
Disto features to the new version.
One caveat: as people will attest, I've been working on this new version of
Compass for years (decades) and although I have most of the pieces written,
I have trouble get enough free time from work to finish it up. As a result,
the free time I do have is devoted to fixing bugs and incrementally adding
new features to the existing version.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 11, 2018 1:39 PM
Subject: [compass-users] Re: Problem printing/creating a file of blundered
loops
Thanks, Larry. I was led astray by my misinterpretation of the help
file, which indicates that you can "print or save to disk the currently
displayed blunder information". I interpreted that to mean the entire
displayed list of blundered loops, rather than the selected loop. If
you'd like to make the help file less ambiguous, it could perhaps be
written as "print or save to disk the blunder information for the
currently selected loop".
What I was trying to accomplish was to figure out how edits to survey
files in Lechuguilla Cave affected the number of bad loops. So I wanted
to be able to compare the compact blundered loop lists in the Find
Blundered Loops page before and after changes. Unfortunately, the file
created from the Loop Errors page in Cave Statistics is not conducive to
simply importing that compact, spreadsheet-style list into Excel. I
ultimately accomplished my objective by taking screencaps of the lists,
converting them to PDF, running OCR, and then pasting the lists into Excel.
But this exercise appears to have revealed another aspect of Compass,
which I am hoping that you might be able to help me understand and
minimize its effect. Changing the survey order in the DAT file (using
the Manipulate Surveys function) can change the number of bad loops. For
a cave like Lech where we are constantly resurveying to fix old blunders
and then "X"ing out old shots, this is concerning to me. Can you help me
understand why this would be the case, and what if anything can be done
to minimize the effect of survey order to the loop closure error
algorithm? If it would be helpful, I would be happy to send you two
files that demonstrate this behavior.
Also, while I'm at it, two (hopefully minor) requests for the next release:
- Now that we are firmly in the DistoX age, it would be awesome if you
could add a second distance field in the backsights section (and maybe
change the names from "Tape" to "Dist1" and "Dist2" now that fiberglass
measuring tapes are being supplanted by DistoXs and other laser distance
measuring tools). DistoXs are awesome, but unlike measuring tapes, they
are definitely prone to significant distance errors if the laser strays
off the target (or partially encounters an obstruction). Our data-entry
sheets for Lech now include a box for backsight distances to help catch
these errors, but there is currently no way to enter these measurements
in Compass.
- It would also be great if you could increase the maximum character
length in the Shot Comment field from 160 characters to at least 320
characters. We are using this field to help track changes, and having
more characters to document those changes (and the rationale) would be
very helpful!
Thanks again for your excellent software!
Ron
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta4001.groups.mail.bf1.yahoo.com from=gmail.com; domainkeys=neutral (no sig); from=gmail.com; dkim=pass (ok) Date: Wed, 11 Jul 2018 15:28:22 -0600 Subject: Re: [compass-users] Re: Problem printing/creating a file of blundered loops From: Derek Bristol Hi Larry, Since you brought up the fact that survey order affects loop identification, I have a question that's bothered me for some time. It seems that changing the order of the surveys may change the location of stations following loop closure. If I understand your algorithm for loop closure correctly, the best loops are closed first, and then these stations are fixed. This should only matter for multi-loops (i.e. interconnected loops). But if the survey order is changed, and the number and relative quality of loops then changes, then the loop closure order may change, and thus the location of stations. The result is that two sets of identical survey data, with no other difference but the order of the surveys, may end up with a different line plot. I've been meaning to test that out but haven't found the time. Perhaps the algorithm for loop closure drives that to happen, but it feels like it shouldn't make a difference what order the surveys are in... the closed loop data should put the stations in the same location. Derek Bristol On Wed, Jul 11, 2018 at 3:02 PM, 'Larry' [email protected] [compass-users] wrote: Ron, Thanks for you email. Changing the survey order in the DAT file (using the Manipulate Surveys function) can change the number of bad loops. When Compass looks for blunders, it processes loops in the order they were surveyed. For example, in this survey: *A ------- B ------ C* *| | |* *| | |* *F---------E--------D* There are three possible loops. 1 = A,B,C,D,E,F,A 2 = A,B,E,F,A 3 = B,C,D,E,B However, only two of the loops are necessary to encompass all the shots in the loops. As a result, Compass will only use two of the possible loops in its data processing. Which loop depends on the survey order. If the cave was surveyed in this order: A,B,C,D,E,F,A B,E Compass will see loops 1 and 2. If the cave was surveyed in this order: A,B,E,F,A B,C,D,E,B Compass will see loops 2 and 3. None of this matters for loop closures, because closing loops is a matter of distributing the error across all adjacent surveys. However, for blunder detection, the order will change where the errors appear. But even that doesn't matter much. Where the errors appears is unimportant because the error will still always show up somewhere and that is what Compass needs to help find the error. Let me explain: If shot B--E has a blunder in it, the order of the surveys will make a difference as to what the blunder tools sees. If Compass sees loops 1 and 2, only loop 2 will contain the error. On the other hand, if Compass sees loop 2 and 3, both loops will have the error in it. In either case, Compass will see the blunder and the blunder tools will be able to find possible locations for the blunder. All this gets into a complicated discussion about what are optimal loops. I wrote a document on the finding optimal loops that you can find here: http://www.fountainware.com/compass/Documents/ FindingLoops/FindingLoops.html It would also be great if you could increase the maximum character length in the Shot Comment field from 160 characters to at least 320 characters. Actually, the current length of Shot Comments is 255 characters. (Apparently the 160 character limit is still in the documentation somewhere). However, many of these limits don't actually apply because Compass now uses expandable strings that can be up to 2-gigabytes long. In the case of the survey comments, I just tested them by entering a 400 characters shot-comment and I was able to save and reload it with no lost characters. There may be a few places where the 255 character limit applies, but the fact that I was able to save and load long comments means won�?Tt lose any characters so you're safe to use longer comments. it would be awesome if you could add a second distance field in the backsights section (and maybe change the names from "Tape" to "Dist1" and "Dist2" I agree and I'm working on a bunch of changes to accommodate the new surveying tools like the Disto. Basically, I'm working on a major rewrite of Compass that will add a much more flexible data format that will make it easy to add new features like the Disto data. It would be best to defer the Disto features to the new version. One caveat: as people will attest, I've been working on this new version of Compass for years (decades) and although I have most of the pieces written, I have trouble get enough free time from work to finish it up. As a result, the free time I do have is devoted to fixing bugs and incrementally adding new features to the existing version. Larry ------------------------------ *From:* [email protected] [mailto:compass-users@ yahoogroups.com] *Sent:* Wednesday, July 11, 2018 1:39 PM *To:* [email protected] *Subject:* [compass-users] Re: Problem printing/creating a file of blundered loops Thanks, Larry. I was led astray by my misinterpretation of the help file, which indicates that you can "print or save to disk the currently displayed blunder information". I interpreted that to mean the entire displayed list of blundered loops, rather than the selected loop. If you'd like to make the help file less ambiguous, it could perhaps be written as "print or save to disk the blunder information for the currently selected loop". What I was trying to accomplish was to figure out how edits to survey files in Lechuguilla Cave affected the number of bad loops. So I wanted to be able to compare the compact blundered loop lists in the Find Blundered Loops page before and after changes. Unfortunately, the file created from the Loop Errors page in Cave Statistics is not conducive to simply importing that compact, spreadsheet-style list into Excel. I ultimately accomplished my objective by taking screencaps of the lists, converting them to PDF, running OCR, and then pasting the lists into Excel. But this exercise appears to have revealed another aspect of Compass, which I am hoping that you might be able to help me understand and minimize its effect. Changing the survey order in the DAT file (using the Manipulate Surveys function) can change the number of bad loops. For a cave like Lech where we are constantly resurveying to fix old blunders and then "X"ing out old shots, this is concerning to me. Can you help me understand why this would be the case, and what if anything can be done to minimize the effect of survey order to the loop closure error algorithm? If it would be helpful, I would be happy to send you two files that demonstrate this behavior. Also, while I'm at it, two (hopefully minor) requests for the next release: - Now that we are firmly in the DistoX age, it would be awesome if you could add a second distance field in the backsights section (and maybe change the names from "Tape" to "Dist1" and "Dist2" now that fiberglass measuring tapes are being supplanted by DistoXs and other laser distance measuring tools). DistoXs are awesome, but unlike measuring tapes, they are definitely prone to significant distance errors if the laser strays off the target (or partially encounters an obstruction). Our data-entry sheets for Lech now include a box for backsight distances to help catch these errors, but there is currently no way to enter these measurements in Compass. - It would also be great if you could increase the maximum character length in the Shot Comment field from 160 characters to at least 320 characters. We are using this field to help track changes, and having more characters to document those changes (and the rationale) would be very helpful! Thanks again for your excellent software! Ron Derek Bristol [email protected] (303) 589-4469 (mobile) (303) 284-9360 (home) Hi Larry,Since you brought up the fact that survey order affects loop identification, I have a question that's bothered me for some time.It seems that changing the order of the surveys may change the location of stations following loop closure. If I understand your algorithm for loop closure correctly, the best loops are closed first, and then these stations are fixed. This should only matter for multi-loops (i.e. interconnected loops). But if the survey order is changed, and the number and relative quality of loops then changes, then the loop closure order may change, and thus the location of stations. The result is that two sets of identical survey data, with no other difference but the order of the surveys, may end up with a different line plot. I've been meaning to test that out but haven't found the time. Perhaps the algorithm for loop closure drives that to happen, but it feels like it shouldn't make a difference what order the surveys are in... the closed loop data should put the stations in the same location.Derek BristolOn Wed, Jul 11, 2018 at 3:02 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote: A� Ron, Thanks for you email. > Changing the survey order in the DAT file (using the > Manipulate Surveys function) can change the number of bad > loops. When Compass looks for blunders, it processes loops in the order they were surveyed. For example, in this survey: A ------- B ------ C |A�A�A�A�A�A�A�A� |A�A�A�A�A�A�A� | |A�A�A�A�A�A�A�A� |A�A�A�A�A�A�A� | F---------E--------D There are three possible loops. 1 = A,B,C,D,E,F,A 2 = A,B,E,F,A 3 = B,C,D,E,B However, only two of the loops are necessary to encompass all the shots in the loops. As a result, Compass will only use two of the possible loops in its data processing. Which loop depends on the survey order. If the cave was surveyed in this order: A,B,C,D,E,F,A B,E Compass will see loops 1 and 2. If the cave was surveyed in this order: A,B,E,F,A B,C,D,E,B Compass will see loops 2 and 3. None of this matters for loop closures, because closing loops is a matter of distributing the error across all adjacent surveys. However, for blunder detection, the order will change where the errors appear. But even that doesn't matter much. Where the errors appears is unimportant because the error will still always show up somewhere and that is what Compass needs to help find the error. Let me explain: If shot B-->E has a blunder in it, the order of the surveys will make a difference as to what the blunder tools sees. If Compass sees loops 1 and 2, only loop 2 will contain the error. On the other hand, if Compass sees loop 2 and 3, both loops will have the error in it. In either case, Compass will see the blunder and the blunder tools will be able to find possible locations for the blunder. All this gets into a complicated discussion about what are optimal loops. I wrote a document on the finding optimal loops that you can find here: http://www.fountainware.com/compass/Documents/FindingLoops/FindingLoops.html > It would also be great if you could increase the maximum > character length in the Shot Comment field from 160 > characters to at least 320 characters. Actually, the current length of Shot Comments is 255 characters. (Apparently the 160 character limit is still in the documentation somewhere). However, many of these limits don't actually apply because Compass now uses expandable strings that can be up to 2-gigabytes long. In the case of the survey comments, I just tested them by entering a 400 characters shot-comment and I was able to save and reload it with no lost characters. There may be a few places where the 255 character limit applies, but the fact that I was able to save and load long comments means won�?Tt lose any characters so you're safe to use longer comments. > it would be awesome if you could add a second distance field > in the backsights section (and maybe change the names from > "Tape" to "Dist1" and "Dist2" I agree and I'm working on a bunch of changes to accommodate the new surveying tools like the Disto. Basically, I'm working on a major rewrite of Compass that will add a much more flexible data format that will make it easy to add new features like the Disto data. It would be best to defer the Disto features to the new version. One caveat: as people will attest, I've been working on this new version of Compass for years (decades) and although I have most of the pieces written, I have trouble get enough free time from work to finish it up. As a result, the free time I do have is devoted to fixing bugs and incrementally adding new features to the existing version. Larry A� From: [email protected] [mailto:[email protected]] Sent: Wednesday, July 11, 2018 1:39 PM To: [email protected] Subject: [compass-users] Re: Problem printing/creating a file of blundered loops A� A� Thanks, Larry. I was led astray by my misinterpretation of the help file, which indicates that you can "print or save to disk the currently displayed blunder information". I interpreted that to mean the entire displayed list of blundered loops, rather than the selected loop. If you'd like to make the help file less ambiguous, it could perhaps be written as "print or save to disk the blunder information for the currently selected loop". What I was trying to accomplish was to figure out how edits to survey files in Lechuguilla Cave affected the number of bad loops. So I wanted to be able to compare the compact blundered loop lists in the Find Blundered Loops page before and after changes. Unfortunately, the file created from the Loop Errors page in Cave Statistics is not conducive to simply importing that compact, spreadsheet-style list into Excel. I ultimately accomplished my objective by taking screencaps of the lists, converting them to PDF, running OCR, and then pasting the lists into Excel. But this exercise appears to have revealed another aspect of Compass, which I am hoping that you might be able to help me understand and minimize its effect. Changing the survey order in the DAT file (using the Manipulate Surveys function) can change the number of bad loops. For a cave like Lech where we are constantly resurveying to fix old blunders and then "X"ing out old shots, this is concerning to me. Can you help me understand why this would be the case, and what if anything can be done to minimize the effect of survey order to the loop closure error algorithm? If it would be helpful, I would be happy to send you two files that demonstrate this behavior. Also, while I'm at it, two (hopefully minor) requests for the next release: - Now that we are firmly in the DistoX age, it would be awesome if you could add a second distance field in the backsights section (and maybe change the names from "Tape" to "Dist1" and "Dist2" now that fiberglass measuring tapes are being supplanted by DistoXs and other laser distance measuring tools). DistoXs are awesome, but unlike measuring tapes, they are definitely prone to significant distance errors if the laser strays off the target (or partially encounters an obstruction). Our data-entry sheets for Lech now include a box for backsight distances to help catch these errors, but there is currently no way to enter these measurements in Compass. - It would also be great if you could increase the maximum character length in the Shot Comment field from 160 characters to at least 320 characters. We are using this field to help track changes, and having more characters to document those changes (and the rationale) would be very helpful! Thanks again for your excellent software! Ron -- Derek [email protected](303) 589-4469 (mobile)(303) 284-9360 (home)
Authentication-Results: mta4000.groups.mail.ne1.yahoo.com from=ronmiller.net; domainkeys=neutral (no sig); from=ronmiller.net; dkim=pass (ok) Date: Wed, 11 Jul 2018 19:55:50 -0400 Subject: "Not a Valid Floating Point Value issue - shot comment field? From: Ron Miller Sorry to be bringing up what may be basic issues, but again today I experienced an error that seems like it could be quite serious if a user does not have a recent data backup. Also, I see from reviewing the archive that this issue has occasionally arisen in the past but the most recent mention I found is from five years ago. On a couple of occasions over the past few days, I have encountered the following error " '[X]' is not a valid floating point value" where [X] has in each case been a date value that I have just entered into a relatively long (but less than 255 character!) shot comment on a survey I am editing in the Editor. "07-04-2018" was one example of such a date value. Once that error appears (initially on attempting to save the current file, if I recall correctly), it makes that survey inaccessible, as the error re-appears on each attempt to open the survey. I tried saving just the problematic survey file, and that at first seemed successful, but when I opened the standalone file, it contained only a generic header and a "NEW1" to "NEW2" null shot. The only way I have been able to recover the problematic survey's data has been to use Manipulate Surveys in the Project Manager to delete the survey file and replace it with an uncorrupted survey file from a backup dat file. Larry, I'd be happy to send you a copy of the entire dat file by email. Unfortunately, I didn't preserve the dat file version with the corrupted survey, although I do still have the empty standalone survey dat file. If/when it happens again, I'll remember to save it. Thanks again for your help! Ron Miller
Authentication-Results: mta4000.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Wed, 11 Jul 2018 20:12:19 -0600
Subject: RE: [compass-users] "Not a Valid Floating Point Value issue - shot comment field?
From: "Larry"
Ron,
Thanks for your email.
I fixed a similar bug just recently. Send me a copy of the file and I'll
check it. Be sure to describe exactly what steps I need to take to make the
error appear.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 11, 2018 5:56 PM
Subject: [compass-users] "Not a Valid Floating Point Value issue - shot
comment field?
Sorry to be bringing up what may be basic issues, but again today I
experienced an error that seems like it could be quite serious if a user
does not have a recent data backup.
Also, I see from reviewing the archive that this issue has occasionally
arisen in the past but the most recent mention I found is from five
years ago.
On a couple of occasions over the past few days, I have encountered the
following error " '[X]' is not a valid floating point value" where [X]
has in each case been a date value that I have just entered into a
relatively long (but less than 255 character!) shot comment on a survey
I am editing in the Editor. "07-04-2018" was one example of such a date
value. Once that error appears (initially on attempting to save the
current file, if I recall correctly), it makes that survey inaccessible,
as the error re-appears on each attempt to open the survey. I tried
saving just the problematic survey file, and that at first seemed
successful, but when I opened the standalone file, it contained only a
generic header and a "NEW1" to "NEW2" null shot.
The only way I have been able to recover the problematic survey's data
has been to use Manipulate Surveys in the Project Manager to delete the
survey file and replace it with an uncorrupted survey file from a backup
dat file.
Larry, I'd be happy to send you a copy of the entire dat file by email.
Unfortunately, I didn't preserve the dat file version with the corrupted
survey, although I do still have the empty standalone survey dat file.
If/when it happens again, I'll remember to save it.
Thanks again for your help!
Ron Miller
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta4003.groups.mail.bf1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Wed, 11 Jul 2018 20:26:05 -0600
Subject: RE: [compass-users] Re: Problem printing/creating a file of blundered loops
From: "Larry"
Hi Derek,
This is a complicated topic which requires a lot of explanation, so bear
with me if get a little long-winded.
But if the survey order is changed, and the number and
relative quality of loops then changes, then the loop
closure order may change, and thus the location of stations.
1. First, the number of loops never changes. No matter what order the
surveys are processed, the number always remains that same. For example,
here the test loop I described in the previous email:
A ------- B ------ C
| | |
| | |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
But only two are necessary are to cover all the shots in the loops. So
Compass will always see two loops. The only question is whether those loops
are (1,2), (2 ,3) or (1,3).
2. Second, it is not the "order of the surveys" that can change which loops
are found, it is the "order of the shots." In the example above, if
(A,B,C,D,E,F,A) is one survey and (B,E) is another survey, it doesn't matter
what order they appear in the file. Compass will always choose loop 1 and 2
as the two loops in that set. However, if the shot order is changed to
(A,B,E,F,A) and (B,C,D,E,B) loops 2 and 3 will be chosen.
The reason that I sometimes say survey order matters is that the order the
surveys were done usually dictates the order the shots were done. In the
example above, it is likely that (A,B,C,D,E,F,A) was done first and (B,E)
was done later. So it is likely that (A,B,C,D,E,F,A) was done first and
(B,E) was done last. However Compass doesn't care.
3. Even if the actual selection of loops changed by the shot-order, it
wouldn't make much practical difference. Under normal circumstances, the
differences would be so small that there would be virtually no difference.
Here is a little more detail.
This gets into complicated questions and myths about loop closure.
4. Every survey has random errors in it. If you don't do something about
them, the errors will pile up at the end of the loop and cause a large
anomaly between the last and first station of the loop. The purpose of loop
closure is to distribute those errors around the loop so there isn't an ugly
jump at the end of the loop. The purpose of this is primarily "cosmetic."
Most people think that closing loops improves the accuracy of surveys, but
that is not case. In fact, it can make them less accurate. For example, if
you have a 10-shot loop, where nine shots that are very accurate and one
shot that isn't, closing the loop make will make the nine of the 10 shots
less accurate. Since it difficult to tell which shots are accurate and which
are not, the best you can do is apply statistics to the process and come up
with a system that provides the "most probable" location for each survey.
One problem is that there are lots of different methods that claim to be the
most statistically correct method. Here are a couple examples:
http://www.fountainware.com/compass/Documents/LeastSquares/Schmidt_and_Schel
leng/Schmidt_and_Schellen_Pages.htm#Page1
http://www.fountainware.com/compass/Documents/LeastSquares/Neil_Smith/Smith_
Pages.htm#Page1
I can think of several others that also claim to be superior. However, each
of these techniques is different and produces different results so they all
can't be superior. In my estimation, there are advantages and disadvantages
to each one and which one is best depends on your objectives.
5. But here is the important part: these loop closure techniques only work
if the errors are random. However, if the errors are random, the errors are
generally so small that it hardly matters what technique you use. When the
errors are random, the difference between one technique and another is means
the stations might move a few inches by using a different closure technique.
On the other hand, if the errors are not random, all bets are off. Loop
closure technique only work if the shots only have random errors. Random
errors obey statistical rules that make the loop closure algorithms work.
When survey data has blunders in them, if you apply normal statistical
techniques, you spread the errors around and make everything worse. This
problem has been explained in detail by John Halleck:
http://www.cc.utah.edu/~nahaj/cave/survey/overview.html
6. The same thing happens if Compass processes loops in a different order.
If all the loops have random errors, it doesn't matter very much in what
order the loops are closed. Even if the order is changed, the change in
error will be small and the largest errors will still be confined to
adjacent loops.
7. When you have blunders, there is no technique that does a really good job
of fixing the data. If you isolate the blunder to a small part of the cave,
it makes the rest of the cave more accurate, but it may cause big
distortions near the blunder and that can be cosmetically ugly. On the other
hand, if you spread the error to a large part of the cave, the map will look
better cosmetically, but the overall accuracy will be lower.
With Compass I've chosen to isolate the blunders, tolerate large distortions
near blunders and then provide tools for finding the Blunders. The
blunder-tools don't particularly care what loops are used or what order the
shots are processed. Blunders always cause the kind of anomalies that can be
picked up by the blunder tools. The bottom line is that the only effective
way to deal with blunders is remove them by fixing transcription errors or
resurveying the defective surveys.
Larry
_____
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 11, 2018 3:28 PM
Subject: Re: [compass-users] Re: Problem printing/creating a file of
blundered loops
Hi Larry,
Since you brought up the fact that survey order affects loop identification,
I have a question that's bothered me for some time.
It seems that changing the order of the surveys may change the location of
stations following loop closure. If I understand your algorithm for loop
closure correctly, the best loops are closed first, and then these stations
are fixed. This should only matter for multi-loops (i.e. interconnected
loops). But if the survey order is changed, and the number and relative
quality of loops then changes, then the loop closure order may change, and
thus the location of stations. The result is that two sets of identical
survey data, with no other difference but the order of the surveys, may end
up with a different line plot. I've been meaning to test that out but
haven't found the time. Perhaps the algorithm for loop closure drives that
to happen, but it feels like it shouldn't make a difference what order the
surveys are in... the closed loop data should put the stations in the same
location.
Derek Bristol
On Wed, Jul 11, 2018 at 3:02 PM, 'Larry' [email protected]
[compass-users] wrote:
Ron,
Thanks for you email.
Changing the survey order in the DAT file (using the
Manipulate Surveys function) can change the number of bad
loops.
When Compass looks for blunders, it processes loops in the order they were
surveyed. For example, in this survey:
A ------- B ------ C
| | |
| | |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
However, only two of the loops are necessary to encompass all the shots in
the loops. As a result, Compass will only use two of the possible loops in
its data processing. Which loop depends on the survey order.
If the cave was surveyed in this order:
A,B,C,D,E,F,A
B,E
Compass will see loops 1 and 2. If the cave was surveyed in this order:
A,B,E,F,A
B,C,D,E,B
Compass will see loops 2 and 3.
None of this matters for loop closures, because closing loops is a matter of
distributing the error across all adjacent surveys.
However, for blunder detection, the order will change where the errors
appear. But even that doesn't matter much. Where the errors appears is
unimportant because the error will still always show up somewhere and that
is what Compass needs to help find the error.
Let me explain:
If shot B--E has a blunder in it, the order of the surveys will make a
difference as to what the blunder tools sees. If Compass sees loops 1 and 2,
only loop 2 will contain the error. On the other hand, if Compass sees loop
2 and 3, both loops will have the error in it.
In either case, Compass will see the blunder and the blunder tools will be
able to find possible locations for the blunder.
All this gets into a complicated discussion about what are optimal loops. I
wrote a document on the finding optimal loops that you can find here:
http://www.fountainware.com/
compass/Documents/FindingLoops/FindingLoops.html
It would also be great if you could increase the maximum
character length in the Shot Comment field from 160
characters to at least 320 characters.
Actually, the current length of Shot Comments is 255 characters. (Apparently
the 160 character limit is still in the documentation somewhere).
However, many of these limits don't actually apply because Compass now uses
expandable strings that can be up to 2-gigabytes long. In the case of the
survey comments, I just tested them by entering a 400 characters
shot-comment and I was able to save and reload it with no lost characters.
There may be a few places where the 255 character limit applies, but the
fact that I was able to save and load long comments means won't lose any
characters so you're safe to use longer comments.
it would be awesome if you could add a second distance field
in the backsights section (and maybe change the names from
"Tape" to "Dist1" and "Dist2"
I agree and I'm working on a bunch of changes to accommodate the new
surveying tools like the Disto. Basically, I'm working on a major rewrite of
Compass that will add a much more flexible data format that will make it
easy to add new features like the Disto data. It would be best to defer the
Disto features to the new version.
One caveat: as people will attest, I've been working on this new version of
Compass for years (decades) and although I have most of the pieces written,
I have trouble get enough free time from work to finish it up. As a result,
the free time I do have is devoted to fixing bugs and incrementally adding
new features to the existing version.
Larry
_____
From: [email protected] [mailto:compass-users@
yahoogroups.com]
Sent: Wednesday, July 11, 2018 1:39 PM
Subject: [compass-users] Re: Problem printing/creating a file of blundered
loops
Thanks, Larry. I was led astray by my misinterpretation of the help
file, which indicates that you can "print or save to disk the currently
displayed blunder information". I interpreted that to mean the entire
displayed list of blundered loops, rather than the selected loop. If
you'd like to make the help file less ambiguous, it could perhaps be
written as "print or save to disk the blunder information for the
currently selected loop".
What I was trying to accomplish was to figure out how edits to survey
files in Lechuguilla Cave affected the number of bad loops. So I wanted
to be able to compare the compact blundered loop lists in the Find
Blundered Loops page before and after changes. Unfortunately, the file
created from the Loop Errors page in Cave Statistics is not conducive to
simply importing that compact, spreadsheet-style list into Excel. I
ultimately accomplished my objective by taking screencaps of the lists,
converting them to PDF, running OCR, and then pasting the lists into Excel.
But this exercise appears to have revealed another aspect of Compass,
which I am hoping that you might be able to help me understand and
minimize its effect. Changing the survey order in the DAT file (using
the Manipulate Surveys function) can change the number of bad loops. For
a cave like Lech where we are constantly resurveying to fix old blunders
and then "X"ing out old shots, this is concerning to me. Can you help me
understand why this would be the case, and what if anything can be done
to minimize the effect of survey order to the loop closure error
algorithm? If it would be helpful, I would be happy to send you two
files that demonstrate this behavior.
Also, while I'm at it, two (hopefully minor) requests for the next release:
- Now that we are firmly in the DistoX age, it would be awesome if you
could add a second distance field in the backsights section (and maybe
change the names from "Tape" to "Dist1" and "Dist2" now that fiberglass
measuring tapes are being supplanted by DistoXs and other laser distance
measuring tools). DistoXs are awesome, but unlike measuring tapes, they
are definitely prone to significant distance errors if the laser strays
off the target (or partially encounters an obstruction). Our data-entry
sheets for Lech now include a box for backsight distances to help catch
these errors, but there is currently no way to enter these measurements
in Compass.
- It would also be great if you could increase the maximum character
length in the Shot Comment field from 160 characters to at least 320
characters. We are using this field to help track changes, and having
more characters to document those changes (and the rationale) would be
very helpful!
Thanks again for your excellent software!
Ron
Derek Bristol
[email protected]
(303) 589-4469 (mobile)
(303) 284-9360 (home)
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta4001.groups.mail.ne1.yahoo.com from=skynet.be; domainkeys=neutral (no sig); from=skynet.be; dkim=pass (ok)
IronPort-PHdr: =?us-ascii?q?9a23:A7ALGB0dSSrgk1uVsmDT+DRfVm0co7zxezQtwd? =?us-ascii?q?8ZseMQLfad9pjvdHbS+e9qxAeQG9mDtbQc06L/iOPJYSQ4+5GPsXQPItRndi? =?us-ascii?q?QuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBg? =?us-ascii?q?vwNRZvJuTyB4Xek9m72/q99pHPYghEniaxba9vJxiqsAvdsdUbj5F/Iagr0B? =?us-ascii?q?vJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PG? =?us-ascii?q?Av5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb5Sq06WS? =?us-ascii?q?m576dzVhDnlDsHOTA+8GHSkMNwjaRbqw+lqxFwx4PYZYeYP+d8cKzAZ9MXXW? =?us-ascii?q?pPUNhfWSJCAIy8YYUAAfcOMulEtITyvUcCrBSkCAWwHu7iyDlFjWL2060g1O? =?us-ascii?q?QhFBnL0hY6ENITtHTfsdv7O7kPWu2ozanH0yjIYvRO2Tjn9YjIdgotruySUr? =?us-ascii?q?5qasXRyFcgGhjejlWTqY3lOS2a1vgXv2eA8eVtTOSigHMppQF2pzig3MYsio? =?us-ascii?q?/Ri4II1lDL7yV5zJwrKtKlVU53ed6lH4FQtyGdMIt2TdkiQ2Z1uCYi0b0Ko4? =?us-ascii?q?K0fC8PyJg/yR7fbOGHc46U4h35VeaRJzl5i2h/eL2hnRq97U+gyujkWsi0yl? =?us-ascii?q?lKri1Fkt7Wun8R0BzT786KQeZ+8Ee5wTuC1B3f5vtaLU07m6fXMYMtz7Ewm5? =?us-ascii?q?YJrEjOGiH7lUPrh6GMbEok4PKn6+H/b7XjoZ+TKpF7hxnlMqQrhsy/GeM4Mh? =?us-ascii?q?USX2SD+eSzyrnj/UrhTbpOk/E7lrfVvIrHKckapaO1GRJZ3pw95xm5Fzum0d? =?us-ascii?q?IYkmcbLF9dex+LkpLlN0/BLf32F/uznluhnTdxy/zbOrDsDI3BLn3Zn7fgeb? =?us-ascii?q?Z95VRcyA02zd1H/5JbEKwBIPbpVkDsqtPUFAQ2Mw2qzOv8E9V91YMfWWSRDa? =?us-ascii?q?+FKq/dqkGH6vo1I+aQfI8VpCr9K/896vHyin85nEcdcrOy3ZsMcXy4A+9mLF? =?us-ascii?q?uDYXr3mdoAEX0Fvgo5TOzth12CSzlTZ2uqX6In/D00FIWmDYKQDr2rm6GLiS? =?us-ascii?q?KyH5lKYTJNDVWUGGzzMpifVu0XLT+UOdJriTceVLKsY54o1RapuxX91qJ8aO? =?us-ascii?q?HT/3oDqJjh2dNpstDVjgw47jduDs6QgF2KGjV/mWYQTiQtmb1krFZm4kaK0a? =?us-ascii?q?9/jOZfCMRIofhOV1FpG4TbyrlCAs32Ei7MNv2IRR7yWty7BXc9Q5Q7wtImeE? =?us-ascii?q?VsHdi+yBrOiXn5S4QJnqCGUcRnupnX2GL8cposxg==?Date: Thu, 12 Jul 2018 09:01:48 +0200
Subject: RE: [compass-users] Re: Problem printing/creating a file of blundered loops
From: Paul De Bie
hi Larry, thanks for this (extensive) explanation! I'll keep it for
reference. Maybe you could add it to the Help or even put it on your website.
As for the order of surveys and shots in a survey: they do matter for stuff
such as showing the distance to the entrance (as shot labels). I often
wondered if it wouldn't be better to add a shot flag or another way, to
indicate what the entrance station is. Now it is the very first station.
But often we survey caves on the way out, from bottom to entrance.
Regards
Paul De Bie
Op 12 juli 2018 4:27:42 a.m. schreef "'Larry' [email protected]
[compass-users]" :
Hi Derek,
This is a complicated topic which requires a lot of
explanation, so bear with me if get a little long-winded.
But if the survey order is changed, and the number and
relative quality of loops then changes, then the loop
closure order may change, and thus the location of
stations.
1. First, the number of loops never changes. No matter what
order the surveys are processed, the number always remains that same. For
example, here the test loop I described in the previous email:
A ------- B ------ C
|
| |
|
| |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
But only two are necessary are to cover all the shots in the
loops. So Compass will always see two loops. The only question is whether those
loops are (1,2), (2 ,3) or (1,3).
2. Second, it is not the �?oorder of the surveys�??
that can change which loops are found, it is the �?oorder of the shots.�??
In the example above, if (A,B,C,D,E,F,A) is one survey and (B,E) is another
survey, it doesn�?Tt matter what order they appear in the file. Compass
will always choose loop 1 and 2 as the two loops in that set. However, if the
shot order is changed to (A,B,E,F,A) and (B,C,D,E,B) loops 2
and 3 will be chosen.
The reason that I sometimes say survey order matters is that
the order the surveys were done usually dictates the order the shots were done.
In the example above, it is likely that (A,B,C,D,E,F,A) was done first and
(B,E)
was done later. So it is likely that (A,B,C,D,E,F,A) was done first and (B,E)
was done last. However Compass doesn�?Tt care.
3. Even if the actual selection of loops changed by the
shot-order, it wouldn�?Tt make much practical difference. Under normal
circumstances, the differences would be so small that there would be virtually
no difference. Here is a little more detail.
This gets into complicated questions and myths about loop
closure.
4. Every survey has random errors in it. If you don�?Tt
do something about them, the errors will pile up at the end of the loop and
cause a large anomaly between the last and first station of the loop. The
purpose of loop closure is to distribute those errors around the loop so there
isn�?Tt an ugly jump at the end of the loop. The purpose of this is
primarily �?ocosmetic.�??
Most people think that closing loops improves the accuracy of surveys, but that
is not case. In fact, it can make them less accurate. For example, if you have
a 10-shot loop, where nine shots that are very accurate and one shot that
isn�?Tt,
closing the loop make will make the nine of the 10 shots less accurate. Since
it difficult to tell which shots are accurate and which are not, the best you
can do is apply statistics to the process and come up with a system that
provides the �?omost probable�?? location for each survey.
One problem is that there are lots of different methods that
claim to be the most statistically correct method. Here are a couple examples:
http://www.fountainware.com/compass/Documents/LeastSquares/Schmidt_and_Schelleng/Schmidt_and_Schellen_Pages.htm#Page1
http://www.fountainware.com/compass/Documents/LeastSquares/Neil_Smith/Smith_Pages.htm#Page1
I can think of several others that also claim to be
superior. However, each of these techniques is different and produces different
results so they all can�?Tt be superior. In my estimation, there are
advantages and disadvantages to each one and which one is best depends on your
objectives.
5. But here is the important part: these loop closure techniques only work
if the errors
are random. However, if the errors are random, the errors are generally so
small that it hardly matters
what technique you use. When the errors are random, the
difference between one technique and another is means the stations might move a
few inches by using a different closure technique.
On the other hand, if the errors are not random, all bets
are off. Loop closure technique only work if the shots only have random errors.
Random errors obey statistical rules that make the loop closure algorithms
work. When survey data has blunders in them, if you apply normal statistical
techniques, you spread the errors around and make everything worse. This
problem has been explained in detail by John Halleck:
http://www.cc.utah.edu/~nahaj/cave/survey/overview.html
6. The same thing happens if Compass processes loops in a
different order. If all the loops have random errors, it doesn�?Tt matter
very much in what order the loops are closed. Even if the order is changed, the
change in error will be small and the largest errors will still be confined
to adjacent
loops.
7. When you have blunders, there is no technique that does a
really good job of fixing the data. If you isolate the blunder to a small part
of the cave, it makes the rest of the cave more accurate, but it may cause big
distortions near the blunder and that can be cosmetically ugly. On the other
hand, if you spread the error to a large part of the cave, the map will look
better cosmetically, but the overall accuracy will be lower.
With Compass I�?Tve chosen to isolate the blunders,
tolerate large distortions near blunders and then provide tools for finding the
Blunders. The blunder-tools don�?Tt particularly care what loops are
used or what order the shots are processed. Blunders always cause the kind
of anomalies
that can be picked up by the blunder tools. The bottom line is that the only
effective way to deal with blunders is remove them by fixing transcription
errors or resurveying the defective surveys.
Larry
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 11, 2018
3:28 PM
To: [email protected]
Subject: Re: [compass-users] Re:
Problem printing/creating a file of blundered loops
Hi Larry,
Since you brought up the fact that survey order affects loop
identification, I have a question that's bothered me for some time.
It seems that changing the order of the surveys may change the location
of stations following loop closure. If I understand your algorithm for loop
closure correctly, the best loops are closed first, and then these stations are
fixed. This should only matter for multi-loops (i.e. interconnected loops). But
if the survey order is changed, and the number and relative quality of loops
then changes, then the loop closure order may change, and thus the location of
stations. The result is that two sets of identical survey data, with no other
difference but the order of the surveys, may end up with a different line plot.
I've been meaning to test that out but haven't found the time. Perhaps the
algorithm for loop closure drives that to happen, but it feels like it
shouldn't
make a difference what order the surveys are in... the closed loop data should
put the stations in the same location.
Derek Bristol
On Wed, Jul 11, 2018 at 3:02 PM, 'Larry' [email protected] [compass-users]
wrote:
Ron,
Thanks for you email.
Changing the survey order in the DAT file (using the
Manipulate Surveys function) can change the number of
bad
loops.
When Compass looks for blunders, it processes loops in the
order they were surveyed. For example, in this survey:
A ------- B ------ C
|
| |
|
| |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
However, only two of the loops are necessary to encompass
all the shots in the loops. As a result, Compass will only use two of the
possible loops in its data processing. Which loop depends on the survey order.
If the cave was surveyed in this order:
A,B,C,D,E,F,A
B,E
Compass will see loops 1 and 2. If the cave was surveyed in
this order:
A,B,E,F,A
B,C,D,E,B
Compass will see loops 2 and 3.
None of this matters for loop closures, because closing
loops is a matter of distributing the error across all adjacent surveys.
However, for blunder detection, the order will change where
the errors appear. But even that doesn't matter much. Where the errors appears
is unimportant because the error will still always show up somewhere and that
is what Compass needs to help find the error.
Let me explain:
If shot B--E has a blunder in it, the order of the
surveys will make a difference as to what the blunder tools sees. If Compass
sees loops 1 and 2, only loop 2 will contain the error. On the other hand, if
Compass sees loop 2 and 3, both loops will have the error in it.
In either case, Compass will see the blunder and the blunder
tools will be able to find possible locations for the blunder.
All this gets into a complicated discussion about what are
optimal loops. I wrote a document on the finding optimal loops that you can
find here:
http://www.fountainware.com/compass/Documents/FindingLoops/FindingLoops.html
It would also be great if you could increase the
maximum
character length in the Shot Comment field from 160
characters to at least 320 characters.
Actually, the current length of Shot Comments is 255
characters. (Apparently the 160 character limit is still in the documentation
somewhere).
However, many of these limits don't actually apply because
Compass now uses expandable strings that can be up to 2-gigabytes long. In the
case of the survey comments, I just tested them by entering a 400 characters
shot-comment and I was able to save and reload it with no lost characters.
There may be a few places where the 255 character limit
applies, but the fact that I was able to save and load long comments means
won�?Tt lose any characters so you're safe to use longer comments.
it would be awesome if you could add a second distance
field
in the backsights section (and maybe change the names
from
"Tape" to "Dist1" and
"Dist2"
I agree and I'm working on a bunch of changes to accommodate
the new surveying tools like the Disto. Basically, I'm working on a major
rewrite of Compass that will add a much more flexible data format that will
make it easy to add new features like the Disto data. It would be best to defer
the Disto features to the new version.
One caveat: as people will attest, I've been working on this
new version of Compass for years (decades) and although I have most of the
pieces written, I have trouble get enough free time from work to finish it up.
As a result, the free time I do have is devoted to fixing bugs and
incrementally adding new features to the existing version.
Larry
From: [email protected]
[mailto:[email protected]]
Sent: Wednesday, July 11, 2018
1:39 PM
To: [email protected]
Subject: [compass-users] Re:
Problem printing/creating a file of blundered loops
Thanks, Larry. I was led
astray by my misinterpretation of the help
file, which indicates that you can "print or save to disk the currently
displayed blunder information". I interpreted that to mean the entire
displayed list of blundered loops, rather than the selected loop. If
you'd like to make the help file less ambiguous, it could perhaps be
written as "print or save to disk the blunder information for the
currently selected loop".
What I was trying to accomplish was to figure out how edits to survey
files in LechuguillaCave affected the number
of bad loops. So I wanted
to be able to compare the compact blundered loop lists in the Find
Blundered Loops page before and after changes. Unfortunately, the file
created from the Loop Errors page in Cave Statistics is not conducive to
simply importing that compact, spreadsheet-style list into Excel. I
ultimately accomplished my objective by taking screencaps of the lists,
converting them to PDF, running OCR, and then pasting the lists into Excel.
But this exercise appears to have revealed another aspect of Compass,
which I am hoping that you might be able to help me understand and
minimize its effect. Changing the survey order in the DAT file (using
the Manipulate Surveys function) can change the number of bad loops. For
a cave like Lech where we are constantly resurveying to fix old blunders
and then "X"ing out old shots, this is concerning to me. Can you help
me
understand why this would be the case, and what if anything can be done
to minimize the effect of survey order to the loop closure error
algorithm? If it would be helpful, I would be happy to send you two
files that demonstrate this behavior.
Also, while I'm at it, two (hopefully minor) requests for the next release:
- Now that we are firmly in the DistoX age, it would be awesome if you
could add a second distance field in the backsights section (and maybe
change the names from "Tape" to "Dist1" and
"Dist2" now that fiberglass
measuring tapes are being supplanted by DistoXs and other laser distance
measuring tools). DistoXs are awesome, but unlike measuring tapes, they
are definitely prone to significant distance errors if the laser strays
off the target (or partially encounters an obstruction). Our data-entry
sheets for Lech now include a box for
backsight distances to help catch
these errors, but there is currently no way to enter these measurements
in Compass.
- It would also be great if you could increase the maximum character
length in the Shot Comment field from 160 characters to at least 320
characters. We are using this field to help track changes, and having
more characters to document those changes (and the rationale) would be
very helpful!
Thanks again for your excellent software!
Ron
--
Derek Bristol
[email protected]
(303) 589-4469 (mobile)
(303) 284-9360 (home)
#aqm-original #ACTIVITY {
float:left;
} /* style */
#aqm-original #activity span:first-child {
text-transform: uppercase;
} /* style */
#aqm-original ..ATTACH {
display: table;
} /* style */
#aqm-original div.file-title a, #aqm-original div.file-title a:active, #aqm-original div.file-title a:hover, #aqm-original div.file-title a:visited {
text-decoration: none;
} /* style */
#aqm-original div.photo-title a, #aqm-original div.photo-title a:active, #aqm-original div.photo-title a:hover, #aqm-original div..photo-title a:visited {
text-decoration: none;
} /* style */
#aqm-original o {
font-size: 0;
} /* style */
#aqm-original #PHOTOS div {
float:left;
} /* style */
#aqm-original #PHOTOS div div {
overflow:hidden;
} /* style */
#aqm-original #PHOTOS div label {
overflow:hidden;
} /* style */
#aqm-original #ygrp-actbar div a:first-child {
margin-right: 2px;
padding-right: 5px;
} /* style */
#aqm-original #YGRP-MLMSG {
*font-size: small;
*font: x-small;
} /* style */
#aqm-original #YGRP-MLMSG table {
font-size: inherit;
} /* style */
#aqm-original #YGRP-MLMSG pre {
*font-size:100%;
} /* style */
#aqm-original code {
*font-size:100%;
} /* style */
#aqm-original #ygrp-mlmsg * {
line-height: 1.22em;
} /* style */
#aqm-original #ygrp-vital ul li:last-child {
border-right: none !important;
} /* style */
#aqm-original p.MsoNormal, #aqm-original li.MsoNormal, #aqm-original div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original a:link, #aqm-original span.MsoHyperlink {
color:blue;
text-decoration:underline;
} /* style */
#aqm-original a:visited, #aqm-original span.MsoHyperlinkFollowed {
color:blue;
text-decoration:underline;
} /* style */
#aqm-original p {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original code {
font-family:"Courier New";
} /* style */
#aqm-original pre {
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
} /* style */
#aqm-original tt {
font-family:"Courier New";
} /* style */
#aqm-original p.attach, #aqm-original li.attach, #aqm-original div.attach {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:7.5pt;
font-family:Arial;
} /* style */
#aqm-original p.bold, #aqm-original li.bold, #aqm-original div.bold {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:8.0pt;
font-family:Arial;
font-weight:bold;
} /* style */
#aqm-original p.green, #aqm-original li.green, #aqm-original div.green {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
color:#628C2A;
} /* style */
#aqm-original p.replbq, #aqm-original li.replbq, #aqm-original div.replbq {
margin:2.5pt;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original p.ad, #aqm-original li.ad, #aqm-original div.ad {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original p.underline, #aqm-original li.underline, #aqm-original div.underline {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original p.ad1, #aqm-original li.ad1, #aqm-original div.ad1 {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original p.ad2, #aqm-original li.ad2, #aqm-original div.ad2 {
mso-margin-top-alt:auto;
margin-right:0in;
margin-bottom:6.25pt;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
} /* style */
#aqm-original p.underline1, #aqm-original li.underline1, #aqm-original div.underline1 {
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
text-decoration:underline;
} /* style */
#aqm-original span.yshortcuts1 {
font-family:Verdana;
font-weight:bold;
} /* style */
#aqm-original span.yshortcuts2 {
font-family:Verdana;
font-weight:normal;
} /* style */
#aqm-original span.EmailStyle33 {
mso-style-type:personal-reply;
font-family:Arial;
color:windowtext;
} /* style */
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
#aqm-original div.Section1 {
page:Section1;
} /* style */
@list l0
{mso-list-id:953244010;
mso-list-template-ids:195300774;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
#aqm-original ol {
margin-bottom:0in;
} /* style */
#aqm-original ul {
margin-bottom:0in;
} /* style */
#aqm-original .ygrp-photo-title {
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
} /* style */
#aqm-original div.ygrp-photo {
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
} /* style */
#aqm-original div.photo-title
a, #aqm-original div.photo-title a:active, #aqm-original div.photo-title a:hover, #aqm-original div.photo-title a:visited {
text-decoration: none;
} /* style */
#aqm-original div.attach-table div.attach-row {
clear: both;
} /* style */
#aqm-original div.attach-table div.attach-row div {
float: left;
} /* style */
#aqm-original p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
} /* style */
#aqm-original div.ygrp-file {
width: 30px;
valign: middle;
} /* style */
#aqm-original div.attach-table div.attach-row div div a {
text-decoration: none;
} /* style */
#aqm-original div.attach-table div.attach-row div div span {
font-weight: normal;
} /* style */
#aqm-original div.ygrp-file-title {
font-weight: bold;
} /* style */
hi Larry, thanks for this (extensive) explanation! I'll keep it for reference. Maybe you could add it to the Help or even put it on your website.As for the order of surveys and shots in a survey: they do matter for stuff such as showing the distance to the entrance (as shot labels). I often wondered if it wouldn't be better to add a shot flag or another way, to indicate what the entrance station is. Now it is the very first station. But often we survey caves on the way out, from bottom to entrance. RegardsPaul De Bie
Op 12 juli 2018 4:27:42 a.m. schreef "'Larry' [email protected] [compass-users]" <[email protected]>:
Hi Derek,
This is a complicated topic which requires a lot of
explanation, so bear with me if get a little long-winded.
> But if the survey order is changed, and the number and
> relative quality of loops then changes, then the loop
> closure order may change, and thus the location of
stations.
1. First, the number of loops never changes. No matter what
order the surveys are processed, the number always remains that same. For
example, here the test loop I described in the previous email:
A ------- B --|
| |
|
| |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
But only two are necessary are to cover all the shots in the
loops. So Compass will always see two loops. The only question is whether those
loops are (1,2), (2 ,3) or (1,3).
2. Second, it is not the �?oorder of the surveys�??
that can change which loops are found, it is the �?oorder of the shots.�??
In the example above, if (A,B,C,D,E,F,A) is one survey and (B,E) is another
survey, it doesn�?Tt matter what order they appear in the file. Compass
will always choose loop 1 and 2 as the two loops in that set. However, if the
shot order is changed to (A,B,E,F,A) and (B,C,D,E,B) loops 2
and 3 will be chosen.
The reason that I sometimes say survey order matters is that
the order the surveys were done usually dictates the order the shots were done.
In the example above, it is likely that (A,B,C,D,E,F,A) was done first and (B,E)
was done later. So it is likely that (A,B,C,D,E,F,A) was done first and (B,E)
was done last. However Compass doesn�?Tt care.
3. Even if the actual selection of loops changed by the
shot-order, it wouldn�?Tt make much practical difference. Under normal
circumstances, the differences would be so small that there would be virtually
no difference. Here is a little more detail.
This gets into complicated questions and myths about loop
closure.
4. Every survey has random errors in it. If you don�?Tt
do something about them, the errors will pile up at the end of the loop and
cause a large anomaly between the last and first station of the loop. The
purpose of loop closure is to distribute those errors around the loop so there
isn�?Tt an ugly jump at the end of the loop. The purpose of this is
primarily �?ocosmetic.�??
Most people think that closing loops improves the accuracy of surveys, but that
is not case. In fact, it can make them less accurate. For example, if you have
a 10-shot loop, where nine shots that are very accurate and one shot that isn�?Tt,
closing the loop make will make the nine of the 10 shots less accurate. Since
it difficult to tell which shots are accurate and which are not, the best you
can do is apply statistics to the process and come up with a system that
provides the �?omost probable�?? location for each survey.
One problem is that there are lots of different methods that
claim to be the most statistically correct method. Here are a couple examples:
http://www.fountainware.com/compass/Documents/LeastSquares/Schmidt_and_Schelleng/Schmidt_and_Schellen_Pages.htm#Page1
http://www.fountainware.com/compass/Documents/LeastSquares/Neil_Smith/Smith_Pages.htm#Page1
I can think of several others that also claim to be
superior. However, each of these techniques is different and produces different
results so they all can�?Tt be superior. In my estimation, there are
advantages and disadvantages to each one and which one is best depends on your
objectives.
5. But here is the important part: these loop closure techniques only work if the errors
are random. However, if the errors are random, the errors are generally so small that it hardly matters
what technique you use. When the errors are random, the
difference between one technique and another is means the stations might move a
few inches by using a different closure technique.
On the other hand, if the errors are not random, all bets
are off. Loop closure technique only work if the shots only have random errors.
Random errors obey statistical rules that make the loop closure algorithms
work. When survey data has blunders in them, if you apply normal statistical
techniques, you spread the errors around and make everything worse. This
problem has been explained in detail by John Halleck:
http://www.cc.utah.edu/~nahaj/cave/survey/overview.html
6. The same thing happens if Compass processes loops in a
different order. If all the loops have random errors, it doesn�?Tt matter
very much in what order the loops are closed. Even if the order is changed, the
change in error will be small and the largest errors will still be confined to adjacent
loops.
7. When you have blunders, there is no technique that does a
really good job of fixing the data. If you isolate the blunder to a small part
of the cave, it makes the rest of the cave more accurate, but it may cause big
distortions near the blunder and that can be cosmetically ugly. On the other
hand, if you spread the error to a large part of the cave, the map will look
better cosmetically, but the overall accuracy will be lower.
With Compass I�?Tve chosen to isolate the blunders,
tolerate large distortions near blunders and then provide tools for finding the
Blunders. The blunder-tools don�?Tt particularly care what loops are
used or what order the shots are processed. Blunders always cause the kind of anomalies
that can be picked up by the blunder tools. The bottom line is that the only
effective way to deal with blunders is remove them by fixing transcription
errors or resurveying the defective surveys.
Larry
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 11, 2018
3:28 PM
To: [email protected]
Subject: Re: [compass-users] Re:
Problem printing/creating a file of blundered loops
Hi Larry,
Since you brought up the fact that survey order affects loop
identification, I have a question that's bothered me for some time.
It seems that changing the order of the surveys may change the location
of stations following loop closure. If I understand your algorithm for loop
closure correctly, the best loops are closed first, and then these stations are
fixed. This should only matter for multi-loops (i.e. interconnected loops). But
if the survey order is changed, and the number and relative quality of loops
then changes, then the loop closure order may change, and thus the location of
stations. The result is that two sets of identical survey data, with no other
difference but the order of the surveys, may end up with a different line plot.
I've been meaning to test that out but haven't found the time. Perhaps the
algorithm for loop closure drives that to happen, but it feels like it shouldn't
make a difference what order the surveys are in... the closed loop data should
put the stations in the same location.
Derek Bristol
On Wed, Jul 11, 2018 at 3:02 PM, 'Larry' [email protected] [compass-users]
<[email protected]>
wrote:
Ron,
Thanks for you email.
> Changing the survey order in the DAT file (using the
> Manipulate Surveys function) can change the number of
bad
> loops.
When Compass looks for blunders, it processes loops in the
order they were surveyed. For example, in this survey:
A ------- B --
|
| |
|
| |
F---------E---
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
However, only two of the loops are necessary to encompass
all the shots in the loops. As a result, Compass will only use two of the
possible loops in its data processing. Which loop depends on the survey order.
If the cave was surveyed in this order:
A,B,C,D,E,F,A
B,E
Compass will see loops 1 and 2. If the cave was surveyed in
this order:
A,B,E,F,A
B,C,D,E,B
Compass will see loops 2 and 3.
None of this matters for loop closures, because closing
loops is a matter of distributing the error across all adjacent surveys.
However, for blunder detection, the order will change where
the errors appear. But even that doesn't matter much. Where the errors appears
is unimportant because the error will still always show up somewhere and that
is what Compass needs to help find the error.
Let me explain:
If shot B-->E has a blunder in it, the order of the
surveys will make a difference as to what the blunder tools sees. If Compass
sees loops 1 and 2, only loop 2 will contain the error. On the other hand, if
Compass sees loop 2 and 3, both loops will have the error in it.
In either case, Compass will see the blunder and the blunder
tools will be able to find possible locations for the blunder.
All this gets into a complicated discussion about what are
optimal loops. I wrote a document on the finding optimal loops that you can
find here:
http://www.fountainware.com/compass/Documents/FindingLoops/FindingLoops.html
> It would also be great if you could increase the
maximum
> character length in the Shot Comment field from 160
> characters to at least 320 characters.
Actually, the current length of Shot Comments is 255
characters. (Apparently the 160 character limit is still in the documentation
somewhere).
However, many of these limits don't actually apply because
Compass now uses expandable strings that can be up to 2-gigabytes long. In the
case of the survey comments, I just tested them by entering a 400 characters
shot-comment and I was able to save and reload it with no lost characters.
There may be a few places where the 255 character limit
applies, but the fact that I was able to save and load long comments means
won�?Tt lose any characters so you're safe to use longer comments.
> it would be awesome if you could add a second distance
field
> in the backsights section (and maybe change the names
from
> "Tape" to "Dist1" and
"Dist2"
I agree and I'm working on a bunch of changes to accommodate
the new surveying tools like the Disto. Basically, I'm working on a major
rewrite of Compass that will add a much more flexible data format that will
make it easy to add new features like the Disto data. It would be best to defer
the Disto features to the new version.
One caveat: as people will attest, I've been working on this
new version of Compass for years (decades) and although I have most of the
pieces written, I have trouble get enough free time from work to finish it up.
As a result, the free time I do have is devoted to fixing bugs and
incrementally adding new features to the existing version.
Larry
From: [email protected]
[mailto:[email protected]]
Sent: Wednesday, July 11, 2018
1:39 PM
To: [email protected]
Subject: [compass-users] Re:
Problem printing/creating a file of blundered loops
Thanks, Larry. I was led
astray by my misinterpretation of the help
file, which indicates that you can "print or save to disk the currently
displayed blunder information". I interpreted that to mean the entire
displayed list of blundered loops, rather than the selected loop. If
you'd like to make the help file less ambiguous, it could perhaps be
written as "print or save to disk the blunder information for the
currently selected loop".
What I was trying to accomplish was to figure out how edits to survey
files in Lechuguilla
Cave affected the number
of bad loops. So I wanted
to be able to compare the compact blundered loop lists in the Find
Blundered Loops page before and after changes. Unfortunately, the file
created from the Loop Errors page in Cave Statistics is not conducive to
simply importing that compact, spreadsheet-style list into Excel. I
ultimately accomplished my objective by taking screencaps of the lists,
converting them to PDF, running OCR, and then pasting the lists into Excel.
But this exercise appears to have revealed another aspect of Compass,
which I am hoping that you might be able to help me understand and
minimize its effect. Changing the survey order in the DAT file (using
the Manipulate Surveys function) can change the number of bad loops. For
a cave like Lech where we are constantly resurveying to fix old blunders
and then "X"ing out old shots, this is concerning to me. Can you help
me
understand why this would be the case, and what if anything can be done
to minimize the effect of survey order to the loop closure error
algorithm? If it would be helpful, I would be happy to send you two
files that demonstrate this behavior.
Also, while I'm at it, two (hopefully minor) requests for the next release:
- Now that we are firmly in the DistoX age, it would be awesome if you
could add a second distance field in the backsights section (and maybe
change the names from "Tape" to "Dist1" and
"Dist2" now that fiberglass
measuring tapes are being supplanted by DistoXs and other laser distance
measuring tools). DistoXs are awesome, but unlike measuring tapes, they
are definitely prone to significant distance errors if the laser strays
off the target (or partially encounters an obstruction). Our data-entry
sheets for Lech now include a box for
backsight distances to help catch
these errors, but there is currently no way to enter these measurements
in Compass.
- It would also be great if you could increase the maximum character
length in the Shot Comment field from 160 characters to at least 320
characters. We are using this field to help track changes, and having
more characters to document those changes (and the rationale) would be
very helpful!
Thanks again for your excellent software!
Ron
--
Derek Bristol
[email protected]
(303) 589-4469 (mobile)
(303) 284-9360 (home)
Authentication-Results: mta4002.groups.mail.bf1.yahoo.com from=yahoogroups.com; domainkeys=neutral (no sig); from=yahoogroups.com; dkim=permerror (bad sig) Date: 12 Jul 2018 21:53:51 +0000 Subject: RE: [compass-users] Re: Problem printing/creating a file of blundered loops From: [email protected] Hi Larry, Thanks for your detailed explanations. With that in mind, I have an additional question. While I understand now that survey order wouldn't really matter if none of the surveys had blunders, the project on which I am currently working (the Far East branch of Lechuguilla Cave) has numerous likely blunders, and I need the best assistance I can get to figure out which ones are priorities, and which ones may be OK. As an example, inadvertently changing the survey order of a single 2001 survey to last in the survey order changed the number of reported "bad" survey loops (STD 2) from 28 to 31. (As previously discussed, this happened as a result of my need to copy a survey from backup into the dat file to replace a survey corrupted by the "not a valid floating point value" bug, and the Editor's default behavior of appending copied files to the end.) So with a project that contains more than 500 surveys spanning nearly 30 years, in which we are still resurveying to correct blunders from the early years, do you have any suggestions on the best way to ensure that "bad" (e.g. likely blundered) survey loops are accurately reported within Compass? For example, do you recommend that we continue to "X" out the old blundered shots, but perhaps use the Manipulate Surveys feature to move new resurveys up in the survey order so that they appear immediately after the original survey, even though the dates are different? (Speaking of which, does date matter in the loop closure algorithm, or does it just rely on the survey order? ) Or should we just keep with the current practice, of Xing out the bad shots, and having the resurvey data remain in the order it is entered into the computer? Or something else entirely? Thanks again for your dedication and responsiveness! Ron Hi Larry,Thanks for your detailed explanations. With that in mind, I have an additional question. While I understand now that survey order wouldn't really matter if none of the surveys had blunders, the project on which I am currently working (the Far East branch of Lechuguilla Cave) has numerous likely blunders, and I need the best assistance I can get to figure out which ones are priorities, and which ones may be OK. As an example, inadvertently changing the survey order of a single 2001 survey to last in the survey order changed the number of reported "bad" survey loops (STD > 2) from 28 to 31. (As previously discussed, this happened as a result of my need to copy a survey from backup into the dat file to replace a survey corrupted by the "not a valid floating point value" bug, and the Editor's default behavior of appending copied files to the end.)So with a project that contains more than 500 surveys spanning nearly 30 years, in which we are still resurveying to correct blunders from the early years, do you have any suggestions on the best way to ensure that "bad" (e.g. likely blundered) survey loops are accurately reported within Compass? For example, do you recommend that we continue to "X" out the old blundered shots, but perhaps use the Manipulate Surveys feature to move new resurveys up in the survey order so that they appear immediately after the original survey, even though the dates are different? (Speaking of which, does date matter in the loop closure algorithm, or does it just rely on the survey order? ) Or should we just keep with the current practice, of Xing out the bad shots, and having the resurvey data remain in the order it is entered into the computer? Or something else entirely?Thanks again for your dedication and responsiveness!Ronn7
Authentication-Results: mta4002.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok)
Date: Thu, 12 Jul 2018 20:10:22 -0600
Subject: RE: [compass-users] Re: Problem printing/creating a file of blundered loops
From: "Larry"
Hi Ron,
I don't think the number of bad surveys really matters when you are looking
for blunders.
Here is the example I used in a previous email:
A ------- B ------ C
| | |
| | |
F---------E--------D
There are three possible loops.
1 = A,B,C,D,E,F,A
2 = A,B,E,F,A
3 = B,C,D,E,B
If there is a blunder between B and E, the shot order will control how that
blunder affects the three possible loops. If the shots were surveyed like
this:
Survey-1 = A,B,C,D,E,F,A
Survey-2 = B-E
Compass will see these two loops, with the following loop quality:
1 = A,B,C,D,E,F,A = GOOD
2 = A,B,E,F,A = BAD
If the shots were surveyed like this:
Survey-1 = A,B,E,F,A
Survey-2 = B,C,D,E,B
Compass will see these two loops, with the following loop quality:
2 = A,B,E,F,A = BAD
3 = B,C,D,E,B = BAD
Even though there are a different number of blundered loops, the blunder
still shows up and the blunder tools should be able to help isolate it.
That said, the blunder tools are not a panacea. Finding blunders is
difficult for lots of reasons.
In general, you have to take errors and standard deviations with a grain of
salt. Just because a loop has standard-deviation more than 2, doesn't mean
that there is something wrong with the loop. It just means that there is a
relatively high probability there is blunder.
Every survey measurement has small random errors in it. Usually those errors
tend to cancel out over the course of a loop. For example sometimes the
compass reads a little right of target, sometimes a little left and so the
errors cancel out. However, sometimes the errors fall more right than left
and that will cause the errors to add up.
Because of that, even if a loop is surveyed perfectly, with no blunder or
big errors, there is still a chance that all the small random errors will
add up to a big error at the end of the loop. Here's a chart showing the
chance of having perfectly good loop with an error above a certain level
above the expected error:
1-Std = 31.73%
2-Std = 4.55%
3-Std = 0.26%
If you have a perfectly surveyed loop, random errors will give you errors
greater than 1-STD 32.73% of the time. For 2-STD it is 4.55% of the time and
3-STD it is 0.26% of the time.
https://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distribu
ted_data
Lechuguilla has around 1,800 loops. Even if every survey was done perfectly,
you'd expect 81 loop would show errors 2-STD or greater and 4.6 loops with
errors greater than 3-STD. In other words, those 81 and 4.6 would have
nothing wrong them with other than the fact that the random errors fell in
just such a way that they pushed the error further than expected. My copy of
the Lechuguilla data has 286 loops with standard deviations more than two.
That means that 28% of all those "bad loops" are actually okay.
This is problematic if you are trying to fix errors in the cave, because no
matter what you do, you will not be able to find a specific, individual
error that will fix 81 loops on average. Since you don't know which 81 loops
out of the 286 are bad, you have to use the blunder tools and other
techniques to eliminate the false positives. When you think you have a false
positive, the best you could do is resurvey the whole loop to try to push
the average error lower.
Finally, I do have a method that will always find the same loops no matter
how the shots are surveyed. It is outlined here:
http://www.fountainware.com/compass/Documents/FindingLoops/FindingLoops.html
I actually use it in the Viewer as one of the options for displaying loops.
I haven't incorporated it into the Compiler, Loop Closer or Blunder
detection tools because I'm planning on putting it into the completely
rewritten version of Compass that I've been working on for the last few
years.
Larry
________________________________________
From: [email protected] [mailto:[email protected]]
Sent: Thursday, July 12, 2018 3:54 PM
Subject: RE: [compass-users] Re: Problem printing/creating a file of
blundered loops
Hi Larry,
Thanks for your detailed explanations. With that in mind, I have an
additional question. While I understand now that survey order wouldn't
really matter if none of the surveys had blunders, the project on which I am
currently working (the Far East branch of Lechuguilla Cave) has numerous
likely blunders, and I need the best assistance I can get to figure out
which ones are priorities, and which ones may be OK. As an example,
inadvertently changing the survey order of a single 2001 survey to last in
the survey order changed the number of reported "bad" survey loops (STD 2)
from 28 to 31. (As previously discussed, this happened as a result of my
need to copy a survey from backup into the dat file to replace a survey
corrupted by the "not a valid floating point value" bug, and the Editor's
default behavior of appending copied files to the end.)
So with a project that contains more than 500 surveys spanning nearly 30
years, in which we are still resurveying to correct blunders from the early
years, do you have any suggestions on the best way to ensure that "bad"
(e.g. likely blundered) survey loops are accurately reported within Compass?
For example, do you recommend that we continue to "X" out the old blundered
shots, but perhaps use the Manipulate Surveys feature to move new resurveys
up in the survey order so that they appear immediately after the original
survey, even though the dates are different? (Speaking of which, does date
matter in the loop closure algorithm, or does it just rely on the survey
order? ) Or should we just keep with the current practice, of Xing out the
bad shots, and having the resurvey data remain in the order it is entered
into the computer? Or something else entirely?
Thanks again for your dedication and responsiveness!
Ron
st1\:*{behavior:url(#default#ieooui) }
Authentication-Results: mta4003.groups.mail.bf1.yahoo.com from=verizon.net; domainkeys=neutral (no sig); from=yahoo.com; dkim=pass (ok) Date: Sun, 9 Sep 2018 18:04:26 -0400 Subject: missing front sights From: Dwight Livingston Larry I find that Compass data will plot correctly when both front and back sight data (azimuth or inclination) are entered, or when back sight data is missing, but shows incorrectly (without a error flag) when front sight data is missing. Would it be possible to change the program to have shots with missing front sight data plot correctly? Thanks Dwight
Authentication-Results: mta4001.groups.mail.bf1.yahoo.com from=verizon.net; domainkeys=neutral (no sig); from=yahoo.com; dkim=pass (ok) Date: Sun, 9 Sep 2018 18:15:16 -0400 Subject: Re: missing front sights From: Dwight Livingston Larry I was on an old version. I updated and now it plots correctly. Thanks Dwight On 9/9/2018 6:04 PM, Dwight Livingston wrote: Larry I find that Compass data will plot correctly when both front and back sight data (azimuth or inclination) are entered, or when back sight data is missing, but shows incorrectly (without a error flag) when front sight data is missing. Would it be possible to change the program to have shots with missing front sight data plot correctly? Thanks Dwight
Authentication-Results: mta4004.groups.mail.ne1.yahoo.com from=fountainware.com; domainkeys=neutral (no sig); from=fountainware.com; dkim=pass (ok) Date: Sun, 9 Sep 2018 21:44:45 -0600 Subject: RE: [compass-users] Re: missing front sights From: "Larry" Dwight, I'm glad the problem fixed itself. I wish all my fixes were that easy. More seriously, I'm making improvements and fixing problems all the time. It is well worth the time to check the Compass web site periodically to see if there have been any changes. The main web page will have a list of the major improvements: http://www.fountainware.com/compass/ However, this doesn't usually cover bug fixes and minor changes. The revision history lists smaller changes and bug fixes. http://www.fountainware.com/compass/Misc/revhist.htm Finally, you can look at the dates on the down loads. They will tell you when I released a new version. For example, the current version of Compass for Windows has a date of June 29, 2018, so the most recent update was about 2 and � months ago: http://www.fountainware.com/compass/downloads/download.htm Larry _____ From: [email protected] [mailto:[email protected]] Sent: Sunday, September 09, 2018 4:15 PM Subject: [compass-users] Re: missing front sights Larry I was on an old version. I updated and now it plots correctly. Thanks Dwight On 9/9/2018 6:04 PM, Dwight Livingston wrote: Larry I find that Compass data will plot correctly when both front and back sight data (azimuth or inclination) are entered, or when back sight data is missing, but shows incorrectly (without a error flag) when front sight data is missing. Would it be possible to change the program to have shots with missing front sight data plot correctly? Thanks Dwight