Re: [Therion] Therion Theory - scrap and map definitions

[Martin Sluka via Therion]

> 10. 7. 2017 v 20:54, Martin Sluka via Therion :
> 
> north_branch_scrap1_170321.th2
> north_branch_scrap2_170321.th2
> north_branch_scrap3_170321.th2
> 

I apologize myself, more logical would be:

north_branch_170321_scrap1.th2
north_branch_170321_scrap2.th2
north_branch_170321_scrap3.th2


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

Re: [Therion] Therion Theory - scrap and map definitions

[Martin Sluka via Therion]

> 10. 7. 2017 v 12:08, Bruce Mutton via Therion :
> 
> Before I wiki-ise it, I’d like some feedback, or criticism, as appropriate!  
> Is it helpful? (I think so)
> 

Hi Bruce and all,

after many years of experimenting I made a presentation of What is behind 
Therion. You may download it here: http://studiosluka.eu/therion/ 
 The most difficult for me was to understand 
the principle of name spaces, what is normal way of thinking for authors of 
Therion. But at the end I did it, I hope.

As you probably know, all Therion’s data could be only in one file, including 
centerline, comments, log, maps and layout. Examples of such files made by 
Stacho were in Sample folder of Therion source code in former versions. By 
command „input“ you may add to therion file any piece of plain text code. So it 
doesn’t matter, if you’ll have all your .th files in separate file and you add 
them all by simple "input index_th.thc“ command to survey in higher level, or 
you’ll list them all in that survey. The same with equates, joins, logs, maps, 
… 

You may organize in the same way smaller parts of cave system as: 
index_th_north_branch.thc, index_equate_north_branch.thc, 
index_join_north_branch.thc index_map_north_branch.thc, etc. and input them one 
by one.

The same is possible to do with th2 files. The fastest way, how to work with 
Therion map editor is to have only one small scrap in one th2 file. And input 
all particular scrap to survey one by one.

Everything, what is in particular survey used as „source“ in thconfig is 
available to compilation. But everything, what is outside that survey is not 
available.

I started to use .scrap and .map „extensions in names of scraps and maps. 
Simply to be sure, what is what. It is more easy to add to scrap name from 
other surveyor „.scrap", then to correct his/her way to my  scrap names 
convention. And I started to use really long names for scraps and maps, to be 
from first sight sure, what that piece of text means.

Therion is able to collect all informations available in „source“ file and its 
name space. But not in all case it is what we want. So I prefer to use 
obligatory „select“ command in thconfig and select only one map definition. 
(thanks, Martin Budaj)

Because of better description of what is particular thconfig for I prefer to 
use extension .thconfig for configuration files. So I’ll use 
north_branch.thconfig instead thconfig file in folder North_Branch.

I use base survey as really base survey, with all informations about that 
particular survey trip, if possible with commented each survey shot (ignore 
all) and better all shots (but is more or less theory). It includes map 
definition too, just to check of drawing. In this case I don’t need to use any 
additional commands in header of survey or scrap. I simply follow numbering of 
stations as in centerline. All connections of data in higher surveys are made 
in by Therion’s name space convention with @ syntax. I apologize to Survex 
developers, but it is for me more logical way, because it allows me to use 
extension for scraps, maps an to use original data from Toporobot or 
PocketTopo. In this base survey I may define several maps if necessary for each 
particular scrap and select only one of them. There could be a map definition 
for all scraps together too.

In this way I input only .th files from lover levels, because .th2 files are 
inputed in them yet and I don’t need to voodoo with names of stations.

My data structure is simple:

my_cave
  my_cave.thconfig
  my_cave.th
  data
 north_branch— folder
  north_branch_170321— folder
north_branch.thconfig   
north_branch_170321.th 
north_branch_scrap1_170321.th2
north_branch_scrap2_170321.th2
north_branch_scrap3_170321.th2
...
scans — folder
output— folder
  north_branch_170514 — folder
...

 south_branch — folder
  ...

  index   — folder
  output  — folder
m.s.___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion Theory - scrap and map definitions

[Jonny Prouty via Therion]

Hello Bruce,

I've forwarded your email to Will Urbanski in regards to permission for
using the Radio Collar Cave data.


Best regards,

Jonny

---

Please excuse my brevity, I am responding from my phone.

On Jul 5, 2017 4:09 PM, "Bruce Mutton via Therion" 
wrote:

