Yahoo Archive - 2015 

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 #: 461
Date: Tue, 6 Jan 2015 10:36:10 -0500
Subject: Radio Location: Constrain X, Y, but not Z?
From: "David A. Riggs" 

Hi all,

We have a fairly large Compass project encompassing 75+ miles of
underground cave survey, tied together with a few miles of
high-accuracy surface survey. Unfortunately we're not blessed with the
benefit of numerous cave entrances, so we have instances of ~28 miles
of cave hanging off of two surface fixed points, and 40+ miles of cave
hanging off of two surface fixed points.

We've tried to supplement this problem with numerous radio location
surveys over the years, but the radio location points are frequently
of considerable depth; thus, we consider them to have high accuracy
with respect to X and Y, but less or even dubious accuracy with
respect to Z (depth).

The Compass manual mentions using Fixed Stations for radio location
surveys, but makes no specific mention of them with regard to actually
entering the data. What we would like, ideally, is to fix the X and Y
(East and North), but apply loop closure to Z (Vert). Or, since we
generally have more confidence in Z over the course of a cave survey,
it would probably be acceptable if we could omit Z for a Fixed Station
such that its Z value is determined entirely by the underground tie-in
(and thus also subject to loop closure).

Is anything like this possible currently in Compass, or if not, is it
a feature that others would find desirable?

- DR

David A. Riggs 


Messsage #: 462
Date: Tue, 6 Jan 2015 16:59:20 +0100 (CET)
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Paul De Bie 

Hi David,

you could enter the fixed stations with their coordinates at the File Node level
(right click File Node in the Editor).

As for avoiding the Z from being taken into account by the loop closure:
entering 0 will not produce the desired effect, I'm afraid, but you could give
the fixed point an arbitrary Z which is the same as the closest underground
survey station.

=��
 Op 6 januari 2015 om 16:36 schreef "'David A. Riggs' [email protected]
 [compass-users]" :

 Hi all,

 We have a fairly large Compass project encompassing 75+ miles of
 underground cave survey, tied together with a few miles of
 high-accuracy surface survey. Unfortunately we're not blessed with the
 benefit of numerous cave entrances, so we have instances of ~28 miles
 of cave hanging off of two surface fixed points, and 40+ miles of cave
 hanging off of two surface fixed points.

 We've tried to supplement this problem with numerous radio location
 surveys over the years, but the radio location points are frequently
 of considerable depth; thus, we consider them to have high accuracy
 with respect to X and Y, but less or even dubious accuracy with
 respect to Z (depth).

 The Compass manual mentions using Fixed Stations for radio location
 surveys, but makes no specific mention of them with regard to actually
 entering the data. What we would like, ideally, is to fix the X and Y
 (East and North), but apply loop closure to Z (Vert). Or, since we
 generally have more confidence in Z over the course of a cave survey,
 it would probably be acceptable if we could omit Z for a Fixed Station
 such that its Z value is determined entirely by the underground tie-in
 (and thus also subject to loop closure).

 Is anything like this possible currently in Compass, or if not, is it
 a feature that others would find desirable?

 - DR

 --
 David A. Riggs 

 ------------------------------------
 Posted by: "David A. Riggs" 
 ------------------------------------

 ------------------------------------

 Yahoo Groups Links
 
  .mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000}
  
   Hi David,
  
    
  
   you could enter the fixed stations with their coordinates at the File Node level (right click File Node in the Editor).
  
    
  
   As for avoiding the Z from being taken into account by the loop closure: entering 0 will not produce the desired effect, I'm afraid, but you could give the fixed point an arbitrary Z which is the same as the closest underground survey station. 
  
    
  
   Paul
  
   > Op 6 januari 2015 om 16:36 schreef "'David A. Riggs' [email protected] [compass-users]" <[email protected]>:
   > 
   > 
   > Hi all,
   > 
   > We have a fairly large Compass project encompassing 75+ miles of
   > underground cave survey, tied together with a few miles of
   > high-accuracy surface survey. Unfortunately we're not blessed with the
   > benefit of numerous cave entrances, so we have instances of ~28 miles
   > of cave hanging off of two surface fixed points, and 40+ miles of cave
   > hanging off of two surface fixed points.
   > 
   > We've tried to supplement this problem with numerous radio location
   > surveys over the years, but the radio location points are frequently
   > of considerable depth; thus, we consider them to have high accuracy
   > with respect to X and Y, but less or even dubious accuracy with
   > respect to Z (depth).
   > 
   > The Compass manual mentions using Fixed Stations for radio location
   > surveys, but makes no specific mention of them with regard to actually
   > entering the data. What we would like, ideally, is to fix the X and Y
   > (East and North), but apply loop closure to Z (Vert). Or, since we
   > generally have more confidence in Z over the course of a cave survey,
   > it would probably be acceptable if we could omit Z for a Fixed Station
   > such that its Z value is determined entirely by the underground tie-in
   > (and thus also subject to loop closure).
   > 
   > Is anything like this possible currently in Compass, or if not, is it
   > a feature that others would find desirable?
   > 
   > - DR
   > 
   > 
   > -- 
   > David A. Riggs <[email protected]>
   > 
   > 
   > ------------------------------------
   > Posted by: "David A. Riggs" <[email protected]>
   > ------------------------------------
   > 
   > 
   > ------------------------------------
   > 
   > Yahoo Groups Links
   > 
   > <*> To visit your group on the web, go to:
   > http://groups.yahoo.com/group/compass-users/
   > 
   > <*> Your email settings:
   > Individual Email | Traditional
   > 
   > <*> To change settings online go to:
   > http://groups.yahoo.com/group/compass-users/join
   > (Yahoo! ID required)
   > 
   > <*> To change settings via email:
   > [email protected] 
   > [email protected]
   > 
   > <*> To unsubscribe from this group, send an email to:
   > [email protected]
   > 
   > <*> Your use of Yahoo Groups is subject to:
   > https://info.yahoo.com/legal/us/yahoo/utos/terms/
   > 


Messsage #: 463
Date: Tue, 6 Jan 2015 13:15:50 -0800
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Tom 

I use control points in the project manager. They are high accuracy GPS with no surface survey tied into them. Larry added that feature at my request, which I use in the Marbles, CA. 
The radio location sounds like you want an station tie up to the surface from an underground survey?

Tom rl23455

On Tue, Jan 6, 2015 7:36 AM PST 'David A. Riggs' [email protected] [compass-users] wrote:

Hi all,

We have a fairly large Compass project encompassing 75+ miles of
underground cave survey, tied together with a few miles of
high-accuracy surface survey. Unfortunately we're not blessed with the
benefit of numerous cave entrances, so we have instances of ~28 miles
of cave hanging off of two surface fixed points, and 40+ miles of cave
hanging off of two surface fixed points.

We've tried to supplement this problem with numerous radio location
surveys over the years, but the radio location points are frequently
of considerable depth; thus, we consider them to have high accuracy
with respect to X and Y, but less or even dubious accuracy with
respect to Z (depth).

The Compass manual mentions using Fixed Stations for radio location
surveys, but makes no specific mention of them with regard to actually
entering the data. What we would like, ideally, is to fix the X and Y
(East and North), but apply loop closure to Z (Vert). Or, since we
generally have more confidence in Z over the course of a cave survey,
it would probably be acceptable if we could omit Z for a Fixed Station
such that its Z value is determined entirely by the underground tie-in
(and thus also subject to loop closure).

Is anything like this possible currently in Compass, or if not, is it
a feature that others would find desirable?

- DR

-- 
David A. Riggs 

------------------------------------
Posted by: "David A. Riggs" 
------------------------------------

------------------------------------

Yahoo Groups Links


Messsage #: 464
Date: Tue, 6 Jan 2015 16:04:36 -0700
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: "Larry" 

Hi David,

Thanks for the question. Here are my general thoughts on radio locations and
how to use them in Compass

I don't think even the X,Y aspect radio stations are as accurate as most
people believe. It is obvious that the depth measurements from a radio
location are not highly accurate because it requires an accurate measurement
of the angle of the inclination of the magnetic field, particularly when the
cave is deep. However, similar problems apply to X,Y aspect of a radio
location. There are several sources of error for the X/Y aspect of Radio
locations:

1. In order for the X,Y aspect to be accurate, both coils must be absolutely
horizontal. Most cave radios use a Spirit Level to make the coils
horizontal. Depending on the curve of the glass in the Spirit Level, the
accuracy can be as little as 2 degrees per millimeter of bubble
displacement.

http://www.leveldevelopments.com/sensitivity-explained/

In addition, the spirit level must be attached to the coil so it is at a
perfect right angle to the plane of the coil. Cave radios are generally
home-made devices and so they lack the precision of a factory-made product.
Even if they were factory-made, that wouldn't guarantee any higher accuracy
than the typical instruments we use for regular surveying. For example, even
a precision-made product like a Suunto Inclinometer only has a resolution of
1 Degree. That means it very unlikely that a cave radio could leveled more
precisely than 2 degrees. A 2-degree error in level would produce position
errors of 16 feet at 500 feet of depth.

Finally, just like other cave instruments, spirit levels are subject to the
same type of reading errors that compasses and inclinometers are, especially
in the harsh cave environment. Judging by the number of blunders I see in
ordinary cave survey measurement, it wouldn't be surprised if you had large
numbers of leveling blunders attributable to human error and the harsh
environment.

2. Even if the coils are perfectly horizontal, distortions in the magnetic
field can be produced by the way the coils are manufactured. The coil itself
should be symetrical and as flat as possible, without any folds or bumps, or
the field may be distorted. Again, home-made coils are not likely to be
flat, especially if the coils are made to fold for easy transport through
the cave. 

3. In addition, the rock above and around the cave may affect the magnetic
field. Most limestone deposits have pyrite and limemonite deposits that can
distort the magnetic field. This is particularly true around joints and
faults were caves are concentrated and ground water has the most chance to
redeposit minerals. Finally, changes in the saturation of ground water can
affect the magnet field. As an example of this type of phenomena, there are
large magnetic distortions in the magnetic field in Lechuguilla cave near
the "Rift" area. I also have an aviation map that warns of large magnetic
compass deflection near Manitou Springs, Colorado, which is one of our
favorite caving areas.

This is what Ian Drummond said about the magnet field distortions:

"Unfortunately the effect of the conductive ground is not just to weaken the
intensity of the magnetic field, but also to induce a component which is out
of phase. As a result the magnetic field on the surface above the cave is no
longer plane-polarized, but rotating."

http://caves.org/section/commelect/drupal/files/Speleonics/splncs07.pdf

If the magnetic field is no longer "plane-polarized" then the peak position
of the radio signal is likely to be offset from the actual underground
position of the transmitter.

Here is a summary of the types of errors with radio locations:

http://www.chaos.org.uk/survex/cp/CP10/CPoint10.htm

For all these reason, I wouldn't put too much faith in a Radio Location. I
think about Radio Locations as them being the equivalent of any other survey
shot, with similar uncertainties about their accuracy. In fact, the only
thing that makes them accurate is the fact that they are directly tied to a
GPS location, but the same thing could be said about the first shot from an
entrance GPS station.

In my opinion, the best way to use a radio location is to connect it to the
cave with a an artificial vertical shot. I would not enter it as a fixed
station, with the X,Y taken from the GPS and the Z derived by subtracting
the depth.

What I'd do is enter a fixed GPS location for the place on the surface where
the radio location was taken. Then you would add an artificial vertical shot
with an inclination of -90 and a length equal to the radio depth
measurement. Compass would then treat it as an ordinary survey shot with the
same error processing as a regular shot.

Compass adjusts the X, Y and Z aspects of the survey separately. Since the X
and Y offsets from the GPS location to the cave, will be zero, Compass will
perform very little adjustment on the X/Y values. On the other hand, the Z
aspect of the shot will be much larger, so Compass will perform more
adjustment on it. 

Setting up fixed stations is described in the Project Manager's help file.
Let me know if you have any questions.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, January 06, 2015 8:36 AM
Subject: [compass-users] Radio Location: Constrain X, Y, but not Z?

Hi all,

We have a fairly large Compass project encompassing 75+ miles of
underground cave survey, tied together with a few miles of
high-accuracy surface survey. Unfortunately we're not blessed with the
benefit of numerous cave entrances, so we have instances of ~28 miles
of cave hanging off of two surface fixed points, and 40+ miles of cave
hanging off of two surface fixed points.

We've tried to supplement this problem with numerous radio location
surveys over the years, but the radio location points are frequently
of considerable depth; thus, we consider them to have high accuracy
with respect to X and Y, but less or even dubious accuracy with
respect to Z (depth).

The Compass manual mentions using Fixed Stations for radio location
surveys, but makes no specific mention of them with regard to actually
entering the data. What we would like, ideally, is to fix the X and Y
(East and North), but apply loop closure to Z (Vert). Or, since we
generally have more confidence in Z over the course of a cave survey,
it would probably be acceptable if we could omit Z for a Fixed Station
such that its Z value is determined entirely by the underground tie-in
(and thus also subject to loop closure).

Is anything like this possible currently in Compass, or if not, is it
a feature that others would find desirable?

- DR

David A. Riggs 

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 #: 465
Date: Tue, 06 Jan 2015 18:32:17 -0500
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Tony Canike 

That's exactly what I do.   Sometimes I even remember to exclude the 
length of the artificial vertical shot.

Another advantage of Larry's suggested approach is all your numerical 
inputs are documented in the data files and can be reviewed later.  That 
is, the elevation of the surface at the GPS location is documented in 
the elevation for the fixed station, and the radio location depth is 
documented in the length of the artificial vertical shot.  Thus, if you 
find later you had a bad surface elevation, you can fix it unambigiously.

If you subtract the radio location depth from the surface elevation, 
then there is just one number, and your successor may have no idea how 
it was calculated.

On 1/6/2015 6:04 PM, 'Larry' [email protected] [compass-users] 
([email protected]) wrote

 In my opinion, the best way to use a radio location is to connect it 
 to the cave with a an artificial vertical shot. I would not enter it 
 as a fixed station, with the X,Y taken from the GPS and the Z derived 
 by subtracting the depth.

 What I'd do is enter a fixed GPS location for the place on the surface 
 where the radio location was taken. Then you would add an artificial 
 vertical shot with an inclination of -90 and a length equal to the 
 radio depth measurement. Compass would then treat it as an ordinary 
 survey shot with the same error processing as a regular shot.
  
    That's exactly what I do.�� Sometimes I even remember to exclude the
    length of the artificial vertical shot.
    
    Another advantage of Larry's suggested approach is all your
    numerical inputs are documented in the data files and can be
    reviewed later.� That is, the elevation of the surface at the GPS
    location is documented in the elevation for the fixed station, and
    the radio location depth is documented in the length of the
    artificial vertical shot.� Thus, if you find later you had a bad
    surface elevation, you can fix it unambigiously.
    
    If you subtract the radio location depth from the surface elevation,
    then there is just one number, and your successor may have no idea
    how it was calculated.
    
    On 1/6/2015 6:04 PM, 'Larry'
      [email protected] [compass-users]
      ([email protected]) wrote
    
      In my opinion,
            the best way to use a radio location is to
            connect it to the cave with a an artificial vertical shot. I
            would not enter it
            as a fixed station, with the X,Y taken from the GPS and the
            Z derived by
            subtracting the depth.
      What I'd do is
            enter a fixed GPS location for the place on
            the surface where the radio location was taken. Then you
            would add an
            artificial vertical shot with an inclination of -90 and a
            length equal to the
            radio depth measurement. Compass would then treat it as an
            ordinary survey shot
            with the same error processing as a regular shot.


Messsage #: 466
Date: Wed, 7 Jan 2015 08:45:46 +0100 (CET)
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Paul De Bie 

It's indeed one of the possibile approaches but then you also have to exclude
the shot from plotting (which is possible by using the P flag), otherwise the
cave will look quite unrealistic with such vertical "artificial" shots. And my
experience is that, excluding things from plotting, is not such a good idea. You
don't see them anymore and as time goes by, you forget they are there. But they
still live their life... playing a role in loop closure etc. :-)  Just my 2 c.

