What can I say?! Bruce, that was some black magic. I don't quite understand why asking it to ignore a leg then changing your mind and asking it to draw it anyway, would cause it to then split it at the point you want. I wonder if I will be able to make sense out of that in future. What is makes me wonder is; why doesn't this exist? extend break 6 This could cause a centreline "weakness", and prefer (but not mandate) breaking at that point. It would massively simplify this control, and be much more predictable.

try to change the line in your .th file from:

extend ignore 6 5

to:

extend ignore 5 6

There is no leg 6-5 in your data, but there is leg 5-6.

This does not work. I assume that is because it is trying to extend the centreline from left to right, so it steps backwards through that oxbow (compared with the data). Or maybe I have not played with Bruce's solution enough... Cheers! Tarquin

Hi Tarquin

I don't quite understand why asking it to ignore a leg then changing your mind and asking it to draw it anyway, would cause it to then split it at the point you want. I wonder if I will be able to make sense out of that in future.

I think of extended generation as a trial and error sequential process. Tell it where to start, then what direction. See what happens. At the point where the generation deviates from what you would like, add an instruction, in the correct sequence. See what happens. Once that part works OK, look further along the centreline to find the next deviation, and add another instruction. So it is not changing mind or contradicting previous statements. See sequence below.

What is makes me wonder is; why doesn't this exist?

extend break 6

This could cause a centreline "weakness", and prefer (but not mandate) breaking at that point. It would massively simplify this control, and be much more predictable.

This is pretty much exactly what ‘extend ignore 6 <station at other end of leg>’ does. It causes the centreline to break at station 6, and continue automatic extended centreline generation elsewhere. Here is the plan view, and the solution I came up with. There are probably others. survey extendedloop centreline data normal from to length compass clino 1 2 1 0 5 2 3 1 0 -5 3 4 1 45 -10 4 5 1 90 5 5 6 1.71 225 45 6 2 1.71 225 -45 5 7 1 90 0 extend start 1 extend right 1 extend ignore 6 5 extend right 6 5 endcentreline endsurvey Stepping through the process I take; extend start 1 extend right 1 This produces an extended centreline that propagates 1 2 6 5 4 3 2, and now that the loop is closed (and broken at 2), propagation continues for the rest of the cave from 5 7. Could I have predicted this sequence? No. Usually I think Therion chooses the surveyed sequence, but not always. This is why I use a trial and error approach.

From the diagram above, I think that I want the map-connection line (the break) at station 6, and the extended generation direction for the leg to ignore is 6 5 (despite the survey data enumerating this leg as 5 6). So now I try;

extend start 1 extend right 1 extend ignore 6 5 This is much better, but the leg 5 6 is extending right and not left. The apparent generation sequence is now 1 2 6, 2 3 4 5 6, 5 7 So I could try; extend right 6 5 or extend left 5 6 I chose the former because it involved less typing, but the latter makes more sense perhaps if you are following the apparent sequence of generation. It turns out that they both work, and produce this (same apparent generation sequence, just the extend direction differs for 5 6); Don’t worry, extend is a mystery for me as well. This example turns out to fairly straight forward, but it can be very complicated for a real cave, especially if you don’t start thinking about the extended elevation until you have 10 km of passage in your project. Any further insights greatly appreciated. Bruce PS: I just noticed on page 25 of the Therion Book, that extend directions can be explicitly influenced from within a scrap drawing. I’d be interested in finding out about usage scenarios.

Tarquin Was hoping you would offer! Yes, this simple example makes a great starting point for an example that can shine light on extended elevation behaviour, and can be made progressively more complex to demonstrate behaviour changes. I have in previous projects noticed all you mention in your point 1 below. I don't have a problem with the characteristic you mention in point 2. I think it is just semantics associated with the word 'ignore', and sequential process. If you think 'break' then is it all OK? Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Monday, 11 November 2019 21:42 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: Re: [Therion] Breaking a loop at a specific station on extended elevation Hi Bruce,

Stepping through the process I take;

Thanks for that detailed explanation! The main things that threw me were: 1. That Therion is stepping *backwards* along the oxbow - in the direction of the cave passage from the "start" instead of in the direction that it is surveyed. This means that you must use your "extend ignore" in that same direction. "extend ignore 6 5" works, "extend ignore 5 6" does not. Apparently I am not the only one who finds this surprising. Also, just to be confusing, "extend ignore 6" will cause it to go completely wrong and break both ends of the loop (sounds buggy to me), while if the loops had more stations, it would break at station *2* in the oxbow, rather than at station 6. In loops with more stations, you can also break the offending leg in both directions without harm, while in the data I gave you, you can't. So there are some real gotchas in here. 2. That you can then tell a leg that was ignored to not be ignored after all. It can have two states specified, one immediately after the other, and *both* are respected. The first makes Therion change its "main path" of the extended elevation, and the second makes it draw the parts of the disconnected passage in the desired direction. This would make an excellent mini topic on the wiki (in the existing article on "extend"). I have made a more complete version of the survey that allows it to show a couple more variations. So if you don't mind, I would like to use some of your words to turn it into a mini-topic. Unless you argue, I will start to write this up. Cheers again, and thanks for the wisdom. Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion

Hi Wookey, Tarquin, I agree that extended elevations are too unpredictable, hard to use, and that there needs to be a simpler way. Not sure if it is that there are bugs, that instructions and understanding is inadequate, or if there is required functionality that is missing. Because extend ignore is usually associated with a survey network junction (nearby or not so nearby), I have a gut feeling that specifying a leg (perhaps with sensitivity to direction) will generally give more refined control. To use extend ignore to break at a particular station, using just a single station (if I have it right), you need to specify the station one leg beyond the desired break (a bit like 'flip' in PocketTopo). Generally, I find this approach to result in cognitive overload! If you want the break at a junction, you would often need to specify which leg anyway, depending on whether Therion's auto extended generation was incoming to or outgoing from the junction. Extend ignore directly controls branching, and only indirectly controls the break-point in the centreline. So perhaps the issue is missing functionality. Do we need direct user control over the break stations? It would be nice. Extend ignore also feels like a very indirect way of specifying network generation. As someone mentioned a long time back, it would be easier to specify 'extend force <leg>' rather than 'extend ignore <leg>'. ie 'Specify take this leg, rather than specifying take a different leg'. Especially where there are more than three branches emanating from a single station. While I would welcome Therion improvement in this space, I am a little concerned about all of my existing extended elevations that might be broken by changes in behaviour. I'm sure this eventuality can be accommodated by clever coders however. :) Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Wookey Sent: Tuesday, 12 November 2019 11:18 To: therion@speleo.sk Subject: Re: [Therion] Breaking a loop at a specific station on extended elevation On 2019-11-12 07:20 +1300, Bruce Mutton wrote:

I don't have a problem with the characteristic you mention in point 2. I think it is just semantics associated with the word 'ignore', and sequential process. If you think 'break' then is it all OK?

We think it should be possible to specify 'break/ignore' at a point, rather than a point+direction (i.e. a leg/pair of points) We want the computer to worry about the 'direction' aspect, and feel we shouldn't have to. It seems like this should be possible. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

This would make an excellent mini topic on the wiki (in the existing article on "extend").

I have now added a new article, with details of the investigation: https://therion.speleo.sk/wiki/breakingextend Because it uses a load of images, it was nicer to have it as a separate article, rather than litter the existing one. Bruce, please double check you are happy with how I linked it from your "extend" article.

Stacho, I am wondering if there is a fault in all the other "extend" options, rather than this problem being specific to "extend ignore". extend vertical 3 # everything after station *2* is vertical extend right 8 # everything after station *7* is extended to the right It seems like your "extend ignore" fix did not change any of these others, but now I am wondering if this is a general bug, or if they are supposed to take place for "the leg that reaches this station, and every leg after it". ... o_O Cheers, Tarquin

If extend algorithm follows stations in order 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 and you specify extend vertical 3 extend right 8 Then stations 3,4,5,6,7 should be placed vertical and 8,9 on the right. I have tested it and in my example, it works like this.

In the case of what you said, I would have expected the following legs to be default (right): 1-2 2-3 the following legs to be vertical: 3-4 4-5 5-6 6-7 7-8 then the following legs to be right: 8-9 Instead, leg 2-3 will be vertical, and leg 7-8 will be right. At least in my head, "extend vertical 3" feels like it should mean "everything from station 3 onwards". I think Bruce also expected this, given what he wrote in the wiki "extend" article: https://therion.speleo.sk/wiki/extend "Usually this option will not work as described, unless it is preceded by one or two extend right <leg> statements." So perhaps this is either a generic misunderstanding; Therion assumes that by <station> it means <the leg that goes *to* the station>. We assume that by <station> it should be <the legs that come *after* this station>. I don't know which of those is right. I have also never used this with Survex, so I don't know if Survex agrees with Therion - Perhaps Wookey can say?

Tarquin, our messages crossed...

At least in my head, "extend vertical 3" feels like it should mean "everything from station 3 onwards". I think Bruce also expected this, given what he wrote in the wiki "extend" article: https://therion.speleo.sk/wiki/extend "Usually this option will not work as described, unless it is preceded by one or two extend right <leg> statements."

No, I did not intend it that way, but I did not write it very clearly, as I noticed when I sent my previous message. The bit about 'usually will not work' is probably another issue. I don't know if it will still be the case with the recent changes. Bruce

Pretty sure this is the way it is. Which is why I tend to use extend <leg> rather than with a single <station>.

Yes, I think this might be something I will end up relying on, because it is much more readable, and understandable. And on top of that, you know that even if Therion gets changed to follow Survex, at least your Therion data will work either way.

Extend <station> in Therion is the same as the way PocketTopo implements 'flip' (equivalent to Therion's 'extend').

Interesting. So we have three existing implementations, but two different mechanisms (Survex does it the other way). Most of Therion's data syntax is compatible (and directly interchangeable) with Survex. This is an unusual case where it isn't compatible.

Normally, extend ignore 6 should do the job. But there was a bug in the code, so it did not work as intended. It should be fixed now in the latest commit. If some of you have more complex entended elevation projects, could you please check, whether this change does not introduce new errors? The behaviour of "extend ignore <from> <to>" should not be affected. Thanks, S. On Sun, 10 Nov 2019 at 12:08, Tarquin Wilton-Jones via Therion < therion@speleo.sk> wrote:

What can I say?!

Bruce, that was some black magic. I don't quite understand why asking it to ignore a leg then changing your mind and asking it to draw it anyway, would cause it to then split it at the point you want. I wonder if I will be able to make sense out of that in future.

What is makes me wonder is; why doesn't this exist? extend break 6

This could cause a centreline "weakness", and prefer (but not mandate) breaking at that point. It would massively simplify this control, and be much more predictable.

...

try to change the line in your .th file from:

extend ignore 6 5

to:

extend ignore 5 6

There is no leg 6-5 in your data, but there is leg 5-6.

This does not work. I assume that is because it is trying to extend the centreline from left to right, so it steps backwards through that oxbow (compared with the data). Or maybe I have not played with Bruce's solution enough...

Cheers!

Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion

Thanks Stacho, I have had a look through my projects, and I don’t think I have ever used an ‘extend ignore station’ because of its unpredictable results (but I have used many ‘extend ignore leg’, which usually work as expected). A quick check seems to indicate all my projects are unaffected by your latest update 094ac85fc5. Having a play with Tarquin’s example, it looks like an effect of ‘extend ignore station’ is to cause the map-connection break to occur at that station. That is conceptually quite nice for users. It seems to be consistent in that behaviour for the simple example, and is only ineffective if the station chosen is not in a loop (as you might expect). I did not test it where there is a pair of open branches though – that is a common scenario that should be checked. One more wish list for extend. I would like a; debug extend statement. This would enumerate in the log file the sequence of stations/legs that the extend algorithm is traversing. In complex survey networks with many loops it can seem impossible to unravel a sensible extended centreline. For example, if there are six survey branches coming into a single station, how do you isolate the particular leg that you want? A textual debug might help find the answer. Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Stacho Mudrak Sent: Friday, 15 November 2019 00:09 To: List for Therion users <therion@speleo.sk> Subject: Re: [Therion] Breaking a loop at a specific station on extended elevation Normally, extend ignore 6 should do the job. But there was a bug in the code, so it did not work as intended. It should be fixed now in the latest commit. If some of you have more complex entended elevation projects, could you please check, whether this change does not introduce new errors? The behaviour of "extend ignore <from> <to>" should not be affected. Thanks, S. On Sun, 10 Nov 2019 at 12:08, Tarquin Wilton-Jones via Therion <therion@speleo.sk <mailto:therion@speleo.sk> > wrote: What can I say?! Bruce, that was some black magic. I don't quite understand why asking it to ignore a leg then changing your mind and asking it to draw it anyway, would cause it to then split it at the point you want. I wonder if I will be able to make sense out of that in future. What is makes me wonder is; why doesn't this exist? extend break 6 This could cause a centreline "weakness", and prefer (but not mandate) breaking at that point. It would massively simplify this control, and be much more predictable.

try to change the line in your .th file from:

extend ignore 6 5

to:

extend ignore 5 6

There is no leg 6-5 in your data, but there is leg 5-6.

This does not work. I assume that is because it is trying to extend the centreline from left to right, so it steps backwards through that oxbow (compared with the data). Or maybe I have not played with Bruce's solution enough... Cheers! Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion

I have added

log extend

feature to thconfig. It should log the traversing sequence of extend algorithm to therion.log file.

Brilliant! Thanks Stacho :) I will add it to my wiki article. (And I have no doubt that Bruce will also add it to his.)