> A little while ago I explored the effects of different ways of relating
> scraps and maps to surveys, and to the files that contain them.
>
> I came up with the attached text, which I might get around to turning into
> a wiki page sometime.  There are links to some examples already available
> via the wiki.
>
>
>
> Before I wiki-ise it, I’d like some feedback, or criticism, as
> appropriate!  Is it helpful? (I think so)
>
>
>
> Footleg, I plagiarised your page, just a little.
>
> Also, if Danilo Magnani or Will Urbanski are still listening, or if
> someone knows how to contact them, I’d like permission to put on the wiki
> the project samples they posted to this forum some years ago. Those are
> named Complesso - Buc di V,  and DDC – Radio Collar Cave.
>
>
>
> Bruce
>
> ___
> 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] Therion Theory - scrap and map definitions

[Bruce Mutton via Therion]

Thankyou Andrew, Kevin, Vasily, Footleg

Your feedback appreciated, I’ll build on what I started, eventually, and put 
something on the wiki.

My view is that that there is no single consistent approach with Therion, 
instead there are principles that can be chosen or discarded by individual 
users.  The evidence for this is the wide variety of approaches described on 
the wiki and on this forum over the years.   I don’t really have a good handle 
on what all these approaches are yet, which is why I make these exploratory 
contributions!  But I feel like understanding is getting close!

 

A reason why there is no single approach is because we all have differing 
circumstances and preferences that make some aspects of project organisation 
seem better than others.  ie 

*   legacies, such as data from precedent software (PocketTopo, TopoDroid, 
Survex, pencil and paper, etc)
*   legacies such as ‘the way my peers do it’, or ‘the way I did it the 
first time I could make Therion work’, etc
*   personal preferences for organising data, 
*   how big your projects are, what you want to do with them or use them 
for, and
*   what other characteristics you place value on, and which ones you see 
as disadvantages or advantages.

 

Vasily’s  very ordered folder structure is the sort of thing you can do if  
adopt what I called 
‘Scrap and map definitions – outside trip file – outside survey’ SAMD-OTF-OS.  
Will Urbanski did a similar thing.

I like the orderliness of it, and that maps are not tightly bound to surveys, 
but seems to me it would entail lots of navigation while working on the 
project, as all the components you need while drawing one trip are stored far 
apart.  That is just my impression, and it might be quite wrong, as I have 
never developed a project of my own along those lines.  Like I said it all 
depends on preference, and what you see as advantage or disadvantage.

 

Footleg.  I have two cases like what you describe, where multiple surveys (up 
to 6) are describing either parts of the same chamber, or parts of a tightly 
interconnected part of the cave.  In one we made no allowance, and stuck to our 
system (SAMD-ITF-OS) and in hindsight, was a mistake – drawing and joining 
scraps was a nightmare.  In the other we bent the system slightly (so slightly 
I had trouble finding it just now) in effect creating a .th2 file that 
contained survey stations from 6 surveys.  That one was easy, and although is 
locally a bit of SAMD-OTF-OS, does not seem to create any glaring dislocation 
of the dominant pattern.  Nothing bad happened in terms of project consistency.

Like Footleg describes, I hate adding namespace descriptors to each survey 
station, so I never do it now.  Rather, I add it in the header, as Footleg 
described, so that the station points have names that match exactly the xvi 
imported from PocketTopo.   I use the revise statement to keep the survey 
stations in the scrap in this clean state.  It is described in 
https://therion.speleo.sk/wiki/paperless#data_transfer_from_pockettopo_to_therion
 Search for  the word revise about ¾ way down the page.

 

Kevin’s question about plan map of whole system and multiple projected 
elevations probably has a simple answer, but I have never used Survex, so it 
introduces variables that I know nothing about.  If Therion is fed individual 
survey trip centrelines, then Therion can be used to manage these into the 
various xvi files and scraps and maps of whichever projections and cave extents 
that you want.  If Therion is fed a single monster 3d file then I imagine it 
will be a challenge.  Not for me to comment on really, as I don’t know what I’m 
talking about.

 

So the last pages of the document posted did have a list of pro’s and con’s for 
each pattern, but I did not label them as pro’s and con’s, because one persons 
pro is another persons con.  I’ll add to them based on your feedback however.  
Sooner I get it on the wiki, sooner others can add their insights to it.

 

Bruce

 

 

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Footleg via 
Therion
Sent: Saturday, 8 July 2017 1:26 AM
To: Bruce Mutton via Therion <therion@speleo.sk>
Cc: Footleg <drfoot...@gmail.com>
Subject: Re: [Therion] Therion Theory - scrap and map definitions

 