About precision of radio locations: I'm sure Larry is right by warning us for
the mediocre precision but: we have done several radiolocations that have
resulted in artifical entrances being dug afterwards. In most cases, the depth
was minimal of course, but in one case, it was for a tourist cave that wanted to
drill an elevator shaft through 50 m of rock. When the shaft was finally made,
it was only 0.5 m away from the spot that we had pinpointed with the radio. I'm
quite sure that if we had done a precision survey connecting the surface with
the underground galery (several 100's of metres of surveying), the precision
would not have bene better, maybe even worse...

=��
 Op 7 januari 2015 om 0:32 schreef "Tony Canike [email protected]
 [compass-users]" :
 
  That's exactly what I do.   Sometimes I even remember to exclude the length
 of the artificial vertical shot.
 
  Another advantage of Larry's suggested approach is all your numerical inputs
 are documented in the data files and can be reviewed later.  That is, the
 elevation of the surface at the GPS location is documented in the elevation
 for the fixed station, and the radio location depth is documented in the
 length of the artificial vertical shot.  Thus, if you find later you had a bad
 surface elevation, you can fix it unambigiously.
 
  If you subtract the radio location depth from the surface elevation, then
 there is just one number, and your successor may have no idea how it was
 calculated.
 
  On 1/6/2015 6:04 PM, 'Larry' [email protected]
  [compass-users] (
 [email protected]  ) wrote
        
       In my opinion, the best way to use a radio location is to connect it to
  the cave with a an artificial vertical shot. I would not enter it as a fixed
  station, with the X,Y taken from the GPS and the Z derived by subtracting
  the depth.
  
       What I'd do is enter a fixed GPS location for the place on the surface
  where the radio location was taken. Then you would add an artificial
  vertical shot with an inclination of -90 and a length equal to the radio
  depth measurement. Compass would then treat it as an ordinary survey shot
  with the same error processing as a regular shot.
  
        .mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000}
  
   It's indeed one of the possibile approaches but then you also have to exclude the shot from plotting (which is possible by using the P flag), otherwise the cave will look quite unrealistic with such vertical "artificial" shots. And my experience is that, excluding things from plotting, is not such a good idea. You don't see them anymore and as time goes by, you forget they are there. But they still live their life... playing a role in loop closure etc. :-)  Just my 2 c.
  
    
  
   About precision of radio locations: I'm sure Larry is right by warning us for the mediocre precision but: we have done several radiolocations that have resulted in artifical entrances being dug afterwards. In most cases, the depth was minimal of course, but in one case, it was for a tourist cave that wanted to drill an elevator shaft through 50 m of rock. When the shaft was finally made, it was only 0.5 m away from the spot that we had pinpointed with the radio. I'm quite sure that if we had done a precision survey connecting the surface with the underground galery (several 100's of metres of surveying), the precision would not have bene better, maybe even worse...
  
    
  
   Paul
  
   Op 7 januari 2015 om 0:32 schreef "Tony Canike [email protected] [compass-users]" <[email protected]>:
    
    That's exactly what I do.   Sometimes I even remember to exclude the length of the artificial vertical shot.
    
    Another advantage of Larry's suggested approach is all your numerical inputs are documented in the data files and can be reviewed later.  That is, the elevation of the surface at the GPS location is documented in the elevation for the fixed station, and the radio location depth is documented in the length of the artificial vertical shot.  Thus, if you find later you had a bad surface elevation, you can fix it unambigiously.
    
    If you subtract the radio location depth from the surface elevation, then there is just one number, and your successor may have no idea how it was calculated.
   
    On 1/6/2015 6:04 PM, 'Larry' 
    [email protected] [compass-users] (
    [email protected]) wrote
    
    In my opinion, the best way to use a radio location is to connect it to the cave with a an artificial vertical shot. I would not enter it as a fixed station, with the X,Y taken from the GPS and the Z derived by subtracting the depth. 
    What I'd do is enter a fixed GPS location for the place on the surface where the radio location was taken. Then you would add an artificial vertical shot with an inclination of -90 and a length equal to the radio depth measurement. Compass would then treat it as an ordinary survey shot with the same error processing as a regular shot. 
  
    


Messsage #: 467
Date: Wed, 7 Jan 2015 11:19:48 -0500
Subject: IGRF-12 Magnetic Model
From: "David A. Riggs" 

Hi Larry,

The IGRF-12 Model was released in December, and went into effect Jan 1.

I see on your downloads page that there was an unannounced release of
Compass on Jan 1. Does this include the new IGRF coefficients for 2015
- 2020 magnetic declinations?

Thanks!

- DR

David A. Riggs 


Messsage #: 468
Date: Wed, 7 Jan 2015 17:51:42 +0100
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: "Paul De Bie" 

Tom can you explain where/how you enter these in Compass? I wouldn't know where to find these
"control points" in the Project Manager. 
I only know about the link/fixed stations in the File Nodes
tx

Paul De Bie
http://www.scavalon.be
http://scavalon.blogspot.com
 -----Original Message-----
 From: [email protected] [mailto:[email protected]]
 Sent: Tuesday, January 06, 2015 10:16 PM
 To: [email protected]
 Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
 
 I use control points in the project manager. They are high accuracy GPS with no surface survey
 tied into them. Larry added that feature at my request, which I use in the Marbles, CA.
 The radio location sounds like you want an station tie up to the surface from an underground
 survey?
 
 Tom rl23455
 
 ------------------------------
 On Tue, Jan 6, 2015 7:36 AM PST 'David A. Riggs' [email protected] [compass-users] wrote:
 
 Hi all,
 
 We have a fairly large Compass project encompassing 75+ miles of
 underground cave survey, tied together with a few miles of
 high-accuracy surface survey. Unfortunately we're not blessed with the
 benefit of numerous cave entrances, so we have instances of ~28 miles
 of cave hanging off of two surface fixed points, and 40+ miles of cave
 hanging off of two surface fixed points.
 
 We've tried to supplement this problem with numerous radio location
 surveys over the years, but the radio location points are frequently
 of considerable depth; thus, we consider them to have high accuracy
 with respect to X and Y, but less or even dubious accuracy with
 respect to Z (depth).
 
 The Compass manual mentions using Fixed Stations for radio location
 surveys, but makes no specific mention of them with regard to actually
 entering the data. What we would like, ideally, is to fix the X and Y
 (East and North), but apply loop closure to Z (Vert). Or, since we
 generally have more confidence in Z over the course of a cave survey,
 it would probably be acceptable if we could omit Z for a Fixed Station
 such that its Z value is determined entirely by the underground tie-in
 (and thus also subject to loop closure).
 
 Is anything like this possible currently in Compass, or if not, is it
 a feature that others would find desirable?
 
 - DR
 
 --
 David A. Riggs 
 
 ------------------------------------
 Posted by: "David A. Riggs" 
 ------------------------------------
 
 ------------------------------------
 
 Yahoo Groups Links
 
 ------------------------------------
 Posted by: Tom 
 ------------------------------------
 
 ------------------------------------
 
 Yahoo Groups Links


Messsage #: 469
Date: Wed, 7 Jan 2015 18:06:18 +0000 (UTC)
Content-Length: 11892
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Tom 

Sorry, that is what I meant. link/fixed stations in file node.A�You can create ones that don't have to be tied to any survey
A�      From: "'Paul De Bie' [email protected] [compass-users]" 
 To: [email protected] 
 Sent: Wednesday, January 7, 2015 8:51 AM
 Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
   
Tom can you explain where/how you enter these in Compass? I wouldn't know where to find these
"control points" in the Project Manager. 
I only know about the link/fixed stations in the File Nodes
tx

Paul De Bie
http://www.scavalon.be
http://scavalon.blogspot.com
 -----Original Message-----
 From: [email protected] [mailto:[email protected]]
 Sent: Tuesday, January 06, 2015 10:16 PM
 To: [email protected]
 Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
 
 I use control points in the project manager. They are high accuracy GPS with no surface survey
 tied into them. Larry added that feature at my request, which I use in the Marbles, CA.
 The radio location sounds like you want an station tie up to the surface from an underground
 survey?
 
 Tom rl23455
 
 ------------------------------
 On Tue, Jan 6, 2015 7:36 AM PST 'David A. Riggs' [email protected] [compass-users] wrote:
 
 Hi all,
 
 We have a fairly large Compass project encompassing 75+ miles of
 underground cave survey, tied together with a few miles of
 high-accuracy surface survey. Unfortunately we're not blessed with the
 benefit of numerous cave entrances, so we have instances of ~28 miles
 of cave hanging off of two surface fixed points, and 40+ miles of cave
 hanging off of two surface fixed points.
 
 We've tried to supplement this problem with numerous radio location
 surveys over the years, but the radio location points are frequently
 of considerable depth; thus, we consider them to have high accuracy
 with respect to X and Y, but less or even dubious accuracy with
 respect to Z (depth).
 
 The Compass manual mentions using Fixed Stations for radio location
 surveys, but makes no specific mention of them with regard to actually
 entering the data. What we would like, ideally, is to fix the X and Y
 (East and North), but apply loop closure to Z (Vert). Or, since we
 generally have more confidence in Z over the course of a cave survey,
 it would probably be acceptable if we could omit Z for a Fixed Station
 such that its Z value is determined entirely by the underground tie-in
 (and thus also subject to loop closure).
 
 Is anything like this possible currently in Compass, or if not, is it
 a feature that others would find desirable?
 
 - DR
 
 --
 David A. Riggs 
 
 ------------------------------------
 Posted by: "David A. Riggs" 
 ------------------------------------
 
 ------------------------------------
 
 Yahoo Groups Links
 
 ------------------------------------
 Posted by: Tom 
 ------------------------------------
 
 ------------------------------------
 
 Yahoo Groups Links

Posted by: "Paul De Bie" 

Yahoo Groups Links

Sorry, that is what I meant. link/fixed stations in file node. You can create ones that don't have to be tied to any survey        From: "'Paul De Bie' [email protected] [compass-users]" <[email protected]> To: [email protected]  Sent: Wednesday, January 7, 2015 8:51 AM Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?   Tom can you explain where/how you enter these in Compass? I wouldn't know where to find these"control points" in the Project Manager. I only know about the link/fixed stations in the File NodestxPaul De Biehttp://www.scavalon.behttp://scavalon.blogspot.com> -----Original Message-----> From: [email protected] [mailto:[email protected]]> Sent: Tuesday, January 06, 2015 10:16 PM> To: [email protected]> Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?> > > > I use control points in the project manager. They are high accuracy GPS with no surface survey> tied into them. Larry added that feature at my request, which I use in the Marbles, CA.> The radio location sounds like you want an station tie up to the surface from an underground> survey?> > Tom rl23455> > > [email protected]"[email protected] [compass-users] wrote:> > >Hi all,> >> >We have a fairly large Compass project encompassing 75+ miles of> >underground cave survey, tied together with a few miles of> >high-accuracy surface survey. Unfortunately we're not blessed with the> >benefit of numerous cave entrances, so we have instances of ~28 miles> >of cave hanging off of two surface fixed points, and 40+ miles of cave> >hanging off of two surface fixed points.> >> >We've tried to supplement this problem with numerous radio location> >surveys over the years, but the radio location points are frequently> >of considerable depth; thus, we consider them to have high accuracy> >with respect to X and Y, but less or even dubious accuracy with> >respect to Z (depth).> >> >The Compass manual mentions using Fixed Stations for radio location> >surveys, but makes no specific mention of them with regard to actually> >entering the data. What we would like, ideally, is to fix the X and Y> >(East and North), but apply loop closure to Z (Vert). Or, since we> >generally have more confidence in Z over the course of a cave survey,> >it would probably be acceptable if we could omit Z for a Fixed Station> >such that its Z value is determined entirely by the underground tie-in> >(and thus also subject to loop closure).> >> >Is anything like this possible currently in Compass, or if not, is it> >a feature that others would find desirable?> >> >- DR> >> >> >--> >David A. Riggs <[email protected]>> >> >> >------------------------------------> >Posted by: "David A. Riggs" <[email protected]>> >------------------------------------> >> >> >------------------------------------> >> >Yahoo Groups Links> >> >> >> > > > ------------------------------------> Posted by: Tom <[email protected]>> ------------------------------------> > > ------------------------------------> > Yahoo Groups Links> > > [email protected]" ymailto="mailto:[email protected]"[email protected]>------------------------------------------o visit your group on the web, go to:    http://groups.yahoo.com/group/compass-users/<*> Your email settings:    Individual Email | Traditional<*> To change settings online go to:    http://groups.yahoo.com/group/compass-users/join    (Yahoo! ID required)<*> To change settings via email:    [email protected]     [email protected]<*> To unsubscribe from this group, send an email to:    [email protected]<*> Your use of Yahoo Groups is subject to:    https://info.yahoo.com/legal/us/yahoo/utos/terms/    


Messsage #: 470
Authentication-Results: cox.net; none
Date: Wed, 7 Jan 2015 16:01:06 -0700
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Paul Jorgenson KE7HR 

Remember, also, that GPS, unless it is one of the "survey grade" receivers with either real time or post processed corrections to the field calculated position, is likely no better than 10 to 30 feet (3 to 10 meters) accurate in X and Y with modern (high sensitivity) consumer grade GPS units.  Elevation uncertainty in GPS calculated positions are around twice as uncertain as the X and Y uncertainty, no matter what receivers you are using.  Is that good enough for what you are trying to constrain?  Each user will have to make that decision.

In many instances, having a GPS location on an entrance is better than not having another good geo-reference but the accuracy of one entrance or location to another in the same area has uncertainties that are hard to quantify with consumer grade instruments.  Trees or other obstructions can also hinder the process.

Paul Jorgenson KE7HR


Messsage #: 471
Date: Thu, 8 Jan 2015 03:56:01 -0700
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: "Larry" 

Paul - Excellent Point! I hadn't really thought about the errors/uncertainty
in GPS readings.

Thanks to everyone for an excellent discussion. Since I periodically get
questions about the radio locations, I decided to collect a bunch of the
ideas and post them on the Compass web page. Here a link to the document:

http://www.fountainware.com/compass/Tutorials/RadioLocations.htm

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Wednesday, January 07, 2015 4:01 PM
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?

Remember, also, that GPS, unless it is one of the "survey grade" receivers
with either real time or post processed corrections to the field calculated
position, is likely no better than 10 to 30 feet (3 to 10 meters) accurate
in X and Y with modern (high sensitivity) consumer grade GPS units.
Elevation uncertainty in GPS calculated positions are around twice as
uncertain as the X and Y uncertainty, no matter what receivers you are
using. Is that good enough for what you are trying to constrain? Each user
will have to make that decision.

In many instances, having a GPS location on an entrance is better than not
having another good geo-reference but the accuracy of one entrance or
location to another in the same area has uncertainties that are hard to
quantify with consumer grade instruments. Trees or other obstructions can
also hinder the process.

Paul Jorgenson KE7HR

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 #: 472
Authentication-Results: cox.net; none
Date: Thu, 8 Jan 2015 5:48:35 -0700
Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: Paul Jorgenson KE7HR 

I worked on a single entrance cave, a long stream passage, so few loops to help constrain the low ceiling, down in the mud shots.  Years later, a tiny single room "nothing" cave was found.  Years after that, the bulb went off, they might be related and GPS (with averaging many readings over a day) were done and the small cave appeared to be about 60 feet away from the known passage for the long cave below.  That was close enough for a radio location try (the long cave was pretty shallow).  With a radio location it turned out that the small cave was directly over a side passage in the long cave below!  That and a survey station was recovered in the passage below from the 20 years previous survey!  The careful GPS readings were not enough!  A mud filled dig finally connected the two and an air gate was put in to keep from changing the air flow.

Moral of the story: the survey instruments, radio location gear, and the GPS are only tools.  You have to understand the limitations of all of them to get to locally acceptable results.

Paul Jorgenson KE7HR

 Paul - Excellent Point! I hadn't really thought about the errors/uncertainty
 in GPS readings.
 
 Thanks to everyone for an excellent discussion. Since I periodically get
 questions about the radio locations, I decided to collect a bunch of the
 ideas and post them on the Compass web page. Here a link to the document:
 
 http://www.fountainware.com/compass/Tutorials/RadioLocations.htm
 
 Larry
 
   _____  
 
 From: [email protected] [mailto:[email protected]] 
 Sent: Wednesday, January 07, 2015 4:01 PM
 To: [email protected]
 Subject: RE: [compass-users] Radio Location: Constrain X, Y, but not Z?
 
 Remember, also, that GPS, unless it is one of the "survey grade" receivers
 with either real time or post processed corrections to the field calculated
 position, is likely no better than 10 to 30 feet (3 to 10 meters) accurate
 in X and Y with modern (high sensitivity) consumer grade GPS units.
 Elevation uncertainty in GPS calculated positions are around twice as
 uncertain as the X and Y uncertainty, no matter what receivers you are
 using. Is that good enough for what you are trying to constrain? Each user
 will have to make that decision.
 
 In many instances, having a GPS location on an entrance is better than not
 having another good geo-reference but the accuracy of one entrance or
 location to another in the same area has uncertainties that are hard to
 quantify with consumer grade instruments. Trees or other obstructions can
 also hinder the process.
 
 Paul Jorgenson KE7HR

Paul Jorgenson  KE7HR 


Messsage #: 473
Date: Thu, 8 Jan 2015 12:04:52 -0500
Subject: Re: [compass-users] Radio Location: Constrain X, Y, but not Z?
From: "David A. Riggs" 

On Thu, Jan 8, 2015 at 5:56 AM, 'Larry' [email protected]
[compass-users]  wrote:

 Paul - Excellent Point! I hadn�?Tt really thought about the errors/uncertainty in GPS readings.

Not all Fixed Stations are (entirely) from GPS receivers!

As I mentioned, we have a high-accuracy Total Station surface survey
that links caves, aerial photo identifiable surface locations, and
standard benchmark points. We consider the Fixed Stations in this
surface survey to be "gospel", and have redundant information backing
up each of them.

When we use GPS for Fixed Stations, we use a 3-meter resolution
Digital Elevation Model with 1-foot elevation precision for Z, and we
augment X and Y with aerial photos or DEM contours.

Not all projects have that luxury, and while it's worth reminding
people entirely dependent on GPS of its variable limitations, please
don't compensate for them by default!

 Thanks to everyone for an excellent discussion. Since I periodically get questions about the radio locations, I decided to collect a bunch of the ideas and post them on the Compass web page. Here a link to the document:

 http://www.fountainware.com/compass/Tutorials/RadioLocations.htm

Larry, thank you for your suggestion on how to best treat our radio
location data in Compass (and for making this info public!). We're
going to follow your best practices in this regard.

Thanks everyone!

- DR

David A. Riggs 


Messsage #: 474
Date: Sat, 10 Jan 2015 17:06:38 +1100
Subject: Mixed-accuracy surveys
From: Ric Tunney 

Hi all,

I have a traverse incorporating a mix of highly-accurate (we hope!) 
Disto X2 parts and some very dodgy parts. I'm having no trouble with the 
highly-accurate bits as we ALWAYS do it that way. (Laughs)

Parts of the traverse were done by a solo diver in 4 cm visibility water 
using knotted string (2 m intervals!) and orienteering compass on a 
slate. Let's say 10 degrees is really good here. Even if the compass can 
be seen, there's no certainty it's pointing in the right direction! 
Other parts of the survey were done by the same solo diver in diving 
gear using (an old, potentially disposable) Disto and Suunto compass and 
clino while swimming / wading.

As an example, one short, 50% underwater, side loop 50m long had a 16 m 
miss-closure! Running that over the full loop would badly affect the 
not-so-bad legs.

The survey runs from a well-fixed point inside a cave to a GPS point 
outside, so I can get Compass to do a closure on the whole traverse.

So, how do I tell Compass to handle the varying accuracy? The 
Options/Settings seems to apply to the entire Project. I'd like the 
better bits to be relatively unaffected by the loop closure in 
comparison to the bad bits. But I can't say the better bits are so good 
as not to be affected by the closure.

Cheers
Ric
Southern Tasmanian Caverneers


Messsage #: 475
Date: Sat, 10 Jan 2015 04:22:16 -0700
Subject: RE: [compass-users] IGRF-12 Magnetic Model
From: "Larry" 

Hi David,

I had forgotten about the magnetic models needing to be updated for 2015-
thanks for the reminder.

I just installed the new models in Compass and they now cover 2015 up to
2020. The new versions are up on the internet. The update applies to the
main Compass installation and the DEM Reader.

Let me know if you have any questions.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Wednesday, January 07, 2015 9:20 AM
Subject: [compass-users] IGRF-12 Magnetic Model

Hi Larry,

The IGRF-12 Model was released in December, and went into effect Jan 1.

I see on your downloads page that there was an unannounced release of
Compass on Jan 1. Does this include the new IGRF coefficients for 2015
- 2020 magnetic declinations?

Thanks!

- DR

David A. Riggs 

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 #: 476
Date: 21 Jan 2015 15:28:26 -0800
Subject: Re: Mixed-accuracy surveys
From: [email protected]

hi Ric
as we do with the accurate Bullita traverses "C" flag the shots that are accurate and let the other shots hang and do their own sorting out. 
Bob

hi Ricas we do with the accurate Bullita traverses "C" flag the shots that are accurate and let the other shots hang and do their own sorting out. Bob


Messsage #: 477
Date: Thu, 22 Jan 2015 16:41:45 +1100
Subject: Re: [compass-users] Re: Mixed-accuracy surveys
From: Ric Tunney 

I'll give it a try. Thanks Bob.
On 22/01/2015 10:28 AM, [email protected] [compass-users] wrote:

 hi Ric
 as we do with the accurate Bullita traverses "C" flag the shots that 
 are accurate and let the other shots hang and do their own sorting out.
 Bob
  
    I'll give it a try. Thanks Bob.
    On 22/01/2015 10:28 AM,
      [email protected] [compass-users] wrote:
    
     A�
          
            hi Ric
              as we do with the accurate Bullita traverses "C" flag the
              shots that are accurate and let the other shots hang and
              do their own sorting out. 
              Bob


Messsage #: 478
Date: Tue, 3 Feb 2015 12:25:30 -0500
Subject: Davies - Python Compass Library
From: "David A. Riggs" 

Hi all,

Like many of you (?), I've written lots of small scripts over the
years for querying or manipulating Compass cave survey data. As my
needs progressed beyond simple shell pipelines to tasks like creating
time-series geospatial reports, these scripts grew into a full-blown
Python language library.

I've made it available Freely under an open source (MIT) license.
Davies, named in honor of William E. Davies, currently supports:

* Reading .PRJ and .DAT files, including most features used by
"compass and tape" dry cave surveys
* Reading compiled (loop closed) .PLT files
* Writing .DAT files

If you don't know what "Python" means, then this library probably
isn't for you. :-)

But, if you're looking for a way to run advanced queries on your
Compass data... or batch modify a large pile of survey data... or do
custom 3D visualizations... or write a native Mac/Linux Compass editor
(see examples folder)... or write a masters thesis by applying graph
theory to a cave system... or build an autonomous cave survey robot
from a RaspberryPi... you may find Davies helpful!

The source code lives at:

   https://github.com/riggsd/davies

Online documentation is at:

   http://davies.readthedocs.org/en/latest/#

Davies requires Python 2.7 (test cases appear to run correctly on
Python 3, but examples are written with Python 2 syntax). Provided
you've got a working Python 2.7 installation, you can probably install
it with:

   $ pip install davies

or

   $ easy_install davies

The 'examples' folder contains a few example query scripts, as well as
"toy" GUI clients written with the Tk or WxWidgets toolkits.

Any feedback, bug reports, or feature suggestions are welcome. It was
written to "scratch my own itch", but I hope it can help others out as
well.

NOTE: This is absolutely not an "official" Compass project, so please
don't bother Larry or bog down the Compass Users email list if you
have detailed questions or bug reports. Feel free to email me
directly, or to file bug reports ("Issues") at the GitHub link above.

- DR

David A. Riggs 


Messsage #: 479
Date: Tue, 3 Feb 2015 17:31:34 +0000
authentication-results: yahoogroups.com; dkim=none (message not signed)
 header.d=none;
Subject: Re: [compass-users] Davies - Python Compass Library
From: "Addison, Aaron" 

David,

This is great stuff, thanks for you work on this project!

If I had the time, I would very much like to do the similar things with python and Walls.

?

Cheers,

Aaron

Aaron Addison | Director, Data & GIS Services

University Libraries | Washington University in St. Louis

1 Brookings Drive  CB 1061 | St. Louis, MO 63130-4899

T: 314 935 6198 | E:[email protected]

________________________________
From: [email protected]  on behalf of 'David A. Riggs' [email protected] [compass-users] 
Sent: Tuesday, February 3, 2015 11:25 AM
Subject: [compass-users] Davies - Python Compass Library

Hi all,

Like many of you (?), I've written lots of small scripts over the
years for querying or manipulating Compass cave survey data. As my
needs progressed beyond simple shell pipelines to tasks like creating
time-series geospatial reports, these scripts grew into a full-blown
Python language library.

I've made it available Freely under an open source (MIT) license.
Davies, named in honor of William E. Davies, currently supports:

* Reading .PRJ and .DAT files, including most features used by
"compass and tape" dry cave surveys
* Reading compiled (loop closed) .PLT files
* Writing .DAT files

If you don't know what "Python" means, then this library probably
isn't for you. :-)

But, if you're looking for a way to run advanced queries on your
Compass data... or batch modify a large pile of survey data... or do
custom 3D visualizations... or write a native Mac/Linux Compass editor
(see examples folder)... or write a masters thesis by applying graph
theory to a cave system... or build an autonomous cave survey robot
from a RaspberryPi... you may find Davies helpful!

The source code lives at:

https://github.com/riggsd/davies

Online documentation is at:

http://davies.readthedocs.org/en/latest/#

Davies requires Python 2.7 (test cases appear to run correctly on
Python 3, but examples are written with Python 2 syntax). Provided
you've got a working Python 2.7 installation, you can probably install
it with:

$ pip install davies

or

$ easy_install davies

The 'examples' folder contains a few example query scripts, as well as
"toy" GUI clients written with the Tk or WxWidgets toolkits.

Any feedback, bug reports, or feature suggestions are welcome. It was
written to "scratch my own itch", but I hope it can help others out as
well.

NOTE: This is absolutely not an "official" Compass project, so please
don't bother Larry or bog down the Compass Users email list if you
have detailed questions or bug reports. Feel free to email me
directly, or to file bug reports ("Issues") at the GitHub link above.

- DR

David A. Riggs 

David,

This is great stuff, thanks for you work on this project!

If I had the time, I would very much like to do the similar things with python and Walls.

​

Cheers,

Aaron

Aaron Addison | Director, Data & GIS Services 
University Libraries | Washington University in St. Louis
1 Brookings Drive  CB 1061 | St. Louis, MO 63130-4899
T: 314 935 6198 | E:[email protected]

From: [email protected] <[email protected]> on behalf of 'David A. Riggs' [email protected] [compass-users] <[email protected]>
Sent: Tuesday, February 3, 2015 11:25 AM
To: [email protected]
Subject: [compass-users] Davies - Python Compass Library
 

 

Hi all,

Like many of you (?), I've written lots of small scripts over the
years for querying or manipulating Compass cave survey data. As my
needs progressed beyond simple shell pipelines to tasks like creating
time-series geospatial reports, these scripts grew into a full-blown
Python language library.

I've made it available Freely under an open source (MIT) license.
Davies, named in honor of William E. Davies, currently supports:

* Reading .PRJ and .DAT files, including most features used by
"compass and tape" dry cave surveys
* Reading compiled (loop closed) .PLT files
* Writing .DAT files

If you don't know what "Python" means, then this library probably
isn't for you. :-)

But, if you're looking for a way to run advanced queries on your
Compass data... or batch modify a large pile of survey data... or do
custom 3D visualizations... or write a native Mac/Linux Compass editor
(see examples folder)... or write a masters thesis by applying graph
theory to a cave system... or build an autonomous cave survey robot
from a RaspberryPi... you may find Davies helpful!

The source code lives at:

https://github.com/riggsd/davies

Online documentation is at:

http://davies.readthedocs.org/en/latest/#

Davies requires Python 2.7 (test cases appear to run correctly on
Python 3, but examples are written with Python 2 syntax). Provided
you've got a working Python 2.7 installation, you can probably install
it with:

$> pip install davies

or

$> easy_install davies

The 'examples' folder contains a few example query scripts, as well as
"toy" GUI clients written with the Tk or WxWidgets toolkits.

Any feedback, bug reports, or feature suggestions are welcome. It was
written to "scratch my own itch", but I hope it can help others out as
well.

NOTE: This is absolutely not an "official" Compass project, so please
don't bother Larry or bog down the Compass Users email list if you
have detailed questions or bug reports. Feel free to email me
directly, or to file bug reports ("Issues") at the GitHub link above.

- DR

David A. Riggs <[email protected]>


Messsage #: 480
Date: Tue, 3 Feb 2015 13:20:09 -0500
Subject: Re: Davies - Python Compass Library
From: "David A. Riggs" 

On Tue, Feb 3, 2015 at 12:25 PM, David A. Riggs  wrote:

 NOTE: This is absolutely not an "official" Compass project, so please
 don't bother Larry or bog down the Compass Users email list if you
 have detailed questions or bug reports. Feel free to email me
 directly, or to file bug reports ("Issues") at the GitHub link above.

I created a CaveChat thread if anyone would like to discuss Davies
without spamming Larry's official Compass email list.

   http://forums.caves.org/viewtopic.php?f&&t740

On Tue, Feb 3, 2015 at 12:31 PM, 'Addison, Aaron' [email protected]
[compass-users]  wrote:

 If I had the time, I would very much like to do the similar things with python and Walls.

The Walls file format is documented beautifully, it's on my list to
add support for Walls and PocketTopo eventually. Time is always the
limiting factor.

As I'm sure you guessed, the ability to plug Python scripts directly
into GIS environments like ArcGIS and QGIS was one of the prime
motivators for me to turn this into a proper Python library.

- DR

David A. Riggs 


Messsage #: 481
Date: Wed, 4 Feb 2015 06:23:23 +0800
Subject: Bls: [compass-users] Re: Davies - Python Compass Library
From: Kacici Thepresident 

Can i quiction about arcgis and qgis? A have study that. A wanna think this program is impprtant to map a cave, make a work so soft. Thanks to information, i'm happy.

Dikirim dari Yahoo Mail pada Android

Can i quiction about arcgis and qgis? A have study that. A wanna think this program is impprtant to map a cave, make a work so soft. Thanks to information, i'm happy.
Dikirim dari Yahoo Mail pada Android
     Dari:"'David A. Riggs' [email protected] [compass-users]" <[email protected]>Tanggal:Rab, 4 Feb 2015 pada 2:20Judul:[compass-users] Re: Davies - Python Compass Library 
A�
      
      On Tue, Feb 3, 2015 at 12:25 PM, David A. Riggs <[email protected]> wrote:
>
> NOTE: This is absolutely not an "official" Compass project, so please
> don't bother Larry or bog down the Compass Users email list if you
> have detailed questions or bug reports. Feel free to email me
> directly, or to file bug reports ("Issues") at the GitHub link above.

I created a CaveChat thread if anyone would like to discuss Davies
without spamming Larry's official Compass email list.

http://forums.caves.org/viewtopic.php?f=26&t=16740

On Tue, Feb 3, 2015 at 12:31 PM, 'Addison, Aaron' [email protected]
[compass-users] <[email protected]> wrote:
>
> If I had the time, I would very much like to do the similar things with python and Walls.

The Walls file format is documented beautifully, it's on my list to
add support for Walls and PocketTopo eventually. Time is always the
limiting factor.

As I'm sure you guessed, the ability to plug Python scripts directly
into GIS environments like ArcGIS and QGIS was one of the prime
motivators for me to turn this into a proper Python library.

- DR

David A. Riggs <[email protected]>


Messsage #: 482
Date: Wed, 04 Feb 2015 09:20:54 +0100
Subject: Export of cave maps to GIS
From: Martin Sluka 

Dear friend,

I apologize for private mail.

There is very straight way, to use the Therion software. Therion is tool for archiving your data in way you measure them without any recalculation, tool for drawing maps from small pieces from which is possible to define and export (to PDF for example) particular maps or complete map or atlas or advanced 3D model. And from which there are many export formats possible including export to ESRI with layers and free definition of symbols.

Check, please, http://therion.speleo.sk

Best regards

Martin Sluka


Messsage #: 483
Date: Sat, 14 Feb 2015 13:52:08 -0700
Subject: 
From: "Larry" 

A couple of quick announcements:
Import PocketTopo Files.�Compass can now import PocketTopo files and convert
them to Compass data format. The feature does not import the ".top" file
because that format is not documented. You have to export the data from
PocketTopo as a text file then Compass can read the data and convert it to
the Compass format. The import option is available in the Project Manager
under the "Tools- Import PocketTopo Files."
Compass Files Digitally Certified and Signed.�Windows and Antivirus programs
are now getting more and more picky about what programs they will allow to
be installed on a computer. Many antivirus programs rely on the creation
date of a program to determine how safe the program is. New programs are
often flagged as unsafe because so few people have used them that they the
antivirus program will be worried that the file might not have made it into
the virus/malware databases. Since I frequently update Compass with new
features and bug fixes, Compass programs are often just a few weeks old. As
a result, they are often flagged as suspicious.
To solve this problem, all Compass executable files are digitally signed
using anAuthenticode Certificate�fromComodo. Before I could get the
certificate, I had to verify my address and business credentials. Once I had
the certificate, I could sign all my executable files with a code that
cannot be forged. The certificate ensures that the file came from Fountain
Computer and that it hasn't been tampered with. As a result, Antivirus
programs are less likely to flag it and Windows won't warn you about the
trustworthiness of the file. There still may be some issues at first, but as
the Fountain Computer digital signature makes it into more databases and
develops a trustworthy reputation, the problems should fade.
If you have any question about the authenticity of any Compass executable
file, you can verify that the file right from Windows in a few seconds. Just
right click on the file, choose the "Properties" option and select the
"Digital Signatures" page. If the Digital Signatures page does not exist, it
means the file has not been signed. If the Digital Signatures page does
exist, it will give you detailed information about the certificate.� All the
details should match Fountain Computer through Comodo.

Larry Fish


Messsage #: 484
Date: Thu, 14 May 2015 14:28:51 +0200 (CEST)
Disposition-Notification-To: [email protected]
Subject: *.PLT Viewer for I-pad
From: "[email protected]" 

Hi everybody,
there is any possibility of viewing PLT files of Compass using an I-pad?
thank you
Amedeo GambiniGruppo Proteus Speleosub Milano (Italy)

Hi everybody,there is any possibility of viewing PLT files of Compass using an I-pad?thank youAmedeo GambiniGruppo Proteus Speleosub Milano (Italy)


Messsage #: 485
Date: Thu, 14 May 2015 14:38:16 +0200
Subject: Re: [compass-users] *.PLT Viewer for I-pad
From: Giorgio Pannuzzo 

You can use therion's viewer (loch) on Mac version, but I guess it
isn't compatible with I-pad.

Giorgio

2015-05-14 14:28 GMT+02:00, '[email protected]'
[email protected] [compass-users] :
 Hi everybody,
 there is any possibility of viewing PLT files of Compass using an I-pad?
 thank you
 Amedeo GambiniGruppo Proteus Speleosub Milano (Italy)


Messsage #: 486
Date: Tue, 26 May 2015 09:16:44 +0200 (CEST)
Subject: export to shp file
From: Andrea Maconi 

Hi, in the latest versions there is a problem during exportation to shp files. I
 send you a jpg file with the problem. In the shp file are exported straight lin
es parallel that are not visible in compass.
bye
Andrea


Messsage #: 487
Date: Wed, 27 May 2015 03:21:19 -0600
Subject: RE: [compass-users] export to shp file [1 Attachment]
From: "Larry" 

Andrea,

I can't tell what might be causing the problem without looking at the actual
data, but I have a couple thoughts:

It looks like several portions of the cave are connected to another point
that is south west of the cave. The fact that the lines are parallel means
that the point is thousands of kilometers away from the main cave. 

I'm assuming the cave is in Italy. Looking at the angle of the lines, they
point toward Africa. I think there is a pretty good chance the point is at
zero degrees Longitude and Latitude.

Usually, problems like this are caused by conflicting reference points. For
example, you could cause this type of problem by having some fixed reference
points near the cave and others at zero degrees Longitude and Latitude. I
don't have a lot of experience with ArcView, but I believe you can also
cause this type of problem by geo-referencing a cave in ArcView when Compass
also has its own fixed reference points. 

If you would like to have me look at your data and analyze the problem, send
me a private email and we can work out how you can send the data to me.
Yahoo usually puts the private email address in the header of the email. 

Let me know if you have any other thoughts or questions.

Larry Fish

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, May 26, 2015 1:17 AM
Subject: [compass-users] export to shp file [1 Attachment]

[Attachment(s) from Andrea Maconi included below] 

Hi, in the latest versions there is a problem during exportation to shp
files. I
send you a jpg file with the problem. In the shp file are exported straight
lin
es parallel that are not visible in compass.
bye
Andrea

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 #: 488
Authentication-Results: mta1004.groups.mail.bf1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Thu, 13 Aug 2015 19:27:18 -0700
Subject: Re: [compass-users]
From: "David A. Riggs" 

On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
[compass-users]  wrote:

 A couple of quick announcements:
 Import PocketTopo Files. Compass can now import PocketTopo files and
convert
 them to Compass data format. The feature does not import the �?o.top�?? file
 because that format is not documented. You have to export the data from
 PocketTopo as a text file then Compass can read the data and convert it to
 the Compass format. The import option is available in the Project Manager
 under the �?oTools- Import PocketTopo Files.�??

Is anyone using the built-in PocketTopo import feature in the real world?

It seems that, if shooting arbitrary splay shots from each station, which
is where the DistoX really changes cave survey, Compass counts each of
those splays as a mainline shot which counts for length. Unless I'm missing
something (which is possible!), you need to manually mark each of these
shots with the 'L' exclusion flag, and even then you don't get the passage
modeling feature in Compass without additionally entering LRUD info.

Would you consider adding an option during PocketTopo import which would
recognize the difference between:

A) a triple-repeat shot as single mainline survey shot which counts for
length
B) a single shot as a splay which doesn't count for length and doesn't
*directly* affect passage wall modeling
C) and (wishlist) would project all the splays from a single station onto
the horizontal and vertical plane to produce LRUD values from those splays?

I'd be interested in hearing what other people are doing when using
PocketTopo + DistoX in the field and Compass for project management. As is,
I'm working toward a custom script that does as much of the above as
possible, but would prefer a built-in clean solution.

Thanks!

- DR

David A. Riggs 

On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:>> A couple of quick announcements:> Import PocketTopo Files. Compass can now import PocketTopo files and convert> them to Compass data format. The feature does not import the �?o.top�?? file> because that format is not documented. You have to export the data from> PocketTopo as a text file then Compass can read the data and convert it to> the Compass format. The import option is available in the Project Manager> under the �?oTools-> Import PocketTopo Files.�??Is anyone using the built-in PocketTopo import feature in the real world?It seems that, if shooting arbitrary splay shots from each station, which is where the DistoX really changes cave survey, Compass counts each of those splays as a mainline shot which counts for length. Unless I'm missing something (which is possible!), you need to manually mark each of these shots with the 'L' exclusion flag, and even then you don't get the passage modeling feature in Compass without additionally entering LRUD info.Would you consider adding an option during PocketTopo import which would recognize the difference between:A) a triple-repeat shot as single mainline survey shot which counts for lengthB) a single shot as a splay which doesn't count for length and doesn't *directly* affect passage wall modelingC) and (wishlist) would project all the splays from a single station onto the horizontal and vertical plane to produce LRUD values from those splays?I'd be interested in hearing what other people are doing when using PocketTopo + DistoX in the field and Compass for project management. As is, I'm working toward a custom script that does as much of the above as possible, but would prefer a built-in clean solution.Thanks!- DR--David A. Riggs <[email protected]>


Messsage #: 489
Authentication-Results: mta1005.groups.mail.ne1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Fri, 14 Aug 2015 01:26:07 -0600
Subject: RE: [compass-users]
From: "Larry" 

Hi David,

Thanks for your email.

I think I can add some of the features you are requesting. Some comments and
questions first:

