I agree that we should have the control that Marco describes below, but do not have any idea of a conceptual framework that would be compatible with the current Therion extended control.
Stacho's suggestion >Not to implement extend stop, equate, but add the possibility of 3 stations in >extend ignore. I.e. >extend ignore <s1> <s2> <s3> >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? I think that might be a good solution to add to Therion's current extend controls. As a digression, the idea of 'ignoring' particular routes through a station (as Therion currently requires) is not only counterintuitive, but inefficient. Imagine the typical case of one station with two legs attached. There are two ways available to traverse this, 1-2-3 and 3-2-1. For one station with three legs attached. There are six possible ways to traverse (three in each direction). For one station with four legs attached. There are twelve possible ways to traverse (six in each direction). The pattern is, for a station with n legs attached, there are n.(n-1) ways that an extend network could theoretically travel through the station. Therefore, for a station with a number of survey branches attached, it becomes very inefficient to specify with certainty the way the extended network should generate. For the simplest branch (one station with three legs) we could in theory specify one route that must be taken, or five routes that must not be taken, if we want to be certain of the result. Because we must specify (with ignore) those that must not be taken, I tend to be lazy and stop specifying ignores as soon as the network behaves as I wish it to. The risk with this, (I imagine) is that a new survey will one day be added to the network, or there might be some other data change, which changes things sufficiently that Therion takes an unwanted route that has not been specifically 'ignored'. Hence that which worked will suddenly no longer work, and the poor user must study what will by then be an unfamiliar network to track down the problem. If an intuitive and dependable conceptual means of controlling extends could be found that is not compatible with our current approach, then would it be acceptable to introduce a toggle like: extend-method [old-way (default) | new-way] This way old datasets will continue to work as before, and for current and future datasets, users could adopt what is hopefully a better means of extended control. It might be a bit of work, but worth it if it could provide easily understood and predictable control. Maybe TopoDroid has some lessons for what might work well? Bruce -----Original Message----- From: Therion <therion-boun...@speleo.sk> On Behalf Of Marco Corvi Sent: Monday, 20 July 2020 23:26 To: therion@speleo.sk Subject: Re: [Therion] Revisiting Breaking extended elevations on specific stations i realized i was too naive: the "principle" of the spanning tree is ok, but it is not enough. suppose to have five legs at a station 6-7 7-8 20-7 7-21 7-45 and some of them belongs to loop(s). Suppose that the user wants to have 6-7 7-8 together, and 20-7 7-21 together but the two pairs separated, because of the way loops get extended. and 7-45 attached to 6-7 7-8 at station 7. the abstract picture i came up with was to replace a crossway station, like "7" in the above example, with a complete graph (for 3-leg crossway this is trivial) to make the story short i think therion syntax needs a way to specify that 6-7 7-8 and 7-45 share station "7" in the extended elevation and 20-7 7-21 share a separate station "7". marco _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
