Yahoo Archive - 2018 

You can search all users group archives using the Google Search gadget
 

Click here for an overview of the Compass Users Group Archives:

Archives Overview.


Messsage #: 562
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


Messsage #: 563
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) }


Messsage #: 564
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 DD,DD,DDD


Messsage #: 565
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 DEOAIUE 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 ?

IEOE EIIx 

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) }


Messsage #: 566
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?DD'D,  7 DD?,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 DD,DD,DDD


Messsage #: 567
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: compass-users@yahoogroups.com  
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?DD'D, 7 DD?,D 2018, 12:05 +03:00 D_, 'Larry' lfish@fountainware.com   [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: compass-users@yahoogroups.com   [mailto:compass-users@yahoogroups.com  ] 
Sent: Wednesday, March 07, 2018 1:11 AM
lto%253acompass%252dusers@yahoogroups.com 
Subject: [compass-users] (unknown)

Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a DD,DD,DDD


Messsage #: 568
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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: compass-users@yahoogroups.com  
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. 

OA, 7 IAOOA 2018, 12:05 +03:00 IO 'Larry' lfish@fountainware.com
[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: compass-users@yahoogroups.com
  [mailto:compass-users@yahoogroups.com
 ] 
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 DEOAIUE 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 ?

IEOE EIIx 

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) }


Messsage #: 569
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: compass-users@yahoogroups.com  
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: compass-users@yahoogroups.com   [mailto:compass-users@yahoogroups.com] 
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:   compass-users@yahoogroups.com  
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?DD'D, 7 DD?,D 2018, 12:05 +03:00 D_, 'Larry' lfish@fountainware.com   [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: compass-users@yahoogroups.com   [mailto:compass-users@yahoogroups.com  ] 
Sent: Wednesday, March 07, 2018 1:11 AM
lto%253acompass%252dusers@yahoogroups.com 
Subject: [compass-users] (unknown)

Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a DD,DD,DDD


Messsage #: 570
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 smtp.auth=lexus-74@bk.ru smtp.mailfrom=lexus-74@bk.ru
Subject: =?UTF-8?B?UmVbNF06IFtjb21wYXNzLXVzZXJzXSAodW5rbm93bik=?From: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JDQutC40LzQvtCy?= 

Thanks my friends. I will try to understand.A

DD,DD?D3,  8 DD?,D 2018, 1:02 +03:00 D_, 'Paul De Bie' paul.de.bie@skynet.be [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: compass-users@yahoogroups.com  
Sent: Wednesday, March 7, 2018 10:56 PM
To: compass-users@yahoogroups.com
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. AA
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: compass-users@yahoogroups.com [ mailto:compass-users@yahoogroups.com ] 
Sent: Wednesday, March 07, 2018 2:29 PM
To: compass-users@yahoogroups..com
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: compass-users@yahoogroups.com  
Sent: Wednesday, March 7, 2018 9:41 PM
To: compass-users@yahoogroups.com
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?DD'D, 7 DD?,D 2018, 12:05 +03:00 D_, 'Larry'  lfish@fountainware.com [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: compass-users@yahoogroups.com [mailto: compass-users@yahoogroups.com ] 
Sent: Wednesday, March 07, 2018 1:11 AM
To: compass-users@yahoogroups.com
Subject: [compass-users] (unknown)
A
A 
Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a DD,DD,DDD


Messsage #: 571
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 smtp.auth=lexus-74@bk.ru smtp.mailfrom=lexus-74@bk.ru
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,DD?D3,  8 DD?,D 2018, 1:02 +03:00 D_, 'Paul De Bie' paul.de.bie@skynet.be [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: compass-users@yahoogroups.com  
Sent: Wednesday, March 7, 2018 10:56 PM
To: compass-users@yahoogroups.com
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. AA
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: compass-users@yahoogroups.com [ mailto:compass-users@yahoogroups.com ] 
Sent: Wednesday, March 07, 2018 2:29 PM
To: compass-users@yahoogroups..com
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: compass-users@yahoogroups.com  
Sent: Wednesday, March 7, 2018 9:41 PM
To: compass-users@yahoogroups.com
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?DD'D, 7 DD?,D 2018, 12:05 +03:00 D_, 'Larry'  lfish@fountainware.com [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: compass-users@yahoogroups.com [mailto: compass-users@yahoogroups.com ] 
Sent: Wednesday, March 07, 2018 1:11 AM
To: compass-users@yahoogroups.com
Subject: [compass-users] (unknown)
A
A 
Friends, I noticed that the program COMPASS distorts data of topo . For example I write down in a DD,DD,DDD


Messsage #: 572
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: kim_ty0527@yahoo.com

 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


Messsage #: 573
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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 


Messsage #: 574
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


Messsage #: 575
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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) }