1. I'm not sure I understand what a "triple-repeat" shot is. Could you
clarify what that means?

2. I think I can make the Pocket Topo importer add the "L" flag to all splay
shots so they don't count in the length measurement.

3. Integrating the splay shots into the 3D modeling is a bit more of a
problem because I'm working adding Compass's own splay shot handling.
Integrating Pocket Topo splay shots will have to wait until I finish
Compass's own system. (More on this below.)

One of the problems I have with Pocket Topo is that the file format is not
fully documented. There is no information about the ".top" files anywhere
that I can find. There is a tiny bit of documentation on "Text Export"
format here:

http://paperless.bheeb.ch/download/PocketTopoManual.pdf

There is no mention in that document on how Splay Shots are handled the
exported text. The only information on Pocket Topo splay shots that I've
found is in a Java program that supposedly imports the files. Unfortunately,
there are few comments, so I have to untangle the code to figure out what it
means.

From what I've been able to gather, splay shots in the Pocket Topo text
files are indicated by shots that have no "to" station and whose bearing,
inclination and length are zero. If that is correct, I should be able to add
the "L" flag to each shot of those shots.

As I pointed out above, I've been working a splay shot format for Compass.
It is part of a long-term Compass improvement project that I have been
working on for several years. To make it happen, I need to make a lot of
other changes to Compass, so I don't expect to have it ready in the near
future. 

I have already written and tested code to generate 3D models of rooms
derived from splay shots. Basically, you choose a station near the center of
the room and take shots to the wall in various directions. The system would
be flexible and allow the user to enter as little as one splay shot or
dozens of shots at any angle. If the surveyor entered only one splay shot,
Compass would interpret the room as being a circle with a radius of the
splay shot.  If there were more splay shots, Compass would draw a more
accurate model of the room. To display the room, Compass would interpolate
and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of
various sizes to match the contours of the room. The splay shots would be
entered just like a regular shots except that the "To" station would be a
special symbol. Currently, the plan is to use a right parenthesis ")" for
the "To" station because it vaguely resembles a passage wall. It turns out
that parenthesis is one of the few character that exists on most of the
non-English key boards. It also vaguely resembles a passage wall. You could
also associate splay stations with a specific station name by adding the
station name after the parenthesis: )AB24 The Up and Down dimension for each
splay would apply to the "To" station of the shot. In other words, the Up
and Down dimension would describe the wall height where the shot makes
contact with the wall. The height of the center of the room would be
controlled by the LRUDs of the "From" station. This should produce a
reasonably realistic room shape where the floor and the ceiling could be
either convex or concaved. However, it would not model a side branch of a
room wanders around a corner. I also have to think about how to handle rooms
that are surveyed by a series of shots that go around the edge of the room.

Let me know if you have any more questions.

Larry Fish

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Thursday, August 13, 2015 8:27 PM
Subject: Re: [compass-users]

On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
[compass-users]  wrote:

 A couple of quick announcements:
 Import PocketTopo Files. Compass can now import PocketTopo files and
convert
 them to Compass data format. The feature does not import the ".top" file
 because that format is not documented. You have to export the data from
 PocketTopo as a text file then Compass can read the data and convert it to
 the Compass format. The import option is available in the Project Manager
 under the "Tools- Import PocketTopo Files."

Is anyone using the built-in PocketTopo import feature in the real world?

It seems that, if shooting arbitrary splay shots from each station, which is
where the DistoX really changes cave survey, Compass counts each of those
splays as a mainline shot which counts for length. Unless I'm missing
something (which is possible!), you need to manually mark each of these
shots with the 'L' exclusion flag, and even then you don't get the passage
modeling feature in Compass without additionally entering LRUD info.

Would you consider adding an option during PocketTopo import which would
recognize the difference between:

A) a triple-repeat shot as single mainline survey shot which counts for
length

B) a single shot as a splay which doesn't count for length and doesn't
*directly* affect passage wall modeling

C) and (wishlist) would project all the splays from a single station onto
the horizontal and vertical plane to produce LRUD values from those splays?

I'd be interested in hearing what other people are doing when using
PocketTopo + DistoX in the field and Compass for project management. As is,
I'm working toward a custom script that does as much of the above as
possible, but would prefer a built-in clean solution.

Thanks!

- DR

David A. Riggs 

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 #: 490
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com  from=mac.com; domainkeys=neutral (no sig);  from=mac.com; dkim=neutral (no sig)
Date: Fri, 14 Aug 2015 09:47:50 +0200
Subject: Re: [compass-users]
From: Martin Sluka 

In .txt file from PocketTopo are only average data from triple shots. All splay shot have no target station number.

You may use TopParser program to achieve more informations to .th file. To extract data to Compass should be trivial.

Regards

Martin


Messsage #: 491
Authentication-Results: mta1006.groups.mail.bf1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Fri, 14 Aug 2015 12:13:30 -0700
Subject: RE: [compass-users]
From: "David A. Riggs" 

On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"  wrote:

 1. I�?Tm not sure I understand what a �?otriple-repeat�?? shot is. Could you
clarify what that means?

PockeTopo, and with recent firmware update the DistoX2 itself, detects
three duplicate measurements as "quality checking" of a single survey shot.
It averages those three values into a single shot, and - as Martin points
out - doesn't explicitly tell us that in the exported txt file (I haven't
tried parsing the binary top file to see if it retains all three).

I suppose that the heuristic to detect splays is independent of whether you
took triple-shots or not. In my surveys anything without a TO station is a
splay (and shouldn't count for length), anything with a TO station is a
centerline shot. This means that a dead-end passage must have a zero-length
fake shot to ensure that it's final shot counts as passage.

 3. Integrating the splay shots into the 3D modeling is a bit more of a
problem because I�?Tm working adding Compass�?Ts own splay shot handling.
Integrating Pocket Topo splay shots will have to wait until I finish
Compass�?Ts own system. (More on this below.)

This would be most welcome in Compass!

In that case, it makes the most sense for a PockeTopo splay to equal a
Compass splay. I'd like to do away with LRUD entirely now that accurate
sprays are "free".

Thanks Larry!

- DR

 One of the problems I have with Pocket Topo is that the file format is
not fully documented. There is no information about the �?o.top�?? files
anywhere that I can find. There is a tiny bit of documentation on �?oText
Export�?? format here:

 http://paperless.bheeb.ch/download/PocketTopoManual.pdf

 There is no mention in that document on how Splay Shots are handled the
exported text. The only information on Pocket Topo splay shots that I�?Tve
found is in a Java program that supposedly imports the files.
Unfortunately, there are few comments, so I have to untangle the code to
figure out what it means.

 From what I�?Tve been able to gather, splay shots in the Pocket Topo text
files are indicated by shots that have no �?oto�?? station and whose bearing,
inclination and length are zero. If that is correct, I should be able to
add the �?oL�?? flag to each shot of those shots.

 As I pointed out above, I�?Tve been working a splay shot format for
Compass. It is part of a long-term Compass improvement project that I have
been working on for several years. To make it happen, I need to make a lot
of other changes to Compass, so I don�?Tt expect to have it ready in the near
future.

 I have already written and tested code to generate 3D models of rooms
derived from splay shots. Basically, you choose a station near the center
of the room and take shots to the wall in various directions. The system
would be flexible and allow the user to enter as little as one splay shot
or dozens of shots at any angle. If the surveyor entered only one splay
shot, Compass would interpret the room as being a circle with a radius of
the splay shot.  If there were more splay shots, Compass would draw a more
accurate model of the room. To display the room, Compass would interpolate
and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of
various sizes to match the contours of the room. The splay shots would be
entered just like a regular shots except that the "To" station would be a
special symbol. Currently, the plan is to use a right parenthesis ")" for
the "To" station because it vaguely resembles a passage wall. It turns out
that parenthesis is one of the few character that exists on most of the
non-English key boards. It also vaguely resembles a passage wall. You could
also associate splay stations with a specific station name by adding the
station name after the parenthesis: )AB24 The Up and Down dimension for
each splay would apply to the "To" station of the shot. In other words, the
Up and Down dimension would describe the wall height where the shot makes
contact with the wall. The height of the center of the room would be
controlled by the LRUDs of the "From" station. This should produce a
reasonably realistic room shape where the floor and the ceiling could be
either convex or concaved. However, it would not model a side branch of a
room wanders around a corner. I also have to think about how to handle
rooms that are surveyed by a series of shots that go around the edge of the
room.

 Let me know if you have any more questions.

 Larry Fish

 ________________________________

 From: [email protected] [mailto:[email protected]]

 Sent: Thursday, August 13, 2015 8:27 PM
 To: [email protected]
 Subject: Re: [compass-users]

 On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
[compass-users]  wrote:
 
  A couple of quick announcements:
  Import PocketTopo Files. Compass can now import PocketTopo files and
convert
  them to Compass data format. The feature does not import the �?o.top�?? file
  because that format is not documented. You have to export the data from
  PocketTopo as a text file then Compass can read the data and convert it
to
  the Compass format. The import option is available in the Project
Manager
  under the �?oTools- Import PocketTopo Files.�??

 Is anyone using the built-in PocketTopo import feature in the real world?

 It seems that, if shooting arbitrary splay shots from each station, which
is where the DistoX really changes cave survey, Compass counts each of
those splays as a mainline shot which counts for length. Unless I'm missing
something (which is possible!), you need to manually mark each of these
shots with the 'L' exclusion flag, and even then you don't get the passage
modeling feature in Compass without additionally entering LRUD info.

 Would you consider adding an option during PocketTopo import which would
recognize the difference between:

 A) a triple-repeat shot as single mainline survey shot which counts for
length

 B) a single shot as a splay which doesn't count for length and doesn't
*directly* affect passage wall modeling

 C) and (wishlist) would project all the splays from a single station onto
the horizontal and vertical plane to produce LRUD values from those splays?

 I'd be interested in hearing what other people are doing when using
PocketTopo + DistoX in the field and Compass for project management. As is,
I'm working toward a custom script that does as much of the above as
possible, but would prefer a built-in clean solution.

 Thanks!

 - DR

 --
 David A. Riggs 

On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]" <[email protected]> wrote:
>
>
> 1. I�?Tm not sure I understand what a �?otriple-repeat�?? shot is. Could you clarify what that means?
>
PockeTopo, and with recent firmware update the DistoX2 itself, detects three duplicate measurements as "quality checking" of a single survey shot. It averages those three values into a single shot, and - as Martin points out - doesn't explicitly tell us that in the exported txt file (I haven't tried parsing the binary top file to see if it retains all three). 
I suppose that the heuristic to detect splays is independent of whether you took triple-shots or not. In my surveys anything without a TO station is a splay (and shouldn't count for length), anything with a TO station is a centerline shot. This means that a dead-end passage must have a zero-length fake shot to ensure that it's final shot counts as passage. 
>
> 3. Integrating the splay shots into the 3D modeling is a bit more of a problem because I�?Tm working adding Compass�?Ts own splay shot handling. Integrating Pocket Topo splay shots will have to wait until I finish Compass�?Ts own system. (More on this below.)
>
This would be most welcome in Compass! 
In that case, it makes the most sense for a PockeTopo splay to equal a Compass splay. I'd like to do away with LRUD entirely now that accurate sprays are "free". 
Thanks Larry! 
- DR 
> One of the problems I have with Pocket Topo is that the file format is not fully documented. There is no information about the �?o.top�?? files anywhere that I can find. There is a tiny bit of documentation on �?oText Export�?? format here:
>
> http://paperless.bheeb.ch/download/PocketTopoManual.pdf
>
> There is no mention in that document on how Splay Shots are handled the exported text. The only information on Pocket Topo splay shots that I�?Tve found is in a Java program that supposedly imports the files. Unfortunately, there are few comments, so I have to untangle the code to figure out what it means.
>
> From what I�?Tve been able to gather, splay shots in the Pocket Topo text files are indicated by shots that have no �?oto�?? station and whose bearing, inclination and length are zero. If that is correct, I should be able to add the �?oL�?? flag to each shot of those shots.
>
> As I pointed out above, I�?Tve been working a splay shot format for Compass. It is part of a long-term Compass improvement project that I have been working on for several years. To make it happen, I need to make a lot of other changes to Compass, so I don�?Tt expect to have it ready in the near future.
>
> I have already written and tested code to generate 3D models of rooms derived from splay shots. Basically, you choose a station near the center of the room and take shots to the wall in various directions. The system would be flexible and allow the user to enter as little as one splay shot or dozens of shots at any angle. If the surveyor entered only one splay shot, Compass would interpret the room as being a circle with a radius of the splay shot.A� If there were more splay shots, Compass would draw a more accurate model of the room. To display the room, Compass would interpolate and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of various sizes to match the contours of the room.A�The splay shots would be entered just like a regular shots except that the "To" station would be a special symbol. Currently, the plan is to use a right parenthesis ")" for the "To" station because it vaguely resembles a passage wall. It turns out that parenthesis is one of the few character that exists on most of the non-English key boards. It also vaguely resembles a passage wall. You could also associate splay stations with a specific station name by adding the station name after the parenthesis: )AB24A�The Up and Down dimension for each splay would apply to the "To" station of the shot. In other words, the Up and Down dimension would describe the wall height where the shot makes contact with the wall. The height of the center of the room would be controlled by the LRUDs of the "From" station. This should produce a reasonably realistic room shape where the floor and the ceiling could be either convex or concaved. However, it would not model a side branch of a room wanders around a corner. I also have to think about how to handle rooms that are surveyed by a series of shots that go around the edge of the room.
>
> Let me know if you have any more questions.
>
> Larry Fish
>
> A�
>
> ________________________________
>
> From: [email protected] [mailto:[email protected]] 
> Sent: Thursday, August 13, 2015 8:27 PM
> To: [email protected]
> Subject: Re: [compass-users]
>
> A�
>
> A�
>
> On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:
> >
> > A couple of quick announcements:
> > Import PocketTopo Files. Compass can now import PocketTopo files and convert
> > them to Compass data format. The feature does not import the �?o.top�?? file
> > because that format is not documented. You have to export the data from
> > PocketTopo as a text file then Compass can read the data and convert it to
> > the Compass format. The import option is available in the Project Manager
> > under the �?oTools-> Import PocketTopo Files.�??
>
> A�
>
> Is anyone using the built-in PocketTopo import feature in the real world?
>
> A�
>
> It seems that, if shooting arbitrary splay shots from each station, which is where the DistoX really changes cave survey, Compass counts each of those splays as a mainline shot which counts for length. Unless I'm missing something (which is possible!), you need to manually mark each of these shots with the 'L' exclusion flag, and even then you don't get the passage modeling feature in Compass without additionally entering LRUD info.
>
> A�
>
> Would you consider adding an option during PocketTopo import which would recognize the difference between:
>
> A�
>
> A) a triple-repeat shot as single mainline survey shot which counts for length
>
> B) a single shot as a splay which doesn't count for length and doesn't *directly* affect passage wall modeling
>
> C) and (wishlist) would project all the splays from a single station onto the horizontal and vertical plane to produce LRUD values from those splays?
>
> A�
>
> I'd be interested in hearing what other people are doing when using PocketTopo + DistoX in the field and Compass for project management. As is, I'm working toward a custom script that does as much of the above as possible, but would prefer a built-in clean solution.
>
> A�
>
> Thanks!
>
> A�
>
> - DR
>
> A�
>
>
>
>
> --
> David A. Riggs <[email protected]>
>
>
>
> 


Messsage #: 492
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com  from=mac.com; domainkeys=neutral (no sig);  from=mac.com; dkim=neutral (no sig)
Date: Sat, 15 Aug 2015 16:14:20 +0200
Subject: Re: parsing .top files to Compass
From: Martin Sluka 

Example of .th file exported from .top file by TopParser 

https://bitbucket.org/AndrewA/topparser/downloads 

.th file:

�q�q�q�q�I
survey radavc_20141231

input radavc_20141231.th2
input radavc_20141231Ee.th2

map radavc_20141231MAP
	radavc_20141231SP1
endmap

map radavc_20141231MEL
	radavc_20141231SE1
endmap
centreline

copyright 2015 "GNU GPL"

### TRIP COMMENT FROM POCKETTOPO ###
#mapovanie j. Radavc sluka, medzo

#+5 cm distox2

	date 2014.12.31

	team "Andrew Atkinson" notes
	team "Alison Moody" instruments

	instrument  instruments "UBSS DistoX1"

	explo-date 2014.12.31

data normal from to tape compass clino ignoreall
  extend right
#50.0	50.1	2.964	153.3	-64.75	Imrich1_12
#50.0	50.1	2.964	153.39	-64.79	
#50.0	50.1	2.962	153.2	-64.76	
50.0		50.1	2.963	153.35	-64.77	Calculated leg from 3 above
#50.1	50.0	2.966	335.08	65.26	
#50.1	50.0	2.966	335.03	65.23	
#50.1	50.0	2.966	335.01	65.24	
50.1		50.0	2.966	335.05	65.24	Calculated leg from 3 above
#50.1	50.2	1.423	37.86	-46.54	
#50.1	50.2	1.427	37.95	-46.68	
#50.1	50.2	1.423	38.07	-46.55	
50.1		50.2	1.424	37.91	-46.59	Calculated leg from 3 above
50.2	-	0.96	156.74	10.79	
50.2	-	1.352	117.03	57.6	
50.2	-	1.33	66.05	51.53	
50.2	-	1.019	24.62	55.39	
50.2	-	0.493	354.42	12.08	
50.2	-	3.902	71.44	-33.13	
50.2	-	3.668	80.26	-18.17	
50.2	-	5.109	92.57	-37.2	
50.2	-	5.683	79.68	-37.97	
#50.2	50.3	6.653	76.82	-35.35	
#50.2	50.3	6.65	76.81	-35.34	
#50.2	50.3	6.649	76.83	-35.34	
50.2		50.3	6.651	76.81	-35.34	Calculated leg from 3 above
#50.2	51.1	6.043	99.78	11.09	
#50.2	51.1	6.052	99.16	11.21	
#50.2	51.1	6.044	99.11	11.27	
50.2		51.1	6.046	99.35	11.19	Calculated leg from 3 above
19		52.0	0.0	0.0	0.0	IMRICH1_19

endcentreline
endsurvey

xxxxxxxxxxxxxxxxxxx

"ignoreall" means that everything what is after "clino&space" is parsed as comment for particular survey shot. One may use �?z#" instead