Hi Bruce,

 

An interesting read. I think the test of any model is how well it handles the 
exceptions. In the case of my own projects (where I use my recommended 
structure of course) I have cases where I have to draw up a section of cave 
which spans more than one trip in one drawing (typically difficult junctions 
where approach passages were surveyed on different trips). So here I have to 
add a .th2 file at a higher level than the trip and have to draw the scrap 
referencing the station names with more than just the number. The tip to 
specify the namespace in the scrap header is how I handle this where I can keep 
each scrap to an area belonging to a

Re: [Therion] Therion Theory - scrap and map definitions

[Footleg via Therion]

Hi Bruce,

An interesting read. I think the test of any model is how well it handles
the exceptions. In the case of my own projects (where I use my recommended
structure of course) I have cases where I have to draw up a section of cave
which spans more than one trip in one drawing (typically difficult
junctions where approach passages were surveyed on different trips). So
here I have to add a .th2 file at a higher level than the trip and have to
draw the scrap referencing the station names with more than just the
number. The tip to specify the namespace in the scrap header is how I
handle this where I can keep each scrap to an area belonging to a single
trip (I still might want to draw multiple scraps in the same map editor
file, hence the need to place the .th2 file outside the trip). But in some
cases to get things to output how I want, there is no way to avoid having
stations from multiple trips in the same scrap. So here each station name
needs to include the namespace. So in reality the model I recommend only
works in idea cases, and needs to be merged with parts of some of your
other models to deal with these exceptions. The key thing I try to avoid as
far as possible is having to add namespaces to each station (as it means
you can no longer just click on the stations in a sketch imported from
PocketTopo and have the station numbers set automatically). I usually end
up clicking on all the station points to give them automatically assigned
numbers, and then add the namespace using search and replace in a plain
text editor.

It would be good to add an analysis of the pros and cons of each structure
to your document, covering how they handle the imperfect structure of real
world data.

Footleg

On Thu, Jul 6, 2017 at 12:38 PM Vasily Vl. Suhachev via Therion <
therion@speleo.sk> wrote:

> Hello Bruce and All
>
> I had to draw a few large caves and I want to share my experience:
>
> 1) I always keep scanned survey notebooks. This is an artifact obtained in
> a cave and is the source of truth.
>
> 2) I store the entire centerline in a separate directory with a split into
> files on a trip basis. I think this is more correct because the centerline
> is a direct reflection of the survey notebooks. In the case of an error,
> this allows you to quickly navigate to notebooks. Entire cave centerline
> assembled in index file inside centerline directory.
>
> 3) I do not tie maps tightly to survey trips because it's usually more
> convenient to draw a map that covers a cave part (passage, grotto) rather
> than surveying trip.
>
> I call such dedicated part of the cave as `subsystem`. Subsystem maps are
> stored in separate subsystem directories. In each directory there are files
> `thconfig`, * .th2 and a file `maps.th` in which the definition of maps
> and joins is stored.
>
> I store the definition of maps of the entire cave in the top directory in
> the `maps.th` file in which I connect the` maps.th` files from the
> subsystems' directories. I do not use therion namespaces for maps because
> the number of maps are much smaller than the surveys. Uniqueness of names
> of maps I support manually.
>
> Folder structure example:
> cave
> +-- survey# scanned notebooks
> +-- trip1
> +-- 1.jpg
> +-- 2.jpg
> +-- 3.jpg
> +-- trip2
> +-- trip3
> +-- trip4
> +-- cl# centerline
> +-- cave.th   # index file with equates
> +-- trip1.th
> +-- trip2.th
> +-- trip3.th
> +-- trip4.th
> +-- model
> +-- thconfig
> +-- map
> +-- p # plan
> +-- subsystem1
> +-- 1.th2
> +-- 2.th2
> +-- maps.th
> +-- thconfig
> +-- subsystem2
> +-- 3.th2
> +-- maps.th
> +-- thconfig
> +-- maps.th
> +-- thconfig
> +-- rr # extended elevation
> +-- r240   # elevation at 240
>
>
> 06.07.2017 03:08, Bruce Mutton via Therion пишет:
>
> A little while ago I explored the effects of different ways of relating
> scraps and maps to surveys, and to the files that contain them.
>
> I came up with the attached text, which I might get around to turning into
> a wiki page sometime.  There are links to some examples already available
> via the wiki.
>
>
>
> Before I wiki-ise it, I’d like some feedback, or criticism, as
> appropriate!  Is it helpful? (I think so)
>
>
>
> Footleg, I plagiarised your page, just a little.
>
> Also, if Danilo Magnani or Will Urbanski are still listening, or if
> someone knows how to contact them, I’d like permission to put on the wiki
> the project samples they posted to this forum some years ago. Those are
> named Complesso - Buc di V,  and DDC – Radio Collar Cave.
>
>
>
> Bruce
>
>
> 

