search

therion / therion

therion – cave surveying software
https://therion.speleo.sk
GNU General Public License v2.0
94 stars 44 forks source link

topo-length miscalculated for team members only added in a group/endgroup #131

Open tarquinwj opened 5 years ago

tarquinwj commented 5 years ago

survey xyz input "xyz plan.th2" ... centreline team person1 instruments group team person2 assistant 1 2 10 0 0 endgroup 2 3 10 0 0 endcentreline endsurvey

When you use "statistics topo-length on", Therion will say that person2 will have contributed 20 metres, even though they have only contributed 10. (Obviously not important for such a short cave, but in my usage, I have a 400 metre survey, where one person only helped for 50 metres, but because Therion counts them for the entire 400 metres, it ranks them above someone else who contributed 300 metres elsewhere.)

CaverBruce commented 5 years ago

I have not used group endgroup structures much.  I suspect they are not intended for the use you have tried here.  The smallest atom of survey that therion can isolate for statistics output is a whole centreline, as far as I recall. Hence the 20m result you have obtained. If you have distinct sets of metadata that you want isolated, than you need to place them each in their own centerline. A survey can contain many centerlines. Probably your person2 is correctly applied to the survey legs, and it is just that the reporting sees every thing in that centerline as applying to the whole centerline. BruceSent from my Samsung Galaxy smartphone.

tarquinwj commented 5 years ago

So yes, it seems that the group/endgroup relates only to the survey processing (presumably being a direct equivalent of a nameless "begin" and "end" in Survex). This is a really painful limitation though, because it means that if you have a team member who takes part in only part of a survey, you have to start a new centreline, the repeat all calibrations, copyright, units, instrument definitions, data configurations, etc. etc. etc..

It would be so much better for Therion to respect the grouping for statistics.

Even if the decision is not to change it, the documentation currently doesn't reflect this limitation (or suggest using multiple centrelines). The documentation should ideally be updated accordingly if the limitation is preserved.

CaverBruce commented 1 month ago

Some years later I got caught out by the same thing, forgetting that I was so wise in 2019. I just now tried to add all the explo-team and explo-date entries for a centreline mid data-table, just so as to avoid the complexity of creating multiple centrelines that Tarquin describes above: ie

group explo-date 2023.02
explo-team "Gregory"

more data-table shot entries

endgroup

Then another group block with a different date and explorers.

Alas, all of the group data is amalgamated in outputs as though all of the explorers explored all of this centreline's passages. If (topo-)date are entered in groups, then the date reported (in *.3d) outputs is the average of the dates in the entire centreline. It would be better if Therion either honoured the metadata so entered, or threw an error or warning stating that the grouped data entered will not be reported correctly. The current behaviour misleads the user into believing they are properly ascribing metadata to particular shots when for all practical purposes they are not.

I suggest that the statements that manifest this behaviour should throw an error when included within a group - endgroup pair. And 'someone' should check that statements that are claimed to work by the Therion Book entry do in fact work as documented ie calibrate, units, sd etc