Martin

 14. 8. 2015 v 21:13, 'David A. Riggs' [email protected] [compass-users] :
 
 On Aug 14, 2015 12:26 AM, "'Larry' [email protected]  [compass-users]"  wrote:
 
  1. I�?Tm not sure I understand what a �?otriple-repeat�?? shot is. Could you clarify what that means?
 
 PockeTopo, and with recent firmware update the DistoX2 itself, detects three duplicate measurements as "quality checking" of a single survey shot. It averages those three values into a single shot, and - as Martin points out - doesn't explicitly tell us that in the exported txt file (I haven't tried parsing the binary top file to see if it retains all three). 
 
 I suppose that the heuristic to detect splays is independent of whether you took triple-shots or not. In my surveys anything without a TO station is a splay (and shouldn't count for length), anything with a TO station is a centerline shot. This means that a dead-end passage must have a zero-length fake shot to ensure that it's final shot counts as passage. 
 
  3. Integrating the splay shots into the 3D modeling is a bit more of a problem because I�?Tm working adding Compass�?Ts own splay shot handling. Integrating Pocket Topo splay shots will have to wait until I finish Compass�?Ts own system. (More on this below.)
 
 This would be most welcome in Compass! 
 
 In that case, it makes the most sense for a PockeTopo splay to equal a Compass splay. I'd like to do away with LRUD entirely now that accurate sprays are "free". 
 
 Thanks Larry! 
 
 - DR 
 
  One of the problems I have with Pocket Topo is that the file format is not fully documented. There is no information about the �?o.top�?? files anywhere that I can find. There is a tiny bit of documentation on �?oText Export�?? format here:
 
  http://paperless.bheeb.ch/download/PocketTopoManual.pdf 
 
  There is no mention in that document on how Splay Shots are handled the exported text. The only information on Pocket Topo splay shots that I�?Tve found is in a Java program that supposedly imports the files. Unfortunately, there are few comments, so I have to untangle the code to figure out what it means.
 
  From what I�?Tve been able to gather, splay shots in the Pocket Topo text files are indicated by shots that have no �?oto�?? station and whose bearing, inclination and length are zero. If that is correct, I should be able to add the �?oL�?? flag to each shot of those shots.
 
  As I pointed out above, I�?Tve been working a splay shot format for Compass. It is part of a long-term Compass improvement project that I have been working on for several years. To make it happen, I need to make a lot of other changes to Compass, so I don�?Tt expect to have it ready in the near future.
 
  I have already written and tested code to generate 3D models of rooms derived from splay shots. Basically, you choose a station near the center of the room and take shots to the wall in various directions. The system would be flexible and allow the user to enter as little as one splay shot or dozens of shots at any angle. If the surveyor entered only one splay shot, Compass would interpret the room as being a circle with a radius of the splay shot.  If there were more splay shots, Compass would draw a more accurate model of the room. To display the room, Compass would interpolate and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of various sizes to match the contours of the room. The splay shots would be entered just like a regular shots except that the "To" station would be a special symbol. Currently, the plan is to use a right parenthesis ")" for the "To" station because it vaguely resembles a passage wall. It turns out that parenthesis is one of the few character that exists on most of the non-English key boards. It also vaguely resembles a passage wall. You could also associate splay stations with a specific station name by adding the station name after the parenthesis: )AB24 The Up and Down dimension for each splay would apply to the "To" station of the shot. In other words, the Up and Down dimension would describe the wall height where the shot makes contact with the wall. The height of the center of the room would be controlled by the LRUDs of the "From" station. This should produce a reasonably realistic room shape where the floor and the ceiling could be either convex or concaved. However, it would not model a side branch of a room wanders around a corner. I also have to think about how to handle rooms that are surveyed by a series of shots that go around the edge of the room.
 
  Let me know if you have any more questions.
 
  Larry Fish
 
  ________________________________
 
  From: [email protected]  [mailto:[email protected] ] 
  Sent: Thursday, August 13, 2015 8:27 PM
  To: [email protected] 
  Subject: Re: [compass-users]
 
  On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]  [compass-users]  wrote:
  
   A couple of quick announcements:
   Import PocketTopo Files. Compass can now import PocketTopo files and convert
   them to Compass data format. The feature does not import the �?o.top�?? file
   because that format is not documented. You have to export the data from
   PocketTopo as a text file then Compass can read the data and convert it to
   the Compass format. The import option is available in the Project Manager
   under the �?oTools- Import PocketTopo Files.�??
 
  Is anyone using the built-in PocketTopo import feature in the real world?
 
  It seems that, if shooting arbitrary splay shots from each station, which is where the DistoX really changes cave survey, Compass counts each of those splays as a mainline shot which counts for length. Unless I'm missing something (which is possible!), you need to manually mark each of these shots with the 'L' exclusion flag, and even then you don't get the passage modeling feature in Compass without additionally entering LRUD info.
 
  Would you consider adding an option during PocketTopo import which would recognize the difference between:
 
  A) a triple-repeat shot as single mainline survey shot which counts for length
 
  B) a single shot as a splay which doesn't count for length and doesn't *directly* affect passage wall modeling
 
  C) and (wishlist) would project all the splays from a single station onto the horizontal and vertical plane to produce LRUD values from those splays?
 
  I'd be interested in hearing what other people are doing when using PocketTopo + DistoX in the field and Compass for project management. As is, I'm working toward a custom script that does as much of the above as possible, but would prefer a built-in clean solution.
 
  Thanks!
 
  - DR
 
  --
  David A. Riggs 

Example of .th file exported from .top file by TopParser https://bitbucket.org/AndrewA/topparser/downloads.th file:xxxxxxxxxxxxxxxxsurvey radavc_20141231input radavc_20141231.th2input radavc_20141231Ee.th2map radavc_20141231MAP	radavc_20141231SP1endmapmap radavc_20141231MEL	radavc_20141231SE1endmapcentrelinecopyright 2015 "GNU GPL"### TRIP COMMENT FROM POCKETTOPO ####mapovanie j. Radavc sluka, medzo#+5 cm distox2	date 2014.12.31	team "Andrew Atkinson" notes	team "Alison Moody" instruments	instrument  instruments "UBSS DistoX1"	explo-date 2014.12.31data normal from to tape compass clino ignoreall  extend right#50.0	50.1	2.964	153.3	-64.75	Imrich1_12#50.0	50.1	2.964	153.39	-64.79	#50.0	50.1	2.962	153.2	-64.76	50.0		50.1	2.963	153.35	-64.77	Calculated leg from 3 above#50.1	50.0	2.966	335.08	65.26	#50.1	50.0	2.966	335.03	65.23	#50.1	50.0	2.966	335.01	65.24	50.1		50.0	2.966	335.05	65.24	Calculated leg from 3 above#50.1	50.2	1.423	37.86	-46.54	#50.1	50.2	1.427	37.95	-46.68	#50.1	50.2	1.423	38.07	-46.55	50.1		50.2	1.424	37.91	-46.59	Calculated leg from 3 above50.2	-	0.96	156.74	10.79	50.2	-	1.352	117.03	57.6	50.2	-	1.33	66.05	51.53	50.2	-	1.019	24.62	55.39	50.2	-	0.493	354.42	12.08	50.2	-	3.902	71.44	-33.13	50.2	-	3.668	80.26	-18.17	50.2	-	5.109	92.57	-37.2	50.2	-	5.683	79.68	-37.97	#50.2	50.3	6.653	76.82	-35.35	#50.2	50.3	6.65	76.81	-35.34	#50.2	50.3	6.649	76.83	-35.34	50.2		50.3	6.651	76.81	-35.34	Calculated leg from 3 above#50.2	51.1	6.043	99.78	11.09	#50.2	51.1	6.052	99.16	11.21	#50.2	51.1	6.044	99.11	11.27	50.2		51.1	6.046	99.35	11.19	Calculated leg from 3 above19		52.0	0.0	0.0	0.0	IMRICH1_19endcentrelineendsurveyxxxxxxxxxxxxxxxxxxx"ignoreall" means that everything what is after "clino&space" is parsed as comment for particular survey shot. One may use �?z#" insteadMartin14. 8. 2015 v 21:13, 'David A. Riggs' [email protected] [compass-users] <[email protected]>:On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]" <[email protected]> wrote:>>> 1. I�?Tm not sure I understand what a �?otriple-repeat�?? shot is. Could you clarify what that means?>PockeTopo, and with recent firmware update the DistoX2 itself, detects three duplicate measurements as "quality checking" of a single survey shot. It averages those three values into a single shot, and - as Martin points out - doesn't explicitly tell us that in the exported txt file (I haven't tried parsing the binary top file to see if it retains all three). I suppose that the heuristic to detect splays is independent of whether you took triple-shots or not. In my surveys anything without a TO station is a splay (and shouldn't count for length), anything with a TO station is a centerline shot. This means that a dead-end passage must have a zero-length fake shot to ensure that it's final shot counts as passage. >> 3. Integrating the splay shots into the 3D modeling is a bit more of a problem because I�?Tm working adding Compass�?Ts own splay shot handling. Integrating Pocket Topo splay shots will have to wait until I finish Compass�?Ts own system. (More on this below.)>This would be most welcome in Compass! In that case, it makes the most sense for a PockeTopo splay to equal a Compass splay. I'd like to do away with LRUD entirely now that accurate sprays are "free". Thanks Larry! - DR > One of the problems I have with Pocket Topo is that the file format is not fully documented. There is no information about the �?o.top�?? files anywhere that I can find. There is a tiny bit of documentation on �?oText Export�?? format here:>> http://paperless.bheeb.ch/download/PocketTopoManual.pdf>> There is no mention in that document on how Splay Shots are handled the exported text. The only information on Pocket Topo splay shots that I�?Tve found is in a Java program that supposedly imports the files. Unfortunately, there are few comments, so I have to untangle the code to figure out what it means.>> From what I�?Tve been able to gather, splay shots in the Pocket Topo text files are indicated by shots that have no �?oto�?? station and whose bearing, inclination and length are zero. If that is correct, I should be able to add the �?oL�?? flag to each shot of those shots.>> As I pointed out above, I�?Tve been working a splay shot format for Compass. It is part of a long-term Compass improvement project that I have been working on for several years. To make it happen, I need to make a lot of other changes to Compass, so I don�?Tt expect to have it ready in the near future.>> I have already written and tested code to generate 3D models of rooms derived from splay shots. Basically, you choose a station near the center of the room and take shots to the wall in various directions. The system would be flexible and allow the user to enter as little as one splay shot or dozens of shots at any angle. If the surveyor entered only one splay shot, Compass would interpret the room as being a circle with a radius of the splay shot.  If there were more splay shots, Compass would draw a more accurate model of the room. To display the room, Compass would interpolate and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of various sizes to match the contours of the room. The splay shots would be entered just like a regular shots except that the "To" station would be a special symbol. Currently, the plan is to use a right parenthesis ")" for the "To" station because it vaguely resembles a passage wall. It turns out that parenthesis is one of the few character that exists on most of the non-English key boards. It also vaguely resembles a passage wall. You could also associate splay stations with a specific station name by adding the station name after the parenthesis: )AB24 The Up and Down dimension for each splay would apply to the "To" station of the shot. In other words, the Up and Down dimension would describe the wall height where the shot makes contact with the wall. The height of the center of the room would be controlled by the LRUDs of the "From" station. This should produce a reasonably realistic room shape where the floor and the ceiling could be either convex or concaved. However, it would not model a side branch of a room wanders around a corner. I also have to think about how to handle rooms that are surveyed by a series of shots that go around the edge of the room.>> Let me know if you have any more questions.>> Larry Fish>>  >> ________________________________>> From: [email protected] [mailto:[email protected]] > Sent: Thursday, August 13, 2015 8:27 PM> To: [email protected]> Subject: Re: [compass-users]>>  >>  >> On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:> >> > A couple of quick announcements:> > Import PocketTopo Files. Compass can now import PocketTopo files and convert> > them to Compass data format. The feature does not import the �?o.top�?? file> > because that format is not documented. You have to export the data from> > PocketTopo as a text file then Compass can read the data and convert it to> > the Compass format. The import option is available in the Project Manager> > under the �?oTools-> Import PocketTopo Files.�??>>  >> Is anyone using the built-in PocketTopo import feature in the real world?>>  >> It seems that, if shooting arbitrary splay shots from each station, which is where the DistoX really changes cave survey, Compass counts each of those splays as a mainline shot which counts for length. Unless I'm missing something (which is possible!), you need to manually mark each of these shots with the 'L' exclusion flag, and even then you don't get the passage modeling feature in Compass without additionally entering LRUD info.>>  >> Would you consider adding an option during PocketTopo import which would recognize the difference between:>>  >> A) a triple-repeat shot as single mainline survey shot which counts for length>> B) a single shot as a splay which doesn't count for length and doesn't *directly* affect passage wall modeling>> C) and (wishlist) would project all the splays from a single station onto the horizontal and vertical plane to produce LRUD values from those splays?>>  >> I'd be interested in hearing what other people are doing when using PocketTopo + DistoX in the field and Compass for project management. As is, I'm working toward a custom script that does as much of the above as possible, but would prefer a built-in clean solution.>>  >> Thanks!>>  >> - DR>>  >>>>> --> David A. Riggs <[email protected]>>>>> 


Messsage #: 493
Authentication-Results: mta1002.groups.mail.ne1.yahoo.com  from=mac.com; domainkeys=neutral (no sig);  from=mac.com; dkim=neutral (no sig)
Date: Sat, 15 Aug 2015 16:25:48 +0200
Subject: Re: parsing .top files to Compass better formated + a note
From: Martin Sluka 

Example of .th file exported from .top file by TopParser 

https://bitbucket.org/AndrewA/topparser/downloads

note: for the future there should be besides symbol [dash] for splay shot to wall another symbol [dot] for splay shot to feature INSIDE the passage (blocks, �?�) too.

.th file:

�q�q�q�qey radavc_20141231
survey radavc_20141231

input radavc_20141231.th2
input radavc_20141231Ee.th2

map radavc_20141231MAP
	radavc_20141231SP1
endmap

map radavc_20141231MEL
	radavc_20141231SE1
endmap
centreline

copyright 2015 "GNU GPL"

### TRIP COMMENT FROM POCKETTOPO ###
#mapovanie j. Radavc sluka, medzo

#+5 cm distox2

	date 2014.12.31

	team "Andrew Atkinson" notes
	team "Alison Moody" instruments

	instrument  instruments "UBSS DistoX1"

	explo-date 2014.12.31

data normal from to tape compass clino ignoreall
  extend right
#50.0	50.1		2.964	153.3	-64.75	Imrich1_12
#50.0	50.1		2.964	153.39	-64.79	
#50.0	50.1		2.962	153.2	-64.76	
50.0		50.1		2.963	153.35	-64.77	Calculated leg from 3 above
#50.1	50.0		2.966	335.08	65.26	
#50.1	50.0		2.966	335.03	65.23	
#50.1	50.0		2.966	335.01	65.24	
50.1		50.0		2.966	335.05	65.24	Calculated leg from 3 above
#50.1	50.2		1.423	37.86	-46.54	
#50.1	50.2		1.427	37.95	-46.68	
#50.1	50.2		1.423	38.07	-46.55	
50.1		50.2		1.424	37.91	-46.59	Calculated leg from 3 above
50.2		-		0.96		156.74	10.79	
50.2		-		1.352	117.03	57.6	
50.2		-		1.33		66.05	51.53	
50.2		-		1.019	24.62	55.39	
50.2		-		0.493	354.42	12.08	
50.2		-		3.902	71.44	-33.13	
50.2		-		3.668	80.26	-18.17	
50.2		-		5.109	92.57	-37.2	
50.2		-		5.683	79.68	-37.97	
#50.2	50.3		6.653	76.82	-35.35	
#50.2	50.3		6.65		76.81	-35.34	
#50.2	50.3		6.649	76.83	-35.34	
50.2		50.3		6.651	76.81	-35.34	Calculated leg from 3 above
#50.2	51.1		6.043	99.78	11.09	
#50.2	51.1		6.052	99.16	11.21	
#50.2	51.1		6.044	99.11	11.27	
50.2		51.1		6.046	99.35	11.19	Calculated leg from 3 above
19		52.0		0.0		0.0		0.0		IMRICH1_19

endcentreline
endsurvey

xxxxxxxxxxxxxxxxxxx

"ignoreall" means that everything what is after "clino&space" is parsed as comment for particular survey shot. One may use �?z#" instead

Martin

 14. 8. 2015 v 21:13, 'David A. Riggs' [email protected] [compass-users] :
 
 On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"  wrote:
 
  1. I�?Tm not sure I understand what a �?otriple-repeat�?? shot is. Could you clarify what that means?
 
 PockeTopo, and with recent firmware update the DistoX2 itself, detects three duplicate measurements as "quality checking" of a single survey shot. It averages those three values into a single shot, and - as Martin points out - doesn't explicitly tell us that in the exported txt file (I haven't tried parsing the binary top file to see if it retains all three). 
 
 I suppose that the heuristic to detect splays is independent of whether you took triple-shots or not. In my surveys anything without a TO station is a splay (and shouldn't count for length), anything with a TO station is a centerline shot. This means that a dead-end passage must have a zero-length fake shot to ensure that it's final shot counts as passage. 
 
  3. Integrating the splay shots into the 3D modeling is a bit more of a problem because I�?Tm working adding Compass�?Ts own splay shot handling. Integrating Pocket Topo splay shots will have to wait until I finish Compass�?Ts own system. (More on this below.)
 
 This would be most welcome in Compass! 
 
 In that case, it makes the most sense for a PockeTopo splay to equal a Compass splay. I'd like to do away with LRUD entirely now that accurate sprays are "free". 
 
 Thanks Larry! 
 
 - DR 
 
  One of the problems I have with Pocket Topo is that the file format is not fully documented. There is no information about the �?o.top�?? files anywhere that I can find. There is a tiny bit of documentation on �?oText Export�?? format here:
 
  http://paperless.bheeb.ch/download/PocketTopoManual.pdf
 
  There is no mention in that document on how Splay Shots are handled the exported text. The only information on Pocket Topo splay shots that I�?Tve found is in a Java program that supposedly imports the files. Unfortunately, there are few comments, so I have to untangle the code to figure out what it means.
 
  From what I�?Tve been able to gather, splay shots in the Pocket Topo text files are indicated by shots that have no �?oto�?? station and whose bearing, inclination and length are zero. If that is correct, I should be able to add the �?oL�?? flag to each shot of those shots.
 
  As I pointed out above, I�?Tve been working a splay shot format for Compass. It is part of a long-term Compass improvement project that I have been working on for several years. To make it happen, I need to make a lot of other changes to Compass, so I don�?Tt expect to have it ready in the near future.
 
  I have already written and tested code to generate 3D models of rooms derived from splay shots. Basically, you choose a station near the center of the room and take shots to the wall in various directions. The system would be flexible and allow the user to enter as little as one splay shot or dozens of shots at any angle. If the surveyor entered only one splay shot, Compass would interpret the room as being a circle with a radius of the splay shot.  If there were more splay shots, Compass would draw a more accurate model of the room. To display the room, Compass would interpolate and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of various sizes to match the contours of the room. The splay shots would be entered just like a regular shots except that the "To" station would be a special symbol. Currently, the plan is to use a right parenthesis ")" for the "To" station because it vaguely resembles a passage wall. It turns out that parenthesis is one of the few character that exists on most of the non-English key boards. It also vaguely resembles a passage wall. You could also associate splay stations with a specific station name by adding the station name after the parenthesis: )AB24 The Up and Down dimension for each splay would apply to the "To" station of the shot. In other words, the Up and Down dimension would describe the wall height where the shot makes contact with the wall. The height of the center of the room would be controlled by the LRUDs of the "From" station. This should produce a reasonably realistic room shape where the floor and the ceiling could be either convex or concaved. However, it would not model a side branch of a room wanders around a corner. I also have to think about how to handle rooms that are surveyed by a series of shots that go around the edge of the room.
 
  Let me know if you have any more questions.
 
  Larry Fish
 
  ________________________________
 
  From: [email protected] [mailto:[email protected]] 
  Sent: Thursday, August 13, 2015 8:27 PM
  To: [email protected]
  Subject: Re: [compass-users]
 
  On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected] [compass-users]  wrote:
  
   A couple of quick announcements:
   Import PocketTopo Files. Compass can now import PocketTopo files and convert
   them to Compass data format. The feature does not import the �?o.top�?? file
   because that format is not documented. You have to export the data from
   PocketTopo as a text file then Compass can read the data and convert it to
   the Compass format. The import option is available in the Project Manager
   under the �?oTools- Import PocketTopo Files.�??
 
  Is anyone using the built-in PocketTopo import feature in the real world?
 
  It seems that, if shooting arbitrary splay shots from each station, which is where the DistoX really changes cave survey, Compass counts each of those splays as a mainline shot which counts for length. Unless I'm missing something (which is possible!), you need to manually mark each of these shots with the 'L' exclusion flag, and even then you don't get the passage modeling feature in Compass without additionally entering LRUD info.
 
  Would you consider adding an option during PocketTopo import which would recognize the difference between:
 
  A) a triple-repeat shot as single mainline survey shot which counts for length
 
  B) a single shot as a splay which doesn't count for length and doesn't *directly* affect passage wall modeling
 
  C) and (wishlist) would project all the splays from a single station onto the horizontal and vertical plane to produce LRUD values from those splays?
 
  I'd be interested in hearing what other people are doing when using PocketTopo + DistoX in the field and Compass for project management. As is, I'm working toward a custom script that does as much of the above as possible, but would prefer a built-in clean solution.
 
  Thanks!
 
  - DR
 
  --
  David A. Riggs 


