How to get the right count for cave lengths
Hi, I have nearly completed the total survey for the system I am mapping. In total, there are a series of little caves (actually mines, but I will stick with the word "caves" because it is clearer), a blind surface shaft, and a couple of significantly long caves. In total, these were surveyed over a series of 6 trips. On one of those trips, we surveyed the surface, and any short fragments of passage that we encountered that way. One of those fragments turned out to be one of the major caves. The major cave's survey was subsequently completed on another trip, but its first few metres are included in the surface survey. I am used to Survex. Each of the surveying trips has its own .th file: overall.th ("input"s all the other files) surface1/surface1.th (contains the entrances to several fragments, and the first 2 legs of cave 1) surface2/surface2.th (contains the blind shaft's plumbed depth and some other entrances) cave1/cave1.th (does not contain any entrances, but is a long cave, connected to the "cave 1 legs" in surface1.th cave2/cave2.th (contains the first part of cave2, and its entrance) cave3/cave3.th (contains cave3, with two entrances) cave2ext/cave2ext.th (contains the second part of cave2) Cave1 is connected to cave2. Each entrance is marked using "station 2 Cave1 entrance" in the centreline section of the file where it is defined. Survex only displays aggregate statistics. Therion tries to identify "caves", which is a concept I am not used to. I had hoped that Therion would be smart enough to see that caves are connected to each other, and work out the connected lengths. But it seems that it only works out the length of the files within the same survey. Cave1 doesn't get any length. Cave2 gets only the length from cave2.th - the length of the cave2ext and cave1 are not included. How do I make Therion realise what caves are connected? Do I need to put them into a structure like this? survey overall survey cave1_2 -entrance 2@cave2 -name "Caves 1 and 2" input cave1.th input cave2.th input cave2ext.th endsurvey endsurvey And if so ... how do I tell it that *part* of the cave lies within the surface survey file? Do I need to split the surface survey up into parts, one of which is the entrance to cave1? Separately, when using "statistics topo-length on", it ignores the surface survey legs, which is quite unfair for the person who surveyed 1 km of surface to link all of the entrances - they get no credit at all. Can it be asked to include surface legs in the topo-length calculations for survey credits? Thanks for any advice. Tarquin
TarquinHave a look at https://therion.speleo.sk/wiki/faq#how_do_i_specify_a_main_entrance_and_also... find out more about specifying what is a cave and what is just another entrance. To see what Therion is interpreting from your input, cave-list and survey-list are a good compliment to the map output statistics. Surface survey is not counted as cave survey, so the statistics are not reported on map outputs. Yes you do need to structure your data to define which trips belong to which caves. I would also have an overall surface survey to contain all of the surface trips. Also, flags surface and flags not surface are required to distinguish cave passage from from surface survey. I prefer to also make sure the surface survey is in its own centreline (or own survey) if it is more than just once or two legs. In general I find it preferable to keep surface survey for surface (including isolated features like shafts), and create a new trip file for each cave. This helps maintain a clear separation of data for subsequent survey processing and statistics gathering. BruceSent from my Samsung Galaxy smartphone. -------- Original message --------From: Tarquin Wilton-Jones via Therion <therion@speleo.sk> Date: 19/04/19 06:33 (GMT+12:00) To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: [Therion] How to get the right count for cave lengths Hi,I have nearly completed the total survey for the system I am mapping. Intotal, there are a series of little caves (actually mines, but I willstick with the word "caves" because it is clearer), a blind surfaceshaft, and a couple of significantly long caves. In total, these weresurveyed over a series of 6 trips. On one of those trips, we surveyedthe surface, and any short fragments of passage that we encountered thatway. One of those fragments turned out to be one of the major caves. Themajor cave's survey was subsequently completed on another trip, but itsfirst few metres are included in the surface survey.I am used to Survex. Each of the surveying trips has its own .th file:overall.th ("input"s all the other files)surface1/surface1.th (contains the entrances to several fragments, andthe first 2 legs of cave 1)surface2/surface2.th (contains the blind shaft's plumbed depth and someother entrances)cave1/cave1.th (does not contain any entrances, but is a long cave,connected to the "cave 1 legs" in surface1.thcave2/cave2.th (contains the first part of cave2, and its entrance)cave3/cave3.th (contains cave3, with two entrances)cave2ext/cave2ext.th (contains the second part of cave2)Cave1 is connected to cave2.Each entrance is marked using "station 2 Cave1 entrance" in thecentreline section of the file where it is defined. Survex only displaysaggregate statistics. Therion tries to identify "caves", which is aconcept I am not used to.I had hoped that Therion would be smart enough to see that caves areconnected to each other, and work out the connected lengths. But itseems that it only works out the length of the files within the samesurvey. Cave1 doesn't get any length. Cave2 gets only the length fromcave2.th - the length of the cave2ext and cave1 are not included.How do I make Therion realise what caves are connected? Do I need to putthem into a structure like this?survey overallsurvey cave1_2 -entrance 2@cave2 -name "Caves 1 and 2"input cave1.thinput cave2.thinput cave2ext.thendsurveyendsurveyAnd if so ... how do I tell it that *part* of the cave lies within thesurface survey file? Do I need to split the surface survey up intoparts, one of which is the entrance to cave1?Separately, when using "statistics topo-length on", it ignores thesurface survey legs, which is quite unfair for the person who surveyed 1km of surface to link all of the entrances - they get no credit at all.Can it be asked to include surface legs in the topo-length calculationsfor survey credits?Thanks for any advice.Tarquin_______________________________________________Therion mailing listTherion@speleo.skhttps://mailman.speleo.sk/listinfo/therion
Try to arange your surveys to a structure with several layers (“name spaces”). Martin Odesláno z iPhonu 21. 4. 2019 v 5:58, Bruce Mutton <bruce@tomo.co.nz>:
Tarquin Have a look at https://therion.speleo.sk/wiki/faq#how_do_i_specify_a_main_entrance_and_also... to find out more about specifying what is a cave and what is just another entrance.
To see what Therion is interpreting from your input, cave-list and survey-list are a good compliment to the map output statistics. Surface survey is not counted as cave survey, so the statistics are not reported on map outputs. Yes you do need to structure your data to define which trips belong to which caves. I would also have an overall surface survey to contain all of the surface trips. Also, flags surface and flags not surface are required to distinguish cave passage from from surface survey. I prefer to also make sure the surface survey is in its own centreline (or own survey) if it is more than just once or two legs.
In general I find it preferable to keep surface survey for surface (including isolated features like shafts), and create a new trip file for each cave. This helps maintain a clear separation of data for subsequent survey processing and statistics gathering.
Bruce Sent from my Samsung Galaxy smartphone.
-------- Original message -------- From: Tarquin Wilton-Jones via Therion <therion@speleo.sk> Date: 19/04/19 06:33 (GMT+12:00) To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: [Therion] How to get the right count for cave lengths
Hi,
I have nearly completed the total survey for the system I am mapping. In total, there are a series of little caves (actually mines, but I will stick with the word "caves" because it is clearer), a blind surface shaft, and a couple of significantly long caves. In total, these were surveyed over a series of 6 trips. On one of those trips, we surveyed the surface, and any short fragments of passage that we encountered that way. One of those fragments turned out to be one of the major caves. The major cave's survey was subsequently completed on another trip, but its first few metres are included in the surface survey.
I am used to Survex. Each of the surveying trips has its own .th file:
overall.th ("input"s all the other files) surface1/surface1.th (contains the entrances to several fragments, and the first 2 legs of cave 1) surface2/surface2.th (contains the blind shaft's plumbed depth and some other entrances) cave1/cave1.th (does not contain any entrances, but is a long cave, connected to the "cave 1 legs" in surface1.th cave2/cave2.th (contains the first part of cave2, and its entrance) cave3/cave3.th (contains cave3, with two entrances) cave2ext/cave2ext.th (contains the second part of cave2)
Cave1 is connected to cave2.
Each entrance is marked using "station 2 Cave1 entrance" in the centreline section of the file where it is defined. Survex only displays aggregate statistics. Therion tries to identify "caves", which is a concept I am not used to.
I had hoped that Therion would be smart enough to see that caves are connected to each other, and work out the connected lengths. But it seems that it only works out the length of the files within the same survey. Cave1 doesn't get any length. Cave2 gets only the length from cave2.th - the length of the cave2ext and cave1 are not included.
How do I make Therion realise what caves are connected? Do I need to put them into a structure like this? survey overall survey cave1_2 -entrance 2@cave2 -name "Caves 1 and 2" input cave1.th input cave2.th input cave2ext.th endsurvey endsurvey
And if so ... how do I tell it that *part* of the cave lies within the surface survey file? Do I need to split the surface survey up into parts, one of which is the entrance to cave1?
Separately, when using "statistics topo-length on", it ignores the surface survey legs, which is quite unfair for the person who surveyed 1 km of surface to link all of the entrances - they get no credit at all. Can it be asked to include surface legs in the topo-length calculations for survey credits?
Thanks for any advice.
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
Hi Bruce,
To see what Therion is interpreting from your input, cave-list and survey-list are a good compliment to the map output statistics.
Indeed - this is what made me realise I was probably doing it the wrong way for Therion to understand. It is definitely a pain having to split up surveys, but the resulting structure will make more sense in future.
Surface survey is not counted as cave survey, so the statistics are not reported on map outputs.
This is a real shame. People who put in work should be recognised for that work, no matter which part of the survey they take part in. I have no problem at all with the part saying "the cave is this long" - which should of course only use the "not surface" part. But it is wrong for the map to say "this person surveyed 50 metres" or to ignore them completely, when they actually produced 1km of surface survey that allowed all of the other surveys to be linked together in the correct positions. I would dearly love some option to say "include surface legs in topo-length statistics". Really hoping you missed something, but you seem to know the program as well as anyone, so if you don't know of such an option then ... :( Guess I should file it as a feature request.
Yes you do need to structure your data to define which trips belong to which caves. I would also have an overall surface survey to contain all of the surface trips.
A load of great advice, thanks :) I have basically now done all of this. (I also switched to using a new centreline when the team changes - this is a pain though, because it means any calibration, copyright, date, authorship, etc. also has to be repeated. It would be so much easier for it to respect group.) Thanks again for all the assistance. Tarquin
(I also switched to using a new centreline when the team changes - this is a pain though, because it means any calibration, copyright, date, authorship, etc. also has to be repeated. It would be so much easier for it to respect group.)
It is a pain, but it is something I have got used to. Repeating from memory my interpretation of something that I think Stacho or Martin B posted some years ago; the reporting of statistics is only resolved down to centreline resolution (not survey leg resolution). So this means that Therion might well be honouring any changes to metadata that you make using group - endgroup. But the statistics gathering code cannot report accurately those changes, because the lowest resolution is 'by centreline'. If this interpretation is correct, then group endgroup is good for settings that affect the centreline shape, flags, standard deviation, but not for metadata that needs to be gathered for statistics reporting, such as changes relating to team members. Regarding reporting of surface survey statistics, you can export a sql database, and I am sure that it will contain the information you want, subject to the 'centreline resolution' issue above. You will need to think of the query criteria to set to get the result you are after. That is perhaps not completely helpful, because it means you will need to manually enter that information in the map-header, either by customising it, or entering it as a map-comment. 'Statistics' is a layout option, so it is possible that the visibility of surface centrelines may affect the statistics reported. I don't think so, but it is something you should check. ie symbol-show group surface-centreline vs symbol-hide group surface-centreline Otherwise, the next best option is as you have requested, an option to include or exclude the surface survey in the explo-length and topo-length totals for team members. Maybe a new statistics option is desirable; statistics <explo/topo-length on/off>, with the default [off] matching the current behaviour. If such a change were contemplated, then I would like carto'-length' (or maybe better carto'-scrap') to be included in the statistics that can be sorted by team member 'contribution' sorting. ie, I would like to sort cartographers by the amount of drawing they have contributed (currently only alphabetically is possible). I think the best measure of this would be the number of scraps they have drawn (consistent with my contention that more little scraps is better than few large scraps). And I guess the same potentially applies to copyrights. If there are 50 scraps that are copyrighted to one organisation, and 4 scraps to another, there should be the ability to sort the larger one first, rather than alphabetically. ie expand statistics <explo/topo-length on/hide/off> to statistics <explo/topo-length/carto/copyright on/hide/off> with the last two ranked on scrap count. Bruce
Oops, a mistake in the previous post. Should be… Maybe a new statistics option is desirable; statistics <surface-length on/off>, with the default [off] matching the current behaviour
Maybe a new statistics option is desirable;
*statistics <surface-length on/off>*, with the default [off] matching the current behaviour
Or a new value for topo-length, such as: statistics topo-length all But yes, your suggestion covers a few other cases, such as making sure it is also included in carto statistics, which is also nice, imho. It is filed here, but without any suggestion for how to implement it - feel free to add your comment to it, with your suggested option name: https://github.com/therion/therion/issues/132 Your idea of being able to show/sort by carto-length is also great. Not that it matters to our project right now, since I am the only one currently drawing up, but if someone else draws up a single scrap, it would be a little disproportionate to show them first just because their name sorts higher. Copyright, though, is a legal state, so it doesn't really matter so much to me about the ordering - (though yes, I can see why you might want it). Its main need for being there is to say to people "you need to contact these organisations for permission". But I did notice that it only pulls the copyright information from the scraps, not from the centreline, which means that if club A does the surveying (and therefore holds copyright of the data), and club B does the cartography, it will only show club B as copyright holders of the survey. In such a case, the drawn survey is a derived work of the data, and therefore anyone who needs to seek permission to make a derived work would need to seek permission from both club A and club B.
participants (3)
-
Bruce Mutton -
Martin Sluka -
Tarquin Wilton-Jones