arranging files for big systems
OK - now that I have a few non-trivial chunks of therion data to bring together I have re-arranged everything in a big-cave way. This has of course caused some problems. I am documenting them here. What I want to be able to do is produce a whole area map as well as smaller maps of each cave in the area, and maybe parts of a cave, and keep related data together,but only have it appear in one place. I know how to do this in survex, using a directory for each major cave or area. That contains an 'overview file' that is something like: *survey terikan *equate elevator.pt3.18b evening.25 *include elevator.svx *equate river.40 goon.0 *inculde goon.svx ... *end terikan so connections between surveys are here, but not connections within surveys (they are inside each .svx sub-file), and also connections (equates) are grouped together with the relevant files. So, I have an overall file for terikan in therion form but if I try to use the above structure - i.e like this: survey terikan map <scraplist> endmap input elevator.th2 input goon.th2 ... join <whwatever> centreline equate 0@goon 40@river input goon.th equate 25@evening 18b@pt3.elevator input elevator.th endcentreline endsurvey terikan then I get an error: therion: error -- terikan/terikan.th [72] -- not enough data readings at the first line that is an 'input <something>.th' The only way I can get it to work is by moving all the equates into one block, wrapped in a centreline/endcentreline command But for a big system this gives you a huge list of equates in one place and ahuge list of inputs below - it'smuch nicer to have the equates in the file next to the relevant inputs IMHO. So questions: 1) is my preferred arrangement possible/permitted in therion? How do would one do it? 2) Why do I get the error 'not enough data readings'? That seems to have very little to do with the actual problem - it took me some time to work out how to make it go away. I have more questions about arranging scraps and submaps too, but those can wait till another mail. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey wrote:
So, I have an overall file for terikan in therion form but if I try to use the above structure - i.e like this:
survey terikan map <scraplist> endmap
input elevator.th2 input goon.th2 ...
join <whwatever>
centreline equate 0@goon 40@river input goon.th
equate 25@evening 18b@pt3.elevator input elevator.th
endcentreline endsurvey terikan
then I get an error: therion: error -- terikan/terikan.th [72] -- not enough data readings at the first line that is an 'input <something>.th'
You should input files outside of the centreline command. You got the error message because therion considered 'input foo.th' be the station names without instrument readings.
The only way I can get it to work is by moving all the equates into one block, wrapped in a centreline/endcentreline command
You could also use centreline equate 0@goon 40@river endcentreline input goon.th centreline equate 25@evening 18b@pt3.elevator endcentreline input elevator.th which is not particularly nice :( We considered to allow the equate command outside of centerline, which would simplify the syntax to equate 0@goon 40@river input goon.th equate 25@evening 18b@pt3.elevator input elevator.th It may be perhaps introduced in the future. Martin
+++ Martin Budaj [05-01-08 14:49 +0100]:
Wookey wrote:
So, I have an overall file for terikan in therion form
You should input files outside of the centreline command.
You could also use
centreline equate 0@goon 40@river endcentreline input goon.th
Right. As you say, the syntax is a bit ugly. OK, so with the 'break' option I now have all my data arranged and read in in a big structure ready ford rawing the restof the cave. I should now have the same set-up as before, but within a larger structure - notjust the soundriver/elevator section. However with the same scraps and joins as before, just more centreline data and the new context,trying to process gives: ------------------
(0,0)
! Division by zero. <to be read again> endgroup <to be read again> ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; <forever> ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c... l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------ Any clues as to what's wrong there? Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- 38 which seems very odd asit looks perfectly valid to me.... The tarball is at http://trilogy-gw.aleph1.co.uk/~wookey/files/terikan.tgz right. bedtime Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey wrote:
centreline equate 0@goon 40@river endcentreline input goon.th
Right. As you say, the syntax is a bit ugly.
Some time ago, we wanted to enhance JOIN command to work also for survey stations (like it works for drawn scraps, lines or points). This way centreline equate 0@goon 40@river endcentreline would be replaced by join 0@goon 40@river Another possibility is to add separate equate command. I am not sure, which way is more correct. S.
krok = step, interval cas = time dlzka = length mojkrok b= my step, my interval :) MS. --
+++ Wookey [05-01-10 03:07 +0000]:
+++ Martin Budaj [05-01-08 14:49 +0100]:
Wookey wrote:
So, I have an overall file for terikan in therion form
However with the same scraps and joins as before, just more centreline data and the new context,trying to process gives:
------------------
(0,0)
! Division by zero. <to be read again> endgroup <to be read again> ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; <forever> ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c...
l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------
Any clues as to what's wrong there?
OK -I took bits in and out until I worked which bit is causing the problem: If I comment out this join then it works OK. join soundrivercrab_s1 soundriver2_s1 What is odd was that this join was OK when the centreline dataset was smaller. Nothing should have changed in this area. The map still looks OK. I am a bit perplexed. Still,now it is compiling again I can get on with drawing some more and comeback to this. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Has anyone (that probably means you martinB) got any idea what the problem below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't. And I still have no idea about this either: Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- 38 +++ Wookey [05-01-11 01:06 +0000]:
+++ Wookey [05-01-10 03:07 +0000]:
+++ Martin Budaj [05-01-08 14:49 +0100]:
Wookey wrote:
> > So, I have an overall file for terikan in therion form
However with the same scraps and joins as before, just more centreline data and the new context,trying to process gives:
------------------
>> (0,0)
! Division by zero. <to be read again> endgroup <to be read again> ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; <forever> ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c...
l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------
Any clues as to what's wrong there?
OK -I took bits in and out until I worked which bit is causing the problem: If I comment out this join then it works OK. join soundrivercrab_s1 soundriver2_s1
What is odd was that this join was OK when the centreline dataset was smaller. Nothing should have changed in this area. The map still looks OK.
I am a bit perplexed. Still,now it is compiling again I can get on with drawing some more and comeback to this.
Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey wrote:
Has anyone (that probably means you martinB) got any idea what the problem below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't.
The file index.th specified in the thconfig file as the main data source is missing in the archive. Could you supply it? Martin
A question - my developement version reports errors when reading your LRUD data. What doeas 0+8 means? And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 at from-station and 5 at to-station? Regards, S. Wookey wrote:
Has anyone (that probably means you martinB) got any idea what the problem below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't.
And I still have no idea about this either:
Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- 38
+++ Wookey [05-01-11 01:06 +0000]:
+++ Wookey [05-01-10 03:07 +0000]:
+++ Martin Budaj [05-01-08 14:49 +0100]:
Wookey wrote:
So, I have an overall file for terikan in therion form
However with the same scraps and joins as before, just more centreline data and the new context,trying to process gives:
------------------
(0,0)
! Division by zero. <to be read again> endgroup <to be read again> ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; <forever> ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c...
l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------
Any clues as to what's wrong there?
OK -I took bits in and out until I worked which bit is causing the problem: If I comment out this join then it works OK. join soundrivercrab_s1 soundriver2_s1
What is odd was that this join was OK when the centreline dataset was smaller. Nothing should have changed in this area. The map still looks OK.
I am a bit perplexed. Still,now it is compiling again I can get on with drawing some more and comeback to this.
Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Wookey
+++ Martin Budaj [05-01-14 08:13 +0100]:
Wookey wrote:
Has anyone (that probably means you martinB) got any idea what the problem below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't.
The file index.th specified in the thconfig file as the main data source is missing in the archive. Could you supply it?
Sorry, it's currently fairly pointless :-) -------------- #overview file for terikan system input terikan/terikan.th #input bluemoon/bluemoon.th --------------- Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
+++ Stacho Mudrak [05-01-14 08:23 +0100]:
A question - my developement version reports errors when reading your LRUD data. What doeas 0+8 means?
And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 at from-station and 5 at to-station?
Ah - I think both of those are notations for when there are two plausible/significant possible readings. e.g 0+8 could mean the point is on the wall, but there is 8m of bedding plane going off beyond, or keyhole passage where the point is on the wall of the canyon but the upper passage goes off 8m to the left. 1/5 could be two things: Either is has the same meaning but a different notation or it is means 1.5 and not been transliterated on data entry. Recording 'both' values like this is very useful when drawing up but of course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing centrelines that would be handy. Which file was it in? I'd have to check against the notes to be sure what the meaning was. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
soundriver.th [281] I was just asking, because in the 0.3.6, specification of from/to dimension is allowed in non-interleaved data, but currently you have to insert two numbers in [] instead of one. E.g. data from to bearing clino tape up down left right 10 11 123 -10 20 4 5 [8 6] [2 4] where [8 6] means, that left wall is 8 meters from station 10 and 6 metres from station 11. There is possibility to add different separator than space (e.g. /), therefore I was asking. Regards, S. Wookey wrote:
+++ Stacho Mudrak [05-01-14 08:23 +0100]:
A question - my developement version reports errors when reading your LRUD data. What doeas 0+8 means?
And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 at from-station and 5 at to-station?
Ah - I think both of those are notations for when there are two plausible/significant possible readings. e.g 0+8 could mean the point is on the wall, but there is 8m of bedding plane going off beyond, or keyhole passage where the point is on the wall of the canyon but the upper passage goes off 8m to the left.
1/5 could be two things: Either is has the same meaning but a different notation or it is means 1.5 and not been transliterated on data entry.
Recording 'both' values like this is very useful when drawing up but of course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing centrelines that would be handy.
Which file was it in? I'd have to check against the notes to be sure what the meaning was.
Wookey
Wookey wrote:
Ah - I think both of those are notations for when there are two plausible/significant possible readings. e.g 0+8 could mean the point is on the wall, but there is 8m of bedding plane going off beyond, or keyhole passage where the point is on the wall of the canyon but the upper passage goes off 8m to the left.
1/5 could be two things: Either is has the same meaning but a different notation or it is means 1.5 and not been transliterated on data entry.
Recording 'both' values like this is very useful when drawing up but of course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing centrelines that would be handy.
If therion (and/or survex) is going to support this useful concept[0] then we need to decide on a consistent syntax. I'd strongly recommend against using '/' as it's so commonly used as a more robust decimal point by surveyors, and would lead to a lot of the sort of confusion that Wookey's already in. The usual ',' and ';' sequencing operators are respectively the common european decimal point, and the survex comment, so are out too. I'd suggest one of '+', '&', ':' or '|', with a slight preference for '|'. For the record I currently record this type of thing as comments so is never interpreted by software, and I use no consistent syntax. John [0] Even if this is only to parse it then take the larger value, it still allows the data file to represent what was actually recorded in the cave without resorting to comments.
Wookey wrote:
However with the same scraps and joins as before, just more centreline
data
and the new context,trying to process gives:
------------------
> > >> (0,0)
! Division by zero. <to be read again> endgroup <to be read again> ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; <forever> ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c...
l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------
Any clues as to what's wrong there?
OK -I took bits in and out until I worked which bit is causing the problem: If I comment out this join then it works OK. join soundrivercrab_s1 soundriver2_s1
What is odd was that this join was OK when the centreline dataset was smaller. Nothing should have changed in this area. The map still looks OK.
The problem is the pit (line 72 in file commands) in scrap soundrivercrab_s1, which has duplicated last point (781.00 -53.00). I wonder how it could happen -- XTherion finishes the line when you click twice on the same point and doesn't insert the point twice. I have no idea why it is related to joining scraps. The problematic line is too far from the join to be influenced. This is perhaps question for Stacho. Anyway if you delete last duplicated point scrap join works fine. Martin.
participants (5)
-
John Pybus -
Martin Budaj -
Martin Sluka -
Stacho Mudrak -
Wookey