Messsage #: 494
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sat, 15 Aug 2015 13:31:28 -0600
Subject: RE: [compass-users] Re: parsing .top files to Compass
From: "Larry" 

Martin,

Thanks for the information on importing ".top" files. The Python source code
will come in handy for resolving issues with Pocket Topo file format.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Saturday, August 15, 2015 8:14 AM
Subject: [compass-users] Re: parsing .top files to Compass

Example of .th file exported from .top file by TopParser 

https://bitbucket.org/AndrewA/topparser/downloads

.th file:

�q�q�q�qr


Messsage #: 495
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sat, 15 Aug 2015 13:43:54 -0600
Subject: Pocket Topo Importer Improvements
From: "Larry" 

David,

I have reworked the Pocket Topo importer and made the following changes:

1. You have the option of marking each splay shot with "L" flag to exclude
the shot from the cave length statistics. 

2. You have the option of combining "Triple-Shots" into a single shot. If a
Triple-Shot is combined, the measurements for all three shots are averaged
to single values for Length, Bearing and Inclination.

There are check-boxes that allow you to enable or disable the options. The
options are enabled by default.

Let me know if you have any questions or comments.

Larry 

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Friday, August 14, 2015 1:14 PM
Subject: RE: [compass-users]

On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"
 wrote:

 1. I'm not sure I understand what a "triple-repeat" shot is. Could you
clarify what that means?

PockeTopo, and with recent firmware update the DistoX2 itself, detects three
duplicate measurements as "quality checking" of a single survey shot. It
averages those three values into a single shot, and - as Martin points out -
doesn't explicitly tell us that in the exported txt file (I haven't tried
parsing the binary top file to see if it retains all three). 

I suppose that the heuristic to detect splays is independent of whether you
took triple-shots or not. In my surveys anything without a TO station is a
splay (and shouldn't count for length), anything with a TO station is a
centerline shot. This means that a dead-end passage must have a zero-length
fake shot to ensure that it's final shot counts as passage. 

 3. Integrating the splay shots into the 3D modeling is a bit more of a
problem because I'm working adding Compass's own splay shot handling.
Integrating Pocket Topo splay shots will have to wait until I finish
Compass's own system. (More on this below.)

This would be most welcome in Compass! 

In that case, it makes the most sense for a PockeTopo splay to equal a
Compass splay. I'd like to do away with LRUD entirely now that accurate
sprays are "free". 

Thanks Larry! 

- DR 

 One of the problems I have with Pocket Topo is that the file format is not
fully documented. There is no information about the ".top" files anywhere
that I can find. There is a tiny bit of documentation on "Text Export"
format here:

 http://paperless.bheeb.ch/download/PocketTopoManual.pdf

 There is no mention in that document on how Splay Shots are handled the
exported text. The only information on Pocket Topo splay shots that I've
found is in a Java program that supposedly imports the files. Unfortunately,
there are few comments, so I have to untangle the code to figure out what it
means.

 From what I've been able to gather, splay shots in the Pocket Topo text
files are indicated by shots that have no "to" station and whose bearing,
inclination and length are zero. If that is correct, I should be able to add
the "L" flag to each shot of those shots.

 As I pointed out above, I've been working a splay shot format for Compass.
It is part of a long-term Compass improvement project that I have been
working on for several years. To make it happen, I need to make a lot of
other changes to Compass, so I don't expect to have it ready in the near
future.

 I have already written and tested code to generate 3D models of rooms
derived from splay shots. Basically, you choose a station near the center of
the room and take shots to the wall in various directions. The system would
be flexible and allow the user to enter as little as one splay shot or
dozens of shots at any angle. If the surveyor entered only one splay shot,
Compass would interpret the room as being a circle with a radius of the
splay shot.  If there were more splay shots, Compass would draw a more
accurate model of the room. To display the room, Compass would interpolate
and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of
various sizes to match the contours of the room. The splay shots would be
entered just like a regular shots except that the "To" station would be a
special symbol. Currently, the plan is to use a right parenthesis ")" for
the "To" station because it vaguely resembles a passage wall. It turns out
that parenthesis is one of the few character that exists on most of the
non-English key boards. It also vaguely resembles a passage wall. You could
also associate splay stations with a specific station name by adding the
station name after the parenthesis: )AB24 The Up and Down dimension for each
splay would apply to the "To" station of the shot. In other words, the Up
and Down dimension would describe the wall height where the shot makes
contact with the wall. The height of the center of the room would be
controlled by the LRUDs of the "From" station. This should produce a
reasonably realistic room shape where the floor and the ceiling could be
either convex or concaved. However, it would not model a side branch of a
room wanders around a corner. I also have to think about how to handle rooms
that are surveyed by a series of shots that go around the edge of the room.

 Let me know if you have any more questions.

 Larry Fish

 ________________________________

 From: [email protected] [mailto:[email protected]]

 Sent: Thursday, August 13, 2015 8:27 PM
 To: [email protected]
 Subject: Re: [compass-users]

 On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
[compass-users]  wrote:
 
  A couple of quick announcements:
  Import PocketTopo Files. Compass can now import PocketTopo files and
convert
  them to Compass data format. The feature does not import the ".top" file
  because that format is not documented. You have to export the data from
  PocketTopo as a text file then Compass can read the data and convert it
to
  the Compass format. The import option is available in the Project
Manager
  under the "Tools- Import PocketTopo Files."

 Is anyone using the built-in PocketTopo import feature in the real world?

 It seems that, if shooting arbitrary splay shots from each station, which
is where the DistoX really changes cave survey, Compass counts each of those
splays as a mainline shot which counts for length. Unless I'm missing
something (which is possible!), you need to manually mark each of these
shots with the 'L' exclusion flag, and even then you don't get the passage
modeling feature in Compass without additionally entering LRUD info.

 Would you consider adding an option during PocketTopo import which would
recognize the difference between:

 A) a triple-repeat shot as single mainline survey shot which counts for
length

 B) a single shot as a splay which doesn't count for length and doesn't
*directly* affect passage wall modeling

 C) and (wishlist) would project all the splays from a single station onto
the horizontal and vertical plane to produce LRUD values from those splays?

 I'd be interested in hearing what other people are doing when using
PocketTopo + DistoX in the field and Compass for project management. As is,
I'm working toward a custom script that does as much of the above as
possible, but would prefer a built-in clean solution.

 Thanks!

 - DR

 --
 David A. Riggs 

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 #: 496
Authentication-Results: mta1005.groups.mail.ne1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sat, 15 Aug 2015 13:50:20 -0600
Subject: RE: [compass-users] Pocket Topo Importer Improvements
From: "Larry" 

PS: The new version is up on the internet here:

http://www.fountainware.com/compass/downloads/download.htm

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Saturday, August 15, 2015 1:44 PM
Subject: [compass-users] Pocket Topo Importer Improvements

David,

I have reworked the Pocket Topo importer and made the following changes:

1. You have the option of marking each splay shot with "L" flag to exclude
the shot from the cave length statistics. 

2. You have the option of combining "Triple-Shots" into a single shot. If a
Triple-Shot is combined, the measurements for all three shots are averaged
to single values for Length, Bearing and Inclination.

There are check-boxes that allow you to enable or disable the options. The
options are enabled by default.

Let me know if you have any questions or comments.

Larry 

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Friday, August 14, 2015 1:14 PM
Subject: RE: [compass-users]

On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"
 wrote:

 1. I'm not sure I understand what a "triple-repeat" shot is. Could you
clarify what that means?

PockeTopo, and with recent firmware update the DistoX2 itself, detects three
duplicate measurements as "quality checking" of a single survey shot. It
averages those three values into a single shot, and - as Martin points out -
doesn't explicitly tell us that in the exported txt file (I haven't tried
parsing the binary top file to see if it retains all three). 

I suppose that the heuristic to detect splays is independent of whether you
took triple-shots or not. In my surveys anything without a TO station is a
splay (and shouldn't count for length), anything with a TO station is a
centerline shot. This means that a dead-end passage must have a zero-length
fake shot to ensure that it's final shot counts as passage. 

 3. Integrating the splay shots into the 3D modeling is a bit more of a
problem because I'm working adding Compass's own splay shot handling.
Integrating Pocket Topo splay shots will have to wait until I finish
Compass's own system. (More on this below.)

This would be most welcome in Compass! 

In that case, it makes the most sense for a PockeTopo splay to equal a
Compass splay. I'd like to do away with LRUD entirely now that accurate
sprays are "free". 

Thanks Larry! 

- DR 

 One of the problems I have with Pocket Topo is that the file format is not
fully documented. There is no information about the ".top" files anywhere
that I can find. There is a tiny bit of documentation on "Text Export"
format here:

 http://paperless.bheeb.ch/download/PocketTopoManual.pdf

 There is no mention in that document on how Splay Shots are handled the
exported text. The only information on Pocket Topo splay shots that I've
found is in a Java program that supposedly imports the files. Unfortunately,
there are few comments, so I have to untangle the code to figure out what it
means.

 From what I've been able to gather, splay shots in the Pocket Topo text
files are indicated by shots that have no "to" station and whose bearing,
inclination and length are zero. If that is correct, I should be able to add
the "L" flag to each shot of those shots.

 As I pointed out above, I've been working a splay shot format for Compass.
It is part of a long-term Compass improvement project that I have been
working on for several years. To make it happen, I need to make a lot of
other changes to Compass, so I don't expect to have it ready in the near
future.

 I have already written and tested code to generate 3D models of rooms
derived from splay shots. Basically, you choose a station near the center of
the room and take shots to the wall in various directions. The system would
be flexible and allow the user to enter as little as one splay shot or
dozens of shots at any angle. If the surveyor entered only one splay shot,
Compass would interpret the room as being a circle with a radius of the
splay shot.  If there were more splay shots, Compass would draw a more
accurate model of the room. To display the room, Compass would interpolate
and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of
various sizes to match the contours of the room. The splay shots would be
entered just like a regular shots except that the "To" station would be a
special symbol. Currently, the plan is to use a right parenthesis ")" for
the "To" station because it vaguely resembles a passage wall. It turns out
that parenthesis is one of the few character that exists on most of the
non-English key boards. It also vaguely resembles a passage wall. You could
also associate splay stations with a specific station name by adding the
station name after the parenthesis: )AB24 The Up and Down dimension for each
splay would apply to the "To" station of the shot. In other words, the Up
and Down dimension would describe the wall height where the shot makes
contact with the wall. The height of the center of the room would be
controlled by the LRUDs of the "From" station. This should produce a
reasonably realistic room shape where the floor and the ceiling could be
either convex or concaved. However, it would not model a side branch of a
room wanders around a corner. I also have to think about how to handle rooms
that are surveyed by a series of shots that go around the edge of the room.

 Let me know if you have any more questions.

 Larry Fish

 ________________________________

 From: [email protected] [mailto:[email protected]]

 Sent: Thursday, August 13, 2015 8:27 PM
 To: [email protected]
 Subject: Re: [compass-users]

 On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
[compass-users]  wrote:
 
  A couple of quick announcements:
  Import PocketTopo Files. Compass can now import PocketTopo files and
convert
  them to Compass data format. The feature does not import the ".top" file
  because that format is not documented. You have to export the data from
  PocketTopo as a text file then Compass can read the data and convert it
to
  the Compass format. The import option is available in the Project
Manager
  under the "Tools- Import PocketTopo Files."

 Is anyone using the built-in PocketTopo import feature in the real world?

 It seems that, if shooting arbitrary splay shots from each station, which
is where the DistoX really changes cave survey, Compass counts each of those
splays as a mainline shot which counts for length. Unless I'm missing
something (which is possible!), you need to manually mark each of these
shots with the 'L' exclusion flag, and even then you don't get the passage
modeling feature in Compass without additionally entering LRUD info.

 Would you consider adding an option during PocketTopo import which would
recognize the difference between:

 A) a triple-repeat shot as single mainline survey shot which counts for
length

 B) a single shot as a splay which doesn't count for length and doesn't
*directly* affect passage wall modeling

 C) and (wishlist) would project all the splays from a single station onto
the horizontal and vertical plane to produce LRUD values from those splays?

 I'd be interested in hearing what other people are doing when using
PocketTopo + DistoX in the field and Compass for project management. As is,
I'm working toward a custom script that does as much of the above as
possible, but would prefer a built-in clean solution.

 Thanks!

 - DR

 --
 David A. Riggs 

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 #: 497
Authentication-Results: mta1003.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sat, 22 Aug 2015 22:30:36 -0600
Subject: New Compass feature
From: "Larry" 

I've just added a new feature to Compass that may be useful for reorganizing
survey files

The Project Manager now has a tool to make it easier to merge two or more
survey files into a single survey file. You simply create a list of the
files you want to combine, specify a destination file and Compass will merge
the files into a single file.

The files can come from any where so you can combine different directories,
different drives and different devices. You can also drag the files to the
list from any Windows file folder. The files can be combined in any order.
The input file list can contain the output file because program does not
overwrite the output file until all the files have merged together. This
allows you to add or concatenate new files to existing file. To protect you
from accidently overwriting valuable data, the program creates multilevel
backups  for the destination file.

The new version is up on the internet.

Larry


Messsage #: 498
Authentication-Results: mta1002.groups.mail.ne1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Mon, 24 Aug 2015 13:50:50 -0700
Subject: Re: [compass-users] Pocket Topo Importer Improvements
From: "David A. Riggs" 

On Sat, Aug 15, 2015 at 12:43 PM, 'Larry' [email protected]
[compass-users]  wrote:

 I have reworked the Pocket Topo importer and made the following changes:

 1. You have the option of marking each splay shot with �?oL�?? flag to exclude
 the shot from the cave length statistics.

 2. You have the option of combining �?oTriple-Shots�?? into a single shot. If
 a Triple-Shot is combined, the measurements for all three shots are
 averaged to single values for Length, Bearing and Inclination.

 There are check-boxes that allow you to enable or disable the options. The
 options are enabled by default.

Hi Larry,

I'm back from a week in the field using the DistoX2 - PocketTopo -
Compass workflow extensively.

The above new changes are most welcome, and I'll be re-processing my data
with the new version of Compass ASAP to try these out. They are two of my
biggest requests for the Compass PocketTopo import!

My comments apply to the PREVIOUS version, so pardon if these changes have
also already been incorporated.

* Length units are erroneously interpreted as meters even when 'feet' are
selected as unit in PocketTopo. The current workaround is to open the
generated .DAT file with a text editor, then find-replace all occurrences
of 'NAN' and a large scientific notation floating point number from the
file (otherwise Compass goes into an endless death spiral of "Invalid
Numeric Input" errors). Additionally, you must go into the survey editor,
use the "ambulance" repair button, and select "Entered meters, was feet" (I
believe) to scale the length units back.

.TXT files exported from PocketTopo with 'feet' for units will have the
following survey prefix line:

My Cave Name   (feet, 360)

* It is a semi-convention in PocketTopo that new survey legs start with a
zero-length "shot", which enables you to sketch a cross-section facing into
each passage at a junction. I ran into instances where Compass would seem
to group some of these together into an individual survey; they should
probably just be discarded.

Again, thanks so much for quickly incorporating these changes! Setting the
'L' exclude flag on splays and combining triple-shots really go a long way
toward incorporating this data into Compass seamlessly. Now we just need
native splay shots! :-)

- DR

David A. Riggs 

On Sat, Aug 15, 2015 at 12:43 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:

I have reworked the Pocket Topo importer and made the
following changes:

1. You have the option of marking each splay shot with �?oL�??
flag to exclude the shot from the cave length statistics. 

2. You have the option of combining �?oTriple-Shots�??
into a single shot. If a Triple-Shot is combined, the measurements for all
three shots are averaged to single values for Length, Bearing and Inclination.

There are check-boxes that allow you to enable or disable
the options. The options are enabled by default.Hi Larry,I'm back from a week in the field using the DistoX2 -> PocketTopo -> Compass workflow extensively.A�The above new changes are most welcome, and I'll be re-processing my data with the new version of Compass ASAP to try these out. They are two of my biggest requests for the Compass PocketTopo import!My comments apply to the PREVIOUS version, so pardon if these changes have also already been incorporated.* Length units are erroneously interpreted as meters even when 'feet' are selected as unit in PocketTopo. The current workaround is to open the generated .DAT file with a text editor, then find-replace all occurrences of 'NAN' and a large scientific notation floating point number from the file (otherwise Compass goes into an endless death spiral of "Invalid Numeric Input" errors). Additionally, you must go into the survey editor, use the "ambulance" repair button, and select "Entered meters, was feet" (I believe) to scale the length units back..TXT files exported from PocketTopo with 'feet' for units will have the following survey prefix line:My Cave Name A� (feet, 360)* It is a semi-convention in PocketTopo that new survey legs start with a zero-length "shot", which enables you to sketch a cross-section facing into each passage at a junction. I ran into instances where Compass would seem to group some of these together into an individual survey; they should probably just be discarded.Again, thanks so much for quickly incorporating these changes! Setting the 'L' exclude flag on splays and combining triple-shots really go a long way toward incorporating this data into Compass seamlessly. Now we just need native splay shots! :-)- DR-- David A. Riggs <[email protected]>


Messsage #: 499
Authentication-Results: mta1001.groups.mail.ne1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Tue, 25 Aug 2015 03:35:14 -0600
Subject: RE: [compass-users] Pocket Topo Importer Improvements
From: "Larry" 

David,

Thanks for the heads up on the meters/feet problem. I did not catch it. I've
fixed it, but I'm not ready to release the version because I'm working on a
bunch of other changes. I should have something released in the a few days.

I haven seen any files with an NAN in them. I would like to fix that
problem. How did you generate it?

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Monday, August 24, 2015 2:51 PM
Subject: Re: [compass-users] Pocket Topo Importer Improvements

On Sat, Aug 15, 2015 at 12:43 PM, 'Larry' [email protected]
[compass-users]  wrote:

I have reworked the Pocket Topo importer and made the following changes:

1. You have the option of marking each splay shot with "L" flag to exclude
the shot from the cave length statistics. 

2. You have the option of combining "Triple-Shots" into a single shot. If a
Triple-Shot is combined, the measurements for all three shots are averaged
to single values for Length, Bearing and Inclination.

There are check-boxes that allow you to enable or disable the options. The
options are enabled by default.

Hi Larry,

I'm back from a week in the field using the DistoX2 - PocketTopo - Compass
workflow extensively. 

The above new changes are most welcome, and I'll be re-processing my data
with the new version of Compass ASAP to try these out. They are two of my
biggest requests for the Compass PocketTopo import!

My comments apply to the PREVIOUS version, so pardon if these changes have
also already been incorporated.

* Length units are erroneously interpreted as meters even when 'feet' are
selected as unit in PocketTopo. The current workaround is to open the
generated .DAT file with a text editor, then find-replace all occurrences of
'NAN' and a large scientific notation floating point number from the file
(otherwise Compass goes into an endless death spiral of "Invalid Numeric
Input" errors). Additionally, you must go into the survey editor, use the
"ambulance" repair button, and select "Entered meters, was feet" (I believe)
to scale the length units back.

.TXT files exported from PocketTopo with 'feet' for units will have the
following survey prefix line:

My Cave Name   (feet, 360)

* It is a semi-convention in PocketTopo that new survey legs start with a
zero-length "shot", which enables you to sketch a cross-section facing into
each passage at a junction. I ran into instances where Compass would seem to
group some of these together into an individual survey; they should probably
just be discarded.

Again, thanks so much for quickly incorporating these changes! Setting the
'L' exclude flag on splays and combining triple-shots really go a long way
toward incorporating this data into Compass seamlessly. Now we just need
native splay shots! :-)

- DR

David A. Riggs 

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 #: 500
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Tue, 25 Aug 2015 11:00:01 -0700
Subject: Re: [compass-users] Pocket Topo Importer Improvements
From: "David A. Riggs" 

On Tue, Aug 25, 2015 at 2:35 AM, 'Larry' [email protected]
[compass-users]  wrote:

 Thanks for the heads up on the meters/feet problem. I did not catch it.
 I�?Tve fixed it, but I�?Tm not ready to release the version because I�?Tm working
 on a bunch of other changes. I should have something released in the a few
 days.

 I haven seen any files with an NAN in them. I would like to fix that
 problem. How did you generate it?

I consistently generated them on the German-language Windows 7 laptop we
used in the field last week. I just tried on my English-language Win 7
desktop and all the LRUD values are `0.00` as expected.

The field laptop had a recently-installed version of Compass (in English,
thankfully), but I can't speak for any other environmental differences
between the two that would result in such a strange conversion.  I'll see
if I can get you a raw converted .DAT from that machine.

If I recall correctly, the UP value was `NAN`, and the DOWN value was a
very long float in scientific notation format. I had to use find-replace
to convert both columns to `0.00` or else Compass would go into an endless
loop with "Invalid Numeric Input" error.

Guessing that the German-language difference could be the cause, perhaps a
numeric value was coerced to string and back to numeric type during the
conversion, and the German version rendered the string with comma
decimal-separator rather than period decimal-separator? Again, I'll try to
acquire an original converted file from that machine and send to you
off-list, though it may take several days.

- DR

David A. Riggs 

On Tue, Aug 25, 2015 at 2:35 AM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:

Thanks for the heads up on the meters/feet problem. I did
not catch it. I�?Tve fixed it, but I�?Tm not ready to release the
version because I�?Tm working on a bunch of other changes. I should have
something released in the a few days.

I haven seen any files with an NAN
in them. I would like to fix that problem. How did you generate it?

I consistently generated them on the German-language Windows 7 laptop we used in the field last week. I just tried on my English-language Win 7 desktop and all the LRUD values are `0.00` as expected.The field laptop had a recently-installed version of Compass (in English, thankfully), but I can't speak for any other environmental differences between the two that would result in such a strange conversion.A� I'll see if I can get you a raw converted .DAT from that machine.If I recall correctly, the UP value was `NAN`, and the DOWN value was a very long float in scientific notation format. I had to use find->replace to convert both columns to `0.00` or else Compass would go into an endless loop with "Invalid Numeric Input" error.Guessing that the German-language difference could be the cause, perhaps a numeric value was coerced to string and back to numeric type during the conversion, and the German version rendered the string with comma decimal-separator rather than period decimal-separator? Again, I'll try to acquire an original converted file from that machine and send to you off-list, though it may take several days.- DR-- David A. Riggs <[email protected]>


Messsage #: 501
Authentication-Results: mta1003.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Tue, 25 Aug 2015 12:28:17 -0600
Subject: RE: [compass-users] Pocket Topo Importer Improvements
From: "Larry" 

David,

Thanks. I would bet that the problem is the Decimal Separator. In some
European countries it is a Comma instead of the Period that is used in the
United States. I've been burned by the many times. The problem occurs
because the subroutines built into Windows change if the computer is set to
a European standard. They write comma for the decimal point and they expect
numbers that they read to use commas.

This works fine as long as you stay in the same country and don't try to
exchange data with someone living in a different country. Since Compass is
used by people living in different countries, its output cannot change from
country to country. If it did, no one would be to exchange Compass data
across borders. As a result, Compass has to override the Windows settings
and use one setting for all countries. I have chosen to use a period for all
countries.

In this case, I think Pocket Topo generates Periods for decimal points even
if it is on a German system. On the other hand, the Compass importer is
using Windows routines that are expecting a Comma on a German system. That
could easily cause the NAN problem.

I have a single switch in Compass that forces Windows to use a period no
matter what the country settings say. I forgot to use that switch in the
Pocket Topo converter. I should be able to fix this pretty easily. It is
easy to test the problem because it is easy to change my computer to German
standards. I expect to have a new version for you in a few days.

Thanks for the feed back; it is very helpful.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, August 25, 2015 12:00 PM
Subject: Re: [compass-users] Pocket Topo Importer Improvements

On Tue, Aug 25, 2015 at 2:35 AM, 'Larry' [email protected]
[compass-users]  wrote:

Thanks for the heads up on the meters/feet problem. I did not catch it. I've
fixed it, but I'm not ready to release the version because I'm working on a
bunch of other changes. I should have something released in the a few days.

I haven seen any files with an NAN in them. I would like to fix that
problem. How did you generate it?

I consistently generated them on the German-language Windows 7 laptop we
used in the field last week. I just tried on my English-language Win 7
desktop and all the LRUD values are `0.00` as expected.

The field laptop had a recently-installed version of Compass (in English,
thankfully), but I can't speak for any other environmental differences
between the two that would result in such a strange conversion.  I'll see if
I can get you a raw converted .DAT from that machine.

If I recall correctly, the UP value was `NAN`, and the DOWN value was a very
long float in scientific notation format. I had to use find-replace to
convert both columns to `0.00` or else Compass would go into an endless loop
with "Invalid Numeric Input" error.

Guessing that the German-language difference could be the cause, perhaps a
numeric value was coerced to string and back to numeric type during the
conversion, and the German version rendered the string with comma
decimal-separator rather than period decimal-separator? Again, I'll try to
acquire an original converted file from that machine and send to you
off-list, though it may take several days.

- DR

David A. Riggs 

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 #: 502
Authentication-Results: mta1004.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sun, 6 Sep 2015 14:23:58 -0600
Subject: New Compass Version
From: "Larry" 

I wanted to let everyone know there is a new version of Compass with list of
bug fixes and improvements. The new version is up on the internet:
1. I have fixed several problems with the Pocket Topo importer.
2. The Survey Manipulating tool has several improvements.
A. The Up/Down arrow buttons can move multiple surveys at once. If you have
more than one survey highlighted, all of them will move when you press the
up/down arrow buttons.
B. You can also now drag and drop multiple surveys at once. If you have
multiple surveys highlighted all the highlighted surveys will be moved. 
C. You can now delete multiple surveys at once. If you have multiple surveys
highlighted all the highlighted surveys will be deleted. The program will
warn you before the files will be deleted.
D. The Up/Down arrow buttons will auto repeat if you hold the button down.
This speeds up the process of moving surveys into position.
3. The Viewer now allows you to set the line size for the shot lines,
features and the passage walls separately. These sizes can also be saved as
defaults.
4. The Project Manager now generates more accurate passage wall models. In
the past, when Compass processed junctions, it used the last LRUD for all
shots radiating from the From station. Now it uses the LRUD associated with
each shot's From station unless the data is missing. If the data is missing
it uses the best combination dimensions for that station. 
5. The "Error Log" in Project Manager is no longer on a separate page. It
has been moved to the bottom of the main window. This avoids the need to
switch back and forth between the two pages to compile or look at error
messages.
6. All the Compass help files have been improved by adding dozens of new
screen images of the Compass programs, dialog box and screen displays. This
should make it easier for people to following the instructions in the help
files.
Let me know if find any problems with the new version.
Larry


Messsage #: 503
Authentication-Results: mta1006.groups.mail.bf1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Sun, 6 Sep 2015 18:49:22 -0700
Subject: Re: [compass-users] New Compass Version
From: "David A. Riggs" 

On Sun, Sep 6, 2015 at 1:23 PM, 'Larry' [email protected]
[compass-users]  wrote:

 I wanted to let everyone know there is a new version of Compass with list
 of
 bug fixes and improvements. The new version is up on the internet:
 Let me know if find any problems with the new version.

Hi Larry,

Thanks so much for continuing to improve Compass, especially for improving
the DistoX-PocketTopo workflow!

I just downloaded and installed the latest version on a nearly-new Windows
7 virtual machine, and continually get an `Integer Overflow` error when
trying to "Compile and View Cave". I was afraid I'd corrupted some of my
survey data, but I went though the project creation wizard and get the same
error with a brand new .MAK, .DAT, and single-shot survey.

Is it possible that there's a showstopper bug in this release, or have I
botched my installation somehow?

- DR

David A. Riggs 

On Sun, Sep 6, 2015 at 1:23 PM, 'Larry' [email protected] [compass-users] <[email protected]> wrote:I wanted to let everyone know there is a new version of Compass with list of
bug fixes and improvements. The new version is up on the internet:Let me know if find any problems with the new version.Hi Larry,Thanks so much for continuing to improve Compass, especially for improving the DistoX-PocketTopo workflow!I just downloaded and installed the latest version on a nearly-new Windows 7 virtual machine, and continually get an `Integer Overflow` error when trying to "Compile and View Cave". I was afraid I'd corrupted some of my survey data, but I went though the project creation wizard and get the same error with a brand new .MAK, .DAT, and single-shot survey.Is it possible that there's a showstopper bug in this release, or have I botched my installation somehow?- DRA�-- David A. Riggs <[email protected]>


Messsage #: 504
Authentication-Results: mta1003.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sun, 6 Sep 2015 23:15:29 -0600
Subject: RE: [compass-users] New Compass Version [1 Attachment]
From: "Larry" 

Hi David,

I just had another report of the same problem. At first, I could not
reproduce the problem here, but after some poking, I've finally duplicated
the problem. I haven't tracked down the cause yet, but the "Integer
Overflow" error is usually occurs when I instruct the programming language
to flag any number that goes out of range. I thought it was off, but maybe
not or maybe some of my libraries have code where it is still on. What is
odd is the problem only occurs with the installed version, not freshly
compiled versions. 

At any rate, I will dig into it tonight or tomorrow and should have a
solution soon. 

In the meantime, I've uploaded an earlier build, that at least on my system,
doesn't give the error. If you really need a working version, you should
down load it. It probably has other bugs that I fixed in the last few days,
but at least it doesn't give the "Integer Overflow" error and should perform
most basic operations okay. If you still have major problems with it, I can
go back to an even earlier build to be sure that it is working version.

PS: The problem definitely isn't a result of a botched installation. 

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Sunday, September 06, 2015 7:49 PM
Subject: Re: [compass-users] New Compass Version [1 Attachment]

[Attachment(s) from David A. Riggs included below] 

On Sun, Sep 6, 2015 at 1:23 PM, 'Larry' [email protected]
[compass-users]  wrote:

I wanted to let everyone know there is a new version of Compass with list of
bug fixes and improvements. The new version is up on the internet:
Let me know if find any problems with the new version.

Hi Larry,

Thanks so much for continuing to improve Compass, especially for improving
the DistoX-PocketTopo workflow!

I just downloaded and installed the latest version on a nearly-new Windows 7
virtual machine, and continually get an `Integer Overflow` error when trying
to "Compile and View Cave". I was afraid I'd corrupted some of my survey
data, but I went though the project creation wizard and get the same error
with a brand new .MAK, .DAT, and single-shot survey.

Is it possible that there's a showstopper bug in this release, or have I
botched my installation somehow?

- DR

David A. Riggs 

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 #: 505
Authentication-Results: mta1002.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Mon, 7 Sep 2015 16:06:00 -0600
Subject: RE: [compass-users] New Compass Version
From: "Larry" 

Hi David and Everyone,

I've fixed the "Integer Overflow" problem. It turned out the one of my
libraries had the "Overflow Checking" flag left on, and it was flagging a
hash-code subroutine. It deliberately overflows an integer to produce a hash
code. 

The new version is up on the internet. It includes all the improvements
talked about in my previous posts. Let me know if you find any problems.

Larry 

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Sunday, September 06, 2015 11:15 PM
Subject: RE: [compass-users] New Compass Version

Hi David,

I just had another report of the same problem. At first, I could not
reproduce the problem here, but after some poking, I've finally duplicated
the problem. I haven't tracked down the cause yet, but the "Integer
Overflow" error is usually occurs when I instruct the programming language
to flag any number that goes out of range. I thought it was off, but maybe
not or maybe some of my libraries have code where it is still on. What is
odd is the problem only occurs with the installed version, not freshly
compiled versions. 

At any rate, I will dig into it tonight or tomorrow and should have a
solution soon. 

In the meantime, I've uploaded an earlier build, that at least on my system,
doesn't give the error. If you really need a working version, you should
down load it. It probably has other bugs that I fixed in the last few days,
but at least it doesn't give the "Integer Overflow" error and should perform
most basic operations okay. If you still have major problems with it, I can
go back to an even earlier build to be sure that it is working version.

PS: The problem definitely isn't a result of a botched installation. 

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Sunday, September 06, 2015 7:49 PM
Subject: Re: [compass-users] New Compass Version [1 Attachment]

On Sun, Sep 6, 2015 at 1:23 PM, 'Larry' [email protected]
[compass-users]  wrote:

I wanted to let everyone know there is a new version of Compass with list of
bug fixes and improvements. The new version is up on the internet:
Let me know if find any problems with the new version.

Hi Larry,

Thanks so much for continuing to improve Compass, especially for improving
the DistoX-PocketTopo workflow!

I just downloaded and installed the latest version on a nearly-new Windows 7
virtual machine, and continually get an `Integer Overflow` error when trying
to "Compile and View Cave". I was afraid I'd corrupted some of my survey
data, but I went though the project creation wizard and get the same error
with a brand new .MAK, .DAT, and single-shot survey.

Is it possible that there's a showstopper bug in this release, or have I
botched my installation somehow?

- DR

David A. Riggs 

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 #: 506
Authentication-Results: mta1001.groups.mail.ne1.yahoo.com  from=yahoo.com; domainkeys=neutral (no sig);  from=yahoo.com; dkim=pass (ok)
Date: Sat, 19 Sep 2015 22:59:35 +0000 (UTC)
Content-Length: 1245
Subject: export kml
From: Tom 

I try to export a kml, it keeps saying it's not geo-referenced. Yet I can see in the project manager it is. 
I tried closing project manager and re-opening the file, and the geo ref is there. I exported a shapefile and it also is undefined geo.what am I doing wrong?Tom

I try to export a kml, it keeps saying it's not geo-referenced. Yet I can see in the project manager it is. I tried closing project manager and re-opening the file, and the geo ref is there. I exported a shapefile and it also is undefined geo.what am I doing wrong?Tom


Messsage #: 507
Authentication-Results: mta1006.groups.mail.bf1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sun, 20 Sep 2015 00:15:04 -0600
Subject: RE: [compass-users] export kml
From: "Larry" 

Hi Tom,

I think I understand the problem. Let me walk you through some concepts that
will help make sense out how Compass handles KML files. There three kinds of
geo-referencing in Compass:

1. Base Locations. This option sets a general location for the cave. It is
not associated with a specific station so it has no effect on the locations
of the stations and passages in the cave. It is used by Compass to calculate
magnetic declinations. There are lots of caves where people don't have a GPS
location for the entrance but still want to be able to calculate declination
based on date and location. You set this value by pressing the "Set Base
Location" button on the Project Manager Tool Bar.

2. Local Reference Systems. In this system, people choose a location near
the cave as the base. Then every cave entrance is given a fixed location
relative to local location. This was a fairly common technique before people
had easy access to GPS receivers. For example, at one time, all the caves in
the Huautla cave system in Mexico were referenced to a nearby church. The
entrance of every cave in the Huautla system was set to a fixed value that
was the East and North distance from the church. 

3. Fixed UTM. In this system each entrance is set to a fixed UTM coordinate.
(Since it is easy to convert back and forth between UTM and Longitude and
Latitude, you can also enter the coordinates in Longitude and Latitude.)
This ties every station in the cave to a world coordinate system. 

To use the Google Earth KML files, all measurement have to be tied to a
world coordinates system. That means you have to use option #3. Option #1
won't work because it doesn't have any effect the individual stations in the
cave. Option #2 doesn't work because it is a local coordinate system and
doesn't tie cave locations to world locations. The only option that works is
#3 because it ties every cave location to global coordinates.

To use option #3, you must be working with a project or "MAK" file. You
cannot be working with a DAT file alone. 

Once you have a project file and one or more DAT files, you select one of
the DAT sub-files and press the "Edit File Node" button. In the window,
select the "Links/Fixed Stations" tab. On the "Fixed/Linking Stations" grid,
enter an Entrance station name. Next check the "Use UTM" option and press
the "Geo-Calculator" button. Enter the coordinates for the station. 

Now close the Edit Node window and save the project. Finally, press the
"Process and View" cave button. You now should be able to export the KML
without getting the error message.

The key to everything is the UTM Zone. Compass uses the UTM Zone to tell if
the cave is geo-reference or not. Without a UTM Zone, the coordinates aren't
referenced to a global system, so Compass assumes that any fixed stations
are referenced to a local system. 

For that reason, the "Use UTM" option is essential. If that check box is not
enabled, Compass won't write the UTM Zone to the MAK files and the Compiler
won't include the Zone in the PLT files. Without the Zone in the PLT files,
the 3D exporter will refuse to export a KML file. 

Let me know if these suggestions solve the problem. If not, you can send me
a copy of the data and I should be able to figure out the problem.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Saturday, September 19, 2015 5:00 PM
Subject: [compass-users] export kml

I try to export a kml, it keeps saying it's not geo-referenced. Yet I can
see in the project manager it is. 

I tried closing project manager and re-opening the file, and the geo ref is
there. I exported a shapefile and it also is undefined geo.

what am I doing wrong?

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 #: 508
Authentication-Results: mta1005.groups.mail.bf1.yahoo.com  from=skynet.be; domainkeys=neutral (no sig);  from=skynet.be; dkim=neutral (no sig)
Date: Sun, 27 Sep 2015 18:59:18 +0200
Subject: RE: [compass-users] export kml
From: "Paul De Bie" 

Great explanation from Larry and I can confirm it is working perfectly well, I do KML exports to GE
all of the time

Paul De Bie

From: [email protected] [mailto:[email protected]] 
Sent: Sunday, September 20, 2015 8:15 AM
Subject: RE: [compass-users] export kml

Hi Tom,

I think I understand the problem. Let me walk you through some concepts that will help make sense
out how Compass handles KML files. There three kinds of geo-referencing in Compass:

1. Base Locations. This option sets a general location for the cave. It is not associated with a
specific station so it has no effect on the locations of the stations and passages in the cave. It
is used by Compass to calculate magnetic declinations. There are lots of caves where people don't
have a GPS location for the entrance but still want to be able to calculate declination based on
date and location. You set this value by pressing the "Set Base Location" button on the Project
Manager Tool Bar.

2. Local Reference Systems. In this system, people choose a location near the cave as the base. Then
every cave entrance is given a fixed location relative to local location. This was a fairly common
technique before people had easy access to GPS receivers. For example, at one time, all the caves in
the Huautla cave system in Mexico were referenced to a nearby church. The entrance of every cave in
the Huautla system was set to a fixed value that was the East and North distance from the church. 

3. Fixed UTM. In this system each entrance is set to a fixed UTM coordinate. (Since it is easy to
convert back and forth between UTM and Longitude and Latitude, you can also enter the coordinates in
Longitude and Latitude.) This ties every station in the cave to a world coordinate system. 

To use the Google Earth KML files, all measurement have to be tied to a world coordinates system.
That means you have to use option #3. Option #1 won't work because it doesn't have any effect the
individual stations in the cave. Option #2 doesn't work because it is a local coordinate system and
doesn't tie cave locations to world locations. The only option that works is #3 because it ties
every cave location to global coordinates.

To use option #3, you must be working with a project or "MAK" file. You cannot be working with a DAT
file alone. 

Once you have a project file and one or more DAT files, you select one of the DAT sub-files and
press the "Edit File Node" button. In the window, select the "Links/Fixed Stations" tab. On the
"Fixed/Linking Stations" grid, enter an Entrance station name. Next check the "Use UTM" option and
press the "Geo-Calculator" button. Enter the coordinates for the station. 

Now close the Edit Node window and save the project. Finally, press the "Process and View" cave
button. You now should be able to export the KML without getting the error message.

The key to everything is the UTM Zone. Compass uses the UTM Zone to tell if the cave is
geo-reference or not. Without a UTM Zone, the coordinates aren't referenced to a global system, so
Compass assumes that any fixed stations are referenced to a local system. 

For that reason, the "Use UTM" option is essential. If that check box is not enabled, Compass won't
write the UTM Zone to the MAK files and the Compiler won't include the Zone in the PLT files.
Without the Zone in the PLT files, the 3D exporter will refuse to export a KML file. 

Let me know if these suggestions solve the problem. If not, you can send me a copy of the data and I
should be able to figure out the problem.

Larry

  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Saturday, September 19, 2015 5:00 PM
Subject: [compass-users] export kml

I try to export a kml, it keeps saying it's not geo-referenced. Yet I can see in the project manager
it is. 

I tried closing project manager and re-opening the file, and the geo ref is there. I exported a
shapefile and it also is undefined geo.

what am I doing wrong?

Tom

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}


Messsage #: 509
Authentication-Results: mta1003.groups.mail.bf1.yahoo.com  from=gmail.com; domainkeys=neutral (no sig);  from=gmail.com; dkim=pass (ok)
Date: Sat, 21 Nov 2015 17:47:30 +0100
Subject: Re: [compass-users] Pocket Topo Importer Improvements
From: Giorgio Pannuzzo 

Hi.
For the firste time I just tested PocketTopo Importer using last Compass 
version.

Noticed some problems until now:

1 -  Importing of triplets is incorrect in case of inverted legs.
The PocketTopo exported text marks them with the "
 http://www.fountainware.com/compass/downloads/download.htm

    _____

 From: [email protected] [mailto:[email protected]]
 Sent: Saturday, August 15, 2015 1:44 PM
 To: [email protected]
 Subject: [compass-users] Pocket Topo Importer Improvements

 David,

 I have reworked the Pocket Topo importer and made the following changes:

 1. You have the option of marking each splay shot with "L" flag to exclude
 the shot from the cave length statistics.

 2. You have the option of combining "Triple-Shots" into a single shot. If a
 Triple-Shot is combined, the measurements for all three shots are averaged
 to single values for Length, Bearing and Inclination.

 There are check-boxes that allow you to enable or disable the options. The
 options are enabled by default.

 Let me know if you have any questions or comments.

 Larry

    _____

 From: [email protected] [mailto:[email protected]]
 Sent: Friday, August 14, 2015 1:14 PM
 To: [email protected]
 Subject: RE: [compass-users]

 On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"
  wrote:

 1. I'm not sure I understand what a "triple-repeat" shot is. Could you
 clarify what that means?
 PockeTopo, and with recent firmware update the DistoX2 itself, detects three
 duplicate measurements as "quality checking" of a single survey shot. It
 averages those three values into a single shot, and - as Martin points out -
 doesn't explicitly tell us that in the exported txt file (I haven't tried
 parsing the binary top file to see if it retains all three).

 I suppose that the heuristic to detect splays is independent of whether you
 took triple-shots or not. In my surveys anything without a TO station is a
 splay (and shouldn't count for length), anything with a TO station is a
 centerline shot. This means that a dead-end passage must have a zero-length
 fake shot to ensure that it's final shot counts as passage.

 3. Integrating the splay shots into the 3D modeling is a bit more of a
 problem because I'm working adding Compass's own splay shot handling.
 Integrating Pocket Topo splay shots will have to wait until I finish
 Compass's own system. (More on this below.)
 This would be most welcome in Compass!

 In that case, it makes the most sense for a PockeTopo splay to equal a
 Compass splay. I'd like to do away with LRUD entirely now that accurate
 sprays are "free".

 Thanks Larry!

 - DR

 One of the problems I have with Pocket Topo is that the file format is not
 fully documented. There is no information about the ".top" files anywhere
 that I can find. There is a tiny bit of documentation on "Text Export"
 format here:
 http://paperless.bheeb.ch/download/PocketTopoManual.pdf

 There is no mention in that document on how Splay Shots are handled the
 exported text. The only information on Pocket Topo splay shots that I've
 found is in a Java program that supposedly imports the files. Unfortunately,
 there are few comments, so I have to untangle the code to figure out what it
 means.
  From what I've been able to gather, splay shots in the Pocket Topo text
 files are indicated by shots that have no "to" station and whose bearing,
 inclination and length are zero. If that is correct, I should be able to add
 the "L" flag to each shot of those shots.
 As I pointed out above, I've been working a splay shot format for Compass.
 It is part of a long-term Compass improvement project that I have been
 working on for several years. To make it happen, I need to make a lot of
 other changes to Compass, so I don't expect to have it ready in the near
 future.
 I have already written and tested code to generate 3D models of rooms
 derived from splay shots. Basically, you choose a station near the center of
 the room and take shots to the wall in various directions. The system would
 be flexible and allow the user to enter as little as one splay shot or
 dozens of shots at any angle. If the surveyor entered only one splay shot,
 Compass would interpret the room as being a circle with a radius of the
 splay shot.  If there were more splay shots, Compass would draw a more
 accurate model of the room. To display the room, Compass would interpolate
 and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges of
 various sizes to match the contours of the room. The splay shots would be
 entered just like a regular shots except that the "To" station would be a
 special symbol. Currently, the plan is to use a right parenthesis ")" for
 the "To" station because it vaguely resembles a passage wall. It turns out
 that parenthesis is one of the few character that exists on most of the
 non-English key boards. It also vaguely resembles a passage wall. You could
 also associate splay stations with a specific station name by adding the
 station name after the parenthesis: )AB24 The Up and Down dimension for each
 splay would apply to the "To" station of the shot. In other words, the Up
 and Down dimension would describe the wall height where the shot makes
 contact with the wall. The height of the center of the room would be
 controlled by the LRUDs of the "From" station. This should produce a
 reasonably realistic room shape where the floor and the ceiling could be
 either convex or concaved. However, it would not model a side branch of a
 room wanders around a corner. I also have to think about how to handle rooms
 that are surveyed by a series of shots that go around the edge of the room.
 Let me know if you have any more questions.

 Larry Fish

 ________________________________

 From: [email protected] [mailto:[email protected]]
 Sent: Thursday, August 13, 2015 8:27 PM
 To: [email protected]
 Subject: Re: [compass-users]

 On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
 [compass-users]  wrote:
 A couple of quick announcements:
 Import PocketTopo Files. Compass can now import PocketTopo files and
 convert
 them to Compass data format. The feature does not import the ".top" file
 because that format is not documented. You have to export the data from
 PocketTopo as a text file then Compass can read the data and convert it
 to
 the Compass format. The import option is available in the Project
 Manager
 under the "Tools- Import PocketTopo Files."

 Is anyone using the built-in PocketTopo import feature in the real world?

 It seems that, if shooting arbitrary splay shots from each station, which
 is where the DistoX really changes cave survey, Compass counts each of those
 splays as a mainline shot which counts for length. Unless I'm missing
 something (which is possible!), you need to manually mark each of these
 shots with the 'L' exclusion flag, and even then you don't get the passage
 modeling feature in Compass without additionally entering LRUD info.

 Would you consider adding an option during PocketTopo import which would
 recognize the difference between:

 A) a triple-repeat shot as single mainline survey shot which counts for
 length
 B) a single shot as a splay which doesn't count for length and doesn't
 *directly* affect passage wall modeling
 C) and (wishlist) would project all the splays from a single station onto
 the horizontal and vertical plane to produce LRUD values from those splays?

 I'd be interested in hearing what other people are doing when using
 PocketTopo + DistoX in the field and Compass for project management. As is,
 I'm working toward a custom script that does as much of the above as
 possible, but would prefer a built-in clean solution.

 Thanks!

 - DR

 --
 David A. Riggs 


Messsage #: 510
Authentication-Results: mta1004.groups.mail.ne1.yahoo.com  from=fountainware.com; domainkeys=neutral (no sig);  from=fountainware.com; dkim=neutral (no sig)
Date: Sat, 21 Nov 2015 12:57:58 -0700
Subject: RE: [compass-users] Pocket Topo Importer Improvements
From: "Larry" 

Hi Georgio,

Could you send me some data that shows the problems you are having? I have
several PocketTopop files that people have sent me and I've also generated
some files on my own. They all work fine, so it would be useful to have
files that cause the errors so I can be sure that I have fixed the problem
when I work on it. If you need privacy, send it directly to my private email
address. You should be able to find in the email header.

Here are some specific questions and thoughts your points:

1. I didn't know about the "Less-Than" symbol (" http://www.fountainware.com/compass/downloads/download.htm

    _____

 From: [email protected] [mailto:[email protected]]
 Sent: Saturday, August 15, 2015 1:44 PM
 To: [email protected]
 Subject: [compass-users] Pocket Topo Importer Improvements

 David,

 I have reworked the Pocket Topo importer and made the following changes:

 1. You have the option of marking each splay shot with "L" flag to exclude
 the shot from the cave length statistics.

 2. You have the option of combining "Triple-Shots" into a single shot. If
a
 Triple-Shot is combined, the measurements for all three shots are averaged
 to single values for Length, Bearing and Inclination.

 There are check-boxes that allow you to enable or disable the options. The
 options are enabled by default.

 Let me know if you have any questions or comments.

 Larry

    _____

 From: [email protected] [mailto:[email protected]]
 Sent: Friday, August 14, 2015 1:14 PM
 To: [email protected]
 Subject: RE: [compass-users]

 On Aug 14, 2015 12:26 AM, "'Larry' [email protected] [compass-users]"
  wrote:

 1. I'm not sure I understand what a "triple-repeat" shot is. Could you
 clarify what that means?
 PockeTopo, and with recent firmware update the DistoX2 itself, detects
three
 duplicate measurements as "quality checking" of a single survey shot. It
 averages those three values into a single shot, and - as Martin points out
-
 doesn't explicitly tell us that in the exported txt file (I haven't tried
 parsing the binary top file to see if it retains all three).

 I suppose that the heuristic to detect splays is independent of whether
you
 took triple-shots or not. In my surveys anything without a TO station is a
 splay (and shouldn't count for length), anything with a TO station is a
 centerline shot. This means that a dead-end passage must have a
zero-length
 fake shot to ensure that it's final shot counts as passage.

 3. Integrating the splay shots into the 3D modeling is a bit more of a
 problem because I'm working adding Compass's own splay shot handling.
 Integrating Pocket Topo splay shots will have to wait until I finish
 Compass's own system. (More on this below.)
 This would be most welcome in Compass!

 In that case, it makes the most sense for a PockeTopo splay to equal a
 Compass splay. I'd like to do away with LRUD entirely now that accurate
 sprays are "free".

 Thanks Larry!

 - DR

 One of the problems I have with Pocket Topo is that the file format is
not
 fully documented. There is no information about the ".top" files anywhere
 that I can find. There is a tiny bit of documentation on "Text Export"
 format here:
 http://paperless.bheeb.ch/download/PocketTopoManual.pdf

 There is no mention in that document on how Splay Shots are handled the
 exported text. The only information on Pocket Topo splay shots that I've
 found is in a Java program that supposedly imports the files.
Unfortunately,
 there are few comments, so I have to untangle the code to figure out what
it
 means.
  From what I've been able to gather, splay shots in the Pocket Topo text
 files are indicated by shots that have no "to" station and whose bearing,
 inclination and length are zero. If that is correct, I should be able to
add
 the "L" flag to each shot of those shots.
 As I pointed out above, I've been working a splay shot format for
Compass.
 It is part of a long-term Compass improvement project that I have been
 working on for several years. To make it happen, I need to make a lot of
 other changes to Compass, so I don't expect to have it ready in the near
 future.
 I have already written and tested code to generate 3D models of rooms
 derived from splay shots. Basically, you choose a station near the center
of
 the room and take shots to the wall in various directions. The system
would
 be flexible and allow the user to enter as little as one splay shot or
 dozens of shots at any angle. If the surveyor entered only one splay shot,
 Compass would interpret the room as being a circle with a radius of the
 splay shot.  If there were more splay shots, Compass would draw a more
 accurate model of the room. To display the room, Compass would interpolate
 and convert the splay shots into 8 or 10 evenly spaced pie-shaped wedges
of
 various sizes to match the contours of the room. The splay shots would be
 entered just like a regular shots except that the "To" station would be a
 special symbol. Currently, the plan is to use a right parenthesis ")" for
 the "To" station because it vaguely resembles a passage wall. It turns out
 that parenthesis is one of the few character that exists on most of the
 non-English key boards. It also vaguely resembles a passage wall. You
could
 also associate splay stations with a specific station name by adding the
 station name after the parenthesis: )AB24 The Up and Down dimension for
each
 splay would apply to the "To" station of the shot. In other words, the Up
 and Down dimension would describe the wall height where the shot makes
 contact with the wall. The height of the center of the room would be
 controlled by the LRUDs of the "From" station. This should produce a
 reasonably realistic room shape where the floor and the ceiling could be
 either convex or concaved. However, it would not model a side branch of a
 room wanders around a corner. I also have to think about how to handle
rooms
 that are surveyed by a series of shots that go around the edge of the
room.
 Let me know if you have any more questions.

 Larry Fish

 ________________________________

 From: [email protected]
[mailto:[email protected]]
 Sent: Thursday, August 13, 2015 8:27 PM
 To: [email protected]
 Subject: Re: [compass-users]

 On Sat, Feb 14, 2015 at 12:52 PM, 'Larry' [email protected]
 [compass-users]  wrote:
 A couple of quick announcements:
 Import PocketTopo Files. Compass can now import PocketTopo files and
 convert
 them to Compass data format. The feature does not import the ".top" file
 because that format is not documented. You have to export the data from
 PocketTopo as a text file then Compass can read the data and convert it
 to
 the Compass format. The import option is available in the Project
 Manager
 under the "Tools- Import PocketTopo Files."

 Is anyone using the built-in PocketTopo import feature in the real world?

 It seems that, if shooting arbitrary splay shots from each station, which
 is where the DistoX really changes cave survey, Compass counts each of
those
 splays as a mainline shot which counts for length. Unless I'm missing
 something (which is possible!), you need to manually mark each of these
 shots with the 'L' exclusion flag, and even then you don't get the passage
 modeling feature in Compass without additionally entering LRUD info.

 Would you consider adding an option during PocketTopo import which would
 recognize the difference between:

 A) a triple-repeat shot as single mainline survey shot which counts for
 length
 B) a single shot as a splay which doesn't count for length and doesn't
 *directly* affect passage wall modeling
 C) and (wishlist) would project all the splays from a single station onto
 the horizontal and vertical plane to produce LRUD values from those
splays?

 I'd be interested in hearing what other people are doing when using
 PocketTopo + DistoX in the field and Compass for project management. As
is,
 I'm working toward a custom script that does as much of the above as
 possible, but would prefer a built-in clean solution.

 Thanks!

 - DR

 --
 David A. Riggs 

Yahoo Groups Links