Splays - Revisiting Breaking extended elevations
Another random observation on extend control. Extending left and right using a block of control statements (as opposed to in-line with the survey data) results in Therion extending the splays incorrectly. This behaviour is present regardless of whether data is imported via PocketTopo, TopParser or SexyTopo. Examples below. Below, a SexyTopo elevation surveying to the right (splays are correctly drawn) Below, the above SexyTopo elevation exported to Therion (it is the same – good) Below, the above elevation from Therion exported left (splays are wrong) Notice how all the splays are extended in the direction that the legs are extended in. Another example of Therion export to pdf showing splays incorrectly extending in the direction that the legs have been extended. It should be more aligned to the approach that TopoDroid uses (page 19 of the user manual) <https://sites.google.com/site/speleoapps/home/topodroid/user-manual> “mid-line = centreline” “azimuth = bearing” Bruce
Extending left and right using a block of control statements (as opposed to in-line with the survey data) results in Therion extending the splays incorrectly.
Wait ... that's a bug?! I thought Therion just didn't handle splays well compared with Survex.
Notice how all the splays are extended in the direction that the legs are extended in.
Drives me crazy. Pretty bad behaviour, and makes all the splays useless for drawing extended elevations. Does this mean that there is actually a solution to this, by using inline extend commands?
Yeah, I'd call it a bug now. I think I first noticed this behaviour early in 2015, and if that was the case it would have been around version 5.3.16 (the date and version on my first decent extended elevation map). It would have been my first forays into extended elevations and I quickly switched from in-line to data blocks for extends for the reasons outlined here <https://therion.speleo.sk/wiki/extend> . Because I was already drawing completely electronic, not using pdfs or pencil sketches, I was using the xvi s exported from PocketTopo and so the Therion exports were a curiosity only. Placing the extend statements in a block was essentially an undocumented feature, and so I assumed it was my fault for stretching boundaries. And I assumed that if I placed the extends in-line, the splays would behave. I am not sure though, as I have not carried out any explicit tests. I’ve really only been prompted to bring it up now because a) we’re making good progress on extend behaviour and blocks of extend statements are becoming mainstream, and b) I have inherited some survey notes for which the sketches will be best drawn in pencil over a pdf printout. Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Monday, 27 July 2020 21:27 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: Re: [Therion] Splays - Revisiting Breaking extended elevations
Extending left and right using a block of control statements (as
opposed to in-line with the survey data) results in Therion extending
the splays incorrectly.
Wait ... that's a bug?! I thought Therion just didn't handle splays well compared with Survex.
Notice how all the splays are extended in the direction that the legs
are extended in.
Drives me crazy. Pretty bad behaviour, and makes all the splays useless for drawing extended elevations. Does this mean that there is actually a solution to this, by using inline extend commands? _______________________________________________ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion
And I assumed that if I placed the extends in-line, the splays would behave. I am not sure though, as I have not carried out any explicit tests.
Sadly not. Therion - in all cases - extends the splays in the same direction as the default direction from that station (or wherever you placed the inline extend command). Basically, the splays act like legs. This is really quite useless when you are trying to draw the passage shape correctly. TopoDroid, Pocket Topo and Survex all extend only the legs. They all keep the splays in the "same" direction (relative to the leg) as they were before, which makes them normally perfect for drawing extended elevations. They can project forwards and backwards out of the page (so to speak), so they end up the right distance, visually, from the station. There is always the issue when you are at a station where the extend direction changes from left to right or vertical, since at that point you don't know whether a splay should take its direction from the leg before or the leg after (or the "nearest" leg to it - perhaps the most useful answer). Survex gets this wrong sometimes, but is normally useful. Even so, that issue is just peanuts compared with how difficult it currently is to use Therion's exported XVI to draw your extended elevations. I would take an odd splay being wrong over *all* splays being wrong any day. Virtual awards await anyone who chooses to attack this problem. Tarquin
On Wed, Jul 29, 2020 at 06:25:50PM +0100, Tarquin Wilton-Jones via Therion wrote:
TopoDroid, Pocket Topo and Survex all extend only the legs. They all keep the splays in the "same" direction (relative to the leg) as they were before, which makes them normally perfect for drawing extended elevations. They can project forwards and backwards out of the page (so to speak), so they end up the right distance, visually, from the station.
There is always the issue when you are at a station where the extend direction changes from left to right or vertical, since at that point you don't know whether a splay should take its direction from the leg before or the leg after (or the "nearest" leg to it - perhaps the most useful answer). Survex gets this wrong sometimes, but is normally useful.
Examples of where Survex it gets it wrong are definitely of interest. I added extending of splays just over 3 years ago, and the NEWS entry (which also explains the algorithm used) explicitly invites feedback: | + Splays are now carried over the extended survey. The current | handling is simplistic, but should do a good enough job to be more | useful than discarding splays. The splays at each station are all | rotated together based on the bearing between the stations either | side of the current one along the first path extended through that | station. This nicely handles dead ends and the situation at the top | or bottom of a pitch, and should tend to pick an angle close to the | passage orientation along a traverse. It's weakest at junctions. | Feedback (especially examples which could be handled better) most | welcome. But so far the only thing I could possibly count as feedback on this subject is what you wrote above (which is good to hear overall, but it'd be helpful to have some details of where you've seen it go wrong). Cheers, Olly
I have tried to fix all the extended elevation issues in the latest development snapshot (commit 6860f82 <https://github.com/therion/therion/commit/6860f82e616edb5e0fc7b35120cfc68eb682897a> ). 1. splay shots should be extended relatively to survey shot with closest (horizontal) bearing 2. there is a possibility to specify reduction ratio for extended elevation (0 = vertical, 100 = normal left/right) - just use "extend <number>" 3. extend ignore via path of 3 points should now work -- use "extend ignore <s1> <s2> <s3>". I think this should allow all crazy loop configurations to be solved, but I am not still 100% sure. Unfortunately (but not surprisingly :/), there was a bug with the extended elevation algorithm. In the case there were loops present in the centerline, it caused some random behaviour. I have tried to fix this bug, but it required quite a deep change to the code. My data seems to work, but I suppose, there may be some cases when it still can fail. Could you please try your datasets? Thanks, S. On Thu, 30 Jul 2020 at 01:18, Olly Betts <olly@survex.com> wrote:
On Wed, Jul 29, 2020 at 06:25:50PM +0100, Tarquin Wilton-Jones via Therion wrote:
TopoDroid, Pocket Topo and Survex all extend only the legs. They all keep the splays in the "same" direction (relative to the leg) as they were before, which makes them normally perfect for drawing extended elevations. They can project forwards and backwards out of the page (so to speak), so they end up the right distance, visually, from the station.
There is always the issue when you are at a station where the extend direction changes from left to right or vertical, since at that point you don't know whether a splay should take its direction from the leg before or the leg after (or the "nearest" leg to it - perhaps the most useful answer). Survex gets this wrong sometimes, but is normally useful.
Examples of where Survex it gets it wrong are definitely of interest.
I added extending of splays just over 3 years ago, and the NEWS entry (which also explains the algorithm used) explicitly invites feedback:
| + Splays are now carried over the extended survey. The current | handling is simplistic, but should do a good enough job to be more | useful than discarding splays. The splays at each station are all | rotated together based on the bearing between the stations either | side of the current one along the first path extended through that | station. This nicely handles dead ends and the situation at the top | or bottom of a pitch, and should tend to pick an angle close to the | passage orientation along a traverse. It's weakest at junctions. | Feedback (especially examples which could be handled better) most | welcome.
But so far the only thing I could possibly count as feedback on this subject is what you wrote above (which is good to hear overall, but it'd be helpful to have some details of where you've seen it go wrong).
Cheers, Olly _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
1. splay shots should be extended relatively to survey shot with closest (horizontal) bearing
Holy _____, somebody buy this man a beer! Seriously, if I ever meet you in person, I owe you one. This is going to make our surveys so much easier to draw. You will also have Gareth's gratitude once he gets off his bike and realises what you have done :)
extend ignore <s1> <s2> <s3>
Glad you went with your own suggestion in the end. Fewer keywords to learn, and the controls are simple enough, and very intuitive. AFAICT, it does allow you to offer all of the controls needed even for complex looping (bugs aside).
Could you please try your datasets?
I do not yet have enough loops in my system to test it in anger, but I will let you know once I get a more complex extended elevation to draw up. (In surveys where I do have enough loops, I use projected elevation instead.) Hopefully Marco can use something more convoluted for testing. An oxbow maze should be perfect.
participants (4)
-
Bruce Mutton -
Olly Betts -
Stacho Mudrak -
Tarquin Wilton-Jones