Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Stacho Mudrak
Thanks Marco and others for pointing these problems out.

So I have another suggestion. Not to implement extend stop, equate, but add
the possibility of 3 stations in extend ignore. I.e.

extend ignore   

would mean, do not go to s3 if you came to s2 from s1. In your case
Tarquin, specifying

extend ignore 8 7 11
extend ignore 6 7 12

should save the situation. Am I still missing something?

S.

On Thu, 16 Jul 2020 at 23:15, Stacho Mudrak  wrote:

> Thanks Marco, Tarquin for pointing this out.
>
> So I have another suggestion. Not to implement extend stop, but add the
> possibility of 3 stations in extend ignore.
>
> extend ignore   
>
> would mean, do not go to s3 if you came to s2 from s1. In your case
> Tarquin, specifying
>
> extend ignore 8 7 11
> extend ignore 6 7 12
>
> should save the situation. Am I missing something?
>
> S.
>
> On Thu, 16 Jul 2020 at 22:40, Tarquin Wilton-Jones via Therion <
> therion@speleo.sk> wrote:
>
>> > Something important I had not considered.  I wonder what it does to
>> tarquin's example.
>>
>> I don't even begin to know how to cope with the situation where there is
>> a separate branch from 7 to 12 in my example, where you want
>> 2-10-9-8-7-12 to be shown as one branch in the extended elevation, and
>> 1-2-3-4-5-6-7-11 in the other branch, with two station 7s.
>>
>> At that point, I think the only way to cope with it is to say:
>>
>> 7 7a 0 0 0
>> 7a 8 1 2 3
>> ...
>> 7a 12 1 2 3
>> extend ignore 7-7a
>>
>> Manipulate the data to add an extra station, allowing a break.
>>
>> I also don't think this discussion of "extend stop 8 7" can cope with it
>> either.
>>
>> I sense a large spanner in the works...
>>
>>
>> Tarquin
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
>>
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Tarquin Wilton-Jones via Therion
> extend ignore 8 7 11
> extend ignore 6 7 12
> 
> should save the situation. Am I missing something?

This is basically what I also thought; you need to supply three stations
to control it.

I was going to suggest the opposite notation:
extend prefer 8 7 12
meaning "to get to 12, prefer to start from the 8-7 leg".

But either preferring one triplet, or preventing the other, should work.
So I would be just as happy with your suggestion.

Either of these would also solve the "extend stop" problem at the same time.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Tarquin Wilton-Jones via Therion
> Something important I had not considered.  I wonder what it does to tarquin's 
> example.

I don't even begin to know how to cope with the situation where there is
a separate branch from 7 to 12 in my example, where you want
2-10-9-8-7-12 to be shown as one branch in the extended elevation, and
1-2-3-4-5-6-7-11 in the other branch, with two station 7s.

At that point, I think the only way to cope with it is to say:

7 7a 0 0 0
7a 8 1 2 3
...
7a 12 1 2 3
extend ignore 7-7a

Manipulate the data to add an extra station, allowing a break.

I also don't think this discussion of "extend stop 8 7" can cope with it
either.

I sense a large spanner in the works...


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


[Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Bruce Mutton
Stacho

Could there be an ‘extend stop 7’, whereby the algorithm stops extending 
regardless of the direction and branch from which station 7 is traversed?

In the diagram below it seems like station 7 could conceptually be encountered 
from station 6, 8 or 11.

Would the ‘stop’ be invoked every time 7 is encountered, or just the first time?

Seems like ‘extend stop station’ could be problematic or unpredictable, 
especially in live projects where new surveys are regularly added.

 

I like the idea of ‘extend stop leg’, but probably not ‘extend stop station’.

 

Bruce

 

From: Therion  On Behalf Of Stacho Mudrak
Sent: Thursday, 16 July 2020 20:26
To: List for Therion users 
Subject: Re: [Therion] Revisiting Breaking extended elevations on specific 
stations

 

Hi Bruce,

 

extend stop 8 7

 

would mean, that if the algorithm reaches station 7 from station 8, it stops 
extending, turns back, and continues from some previous stations. If the 
algorithm will go the opposite way (11->7->8), extend stop 8 7 will be ignored.

 

And to the general question: the b) is correct. Therion reads all extend 
statements, assign these options to oriented legs and stations, and then 
processes them.

 