Messsage #: 576
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' lfish@fountainware.com [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: compass-users@yahoogroups.com [mailto: compass-users@yahoogroups.com ] 
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' lfish@fountainware.com [compass-users] <compass-users@yahoogroups.com> 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: compass-users@yahoogroups.com [mailto: compass-users@yahoogroups.com ] 
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 


Messsage #: 577
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


Messsage #: 578
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 roger@r-schuster.de [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


Messsage #: 579
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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 roger@r-schuster.de [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) }


Messsage #: 580
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' lfish@fountainware.com [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: compass-users@yahoogroups.com
 [mailto:compass-users@yahoogroups.com] Sent: Sunday, May 20, 2018
 2:35 AM To: compass-users@yahoogroups.com
 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 roger@r-schuster.de [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


Messsage #: 581
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


Messsage #: 582
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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) }


Messsage #: 583
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


Messsage #: 584
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: compass-users@yahoogroups.com [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

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) }


Messsage #: 585
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' lfish@fountainware.com
[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:* compass-users@yahoogroups.com [mailto:compass-users@
 yahoogroups.com]
 *Sent:* Wednesday, July 11, 2018 1:39 PM
 *To:* compass-users@yahoogroups.com
 *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
derekbristol@gmail.com
(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' lfish@fountainware.com [compass-users] <compass-users@yahoogroups.com> 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

|AAAAAAAA |AAAAAAA |

|AAAAAAAA |AAAAAAA |

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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
Sent: Wednesday, July 11, 2018
1:39 PM
To: compass-users@yahoogroups.com
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 Bristolderekbristol@gmail.com(303) 589-4469 (mobile)(303) 284-9360 (home)


Messsage #: 586
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


Messsage #: 587
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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) }


Messsage #: 588
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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' lfish@fountainware.com
[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: compass-users@yahoogroups.com [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

derekbristol@gmail.com

(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) }


Messsage #: 589
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' lfish@fountainware.com 
[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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com]
 Sent: Wednesday, July 11, 2018
 3:28 PM
 To: compass-users@yahoogroups.com
 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' lfish@fountainware.com [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: compass-users@yahoogroups.com
 [mailto:compass-users@yahoogroups.com]
 Sent: Wednesday, July 11, 2018
 1:39 PM
 To: compass-users@yahoogroups.com
 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
 derekbristol@gmail.com
 (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' lfish@fountainware.com [compass-users]" <compass-users@yahoogroups.com>:

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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
Sent: Wednesday, July 11, 2018
3:28 PM
To: compass-users@yahoogroups.com
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' lfish@fountainware.com [compass-users]
<compass-users@yahoogroups.com>
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: compass-users@yahoogroups.com
[mailto:compass-users@yahoogroups.com]

Sent: Wednesday, July 11, 2018
1:39 PM
To: compass-users@yahoogroups.com
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

derekbristol@gmail.com

(303) 589-4469 (mobile)

(303) 284-9360 (home)


Messsage #: 590
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: rmiller@ronmiller.net

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


Messsage #: 591
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 

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) }


Messsage #: 592
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


Messsage #: 593
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


Messsage #: 594
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: compass-users@yahoogroups.com [mailto:compass-users@yahoogroups.com] 
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