Re: [Therion] Therion Theory - scrap and map definitions

[Vasily Vl. Suhachev via Therion]

Hello Bruce and All

I had to draw a few large caves and I want to share my experience:

1) I always keep scanned survey notebooks. This is an artifact obtained 
in a cave and is the source of truth.


2) I store the entire centerline in a separate directory with a split 
into files on a trip basis. I think this is more correct because the 
centerline is a direct reflection of the survey notebooks. In the case 
of an error, this allows you to quickly navigate to notebooks. Entire 
cave centerline assembled in index file inside centerline directory.


3) I do not tie maps tightly to survey trips because it's usually more 
convenient to draw a map that covers a cave part (passage, grotto) 
rather than surveying trip.


I call such dedicated part of the cave as `subsystem`. Subsystem maps 
are stored in separate subsystem directories. In each directory there 
are files `thconfig`, * .th2 and a file `maps.th` in which the 
definition of maps and joins is stored.


I store the definition of maps of the entire cave in the top directory 
in the `maps.th` file in which I connect the` maps.th` files from the 
subsystems' directories. I do not use therion namespaces for maps 
because the number of maps are much smaller than the surveys. Uniqueness 
of names of maps I support manually.


Folder structure example:

cave
+-- survey# scanned notebooks
+-- trip1
+-- 1.jpg
+-- 2.jpg
+-- 3.jpg
+-- trip2
+-- trip3
+-- trip4
+-- cl# centerline
+-- cave.th   # index file with equates
+-- trip1.th
+-- trip2.th
+-- trip3.th
+-- trip4.th
+-- model
+-- thconfig
+-- map
+-- p # plan
+-- subsystem1
+-- 1.th2
+-- 2.th2
+-- maps.th
+-- thconfig
+-- subsystem2
+-- 3.th2
+-- maps.th
+-- thconfig
+-- maps.th
+-- thconfig
+-- rr # extended elevation
+-- r240   # elevationat 240


06.07.2017 03:08, Bruce Mutton via Therion пишет:


A little while ago I explored the effects of different ways of 
relating scraps and maps to surveys, and to the files that contain them.


I came up with the attached text, which I might get around to turning 
into a wiki page sometime.  There are links to some examples already 
available via the wiki.


Before I wiki-ise it, I’d like some feedback, or criticism, as 
appropriate!  Is it helpful? (I think so)


Footleg, I plagiarised your page, just a little.

Also, if Danilo Magnani or Will Urbanski are still listening, or if 
someone knows how to contact them, I’d like permission to put on the 
wiki the project samples they posted to this forum some years ago. 
Those are named Complesso - Buc di V,  and DDC – Radio Collar Cave.


Bruce



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


--
  WBR, Vasily

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

Re: [Therion] Therion Theory - scrap and map definitions

[Andrew Atkinson via Therion]

Yes I think it is useful, clarifies what I think I understand. Might
terrify a beginner. I obviously prefer Footleg's structure, but have used
elements of them all when data demanded.

Andrew

On 5 Jul 2017 9:08 pm, "Bruce Mutton via Therion"  wrote:

> A little while ago I explored the effects of different ways of relating
> scraps and maps to surveys, and to the files that contain them.
>
> I came up with the attached text, which I might get around to turning into
> a wiki page sometime.  There are links to some examples already available
> via the wiki.
>
>
>
> Before I wiki-ise it, I’d like some feedback, or criticism, as
> appropriate!  Is it helpful? (I think so)
>
>
>
> Footleg, I plagiarised your page, just a little.
>
> Also, if Danilo Magnani or Will Urbanski are still listening, or if
> someone knows how to contact them, I’d like permission to put on the wiki
> the project samples they posted to this forum some years ago. Those are
> named Complesso - Buc di V,  and DDC – Radio Collar Cave.
>
>
>
> Bruce
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion