Click here for an overview of the Compass Users Group Archives:
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
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/ >
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
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) }
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.
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.
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
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
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/
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
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) }
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
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
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
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) }
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
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
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
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]>
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
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]>
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
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
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)
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)
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
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) }
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]>
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) }
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
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]> > > > >
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]>>>>>
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
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
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) }
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) }
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
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]>
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) }
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]>
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) }
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
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]>
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) }
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) }
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
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) }
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);}
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
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