S.

 



 

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


Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Bruce Mutton
`> needless to say, i was not able to tell therion how to break the centerline 
for the extended elevation. Eventually i removed a few "equates"
>(the loops closed quite well anyways)

> what about an option to "equate" to tell therion that it must not be used for 
> the extended elevation ?
>marco

Thanks Marco
Something important I had not considered.  I wonder what it does to tarquin's 
example.
Of course, there are two types of equate, although Therion rightly does not 
distinguish.  It was only important for very old software about 30 years ago.

The first type of equate, is that which is necessary to join one survey to the 
next.  Without this, you only have individual surveys that are not connected in 
any way.
It would make no sense for Therion's extend to ignore these.

The second type of equate, is the second, third etc to a particular survey, 
which cause the two centrelines to form loops.

Ah, and there is possibly a third distinction.  Those defined explicitly with 
'equate 1@survey2 43@survey1' and those that just happen to traverse the same 
station more than once within a particular survey trip.

I imagine you mean that a proposed 'extend ignore-equates' would be telling 
Therion to honour only those equates necessary to join the extended survey 
network, and ignore all other equates?

I guess 'extend ignore-equates' could honour namespaces, and be started at 
particular stations/legs and stopped at particular stations legs?
Maybe...
extend [equates (default) | ignore-equates ] [ [station1] [[station2]] ]

This could be used where the extended network is defined 'in-line' with the 
survey data, and 'in blocks' separated from the survey data.

Bruce

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


Re: [Therion] Block comment

2020-07-16 Thread Anton van Rosmalen
It actually works in a .th2 file :-)

> Gesendet: Donnerstag, 16. Juli 2020 um 21:31 Uhr
> Von: "Martin Sluka via Therion" 
> An: "List for Therion users" 
> Cc: "Martin Sluka" 
> Betreff: Re: [Therion] Block comment
>
> You may do it only in survey - endsurvey as comment - endcomment. 
> 
> There is no similar command in  .th2 or .thconfig file. 
> 
> Martin
> 
> Odesláno z iPhonu
> 
> 16. 7. 2020 v 21:28, Bruce Mutton :
> 
> > Anton
> > comment
> > endcomment block is allowed in data and configuration files.
> > Page 13 Therion Book
> > 
> > -Original Message-
> > From: Therion  On Behalf Of Anton van Rosmalen
> > Sent: Friday, 17 July 2020 07:24
> > To: therion@speleo.sk
> > Subject: [Therion] Block comment
> > 
> > Hey guys,
> > 
> > I hope you don't mind me asking another really basic question...
> > 
> > I know I can comment out parts of a line using # Now I want to be able to 
> > comment out whole blocks of text (specifically in the main portion a 
> > .thconfig or .th2 file). I can't find anything in the manual about this.
> > I mean things like:
> > 
> > /* everything
> > in
> > here
> > is commented
> > out...
> > */
> > 
> > like is common in C++ or any other programming language.
> > 
> > What am I missing?
> > 
> > Thanks!
> > 
> > Anton
> > 
> > 
> > ___
> > Therion mailing list
> > Therion@speleo.sk
> > https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Block comment

2020-07-16 Thread Martin Sluka via Therion
You may do it only in survey - endsurvey as comment - endcomment. 

There is no similar command in  .th2 or .thconfig file. 

Martin

Odesláno z iPhonu

16. 7. 2020 v 21:28, Bruce Mutton :

> Anton
> comment
> endcomment block is allowed in data and configuration files.
> Page 13 Therion Book
> 
> -Original Message-
> From: Therion  On Behalf Of Anton van Rosmalen
> Sent: Friday, 17 July 2020 07:24
> To: therion@speleo.sk
> Subject: [Therion] Block comment
> 
> Hey guys,
> 
> I hope you don't mind me asking another really basic question...
> 
> I know I can comment out parts of a line using # Now I want to be able to 
> comment out whole blocks of text (specifically in the main portion a 
> .thconfig or .th2 file). I can't find anything in the manual about this.
> I mean things like:
> 
> /* everything
> in
> here
> is commented
> out...
> */
> 
> like is common in C++ or any other programming language.
> 
> What am I missing?
> 
> Thanks!
> 
> Anton
> 
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Block comment

2020-07-16 Thread Anton van Rosmalen
Thank you sir!

That works :-)

Anton


> Gesendet: Donnerstag, 16. Juli 2020 um 21:28 Uhr
> Von: "Bruce Mutton" 
> An: "'List for Therion users'" 
> Betreff: Re: [Therion] Block comment
>
> Anton
> comment
> endcomment block is allowed in data and configuration files.
> Page 13 Therion Book
>
> -Original Message-
> From: Therion  On Behalf Of Anton van Rosmalen
> Sent: Friday, 17 July 2020 07:24
> To: therion@speleo.sk
> Subject: [Therion] Block comment
>
> Hey guys,
>
> I hope you don't mind me asking another really basic question...
>
> I know I can comment out parts of a line using # Now I want to be able to 
> comment out whole blocks of text (specifically in the main portion a 
> .thconfig or .th2 file). I can't find anything in the manual about this.
> I mean things like:
>
> /* everything
> in
> here
> is commented
> out...
> */
>
> like is common in C++ or any other programming language.
>
> What am I missing?
>
> Thanks!
>
> Anton
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Block comment

2020-07-16 Thread Bruce Mutton
Anton
comment
endcomment block is allowed in data and configuration files.
Page 13 Therion Book

-Original Message-
From: Therion  On Behalf Of Anton van Rosmalen
Sent: Friday, 17 July 2020 07:24
To: therion@speleo.sk
Subject: [Therion] Block comment

Hey guys,

I hope you don't mind me asking another really basic question...

I know I can comment out parts of a line using # Now I want to be able to 
comment out whole blocks of text (specifically in the main portion a .thconfig 
or .th2 file). I can't find anything in the manual about this.
I mean things like:

/* everything
in
here
is commented
out...
*/

like is common in C++ or any other programming language.

What am I missing?

Thanks!

Anton


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


[Therion] Block comment

2020-07-16 Thread Anton van Rosmalen
Hey guys,

I hope you don't mind me asking another really basic question...

I know I can comment out parts of a line using #
Now I want to be able to comment out whole blocks of text (specifically in the 
main portion a .thconfig or .th2 file). I can't find anything in the manual 
about this.
I mean things like:

/* everything
in
here
is commented
out...
*/

like is common in C++ or any other programming language.

What am I missing?

Thanks!

Anton
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Marco Corvi
last weekend i completed the survey of a cave with some parallel close pits
connected through several "windows".
the last survey joined the previous surveys at seven stations.

needless to say, i was not able to tell therion how to break the centerline
for the extended elevation. Eventually i removed a few "equates"
(the loops closed quite well anyways)

extended elevation requires a spanning tree of the centerline graph.
"extend" is meant to tell therion how to break loops "removing" edges/legs.

I suspect that this semantics of "extend stop" is not sufficient because if the
user moves the data around (which is acceptable because in therion data can
be reordered) the result could be different.

I believe that we need a way the user tell therion how to construct the spanning
tree without ambiguities. The only solution i can see is telling which
edge to remove.
The drawback is that each station appears only once (at one node) in
the tree, and
there cannot be two stations "7" as in Tarquin's problem.

back to the problem i experienced:
what about an option to "equate" to tell therion that it must not be
used for the
extended elevation ?

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Revisiting Breaking extended elevations on specific stations

2020-07-16 Thread Stacho Mudrak
Hi Bruce,

extend stop 8 7

would mean, that if the algorithm reaches station 7 from station 8, it
stops extending, turns back, and continues from some previous stations. If
the algorithm will go the opposite way (11->7->8), extend stop 8 7 will be
ignored.

And to the general question: the b) is correct. Therion reads all extend
statements, assign these options to oriented legs and stations, and then
processes them.

S.






On Wed, 15 Jul 2020 at 09:10, Bruce Mutton via Therion 
wrote:

> Stacho
>
> Stop seems like a keyword that probably evokes the right expectations from
> a user.
>
> Although, what are you thinking that a description of what it does would
> look like?
>
>
>
> extend stop 8 7
>
>
>
> Maybe, “when extending along leg 8 7, stop at 7, backup and start
> extending at the next part of the centreline that needs to be extended”.
>
> Or would it exactly mimic the extend ignore 8 7 extend ignore 7 8
> behaviour shown in the log in my 8 July email, which stops generating at
> station 8, then backs up, and eventually assigns itself a second start
> station to patch up an orphaned leg?
>
>
>
> What would be the expected behaviour of extend 8 7 if the centreline were
> to be extending from the right, starting at 11?
>
>
>
> And as a general question…
>
> Are extend statements processed in the sequence they are written, or are
> they all read by Therion before Therion chooses the best order to process
> them (as it does with survey data)?
>
>
>
> Bruce
>
>
>
> *From:* Therion  *On Behalf Of *Stacho Mudrak
> *Sent:* Wednesday, 15 July 2020 17:43
> *To:* List for Therion users 
> *Subject:* Re: [Therion] Revisiting Breaking extended elevations on
> specific stations
>
>
>
> Hi, after returning from the caving trip, I would like to finish this
> topic.
>
>
>
> For me, adding another parameter to extend is a little bit problematic, I
> would prefer some new keyword.
>
>
>
> What do you think about:
>
>
>
> extend stop 8 7
>
>
>
> S.
>
>
>
> On Wed, 8 Jul 2020 at 11:01, Tarquin Wilton-Jones via Therion <
> therion@speleo.sk> wrote:
>
> > How about...
> > extend ignore 8 7 [ (from) | to ]
> > ... since we already use the from and to keywords with respect to
> stations at each end of a survey leg?
>
> It's all good by me.
>
> The only reason I didn't suggest that keyword is that Therion is
> stepping through my loop backwards. So a user might assume that the "to"
> station is the "to" station from their data, when actually it is the
> "to" station from the "extend ignore" pair.
>
> But as long as people think it is intuitive enough, carry on :)
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion