Here is what happens with a real project that I did a year ago. As far as extended elevations go, it is a well-behaved project, that was built incrementally, starting with survey 1, then 2 etc. While the extended network behaves well, the log does not do so well. Here is a small sample. Curiously the extend log shows it starting in the middle of the survey sequence (it goes to survey 6 or 7) at a random entrance. There is no start 4.24 in the data, only a start 1.0! And yet… Two more things: The sequence from 4.20 to 4.19 all the way to 4.15 is extending right, but the log says it is left. I deduce that the sequence then steps back along the same network until it is time to extend along a new branch. That is what the BACK refers to (nice). Here is what the specified extended network that generates both of the images above look like. and much further down the table it gets to the bit of passage in the image above… So, the extend log, although following a credible path along the survey network, has some directional errors, and is nothing like the specified path. Curiously, this log, like the logs for some other projects of mine, end with some apparently random non-existent STARTs and stations that don’t necessarily exist, like -@1 in the sequence below. So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples. Bruce
So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples.
Initial look… * Start is OK. * Right becomes LEFT * Enumeration of the path stops at station 5, and misses legs 6 and 7 Bruce
And another variation… * Start is OK * Right becomes LEFT * LEFT 6 to LEFT 5 is incorrect on two counts. Looks like it should be RIGHT 2 then RIGHT 6 then BACK 2 then RIGHT 3 etc * Enumeration of the path stops at station 5, and misses legs 6 and 7 It seems the log of extend is not reflecting what is specified and what is actually produced. Commenting out the last extend (# extend left 5 6) made no difference between these two example ‘log extend paths’. Commenting station 5 (extend ignore 6 #5) is what triggers the significant difference in the two ‘log extend paths’. Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Bruce Mutton Sent: Thursday, 5 December 2019 06:52 To: 'List for Therion users' <therion@speleo.sk> Subject: [Therion] log extend
So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples.
Initial look… * Start is OK. * Right becomes LEFT * Enumeration of the path stops at station 5, and misses legs 6 and 7 Bruce
It looks there was a copy/paste error in the code :/ In the latest commit, it should be fixed I hope. Could you please check it once again? Thanks, S. On Wed, 4 Dec 2019 at 19:08, Bruce Mutton <bruce@tomo.co.nz> wrote:
And another variation…
- Start is OK - Right becomes LEFT - LEFT 6 to LEFT 5 is incorrect on two counts. Looks like it should be RIGHT 2 then RIGHT 6 then BACK 2 then RIGHT 3 etc - Enumeration of the path stops at station 5, and misses legs 6 and 7
It seems the log of extend is not reflecting what is specified and what is actually produced.
Commenting out the last extend (# extend left 5 6) made no difference between these two example ‘log extend paths’.
Commenting station 5 (extend ignore 6 #5) is what triggers the significant difference in the two ‘log extend paths’.
Bruce
*From:* Therion <therion-bounces@speleo.sk> *On Behalf Of *Bruce Mutton *Sent:* Thursday, 5 December 2019 06:52 *To:* 'List for Therion users' <therion@speleo.sk> *Subject:* [Therion] log extend
So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples.
Initial look…
- Start is OK. - Right becomes LEFT - Enumeration of the path stops at station 5, and misses legs 6 and 7
Bruce _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
It looks there was a copy/paste error in the code :/ In the latest commit, it should be fixed I hope.
Could you please check it once again?
Looking better for this example. And this one is OK… This next one maybe has a problem, stepping back from 2 goes direct to 4, whereas to follow the pattern precisely, it should be BACK 3, BACK 4 Bruce _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
It looks there was a copy/paste error in the code :/ In the latest commit, it should be fixed I hope.
Could you please check it once again? therion-setup-dev-5119596
And with this more complicated example things unravel a little more. Nothing has changed in this project since logs below from 4 December. The pdf outputs are fine, but the log still starts where there is no START (and not honouring the START 1.0 as in the image below), and there seem to be even more strange artefacts. Near the beginning there is a lot of bouncing around between 4.23@4 and -@4... calculating basic statistics ... done processing extended elevation ... START 4.24@4.MrTPot LEFT 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot RIGHT -@4.MrTPot BACK 4.23@4.MrTPot LEFT 4.22@4.MrTPot <mailto:4.22@4.MrTPot> It goes on like this gradually stepping along the survey . Seems it is tracking every single splay shot. In some of the subsurveys it seems like it is not tracking the splays, and in others only one splay per leg, even though there are many splays. So not consistent. Also after about 7200 lines, it seems like it has stopped logging early. Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Bruce Mutton Sent: Wednesday, 4 December 2019 22:35 To: 'List for Therion users' <therion@speleo.sk> Subject: [Therion] log extend Here is what happens with a real project that I did a year ago. As far as extended elevations go, it is a well-behaved project, that was built incrementally, starting with survey 1, then 2 etc. While the extended network behaves well, the log does not do so well. Here is a small sample. Curiously the extend log shows it starting in the middle of the survey sequence (it goes to survey 6 or 7) at a random entrance. There is no start 4.24 in the data, only a start 1.0! And yet… Two more things: The sequence from 4.20 to 4.19 all the way to 4.15 is extending right, but the log says it is left. I deduce that the sequence then steps back along the same network until it is time to extend along a new branch. That is what the BACK refers to (nice). Here is what the specified extended network that generates both of the images above look like. and much further down the table it gets to the bit of passage in the image above… So, the extend log, although following a credible path along the survey network, has some directional errors, and is nothing like the specified path. Curiously, this log, like the logs for some other projects of mine, end with some apparently random non-existent STARTs and stations that don’t necessarily exist, like -@1 in the sequence below. So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples. Bruce
participants (3)
-
Bruce Mutton -
Stacho Mudrak -
Tarquin Wilton-Jones