therion Result of: index.1_999 1: New conference address 8 Sep 2003 Stacho Mudrak 2: Re: How do all the metapost parts fit together. 8 Sep 2003 Martin Budaj 3: Re: [therion-users] Re: therion does a seg fault when I try and run it 8 Sep 2003 Stacho Mudrak 4: Re: New conference address 8 Sep 2003 Michael Lake 5: Re: How do all the metapost parts fit together. 8 Sep 2003 Wookey 6: Re: How do all the metapost parts fit together. 8 Sep 2003 Michael Lake 7: Re: How do all the metapost parts fit together. 8 Sep 2003 Michael Lake 8: Re: How do all the metapost parts fit together. 8 Sep 2003 Martin Budaj 9: Re: New conference address 8 Sep 2003 Stacho Mudrak 10: Re: How do all the metapost parts fit together. 8 Sep 2003 Stacho Mudrak 11: Re: How do all the metapost parts fit together. 8 Sep 2003 Stacho Mudrak 12: Re: How do all the metapost parts fit together. 9 Sep 2003 Stacho Mudrak 13: Re: How do all the metapost parts fit together. 9 Sep 2003 Wookey 14: Re: How do all the metapost parts fit together. 9 Sep 2003 Wookey 15: Re: How do all the metapost parts fit together. 9 Sep 2003 Stacho Mudrak 16: therion 0.2.15 uploaded to Debian 11 Sep 2003 Wookey 17: Re: [therion-users] Therion a MacOS X 10.2.3 - working!!! 23 Sep 2003 Martin Sluka 18: Re: Therion a MacOS X 10.2.3 - working!!! 24 Sep 2003 Stacho Mudrak 19: Re: Therion a MacOS X 10.2.3 - working!!! 24 Sep 2003 Gary Ritchie 20: survex to therion data conversion 5 Nov 2003 Wookey 21: Re: survex to therion data conversion 6 Nov 2003 John Pybus 22: Re: survex to therion data conversion 6 Nov 2003 Michael Lake 23: Re: survex to therion data conversion 6 Nov 2003 Wookey 24: Re: survex to therion data conversion 6 Nov 2003 Wookey 25: Re: survex to therion data conversion 6 Nov 2003 Andy Waddington on Cave Surveying 26: Re: survex to therion data conversion 6 Nov 2003 Stacho Mudrak 27: Re: survex to therion data conversion 6 Nov 2003 Stacho Mudrak 28: Re: survex to therion data conversion 6 Nov 2003 Wookey 29: Re: survex to therion data conversion 6 Nov 2003 Wookey 30: Re: survex to therion data conversion 6 Nov 2003 Stacho Mudrak 31: Re: survex to therion data conversion 7 Nov 2003 Stacho Mudrak 32: Re: survex to therion data conversion 7 Nov 2003 Stacho Mudrak 33: Re: survex to therion data conversion 7 Nov 2003 Wookey 34: Re: survex to therion data conversion 10 Nov 2003 Stacho Mudrak 35: new 0.2.15 14 Nov 2003 Stacho Mudrak 36: Re: new 0.2.15 14 Nov 2003 Wookey 37: Re: new 0.2.15 18 Nov 2003 Stacho Mudrak 38: Therion 0.2.16 24 Nov 2003 Martin Budaj 39: Translation 1 Dec 2003 Stacho Mudrak 40: Re: Translation 1 Dec 2003 Michael Lake 41: Re: Translation 2 Dec 2003 Stacho Mudrak 42: Re: Translation 3 Dec 2003 Michael Lake 43: Therion 0.2.17 4 Dec 2003 Martin Budaj 44: Re: Therion 0.2.17 22 Dec 2003 Wookey 45: Re: Therion 0.2.17 23 Dec 2003 Stacho Mudrak 46: Re: Therion 0.2.17 29 Dec 2003 Wookey 47: Queries and comments on 0.2.17 10 Feb 2004 Wookey 48: Re: Queries and comments on 0.2.17 11 Feb 2004 Stacho Mudrak 49: Re: Queries and comments on 0.2.17 12 Feb 2004 Stacho Mudrak 50: 0.2.18 12 Feb 2004 Stacho Mudrak 51: Re: 0.2.18 13 Feb 2004 Wookey 52: Re: Queries and comments on 0.2.17 13 Feb 2004 Wookey 53: Re: Queries and comments on 0.2.17 16 Feb 2004 Martin Budaj 54: Re: Queries and comments on 0.2.17 19 Feb 2004 Stacho Mudrak 55: Buy watches albacore 19 Feb 2004 Gilberto Byrne 56: Replica Watches uproot 20 Feb 2004 Carey Bermudez 57: SPAM 20 Feb 2004 Stacho Mudrak 58: Re: Queries and comments on 0.2.17 23 Feb 2004 Stacho Mudrak 59: Re: Queries and comments on 0.2.17 23 Feb 2004 Wookey 60: Re: Queries and comments on 0.2.17 23 Feb 2004 Martin Sluka 61: Re: Queries and comments on 0.2.17 24 Feb 2004 Stacho Mudrak 62: feedback on 0.2.18 27 Feb 2004 Wookey 63: Example of spurious text appearing 27 Feb 2004 Wookey 64: Re: feedback on 0.2.18 27 Feb 2004 Martin Budaj 65: Re: feedback on 0.2.18 27 Feb 2004 Stacho Mudrak 66: Re: feedback on 0.2.18 27 Feb 2004 Wookey 67: Re: feedback on 0.2.18 27 Feb 2004 Stacho Mudrak 68: Re: feedback on 0.2.18 27 Feb 2004 Wookey 69: Re: feedback on 0.2.18 27 Feb 2004 Wookey 70: Re: Example of spurious text appearing 27 Feb 2004 Stacho Mudrak 71: Re: feedback on 0.2.18 27 Feb 2004 John Pybus 72: Re: feedback on 0.2.18 1 Mar 2004 Stacho Mudrak 73: Re: Queries and comments on 0.2.17 1 Mar 2004 Stacho Mudrak 74: Re: feedback on 0.2.18 1 Mar 2004 Wookey 75: Re: feedback on 0.2.18 1 Mar 2004 Martin Budaj 76: Re: feedback on 0.2.18 1 Mar 2004 Stacho Mudrak 77: Re: feedback on 0.2.18 1 Mar 2004 Wookey 78: Re: feedback on 0.2.18 2 Mar 2004 Martin Budaj 79: 0.2.19 2 Mar 2004 Stacho Mudrak 80: Re: therion and contours 2 Mar 2004 Wookey 81: Re: therion and contours 2 Mar 2004 Stacho Mudrak 82: Re: therion and contours 2 Mar 2004 Wookey 83: Re: therion and contours 3 Mar 2004 John Pybus 84: Re: therion and contours 3 Mar 2004 Wookey 85: 0.2.19 debianization 5 Mar 2004 Wookey 86: Re: 0.2.19 debianization 5 Mar 2004 Stacho Mudrak 87: Re: 0.2.19 debianization 5 Mar 2004 Wookey 88: Re: therion and contours 6 Mar 2004 Martin Sluka 89: Re: therion and contours 16 Mar 2004 Wookey 90: Re: therion and contours 16 Mar 2004 Martin Budaj 91: Re: therion and contours 17 Mar 2004 Stacho Mudrak 92: Re: therion and contours 17 Mar 2004 Matt Ryan 93: Can I rotate a map? 25 Mar 2004 Wookey 94: Re: Can I rotate a map? 25 Mar 2004 Stacho Mudrak 95: Re: Can I rotate a map? 25 Mar 2004 Wookey 96: Re: Can I rotate a map? 25 Mar 2004 Stacho Mudrak 97: Re: Can I rotate a map? 25 Mar 2004 Wookey 98: Re: Can I rotate a map? 26 Mar 2004 Stacho Mudrak 99: Re: drawing up - seeking advice 31 Mar 2004 Wookey 100: Re: drawing up - seeking advice 31 Mar 2004 Stacho Mudrak 101: Re: drawing up - seeking advice 1 Apr 2004 Martin Sluka 102: Re: drawing up - seeking advice 1 Apr 2004 Stacho Mudrak 103: Therion 0.3.0 16 Apr 2004 m.b.speleo.sk 104: Re: Therion 0.3.0 19 Apr 2004 Wookey 105: Re: Therion 0.3.0 19 Apr 2004 Stacho Mudrak 106: Re: Therion 0.3.0 19 Apr 2004 Martin Budaj 107: Re: Therion 0.3.0 19 Apr 2004 Wookey 108: Re: Therion 0.3.0 20 Apr 2004 Martin Budaj 109: Re: Therion 0.3.0 20 Apr 2004 Stacho Mudrak 110: 'subtype' syntax change proposal 21 Apr 2004 Martin Budaj 111: Re: 'subtype' syntax change proposal 22 Apr 2004 Ladislav Bla¾ek 112: Re: 'subtype' syntax change proposal 22 Apr 2004 Wookey 113: Re: 'subtype' syntax change proposal 22 Apr 2004 Ladislav Bla¾ek 114: Re: 'subtype' syntax change proposal 22 Apr 2004 Wookey 115: Re: Therion 0.3.0 22 Apr 2004 Wookey 116: Re: Therion 0.3.0 23 Apr 2004 Stacho Mudrak 117: Re: 'subtype' syntax change proposal 23 Apr 2004 Stacho Mudrak 118: Re: 'subtype' syntax change proposal 23 Apr 2004 Wookey 119: Re: 'subtype' syntax change proposal 23 Apr 2004 Ladislav Bla¾ek 120: Re: 'subtype' syntax change proposal 23 Apr 2004 Stacho Mudrak 121: Re: 'subtype' syntax change proposal 23 Apr 2004 Ladislav Bla¾ek 122: therion 0.3.1 26 Apr 2004 Stacho Mudrak 123: Survex vs Therion 28 Apr 2004 Olly Betts 124: Re: Survex vs Therion 28 Apr 2004 Stacho Mudrak 125: problem with 0.3.1 25 May 2004 Wookey 126: Re: problem with 0.3.1 26 May 2004 Stacho Mudrak 127: Re: problem with 0.3.1 26 May 2004 Wookey 128: Re: problem with 0.3.1 1 Jun 2004 Wookey 129: new user .... 11 Jun 2004 Eric Madelaine 130: Re: new user .... 14 Jun 2004 Martin Budaj 131: Re: new user .... 14 Jun 2004 Stacho Mudrak 132: Re: new user .... 14 Jun 2004 Stacho Mudrak 133: Re: new user .... 14 Jun 2004 Eric Madelaine 134: Re: new user .... 15 Jun 2004 Martin Sluka 135: Re: new user .... 15 Jun 2004 Ladislav Blazek 136: Re: new user .... 15 Jun 2004 Ladislav Blazek 137: Re: new user .... 15 Jun 2004 Stacho Mudrak 138: Re: Visit in Prague 15 Jun 2004 Eric Madelaine 139: Re: Visit in Prague 15 Jun 2004 Martin Sluka 140: Re: Visit in Prague 15 Jun 2004 Eric Madelaine 141: Re: new user .... 15 Jun 2004 Olly Betts 142: Re: new user .... 21 Jun 2004 Wookey 143: Wook's persistent Therion bug 21 Jun 2004 Wookey 144: Re: Wook's persistent Therion bug 22 Jun 2004 Stacho Mudrak 145: Re: Wook's persistent Therion bug 28 Jun 2004 Wookey 146: Re: Wook's persistent Therion bug 29 Jun 2004 Martin Budaj 147: Re: Wook's persistent Therion bug 29 Jun 2004 Wookey 148: Re: Wook's persistent Therion bug 29 Jun 2004 Stacho Mudrak 149: Re: french translation (fwd) 29 Jun 2004 Eric Madelaine 150: Re: Visit in Prague 2 Jul 2004 Eric Madelaine 151: Re: Visit in Prague 2 Jul 2004 Martin Sluka 152: Re: Report on Therion Visit in Prague 11 Jul 2004 Eric Madelaine 153: Re: Report on Therion Visit in Prague 12 Jul 2004 Michael Lake 154: Extended Elevation, and other questions. 14 Jul 2004 Eric Madelaine 155: Re: Extended Elevation, and other questions. 14 Jul 2004 Martin Budaj 156: Re: Extended Elevation, and other questions. 14 Jul 2004 Stacho Mudrak 157: Re: Extended Elevation, and other questions. 14 Jul 2004 Eric Madelaine 158: Re: Extended Elevation, and other questions. 15 Jul 2004 Martin Budaj 159: Therion 0.3.2 22 Jul 2004 Martin Budaj 160: Re: Left-right-up data 5 Aug 2004 Stacho Mudrak 161: how to connect scraps 9 Aug 2004 Simeon Warner 162: Re: how to connect scraps 9 Aug 2004 Martin Sluka 163: Re: how to connect scraps 10 Aug 2004 Stacho Mudrak 164: Re: Left-right-up data 10 Aug 2004 Julian Todd 165: demo-rabbit doesn't process 5 Sep 2004 Olly Betts 166: Re: demo-rabbit doesn't process 6 Sep 2004 Martin Budaj 167: Re: demo-rabbit doesn't process 9 Sep 2004 Olly Betts 168: Re: demo-rabbit doesn't process 10 Sep 2004 Stacho Mudrak 169: Therion 0.3.3 announce 10 Sep 2004 Martin Budaj 170: Havranik 10 Sep 2004 Martin Sluka 171: Re: Havranik 10 Sep 2004 Martin Sluka 172: Re: demo-rabbit doesn't process 10 Sep 2004 Olly Betts 173: Re: demo-rabbit doesn't process 10 Sep 2004 Stacho Mudrak 174: How to change settings for just a few readings? 27 Sep 2004 Olly Betts 175: Re: How to change settings for just a few readings? 28 Sep 2004 Stacho Mudrak 176: Re: How to change settings for just a few readings? 28 Sep 2004 Olly Betts 177: Re: How to change settings for just a few readings? 28 Sep 2004 John Pybus 178: Re: How to change settings for just a few readings? 28 Sep 2004 Stacho Mudrak 179: Re: How to change settings for just a few readings? 28 Sep 2004 John Pybus 180: Re: How to change settings for just a few readings? 28 Sep 2004 Stacho Mudrak 181: Re: How to change settings for just a few readings? 29 Sep 2004 Stacho Mudrak 182: snow and ice 30 Sep 2004 Olly Betts 183: Example models? 30 Sep 2004 Wookey 184: Re: snow and ice 30 Sep 2004 Stacho Mudrak 185: Re: Example models? 30 Sep 2004 Stacho Mudrak 186: Re: Example models? 30 Sep 2004 Stacho Mudrak 187: Re: Example models? 30 Sep 2004 Wookey 188: Re: Example models? 30 Sep 2004 Stacho Mudrak 189: Re: snow and ice 30 Sep 2004 Olly Betts 190: Re: snow and ice 30 Sep 2004 Stacho Mudrak 191: Unhelpful metapost error 30 Sep 2004 Olly Betts 192: thbook typo corrections 30 Sep 2004 Olly Betts 193: Re: Unhelpful metapost error 30 Sep 2004 Olly Betts 194: Re: Unhelpful metapost error 30 Sep 2004 Olly Betts 195: Re: Unhelpful metapost error 1 Oct 2004 Stacho Mudrak 196: Re: Unhelpful metapost error 1 Oct 2004 Stacho Mudrak 197: Re: Unhelpful metapost error 1 Oct 2004 Olly Betts 198: Fixed station symbols 2 Oct 2004 zillig.hoki.ibp.fhg.de 199: Fixed station symbols 3 Oct 2004 zillig.hoki.ibp.fhg.de 200: Re: Models. 4 Oct 2004 Wookey 201: Re: Fixed station symbols 4 Oct 2004 Wookey 202: Re: Fixed station symbols 4 Oct 2004 Wolfgang Zillig 203: Re: Models. 4 Oct 2004 Stacho Mudrak 204: Re: Fixed station symbols 4 Oct 2004 Stacho Mudrak 205: Re: Fixed station symbols 4 Oct 2004 Wolfgang Zillig 206: Re: Fixed station symbols 4 Oct 2004 Stacho Mudrak 207: 2 Therion Questions 5 Oct 2004 Jenny Black 208: Re: 2 Therion Questions 5 Oct 2004 Stacho Mudrak 209: Re: 2 Therion Questions 7 Oct 2004 Tomas Bohanes 210: Re: 2 Therion Questions 11 Oct 2004 Jenny Black 211: Re: 2 Therion Questions 11 Oct 2004 Stacho Mudrak 212: scale / base-scale question 12 Oct 2004 Jenny Black 213: Re: scale / base-scale question 12 Oct 2004 Stacho Mudrak 214: Re: scale / base-scale question 12 Oct 2004 Stacho Mudrak 215: Re: scale / base-scale question 12 Oct 2004 Jenny Black 216: Re: scale / base-scale question 13 Oct 2004 Stacho Mudrak 217: Re: Unhelpful metapost error 14 Oct 2004 Olly Betts 218: Re: Unhelpful metapost error 14 Oct 2004 Wookey 219: therion workshop 15 Oct 2004 Martin Sluka 220: Re: therion workshop 15 Oct 2004 Ladislav Blazek 221: Therion 0.3.4 22 Oct 2004 Martin Budaj 222: Re: therion workshop 26 Oct 2004 Wolfgang Zillig 223: Re: therion workshop 26 Oct 2004 Martin Sluka 224: Font sizes for labels 26 Oct 2004 Jenny Black 225: Re: therion workshop 26 Oct 2004 Martin Sluka 226: Re: Font sizes for labels 27 Oct 2004 Stacho Mudrak 227: problem with 0.2.17 in 0.3.4 4 Nov 2004 Simeon Warner 228: Re: problem with 0.2.17 in 0.3.4 4 Nov 2004 Stacho Mudrak 229: Re: problem with 0.2.17 in 0.3.4 4 Nov 2004 Simeon Warner 230: Re: therion] 14 Dec 2004 Stacho Mudrak 231: Mud and sand 14 Dec 2004 Andrew Atkinson 232: Re: Mud and sand 15 Dec 2004 Wookey 233: Tom library and scrap connections 15 Dec 2004 Wookey 234: Re: Tom library and scrap connections 15 Dec 2004 Olly Betts 235: Re: Tom library and scrap connections 15 Dec 2004 Wookey 236: Re: Mud and sand 16 Dec 2004 Stacho Mudrak 237: Re: Tom library and scrap connections 16 Dec 2004 Stacho Mudrak 238: Re: Mud and sand 16 Dec 2004 Wookey 239: Re: Mud and sand 16 Dec 2004 Martin Sluka 240: Re: Mud and sand 16 Dec 2004 Eric Madelaine 241: Re: Mud and sand 16 Dec 2004 Andrew Atkinson 242: Therion hangs occaisionally 17 Dec 2004 Wookey 243: Re: Mud and sand 17 Dec 2004 Stacho Mudrak 244: Re: Therion hangs occaisionally 17 Dec 2004 Stacho Mudrak 245: Re: Mud and sand 17 Dec 2004 M.J. Green 246: Re: Mud and sand 17 Dec 2004 Michael Lake 247: Re: Therion hangs occaisionally 17 Dec 2004 Wookey 248: Re: Therion hangs occaisionally 17 Dec 2004 Stacho Mudrak 249: Re: Therion hangs occaisionally 17 Dec 2004 Martin Sluka 250: Re: Therion hangs occaisionally 17 Dec 2004 Stacho Mudrak 251: arranging files and surveys 20 Dec 2004 Wookey 252: No x-size for pillar? 20 Dec 2004 Wookey 253: Re: arranging files and surveys 20 Dec 2004 Martin Budaj 254: Re: No x-size for pillar? 20 Dec 2004 Martin Budaj 255: Therion Wiki pages 20 Dec 2004 Martin Budaj 256: Re: No x-size for pillar? 20 Dec 2004 Stacho Mudrak 257: Re: arranging files and surveys 20 Dec 2004 Wookey 258: Help - my cave is inside-out 26 Dec 2004 Wookey 259: Re: Help - my cave is inside-out 26 Dec 2004 Martin Budaj 260: Re: Help - my cave is inside-out 27 Dec 2004 Wookey 261: Re: Help - my cave is inside-out 28 Dec 2004 Wookey 262: Re: Help - my cave is inside-out 28 Dec 2004 Wookey 263: Re: Help - my cave is inside-out 28 Dec 2004 Martin Budaj 264: Re: Help - my cave is inside-out 28 Dec 2004 Stacho Mudrak 265: Re: Help - my cave is inside-out 28 Dec 2004 Stacho Mudrak 266: Re: Help - my cave is inside-out 28 Dec 2004 Stacho Mudrak 267: Re: Help - my cave is inside-out 28 Dec 2004 Martin Budaj 268: Re: Help - my cave is inside-out 28 Dec 2004 Wookey 269: Re: Help - my cave is inside-out 28 Dec 2004 Martin Budaj 270: Importing surveys with no data 28 Dec 2004 Wookey 271: debug mode 29 Dec 2004 Wookey 272: Re: Help - my cave is inside-out 29 Dec 2004 Ing. Jirí Novotný 273: Re: debug mode 29 Dec 2004 Olly Betts 274: Re: debug mode 29 Dec 2004 Jenny Black 275: Re: debug mode 29 Dec 2004 Wookey 276: Re: debug mode 29 Dec 2004 Wookey 277: Re: debug mode 29 Dec 2004 Olly Betts 278: Re: debug mode 29 Dec 2004 Gary Ritchie 279: Re: Importing surveys with no data 29 Dec 2004 Stacho Mudrak 280: Re: debug mode 29 Dec 2004 Stacho Mudrak 281: Re: debug mode 29 Dec 2004 Stacho Mudrak 282: Re: debug mode 29 Dec 2004 Wookey 283: Re: debug mode 29 Dec 2004 Ladislav Blazek 284: Re: Importing surveys with no data 29 Dec 2004 Wookey 285: Re: Importing surveys with no data 30 Dec 2004 Martin Sluka 286: Re: Importing surveys with no data 30 Dec 2004 Martin Sluka 287: Re: Importing surveys with no data 31 Dec 2004 Stacho Mudrak 288: Re: Importing surveys with no data 31 Dec 2004 Stacho Mudrak 289: Re: Importing surveys with no data 31 Dec 2004 Wookey 290: Re: Help - my cave is inside-out 2 Jan 2005 Wookey 291: Re: Help - my cave is inside-out 2 Jan 2005 Wookey 292: General note and suggestions 3 Jan 2005 Wookey 293: rock-border cannot be presumed 3 Jan 2005 Wookey 294: Re: General note and suggestions 3 Jan 2005 Martin Sluka 295: Re: Help - my cave is inside-out 3 Jan 2005 Martin Budaj 296: Re: General note and suggestions 3 Jan 2005 Wookey 297: Re: General note and suggestions 3 Jan 2005 Martin Sluka 298: Re: Help - my cave is inside-out 5 Jan 2005 Wookey 299: Re: Help - my cave is inside-out 5 Jan 2005 Wookey 300: Re: Help - my cave is inside-out 5 Jan 2005 Wookey 301: Re: General note and suggestions 5 Jan 2005 Martin Sluka 302: Re: Help - my cave is inside-out 5 Jan 2005 Martin Budaj 303: Re: Help - my cave is inside-out 5 Jan 2005 Martin Budaj 304: Re: Help - my cave is inside-out 5 Jan 2005 Martin Budaj 305: Re: Help - my cave is inside-out 6 Jan 2005 Wookey 306: Re: Help - my cave is inside-out 6 Jan 2005 Wookey 307: Re: Help - my cave is inside-out 6 Jan 2005 Martin Budaj 308: piles of rocks 7 Jan 2005 Wookey 309: Re: Help - my cave is inside-out 8 Jan 2005 Wookey 310: arranging files for big systems 8 Jan 2005 Wookey 311: problem with staggered data format 8 Jan 2005 Wookey 312: Re: problem with staggered data format 8 Jan 2005 Olly Betts 313: Re: piles of rocks 8 Jan 2005 Martin Sluka 314: Re: problem with staggered data format 8 Jan 2005 Martin Budaj 315: Re: arranging files for big systems 8 Jan 2005 Martin Budaj 316: Re: Help - my cave is inside-out 8 Jan 2005 Martin Budaj 317: Re: piles of rocks 8 Jan 2005 Martin Budaj 318: Re: problem with staggered data format 10 Jan 2005 Wookey 319: Re: arranging files for big systems 10 Jan 2005 Wookey 320: Re: arranging files for big systems 10 Jan 2005 Stacho Mudrak 321: Compilation Problems... 10 Jan 2005 Thierry GONON 322: Re: General note and suggestions 10 Jan 2005 Stacho Mudrak 323: Re: Compilation Problems... 10 Jan 2005 Stacho Mudrak 324: Re: rock-border cannot be presumed 10 Jan 2005 Stacho Mudrak 325: Re: Compilation Problems... 10 Jan 2005 Thierry GONON 326: Re: Compilation Problems... 10 Jan 2005 Stacho Mudrak 327: Re: General note and suggestions 10 Jan 2005 Wookey 328: Re: rock-border cannot be presumed 10 Jan 2005 Wookey 329: Re: rock-border cannot be presumed 10 Jan 2005 Stacho Mudrak 330: Re: General note and suggestions 10 Jan 2005 Stacho Mudrak 331: Re: General note and suggestions 10 Jan 2005 Wookey 332: Re: rock-border cannot be presumed 10 Jan 2005 Wookey 333: Re: arranging files for big systems 10 Jan 2005 Martin Sluka 334: change to flags and subtypes (was Re: rock-border cannot be presumed) 10 Jan 2005 Andrew Atkinson 335: Re: Compilation Problems... 10 Jan 2005 Martin Sluka 336: Re: change to flags and subtypes (was Re: rock-border cannot be presumed) 11 Jan 2005 Wookey 337: Re: arranging files for big systems 11 Jan 2005 Wookey 338: Segfault when including survey data in plan 11 Jan 2005 Wookey 339: Re: Segfault when including survey data in plan 11 Jan 2005 Stacho Mudrak 340: survex to therion conversion script 12 Jan 2005 Wookey 341: Re: survex to therion conversion script 12 Jan 2005 Olly Betts 342: Re: survex to therion conversion script 12 Jan 2005 Stacho Mudrak 343: Re: survex to therion conversion script 12 Jan 2005 Wookey 344: Re: survex to therion conversion script 12 Jan 2005 Simeon Warner 345: Re: survex to therion conversion script 12 Jan 2005 John Pybus 346: Re: survex to therion conversion script 12 Jan 2005 Stacho Mudrak 347: Re: survex to therion conversion script 12 Jan 2005 Olly Betts 348: Re: arranging files for big systems 14 Jan 2005 Wookey 349: Re: arranging files for big systems 14 Jan 2005 Martin Budaj 350: Re: arranging files for big systems 14 Jan 2005 Stacho Mudrak 351: Re: arranging files for big systems 14 Jan 2005 Stacho Mudrak 352: Re: arranging files for big systems 14 Jan 2005 Wookey 353: Re: arranging files for big systems 14 Jan 2005 Wookey 354: Re: arranging files for big systems 14 Jan 2005 Stacho Mudrak 355: Re: arranging files for big systems 14 Jan 2005 John Pybus 356: another set of inside-out pillars 16 Jan 2005 Wookey 357: Re: another set of inside-out pillars 16 Jan 2005 Martin Sluka 358: Re: another set of inside-out pillars 17 Jan 2005 Stacho Mudrak 359: Re: arranging files for big systems 17 Jan 2005 Martin Budaj 360: Re: another set of inside-out pillars 17 Jan 2005 Wookey 361: Re: another set of inside-out pillars 17 Jan 2005 Wookey 362: problem compiling on debian woody 17 Jan 2005 Roman Muñoz 363: Re: problem compiling on debian woody 18 Jan 2005 Olly Betts 364: Re: problem compiling on debian woody 18 Jan 2005 Roman Muñoz 365: Re: another set of inside-out pillars 18 Jan 2005 Martin Budaj 366: model viewer? 18 Jan 2005 Roman Muñoz 367: Re: model viewer? 18 Jan 2005 Stacho Mudrak 368: Adding sections error 18 Jan 2005 Andrew Atkinson 369: Section problem 18 Jan 2005 Andrew Atkinson 370: Re: Adding sections error 18 Jan 2005 Martin Budaj 371: Re: Adding sections error 18 Jan 2005 Andrew Atkinson 372: Re: Adding sections error 18 Jan 2005 Martin Budaj 373: Re: model viewer? 18 Jan 2005 Roman Muñoz 374: Re: model viewer? 18 Jan 2005 Wookey 375: Re: model viewer? 18 Jan 2005 Olly Betts 376: Re: model viewer? 18 Jan 2005 Roman Muñoz 377: Re: model viewer? 18 Jan 2005 Roman Muñoz 378: Re: model viewer? 18 Jan 2005 Wookey 379: Re: model viewer? 18 Jan 2005 Roman Muñoz 380: Re: model viewer? 19 Jan 2005 Martin Budaj 381: Re: model viewer? 19 Jan 2005 Roman Muñoz 382: Re: model viewer? 19 Jan 2005 Olly Betts 383: translating... 20 Jan 2005 Roman Muñoz 384: Re: translating... 20 Jan 2005 Martin Budaj 385: Re: translating... 20 Jan 2005 Roman Muñoz 386: Re: translating... 20 Jan 2005 Stacho Mudrak 387: Re: translating... 20 Jan 2005 Martin Sluka 388: Re: translating... 20 Jan 2005 Roman Muñoz 389: Re: translating... 21 Jan 2005 Martin Budaj 390: Re: translating... 21 Jan 2005 Stacho Mudrak 391: Re: translating... 21 Jan 2005 Martin Sluka 392: Re: translating... 21 Jan 2005 Martin Sluka 393: Re: translating... 21 Jan 2005 Stacho Mudrak 394: Re: translating... 21 Jan 2005 Ladislav Blazek 395: Re: translating... 21 Jan 2005 Wookey 396: Re: translating... 21 Jan 2005 Stacho Mudrak 397: Re: translating... 21 Jan 2005 Olly Betts 398: Re: translating... 21 Jan 2005 Stacho Mudrak 399: Re: translating... 21 Jan 2005 Martin Budaj 400: texts_es.tx 21 Jan 2005 Roman Muñoz 401: Re: translating... 21 Jan 2005 Roman Muñoz 402: Re: translating... 21 Jan 2005 Olly Betts 403: Re: translating... 21 Jan 2005 Olly Betts 404: string list 22 Jan 2005 Roman Muñoz 405: Re: translating... 22 Jan 2005 Olly Betts 406: Re: translating... 22 Jan 2005 Martin Budaj 407: Re: string list 23 Jan 2005 Martin Budaj 408: Re: string list 23 Jan 2005 Roman Muñoz 409: Re: string list 23 Jan 2005 Wookey 410: SVG output from therion 24 Jan 2005 John Pybus 411: Re: SVG output from therion 24 Jan 2005 Martin Budaj 412: Re: string list 24 Jan 2005 Martin Budaj 413: Re: string list 24 Jan 2005 Stacho Mudrak 414: Re: string list 24 Jan 2005 Martin Sluka 415: Re: SVG output from therion 24 Jan 2005 Martin Sluka 416: Re: SVG output from therion 24 Jan 2005 Ladislav Blazek 417: Re: string list 24 Jan 2005 Eric Madelaine 418: Re: string list 24 Jan 2005 Stacho Mudrak 419: Re: string list 24 Jan 2005 Roman Muñoz 420: Re: SVG output from therion 24 Jan 2005 Andrew Atkinson 421: Re: SVG output from therion 25 Jan 2005 John Pybus 422: Re: SVG output from therion 25 Jan 2005 John Pybus 423: Re: SVG output from therion 25 Jan 2005 Wookey 424: Re: SVG output from therion 25 Jan 2005 Olly Betts 425: Re: SVG output from therion 25 Jan 2005 Martin Budaj 426: Re: SVG output from therion 25 Jan 2005 Martin Sluka 427: Re: string list 25 Jan 2005 Stacho Mudrak 428: Re: SVG output from therion 25 Jan 2005 Stacho Mudrak 429: Re: Compilation Problems... 25 Jan 2005 Thierry GONON 430: Re: Compilation Problems... 26 Jan 2005 Martin Sluka 431: Re: Compilation Problems... 26 Jan 2005 Roman Muñoz 432: Therion 0.3.6 31 Jan 2005 Martin Budaj 433: Re: Therion 0.3.6 31 Jan 2005 Ladislav Blazek 434: therion protractor 31 Jan 2005 Carlos Henrique Grohmann 435: Re: therion protractor 1 Feb 2005 Martin Budaj 436: Re: Therion 0.3.6 1 Feb 2005 Stacho Mudrak 437: New version of therion software 2 Feb 2005 Martin Sluka 438: Re: New version of therion software 2 Feb 2005 Martin Sluka 439: Picts of projects made in therion 3 Feb 2005 Martin Sluka 440: problem importing .3d file 7 Feb 2005 Wookey 441: Re: problem importing .3d file 7 Feb 2005 Martin Sluka 442: Re: problem importing .3d file 7 Feb 2005 Stacho Mudrak 443: Re: problem importing .3d file 7 Feb 2005 Stacho Mudrak 444: translation 7 Feb 2005 Roman Muñoz 445: Re: problem importing .3d file 7 Feb 2005 Wookey 446: Re: problem importing .3d file 7 Feb 2005 Stacho Mudrak 447: translation on therion wiki 7 Feb 2005 Roman Muñoz 448: Re: problem importing .3d file 8 Feb 2005 Wookey 449: Re: problem importing .3d file 8 Feb 2005 Stacho Mudrak 450: Re: problem importing .3d file 8 Feb 2005 Wookey 451: Re: problem importing .3d file 8 Feb 2005 Stacho Mudrak 452: Re: problem importing .3d file 8 Feb 2005 Wookey 453: Re: problem importing .3d file 8 Feb 2005 Martin Sluka 454: Re: problem importing .3d file 8 Feb 2005 Wookey 455: Re: problem importing .3d file 9 Feb 2005 Martin Sluka 456: Re: problem importing .3d file 9 Feb 2005 Martin Sluka 457: Re: problem importing .3d file 9 Feb 2005 Stacho Mudrak 458: flowstone area needed 9 Feb 2005 Wookey 459: Re: flowstone area needed 10 Feb 2005 Stacho Mudrak 460: Re: flowstone area needed 13 Feb 2005 Wookey 461: translating types 15 Feb 2005 Roman Muñoz 462: Re: translating types 16 Feb 2005 Stacho Mudrak 463: Re: translating types 16 Feb 2005 Roman Muñoz 464: Re: translating types 16 Feb 2005 Martin Sluka 465: Re: translating types 16 Feb 2005 Stacho Mudrak 466: Re: translating types 16 Feb 2005 Martin Sluka 467: Re: translating types 16 Feb 2005 Roman Muñoz 468: Re: translating types 16 Feb 2005 Stacho Mudrak 469: xtherion i18n 16 Feb 2005 Stacho Mudrak 470: Re: xtherion i18n 16 Feb 2005 Ladislav Blazek 471: Re: xtherion i18n 16 Feb 2005 Stacho Mudrak 472: Re: xtherion i18n 16 Feb 2005 Ladislav Blazek 473: Re: translating types 16 Feb 2005 Roman Muñoz 474: Re: xtherion i18n 16 Feb 2005 Roman Muñoz 475: Re: Segfault when including survey data in plan 17 Feb 2005 Wookey 476: Re: Segfault when including survey data in plan 17 Feb 2005 Stacho Mudrak 477: xtherion i18n 17 Feb 2005 Stacho Mudrak 478: Wiki 17 Feb 2005 Ladislav Blazek 479: Re: Segfault when including survey data in plan 17 Feb 2005 Stacho Mudrak 480: Re: Segfault when including survey data in plan 17 Feb 2005 Wookey 481: Re: Segfault when including survey data in plan 17 Feb 2005 Wookey 482: Re: Segfault when including survey data in plan 17 Feb 2005 Martin Sluka 483: Re: Segfault when including survey data in plan 17 Feb 2005 Stacho Mudrak 484: Re: Segfault when including survey data in plan 17 Feb 2005 Wookey 485: Re: Segfault when including survey data in plan 17 Feb 2005 Stacho Mudrak 486: windows binary translated 17 Feb 2005 Roman Muñoz 487: Re: windows binary translated 18 Feb 2005 Martin Budaj 488: Re: windows binary translated 18 Feb 2005 Ladislav Blazek 489: New snapshot 18 Feb 2005 Stacho Mudrak 490: Re: New snapshot 18 Feb 2005 Stacho Mudrak 491: Re: windows binary translated 18 Feb 2005 Roman Muñoz 492: Re: windows binary translated 21 Feb 2005 Martin Budaj 493: Re: windows binary translated 21 Feb 2005 Roman Muñoz 494: devel snapshot - translations 21 Feb 2005 Ladislav Blazek 495: New developement snapshot. 21 Feb 2005 Stacho Mudrak 496: Re: devel snapshot - translations 21 Feb 2005 Stacho Mudrak 497: Re: New developement snapshot. 21 Feb 2005 Martin Sluka 498: Re: devel snapshot - translations 21 Feb 2005 Ladislav Blazek 499: Re: devel snapshot - translations 21 Feb 2005 Stacho Mudrak 500: Re: devel snapshot - translations 21 Feb 2005 Ladislav Blazek 501: Re: New developement snapshot. 21 Feb 2005 Stacho Mudrak 502: Re: New developement snapshot. 21 Feb 2005 John Pybus 503: Re: New developement snapshot. 21 Feb 2005 Stacho Mudrak 504: Re: New developement snapshot. 21 Feb 2005 John Pybus 505: wiki examples 21 Feb 2005 Roman Muñoz 506: bad option utf-8 21 Feb 2005 Roman Muñoz 507: Re: New developement snapshot. 22 Feb 2005 Stacho Mudrak 508: Re: bad option utf-8 22 Feb 2005 Stacho Mudrak 509: Re: wiki examples 22 Feb 2005 Stacho Mudrak 510: Re: wiki examples 22 Feb 2005 Martin Sluka 511: Re: wiki examples 22 Feb 2005 Ladislav Blazek 512: Re: New developement snapshot. 22 Feb 2005 Stacho Mudrak 513: Re: wiki examples 22 Feb 2005 Martin Sluka 514: Re: bad option utf-8 22 Feb 2005 Roman Muñoz 515: Re: bad option utf-8 22 Feb 2005 Stacho Mudrak 516: Re: bad option utf-8 22 Feb 2005 Stacho Mudrak 517: Re: bad option utf-8 22 Feb 2005 Stacho Mudrak 518: Re: bad option utf-8 22 Feb 2005 Wookey 519: Re: bad option utf-8 22 Feb 2005 Olly Betts 520: Re: bad option utf-8 22 Feb 2005 M.J. Green 521: next dumb question 22 Feb 2005 Roman Muñoz 522: invalid command message 22 Feb 2005 Roman Muñoz 523: Re: invalid command message 23 Feb 2005 Stacho Mudrak 524: Re: bad option utf-8 23 Feb 2005 Stacho Mudrak 525: Re: next dumb question 23 Feb 2005 Stacho Mudrak 526: Recent changes 23 Feb 2005 Stacho Mudrak 527: Re: next dumb question 23 Feb 2005 Martin Sluka 528: Re: bad option utf-8 23 Feb 2005 Martin Sluka 529: Re: bad option utf-8 23 Feb 2005 Martin Sluka 530: Re: next dumb question 23 Feb 2005 Eric Madelaine 531: Re: next dumb question 23 Feb 2005 John Pybus 532: Re: next dumb question 23 Feb 2005 Roman Muñoz 533: Re: next dumb question 23 Feb 2005 Ladislav Blazek 534: Re: next dumb question 23 Feb 2005 Stacho Mudrak 535: Re: 20050223 translation 24 Feb 2005 Stacho Mudrak 536: preliminary text 25 Feb 2005 Roman Muñoz 537: Re: preliminary text 28 Feb 2005 Stacho Mudrak 538: Re: preliminary text 28 Feb 2005 Roman Muñoz 539: Re: preliminary text 28 Feb 2005 Stacho Mudrak 540: Re: preliminary text 28 Feb 2005 Martin Sluka 541: last snapshot 2 Mar 2005 Roman Muñoz 542: Re: last snapshot 2 Mar 2005 Stacho Mudrak 543: Re: last snapshot 2 Mar 2005 Martin Sluka 544: Re: last snapshot 3 Mar 2005 Roman Muñoz 545: Re: last snapshot 3 Mar 2005 Stacho Mudrak 546: Re: last snapshot 3 Mar 2005 Ladislav Blazek 547: Re: last snapshot 3 Mar 2005 Stacho Mudrak 548: Re: xtherion.ini not found 3 Mar 2005 Roman Muñoz 549: Re: xtherion.ini not found 3 Mar 2005 Stacho Mudrak 550: Re: xtherion.ini not found 3 Mar 2005 Roman Muñoz 551: Re: xtherion.ini not found 3 Mar 2005 Stacho Mudrak 552: Xtherion on MacOS X 3 Mar 2005 Thierry GONON 553: Re: Xtherion on MacOS X 3 Mar 2005 Stacho Mudrak 554: therion 0.3.6 in debian testing 3 Mar 2005 Wookey 555: Re: xtherion.ini not found 3 Mar 2005 Wookey 556: Re: xtherion.ini not found 3 Mar 2005 Roman Muñoz 557: Re: xtherion.ini not found 3 Mar 2005 Olly Betts 558: sharp language 3 Mar 2005 Roman Muñoz 559: sharp language 3 Mar 2005 Roman Muñoz 560: Re: Xtherion on MacOS X 3 Mar 2005 Thierry GONON 561: Re: Xtherion on MacOS X 4 Mar 2005 Stacho Mudrak 562: Re: sharp language 4 Mar 2005 Stacho Mudrak 563: Re: sharp language 4 Mar 2005 Ladislav Blazek 564: Re: Xtherion on MacOS X 4 Mar 2005 Thierry GONON 565: Re: Xtherion on MacOS X 4 Mar 2005 Stacho Mudrak 566: .ini files install 4 Mar 2005 Roman Muñoz 567: Re: Xtherion on MacOS X 4 Mar 2005 Martin Sluka 568: Re: .ini files install 4 Mar 2005 Ladislav Blazek 569: Re: sharp language 4 Mar 2005 Wookey 570: Re: .ini files install 4 Mar 2005 Stacho Mudrak 571: Re: sharp language 4 Mar 2005 John Pybus 572: Extended elevation 4 Mar 2005 Stacho Mudrak 573: Re: Extended elevation 5 Mar 2005 Roman Muñoz 574: error message 8 Mar 2005 Roman Muñoz 575: Re: error message 9 Mar 2005 Stacho Mudrak 576: statistics 9 Mar 2005 Roman Muñoz 577: Re: statistics 10 Mar 2005 Martin Budaj 578: Latest developement snapshot 10 Mar 2005 Stacho Mudrak 579: statistics 11 Mar 2005 Roman Muñoz 580: Re: statistics 11 Mar 2005 Martin Sluka 581: Re: statistics 11 Mar 2005 Stacho Mudrak 582: Re: statistics 11 Mar 2005 Roman Muñoz 583: Re: statistics 11 Mar 2005 Stacho Mudrak 584: Re: statistics 11 Mar 2005 Martin Budaj 585: section lines 14 Mar 2005 Roman Muñoz 586: Re: section lines 14 Mar 2005 Martin Budaj 587: Re: section lines 14 Mar 2005 Roman Muñoz 588: Re: section lines 14 Mar 2005 Martin Budaj 589: Re: section lines 14 Mar 2005 Roman Muñoz 590: Therion 0.3.7 16 Mar 2005 Martin Budaj 591: Re: .ini files install 21 Mar 2005 Olly Betts 592: Xtherion 0.3.7 connecting to the internet 23 Mar 2005 Duncan Collis 593: CMYK colour 23 Mar 2005 Duncan Collis 594: Re: CMYK colour 23 Mar 2005 Martin Budaj 595: Re: CMYK colour 23 Mar 2005 Martin Sluka 596: Re: CMYK colour 23 Mar 2005 Martin Sluka 597: Re: Xtherion 0.3.7 connecting to the internet 23 Mar 2005 Stacho Mudrak 598: SVG export -- labels 30 Mar 2005 Martin Budaj 599: text uploaded on wiki 7 Apr 2005 Roman Muñoz 600: Re: text uploaded on wiki 7 Apr 2005 Wookey 601: Therion and survex 14 Apr 2005 Philip Balister 602: Re: Therion and survex 14 Apr 2005 Wookey therion Digest of: get.1_100 Topics (messages 1 through 100): New conference address 1 by: Stacho Mudrak 4 by: Michael Lake 9 by: Stacho Mudrak Re: How do all the metapost parts fit together. 2 by: Martin Budaj 5 by: Wookey 6 by: Michael Lake 7 by: Michael Lake 8 by: Martin Budaj 10 by: Stacho Mudrak 11 by: Stacho Mudrak 12 by: Stacho Mudrak 13 by: Wookey 14 by: Wookey 15 by: Stacho Mudrak Re: [therion-users] Re: therion does a seg fault when I try and run it 3 by: Stacho Mudrak therion 0.2.15 uploaded to Debian 16 by: Wookey Re: [therion-users] Therion a MacOS X 10.2.3 - working!!! 17 by: Martin Sluka Re: Therion a MacOS X 10.2.3 - working!!! 18 by: Stacho Mudrak 19 by: Gary Ritchie survex to therion data conversion 20 by: Wookey 21 by: John Pybus 22 by: Michael Lake 23 by: Wookey 24 by: Wookey 25 by: Andy Waddington on Cave Surveying 26 by: Stacho Mudrak 27 by: Stacho Mudrak 28 by: Wookey 29 by: Wookey 30 by: Stacho Mudrak 31 by: Stacho Mudrak 32 by: Stacho Mudrak 33 by: Wookey 34 by: Stacho Mudrak new 0.2.15 35 by: Stacho Mudrak 36 by: Wookey 37 by: Stacho Mudrak Therion 0.2.16 38 by: Martin Budaj Translation 39 by: Stacho Mudrak 40 by: Michael Lake 41 by: Stacho Mudrak 42 by: Michael Lake Therion 0.2.17 43 by: Martin Budaj 44 by: Wookey 45 by: Stacho Mudrak 46 by: Wookey Queries and comments on 0.2.17 47 by: Wookey 48 by: Stacho Mudrak 49 by: Stacho Mudrak 52 by: Wookey 53 by: Martin Budaj 54 by: Stacho Mudrak 58 by: Stacho Mudrak 59 by: Wookey 60 by: Martin Sluka 61 by: Stacho Mudrak 73 by: Stacho Mudrak 0.2.18 50 by: Stacho Mudrak 51 by: Wookey Buy watches albacore 55 by: Gilberto Byrne Replica Watches uproot 56 by: Carey Bermudez SPAM 57 by: Stacho Mudrak feedback on 0.2.18 62 by: Wookey 64 by: Martin Budaj 65 by: Stacho Mudrak 66 by: Wookey 67 by: Stacho Mudrak 68 by: Wookey 69 by: Wookey 71 by: John Pybus 72 by: Stacho Mudrak 74 by: Wookey 75 by: Martin Budaj 76 by: Stacho Mudrak 77 by: Wookey 78 by: Martin Budaj Example of spurious text appearing 63 by: Wookey 70 by: Stacho Mudrak 0.2.19 79 by: Stacho Mudrak Re: therion and contours 80 by: Wookey 81 by: Stacho Mudrak 82 by: Wookey 83 by: John Pybus 84 by: Wookey 88 by: Martin Sluka 89 by: Wookey 90 by: Martin Budaj 91 by: Stacho Mudrak 92 by: Matt Ryan 0.2.19 debianization 85 by: Wookey 86 by: Stacho Mudrak 87 by: Wookey Can I rotate a map? 93 by: Wookey 94 by: Stacho Mudrak 95 by: Wookey 96 by: Stacho Mudrak 97 by: Wookey 98 by: Stacho Mudrak Re: drawing up - seeking advice 99 by: Wookey 100 by: Stacho Mudrak Subject: New conference address From: Stacho Mudrak Date: Mon, 08 Sep 2003 10:28:12 +0200 To: "therion@speleo.sk" Hello everybody, we've moved therion conference to our server, because there were a lot of problems with the old one. Now the adress is therion@speleo.sk. More details will come soon on the web-page. S. Subject: Re: [therion] New conference address From: Michael Lake Date: Mon, 08 Sep 2003 21:35:58 +1000 To: Stacho Mudrak CC: "therion@speleo.sk" Stacho Mudrak wrote: > Hello everybody, > we've moved therion conference to our server, because there were a lot of problems with the old one. Now the adress is therion@speleo.sk. More details will come soon on the web-page. > S. Is this connected with why I have just received an email like this: From - Mon Sep 8 21:29:29 2003 Return-Path: for ; Mon, 8 Sep 2003 18:33:00 +1000 Subject: You have been unsubscribed from the therion-users mailing list From: therion-users-bounces@mail.freesoftware.fsf.org To: mikel@speleonics.com.au Date: Mon, 08 Sep 2003 04:22:03 -0400 Sender: therion-users-bounces+mikel=speleonics.com.au@mail.freesoftware.fsf.org Errors-To: therion-users-bounces+mikel=speleonics.com.au@mail.freesoftware.fsf.org There was nothing in the body of the message just the subject that I have been unsubscribed and no reason. I have CC'ed this to Stacho in case this does not get to the therion users list. or is it a result of your server move? -- Mike Lake Caver, Linux enthusiast and interested in anything technical. Subject: Re: [therion] New conference address From: Stacho Mudrak Date: Mon, 08 Sep 2003 15:05:33 +0200 To: "therion@speleo.sk" On Mon, 08 Sep 2003 21:35:58 +1000, Michael Lake wrote: > Is this connected with why I have just received an email like this: Yes, I'm sorry for that - I hoped these messages will not be generated :( There is also a problem with the new conference. A "Reply-To: therion@speleo.sk" field in the message header is missing and I don't have rights to do it (speleo.sk is only a virtual server - I'm not an administrator there). Now I'm trying to contact our system administrator... Best regards, S. Subject: Re: How do all the metapost parts fit together. From: "Martin Budaj" Date: Mon, 08 Sep 2003 12:06:18 +0200 To: therion@speleo.sk Michael Lake writes: > I see that thPoint.mp contains... ... > and that thdraw is defined in mpost/therion.mp which I think is generated from thmpost.h which is generated from your RCS system. I am trying to work out how this all fits together. Actually, thmpost.h file is generated from all metapost sources by the script genmpost.pl in the mpost directory. The reason for this is that we had problems to set-up TeX and MetaPost searching paths for macro files indenpendent on used OS and TeX distribution. Now all macros are stored in the therion executable in a form of a string and are written to working directory just before running metapost and tex. > I gather then that you have some scripts that will generate HTML from the file and that the HTML can document the available symbols. Am I guessing right? Like the ASF symbol for a fixed station. This HTML-like markup is an artefact from 1999/2000 version. There is a perl script which generated HTML documentation, see http://therion.speleo.sk/symlib/ for an example. We plan to make such documentation easier, without HTML markup -- this will require to use standard names for all the symbols, based on symbol names in the Therion Book, e.g. p_sand_UIS for UIS point symbol for sand. > What would be nice would be to generate automatically a PDF doc that has the name of the UIS symbol and it's picture i.e. run a script that processes the mp fragments, extracts the name and desription, creates the eps files and then runs pdflatex to make a table of all the UIS symbols listed alphabetically or by type of symbol. This'll be no problem then. We want to support also automatical creation of a map legend which would contain only symbols used in particuler map &c. > The reason why I am trying t fit it together is so I can do things like make my own symbols -- well even help you make the many other UIS symbols that arent in therion yet too. I dont know much metapost but can learn. It appears at present that to add new symbols one must add the mp code and then recompile. It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work. You may include symbol re-definition in the layout command (after the undocumented `code metapost' command) in the last development version of therion: layout my ... # indicates that following lines are metapost code code metapost # follows an example of an redefinition of a stalactite to empty symbol # # Stalactite is (at present; will be changed soon) internal therion's # name for stalactite point symbol -- look at the first column in # the file thTrans.mp (which maps internal names to names used # in the metapost definitions) # # Parameters count and type is fixed; see the original definition # of the stalactite symbol (p_stalactite_UIS) in the file thPoint.th def Stalactite(expr a,b,c,d) = enddef; endlayout > Also I see you need help with writing some sections in the manual - like the section "New map symbols". Yes, help is welcome ;) but we have probably to clean 4-years old metapost code first... Then I'll try to write at least some hints how to create new symbols. Regards, Martin Subject: Re: How do all the metapost parts fit together. From: Wookey Date: Mon, 8 Sep 2003 12:57:34 +0100 To: Martin Budaj CC: therion@speleo.sk +++ Martin Budaj [03-09-08 12:06 +0200]: >> Michael Lake writes: >> >> Actually, thmpost.h file is generated from all metapost sources by the >> script genmpost.pl in the mpost directory. The reason for this is that we >> had problems to set-up TeX and MetaPost searching paths for macro files >> indenpendent on used OS and TeX distribution. Now all macros are stored in >> the therion executable in a form of a string and are written to working >> directory just before running metapost and tex. The main disadvantage of this is that people can't change of add metapost definitions without recompiling therion, right? If the definitions were read at run-time then we could package UIS or ASF or BCRA or whatever symbols separately and install the version you need rather than having a huge executable. I understand why you've done what you've done, but all of us agree it's a horrible hack and I think we should keep it under review if it's really sensible. How big are the definitions so far and how big do we expect them to get? If they are, and weill remain, quite small and only a tiny number of people will want to change them then the current scheme should work OK. >> This'll be no problem then. We want to support also automatical creation of >> a map legend which would contain only symbols used in particuler map &c. That's a _really_ good idea - I like that. >>> >The reason why I am trying t fit it together is so I can do things like >>> >make my own symbols -- well even help you make the many other UIS symbols >>> >that arent in therion yet too. I dont know much metapost but can learn. It >>> >appears at present that to add new symbols one must add the mp code and >>> >then recompile. > >> >> It's possible to add/change metapost symbols without new therion >> compilation. The interface is rather experimental but should work. ah, I should have read this first. >> You may include symbol re-definition in the layout command (after the >> undocumented `code metapost' command) in the last development version of >> therion: >> >> layout my >> ... >> >> # indicates that following lines are metapost code >> >> code metapost >> >> # follows an example of an redefinition of a stalactite to empty symbol >> # >> # Stalactite is (at present; will be changed soon) internal therion's >> # name for stalactite point symbol -- look at the first column in >> # the file thTrans.mp (which maps internal names to names used >> # in the metapost definitions) >> # >> # Parameters count and type is fixed; see the original definition >> # of the stalactite symbol (p_stalactite_UIS) in the file thPoint.th >> >> >> def Stalactite(expr a,b,c,d) = >> enddef; >> >> endlayout OK - that should do for now. Welcome aboard Michael, BTW - the more hands the merrier I think. Therion is the way forward but it still needs plenty of work to make it accessible to the less geeky cave surveyor. 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/ Subject: Re: [therion] Re: How do all the metapost parts fit together. From: Michael Lake Date: Mon, 08 Sep 2003 21:58:47 +1000 To: therion@speleo.sk Wookey wrote: > The main disadvantage of this is that people can't change of add metapost > definitions without recompiling therion, right? If the definitions were read > at run-time then we could package UIS or ASF or BCRA or whatever symbols > separately and install the version you need rather than having a huge > executable. > > I understand why you've done what you've done, but all of us agree it's a > horrible hack and I think we should keep it under review if it's really > sensible. How big are the definitions so far and how big do we expect them > to get? The Official UIS list of cave symbols is available from: http://www.karto.ethz.ch/neumann-cgi/cave_symbol.pl > If they are, and weill remain, quite small and only a tiny number of > people will want to change them then the current scheme should work OK. Its a big list but it is quite static. However it does allow countries to maintain the use of some of their own symbols - for instance in Australia we will be retaining a few of the older symbols. Thus cavers will want to have small customised sets. We reallly therefore need to load them at runtime via a library or a package like LaTeX does. Probably as plain text mpost macros in a file that is called up by the thconfig file. Mike pondered..... >>> The reason why I am trying t fit it together is so I can do things like make my own symbols -- well even help you make the many other UIS symbols that arent in therion yet too. I dont know much metapost but can learn. It appears at present that to add new symbols one must add the mp code and then recompile. >> It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work. > > > ah, I should have read this first. but it was undocumented. :-) I will try and help with documentation. > Welcome aboard Michael, BTW - the more hands the merrier I think. Therion is > the way forward but it still needs plenty of work to make it accessible to > the less geeky cave surveyor. I can help with documentation. I am good at LaTeX, I am making some headway with plain TeX (even have Knuths book) and I might have to learn C++ :-) Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. Subject: Re: [therion] Re: How do all the metapost parts fit together. From: Michael Lake Date: Mon, 08 Sep 2003 22:11:24 +1000 To: therion@speleo.sk Michael Lake wrote: > The Official UIS list of cave symbols is available from: http://www.karto.ethz.ch/neumann-cgi/cave_symbol.pl By the way helictites are helictites but your xtherion has them as helectites. From the UIS Page: Translations of Helictites - Soda Straws - Crystals Croatian: Heliktiti - Spageti - Kristali Dutch: excentrieken - macaronies - kristallen French: Excentriques/Helictites - Spaghettis - Cristaux German: Excentriques - Spaghetti - Kristalle Italian: Concrezione eccentrica - Spaghetti - Cristalli Romanian: Excentrite-Helictite - macaroane - cristale Slovene: Heliktiti - spageti (cevcice) - kristali How were you planning to cope with things like the text in different languages. survex uses a lookup table of numbers for error messages and their strings that are output for each language. Perhaps therion could use the uis english text in the program but use a lookup table to convert them to other strings for xtherions menus for french and german etc. What do you use in Slovenia. Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. Subject: Re: How do all the metapost parts fit together. From: "Martin Budaj" Date: Mon, 08 Sep 2003 14:38:20 +0200 To: therion@speleo.sk >>> It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work. >> >> >> ah, I should have read this first. > > > but it was undocumented. :-) I will try and help with documentation. There is also documented command-line option --use-extern-libs ;-) When used, therion lets TeX and MP to search for macro files in the run-time. Martin Subject: Re: [therion] Re: How do all the metapost parts fit together. From: Stacho Mudrak Date: Mon, 08 Sep 2003 16:04:55 +0200 To: therion@speleo.sk On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake wrote: > By the way helictites are helictites but your xtherion has them as helectites. This of course a bug (not the first one of this kind :)). If somebody would like to check our point, line and area types and write comments about it like: What has a wrong spelling? What is not understandable? What names should be preferred? (for example: we use popcorn (US) not cauliflower-calcite (UIS))? What symbols are missing? etc. > What do you use in Slovenia. helektity :) > How were you planning to cope with things like the text in different languages. survex uses a lookup table of numbers for error messages and their strings that are output for each language. Perhaps therion could use the uis english text in the program but use a lookup table to convert them to other strings for xtherions menus for french and german etc. OK, some words about our view of internationalization: Therion input files language will be only english (like survex). In fact, it's a code and I have a very negative experience with code written in other languages (Micro$oft once released VisualBasic in SLOVAK (something really nasty) - in the next release, they came back to english) 2. We're also not keen on putting other languages into xtherion. The reason is simple, I've a very bad experience with all programs translated into SLOVAK. The translations are usually less understandable - a lot of technical terms have their equivalents in Slovak - but in Slovakia usually english terms not Slovak are used (ok, may be in France or Germany it's different :) . And also, there are allways problems with regional special characters... The last thing is - that terms like stalactites, helictites etc. are a part of input files - so people should understand them anyway. Like they understand words like length, bearing, clino in survex. 3. Therion map and atlas output will be translated into other languages probably very soon. When it will generate lists of map symbols, they will be described in local language. Regards, S. Subject: Re: [therion] Re: How do all the metapost parts fit together. From: Stacho Mudrak Date: Mon, 08 Sep 2003 16:14:17 +0200 To: therion@speleo.sk On Mon, 08 Sep 2003 21:58:47 +1000, Michael Lake wrote: > Its a big list but it is quite static. However it does allow countries to maintain the use of some of their own symbols - for instance in Australia we will be retaining a few of the older symbols. Thus cavers will want to have small customised sets. We reallly therefore need to load them at runtime via a library or a package like LaTeX does. Probably as plain text mpost macros in a file that is called up by the thconfig file. Even with the current version of therion, if we would have metapost code for ASF (Australian Speleological Federation) symbols, a command like export map -layout symbols-ASF should work. All we need to do is to clean the mess, we have in the therion - metapost cooperation (a lot of old macros, some bugs, names of macros etc.). I believe a week or two should be enought for this. S. Subject: Re: How do all the metapost parts fit together. From: Stacho Mudrak Date: Tue, 09 Sep 2003 14:20:18 +0200 To: therion@speleo.sk This is mail from Wookey, he sent it to the old conference. So I'm resending it to the new one - therion@speleo.sk. The old one is disabled. S. +++ Stacho Mudrak [03-09-08 16:04 +0200]: > On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake wrote: > If somebody would like to check our point, line and area types and write comments about it like: > > What has a wrong spelling? > What is not understandable? > What names should be preferred? (for example: we use popcorn (US) not cauliflower-calcite (UIS))? > What symbols are missing? > etc. I'll try and look these over whilst packaging the next version. Although I'll be very happy if Mike beats me to it :-) > OK, some words about our view of internationalization: > > Therion input files language will be only english (like survex). In fact, it's a code and I have a very negative experience with code written in other languages (Micro$oft once released VisualBasic in SLOVAK (something really nasty) - in the next release, they came back to english) Agreed. > 2. We're also not keen on putting other languages into xtherion. The reason is simple, I've a very bad experience with all programs translated into SLOVAK. > > The translations are usually less understandable - a lot of technical terms have their equivalents in Slovak - but in Slovakia usually english terms not Slovak are used (ok, may be in France or Germany it's different :) . And also, there are allways problems with regional special characters... > > The last thing is - that terms like stalactites, helictites etc. are a part of input files - so people should understand them anyway. Like they understand words like length, bearing, clino in survex. I understand what you are saying - I agree that anything in xtherion which is really referring to the element names in the therion input file should match up. On the other hand it is definately necessary to have proper local language translations for menus, error messages, help and documentation to allow software to be widely used by those who don't already speak good english. Eventually the xtherion interface should get to the point where many users will only use it via the graphical interface and won't be editing text files much at all. When that is true it is important that the meaning of symbols is easily understood, and the cross-reference to the code in the data files becomes less significant. So, I do think that translations are necessary in the user interface, but I agree that the need for the correspondence with the data-files to be clear, makes this problem harder than usual. Displaying both a translation and the string that will be netered in the data-file is probably best, but it might have to be switchable because they won't both fit on the screen. We probably have more important things to worry about at this stage, but I don't think it's right to say 'xtherion is only in english' as a policy. Survex's portuguese support, for example, has made it very popular in Brazil. This wouldn't have happened if it had been english-only. And survex has the same aspect as therion in that the data files are essentially in english. Translating the user-interface is definately a good thing and we should put the infrastructure in place, otherwise whilst the output can be read by anyone, only those who read good english can use the software. > 3. Therion map and atlas output will be translated into other languages probably very soon. When it will generate lists of map symbols, they will be described in local language. OK 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/ Subject: Re: How do all the metapost parts fit together. From: Wookey Date: Tue, 9 Sep 2003 14:20:21 +0100 To: therion@speleo.sk +++ Stacho Mudrak [03-09-09 14:20 +0200]: >> This is mail from Wookey, he sent it to the old conference. So I'm >> resending it to the new one - therion@speleo.sk. The old one is disabled. Ah yes - that's mutt's fault - I tried to set a new 'therion' alias and mutt just told me that I already have an alias of that name and won't let me define a new one. Unhelpful bit of software! I've binned the old one manually now. 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/ Subject: Re: How do all the metapost parts fit together. From: Wookey Date: Tue, 9 Sep 2003 14:23:30 +0100 To: therion@speleo.sk +++ Wookey [03-09-09 14:20 +0100]: >> +++ Stacho Mudrak [03-09-09 14:20 +0200]: > >>> > This is mail from Wookey, he sent it to the old conference. So I'm >>> > resending it to the new one - therion@speleo.sk. The old one is disabled. > >> >> Ah yes - that's mutt's fault - I tried to set a new 'therion' alias and mutt >> just told me that I already have an alias of that name and won't let me >> define a new one. Unhelpful bit of software! I've binned the old one manually now. And now I';ve found the 'right' answer - there is of course an 'unalias' command. Mutt is amazingly clever but sometimes it's not at all obvious how to do what you want. I'll shut up now :-) 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/ Subject: Re: How do all the metapost parts fit together. From: Stacho Mudrak Date: Tue, 09 Sep 2003 16:05:56 +0200 To: therion@speleo.sk Wookey wrote: > So, I do think that translations are necessary in the user interface, but > I agree that the need for the correspondence with the data-files to be > clear, makes this problem harder than usual. Displaying both a translation and the string that will be netered in the > data-file is probably best, but it might have to be switchable > because they won't both fit on the screen. > > We probably have more important things to worry about at this > stage, but I don't think it's right to say 'xtherion is only > in english' as a policy. Of course, you're right. When I'll do internationalization for output strings (we need it for maps in Slovak), there will be no problem to use same routines for error messages (because it's the same stuff). And also there is nothing easier, than to add some script to xtherion make process, that will also enable xtherion to use source file with messages written in multiple languages. I believe, it's a question of one evening. > Survex's portuguese support, for example, has made it very popular in > Brazil. This wouldn't have happened if it had been english-only. And survex > has the same aspect as therion in that the data files are essentially in > english. Translating the user-interface is definately a good thing and we > should put the infrastructure in place, otherwise whilst the output can be > read by anyone, only those who read good english can use the software. I think, that it's more psychological... Once we've written a program completely in Slovak and people here in Slovakia liked it very much. Than when we stopped developement of it and told them, that WinCompass is really better and easier software for them to use - they didn't use it. Even if they've understood the basics of english. May be the manual in Slovak was missing, but may be, they really need translations of menu items... OK. When therion will support multiple languages of output, it'll support also multiple languages at least in error-messages and xtherion menus... For other items in xtherion (that need to be named according to input files - like point types), I'll try to add support of translations into status line (there is short help in english currently). This could be a reasonable compromise. S. Subject: Re: [therion-users] Re: therion does a seg fault when I try and run it From: Stacho Mudrak Date: Mon, 08 Sep 2003 13:09:56 +0200 To: therion@speleo.sk > thpoint.cxx:868): invalid combination of values -- +1.5 -3 This is caused by "unsigned char = -1" problem, should be fixed in the latest 0.2.15 version available on the server. > Thanks for the help. I will now have a look at the diff of that therion.cxx file you sent and see what has changed. I've probably not used va_start, va_end C functions correctly... > I will also write down and send the other compiler warnings and pdf warnings that I get too. We're prepared :) S. Subject: therion 0.2.15 uploaded to Debian From: Wookey Date: Thu, 11 Sep 2003 16:04:05 +0100 To: Therion List I've debianised and uploaded the 0.2.15 release so in a day or two Michael should be able to apt-get the new powerpc version and tell us that it works now.... The new version looks nice in my 2-minute play with it. Great work guys. 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/ Subject: Re: [therion-users] Therion a MacOS X 10.2.3 - working!!! From: Martin Sluka Date: Tue, 23 Sep 2003 20:58:16 +0200 To: therion@speleo.sk I've been looking for into survex and therion on mac ox x. Unfortunately I have not had much success installing X11 apps without the aid of fink. I have installed and run Therion in terminal but nothing happens when i try to execute xTherion. Is there a special place where i need to put the xtherion directory? Currently there is a xtherion symlink in /usr/bin pointing to ~/downloads/Therion/xtherion/xtherion. Tcl/Tk is also installed but I'm not sure about the Bwidget. Is there a guide for us Mac OS X 'nix noobs? Thanks! Gary http://www.garyritchie.com -- Subject: Re: Therion a MacOS X 10.2.3 - working!!! From: Stacho Mudrak Date: Wed, 24 Sep 2003 09:33:02 +0200 To: therion@speleo.sk Hi Gery, unfortunatelly, I've no access to Mac OS X, but I believe, I can answer at least some of your questions: 1. xtherion does not work from command line. I don't know why :( . As far as I remember, you have to run it with command: wish xtherion in xtherion directory (or use complete path of xtherion script name as an argument from whatever directory). 2. BWidget should be installed, if you have installed aqua Tcl/Tk with "Batteries included". You will see, if it will work - it's installed, if not - you have to download it :) (http://www.apple.com/downloads/macosx/unix_open_source/tcltk.html) 3. We will think seriously about Mac OS X guide, until now, nothing like that exists. If my suggestions will not work, please let me know. May be also Martin Sluka (he runs it on Mac OS X) can help you. Regards, S. > I've been looking for into survex and therion on mac ox x. Unfortunately I have not had much success installing X11 apps without the aid of fink. I have installed and run Therion in terminal but nothing happens when i try to execute xTherion. Is there a special place where i need to put the xtherion directory? Currently there is a xtherion symlink in /usr/bin pointing to ~/downloads/Therion/xtherion/xtherion. Tcl/Tk is also installed but I'm not sure about the Bwidget. > > Is there a guide for us Mac OS X 'nix noobs? > Thanks! > Gary > > http://www.garyritchie.com Subject: Re: [therion] Re: Therion a MacOS X 10.2.3 - working!!! From: Gary Ritchie Date: Wed, 24 Sep 2003 11:04:34 -0400 To: therion@speleo.sk Very cool. Thanks so much Stacho! I did finally find the beginning of the thread which had links to the downloads. All I really needed was the TCL/TK from Apple. Then I rm'd my first therion and reinstalled it as instructed in the manual. Finally, cd-ing to the xtherion directory and using 'wish xtherion' granted my wish. Now I'm ready to go caving again ;-) On Wednesday, September 24, 2003, at 03:33 AM, Stacho Mudrak wrote: > Hi Gery, > > unfortunatelly, I've no access to Mac OS X, but I believe, I can answer at least some of your questions: > > 1. xtherion does not work from command line. I don't know why :( . As far as I remember, you have to run it with command: > > wish xtherion > > in xtherion directory (or use complete path of xtherion script name as an argument from whatever directory). > > 2. BWidget should be installed, if you have installed aqua Tcl/Tk with "Batteries included". You will see, if it will work - it's installed, if not - you have to download it :) > > (http://www.apple.com/downloads/macosx/unix_open_source/tcltk.html) > > 3. We will think seriously about Mac OS X guide, until now, nothing like that exists. > > If my suggestions will not work, please let me know. May be also Martin Sluka (he runs it on Mac OS X) can help you. > > Regards, S. > >> I've been looking for into survex and therion on mac ox x. Unfortunately I have not had much success installing X11 apps without the aid of fink. I have installed and run Therion in terminal but nothing happens when i try to execute xTherion. Is there a special place where i need to put the xtherion directory? Currently there is a xtherion symlink in /usr/bin pointing to ~/downloads/Therion/xtherion/xtherion. Tcl/Tk is also installed but I'm not sure about the Bwidget. >> >> Is there a guide for us Mac OS X 'nix noobs? >> Thanks! >> Gary >> >> http://www.garyritchie.com > > > > > > http://www.garyritchie.com Subject: survex to therion data conversion From: Wookey Date: Wed, 5 Nov 2003 18:27:32 +0000 To: Therion List , Survex User Group Having been using Therion to try and draw up some caves I have become somewhat frustrated by the survex/therion data incompatibilities. I think there is room for improvement here and will make some observations, which I hope will promote discussion. The therion centreline data format is pretty-much the same as Survex's - however it's not exactly the same so there is a need for converting data between the two packages. Ultimately I think we need a scheme where the one dataset can be used by both packages as otherwise you end up maintaining two almost identical datasets, which has to be a bad thing. This could be accomplished with conversion tools, but the two formats are so nearly identical that we ought to be able to simply 'include' survex files in therion, or have both packages understand both dialects. In the meantime I need to be able to automate conversion for the hundreds of survex data files I have. Here are the differences I have found so far: First the simple ones: * In therion commands do not have a "*" prefix (lines starting with reserved words that are not actually commands have a "!" prefix) * therion does not understand "export" this is not a big deal, but it would probably be a good idea if it did * therion uses # for comments, survex uses ; (by default) this is just tiresome - especially for hand-editing conversion * Survex uses "begin ", therion uses "survey " * Survex uses "end ", therion uses "endsurvey" * (in *team) (survex currently allows anything but therion has a list) "insts" is not recognised and has to be replaced with "compass clino". I think "insts" or "instruments" should be a permitted synonym as it's in a lot of data files. therion has no eqivalent of "dog" on the surveying team (general checking-out of leads) . I think 'dog' is a colloquial UK term but there should probably be something in *data "ignore" is not supported by therion. - neither is left/right/up/down (survex doesn't support these either, but should - I even did a patch for it somewhere) This construct is needed for entry of LRUD info into files that will one day be processed usefully (at least for interleaved style data). If both bits of software allowed it to be labelled 'left', 'right', 'up', down' then that solves the problem. There are two more fundamental changes: *therion surrounds centreline (ie survex) data (inside the 'survey' construct) with centerline .... endcenterline this makes sense - it is effectively implicit in survex, but therion has other forms of data so the centreline stuff needs to be indicated. (it would be nice if the synonym "centreline" was allowed as well as "centerline", then I wouldn't get an error every time I type it in :-) On the other hand there is a lot to be said for a strict data format). * equates need to live inside centerline/endcenterline this one is tricky as it seems to change the scoping rules survex uses and seems to make it difficult to directly (simply) translate data. typical survex data goes: *begin part1 *end part1 *equate part1.36 part2.0 *begin part2 *end part2 How do I translate this to therion? will: survey part1 centerline endcenterline endsurvey survey part2 centerline equate part1.36 part2.0 endceterline endsurvey work? (It is good practice in survex not to include equates in the survey like this as they don't really belong to the scope of either survey). Recommendations welcome. So - I can probably write some perl to do this conversion reasonably well, but it'd be useful to have agreement on what to do about some of these cases and if we agreed it was better to modify the programs rather than write a converter then I could spend the time doing that instead. Discuss. 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/ Subject: Re: survex to therion data conversion From: John Pybus Date: Thu, 06 Nov 2003 02:27:56 +0000 To: Wookey CC: Therion List , Survex User Group Wookey wrote: > Having been using Therion to try and draw up some caves I have become > somewhat frustrated by the survex/therion data incompatibilities. > > I think there is room for improvement here and will make some observations, > which I hope will promote discussion. > > The therion centreline data format is pretty-much the same as Survex's - > however it's not exactly the same so there is a need for converting data > between the two packages. Ultimately I think we need a scheme where the one > dataset can be used by both packages as otherwise you end up maintaining two > almost identical datasets, which has to be a bad thing. This could be > accomplished with conversion tools, but the two formats are so nearly > identical that we ought to be able to simply 'include' survex files in > therion, or have both packages understand both dialects. I've also started using Therion recenty, and have come to similar conclusions. > * (in *team) (survex currently allows anything but therion has a list) > "insts" is not recognised and has to be replaced with "compass clino". I > think "insts" or "instruments" should be a permitted synonym as it's in a lot > of data files. I've also found the *team difference a problem. > There are two more fundamental changes: > > *therion surrounds centreline (ie survex) data (inside the 'survey' > construct) with centerline > .... > endcenterline > > this makes sense - it is effectively implicit in survex, but therion has > other forms of data so the centreline stuff needs to be indicated. > > (it would be nice if the synonym "centreline" was allowed as well as > "centerline", then I wouldn't get an error every time I type it in :-) On > the other hand there is a lot to be said for a strict data format). I have got this wrong *every* time I've used it so far! I did think of complaining but considered that many people have to put up with every term in computer based languages being non-native so thought I'd just put up with one spelled 'wrongly'. > * equates need to live inside centerline/endcenterline > > this one is tricky as it seems to change the scoping rules survex uses and > seems to make it difficult to directly (simply) translate data. I'm not sure things are quite so different. Survex has an (implicit) root context. In therion you don't, so you'll have to create your own container survey, but you can then put your equates in the same relative position as before. > typical survex data goes: > *begin part1 > > *end part1 > > *equate part1.36 part2.0 > > *begin part2 > > *end part2 > > How do I translate this to therion? > > will: > > survey part1 > centerline > > endcenterline > endsurvey > > survey part2 > centerline > equate part1.36 part2.0 endceterline > endsurvey > > work? (It is good practice in survex not to include equates in the survey > like this as they don't really belong to the scope of either survey). > > Recommendations welcome. Something like: survey outer survey part1 centreline endcentreline endsurvey centreline equate 36@part1 0@part2 endcentreline survey part2 centreline endcentreline endsurvey endsurvey You'll also note the need to convert reference of the form survey.subsurvey.station to station@subsurvey.survey . This is also rather irksome (I think it betrays therion's tcl roots?). I'd really like a survexinclude which would import survex data from the original files. With very little reorganisation my existing data could then be used with therion without change. That might require linking the survex parser into therion to implement. Yours, John Subject: Re: survex to therion data conversion From: Michael Lake Date: Thu, 06 Nov 2003 15:08:03 +1100 To: Therion List CC: Survex User Group John Pybus wrote: >> You'll also note the need to convert reference of the form >> survey.subsurvey.station to station@subsurvey.survey . This is also >> rather irksome (I think it betrays therion's tcl roots?). OT but I think that at some point it will have to use another GUI. Either GTK-anything or wxWindows or ..... now back to the topic at hand. >> I'd really like a survexinclude which would import survex data from the >> original files. With very little reorganisation my existing data could >> then be used with therion without change. That might require linking >> the survex parser into therion to implement. The above would be by far the best option. Copying and pasting in your survex data creates then two copies of survex data that can get out-of-sync when you update the survex data. Mike PS. I have been distracted lately and havent been able to get back to playing with Therions metapost and ASF/UIS cave symbols. I intend to get back onto this in Dec/Jan as Im taking annual leave so will have time. I would like to modify the metapost so that cave symbols can be easily constructed with just a bit of metapost knowledge and pulled in at run time rather than needing to be there when compiled. -- Michael Lake Chemistry, Materials & Forensic Science, UTS Ph: 9514 1724 Fx: 9514 1460 UTS CRICOS Provider Code: 00099F DISCLAIMER ======================================================================== This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. ======================================================================== Subject: Re: survex to therion data conversion From: Wookey Date: Thu, 6 Nov 2003 09:40:14 +0000 To: John Pybus CC: Wookey , Therion List , Survex User Group +++ John Pybus [03-11-06 02:27 +0000]: >> Wookey wrote: >> I've also found the *team difference a problem. I wrote a (survex) patch last night to make survex parse the *TEAM line (with a slightly expanded list over therion's :-) , but having done this I wonder if there is actually much point. What is this data going to be used for? Is there any point trying to classify "disto", "assistant", "clino", "notes", or might it just as well remain as a string to be reported somewhere (then it can say 'Bosch DLE35', or 'Pybus's magic surveyor')? The right thing to do here is to decide what survex and/or therion is going to use this info for first and then agree on a syntax. >>> >(it would be nice if the synonym "centreline" was allowed as well as >>> >"centerline", then I wouldn't get an error every time I type it in :-) On >>> >the other hand there is a lot to be said for a strict data format). > >> >> I have got this wrong *every* time I've used it so far! I did think of >> complaining but considered that many people have to put up with every >> term in computer based languages being non-native so thought I'd just >> put up with one spelled 'wrongly'. But this is European software - we can't go spelling it the American way :-) >>> >* equates need to live inside centerline/endcenterline > >> >> I'm not sure things are quite so different. Survex has an (implicit) >> root context. In therion you don't, so you'll have to create your own >> container survey, but you can then put your equates in the same relative >> position as before. OK - I did wonder if that was the right answer - I didn't have time to check before writing this mail. That all seems fair enough, although it makes writing a perl converter slightly trickier I suspect. I'd be happy to collaborate on writing a 'survexinclude' thing for Therion if that's deemed to be the right answer, although I don't do C++ if I can help it :-) 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/ Subject: Re: survex to therion data conversion From: Wookey Date: Thu, 6 Nov 2003 09:45:32 +0000 To: therion@speleo.sk CC: Survex User Group +++ Michael Lake [03-11-06 15:08 +1100]: >> John Pybus wrote: >> > >>> > You'll also note the need to convert reference of the form >>> > survey.subsurvey.station to station@subsurvey.survey . This is also >>> > rather irksome (I think it betrays therion's tcl roots?). > >> OT but I think that at some point it will have to use another GUI. >> Either GTK-anything or wxWindows or Yes. Everyone agrees xtherion is fairly horrid and is merely a 'proof of concept' UI. I think stacho picked tcl because he already knew it. Most of the people I know who are currently using illustrator rather than therion are doing it because the interface was too slow/horrible in comparison. The problem is of course that writing good UIs is both hard and tedious - any volunteers :-) ..... now back to the topic at hand. >> > >>> > I'd really like a survexinclude which would import survex data from the >>> > original files. With very little reorganisation my existing data could >>> > then be used with therion without change. That might require linking >>> > the survex parser into therion to implement. > >> >> The above would be by far the best option. Copying and pasting in your >> survex data creates then two copies of survex data that can get >> out-of-sync when you update the survex data. OK - that's another vote. Unless any of the main authors object violently this seems like the way to go. 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/ Subject: Re: survex to therion data conversion From: Andy Waddington on Cave Surveying Date: Thu, 6 Nov 2003 10:04:26 +0000 To: Wookey , Therion List , Survex User Group On Wednesday 2003-11-05 18:27, Wookey typed: >> * (in *team) (survex currently allows anything but therion has a list) >> "insts" is not recognised and has to be replaced with "compass clino". I >> think "insts" or "instruments" should be a permitted synonym as it's in a >> lot of data files. The instruments being read are not necessarily compass and clino for some surveying styles. They might, for example, be a compass and depth guage. The more general term should be preferred if all instruments are being read by a single surveyor, but it ought to be accpetable to specify individual instruments if, as occasionally happens, different instruments are being read by different people and you need to specify which/who. >> (it would be nice if the synonym "centreline" was allowed as well as >> "centerline", then I wouldn't get an error every time I type it in :-) On >> the other hand there is a lot to be said for a strict data format). You could have a strict data format whilst still allowing regional variant spellings if you had something like *lingua en-gb ; or *lingua en-us to specify which command set was in use. Your program would need to understand every set of directives. This form of internationalisation is the sort of common courtesy that most English-speaking standards groups neglect :-( I used to have a browser that understood as well as
, which was nice for viewing web pages which had been built in an ordinary text editor (like Wookey, I always type the familiar spelling), but not much use for testing pages that you were actually going to publish. If the DTD line at the top of the page would allow me to specify en-gb tags, that would make life much easier (but would make browsers more complex)-: Andy Subject: Re: [therion] Re: survex to therion data conversion From: Stacho Mudrak Date: Thu, 06 Nov 2003 11:23:39 +0100 To: therion@speleo.sk >> Yes. Everyone agrees xtherion is fairly horrid and is merely a 'proof of >> concept' UI. I think stacho picked tcl because he already knew it. No :) The first editor wrote Martin in Delphi/???(I do not remember the name of Linux clone). But it has not implemented canvas with vector graphics in it - and this was definitely needed. The only APIs, that has it implemented are Tcl/Tk and Qt - the second one is not GPL for Win32 :( >> Most of the people I know who are currently using illustrator rather than >> therion are doing it because the interface was too slow/horrible in >> comparison. Here I disagree. On a computer, where Illustrator works smoothly, also xtherion must work. The horribility is other case - a lot of things should work more intuitivly, I agree, but I do not agree, that drawing maps of complicated caves in Illustrator is more simple. It's the same with Word/TeX. For a simple one page letter to some stupid officer, I always use Word. But when I started to write the first mathematical formula of my diploma thesis in Word, I was forced (by the lack of time) to switch to LaTeX. >> The problem is of course that writing good UIs is both hard and tedious - >> any volunteers :-) :))) We have also something like ultimate GUI in mind, but... >> OK - that's another vote. Unless any of the main authors object violently >> this seems like the way to go. If somebody will write the transformation script - I'll do the stuff around... But I don't thing, that writing such a script will be very easy. S. Subject: Re: [therion] Re: survex to therion data conversion From: Stacho Mudrak (by way of Stacho Mudrak ) Date: Thu, 06 Nov 2003 12:47:01 +0100 To: therion@speleo.sk I'm sorry, but I'm busy now so just very briefly: 1. TEAM will be used in therion very soon to generate map legend item "Surveyed by". The fields we don't care at the moment - we've never noticed in fact the roles on the paper. The man, who drawn the notes is usually very clear, the rest are not important... 2. "centreline" - I'll have to look at this - whether it's possible to change it. But I believe, it should be. But it will not be trivial - it can't be solved by adding a single item to parsing table... 3. survexinclude - it can't be done just by changing the parsing table, but as a first aproximation, therion can call a perl script (C++ is not a good idea for the first approximation) and read data from the pipe (OK, Win32 pipe may be a problem, but on other systems this should work). 4. LRUD in centerline - this should be also implemented very soon, also other format incompatibilities 5. The rest, I'll write something to this later today or tomorrow... >> I'd be happy to collaborate on writing a 'survexinclude' thing for Therion >> if that's deemed to be the right answer, although I don't do C++ if I can >> help it :-) We would be very happy... S. Subject: Re: survex to therion data conversion From: Wookey Date: Thu, 6 Nov 2003 13:06:14 +0000 To: Andy Waddington on Cave Surveying CC: Wookey , Therion List , Survex User Group +++ Andy Waddington on Cave Surveying [03-11-06 10:04 +0000]: >> On Wednesday 2003-11-05 18:27, Wookey typed: > >>> > * (in *team) (survex currently allows anything but therion has a list) >>> > "insts" is not recognised and has to be replaced with "compass clino". I >>> > think "insts" or "instruments" should be a permitted synonym as it's in a >>> > lot of data files. > >> >> The instruments being read are not necessarily compass and clino for >> some surveying styles. They might, for example, be a compass and >> depth guage. The more general term should be preferred if all >> instruments are being read by a single surveyor, but it ought to >> be accpetable to specify individual instruments if, as occasionally >> happens, different instruments are being read by different people and >> you need to specify which/who. There is a huge pile of considerations like this - the tape might be a disto, the instrument might be an altimeter. Does the *team command serve to categorise the person responsible for the 'length, depth, gradient, backclino pictures' measurements in order to know who was respnsible for what in which case all we care about is which numbers to match them up with, or is it simply a string that we can use. I think we want to use this command (as opposed to a comment) to regularise this data so that it can be understood by the programs for future use (e.g making charts of who took the most clino readings, or applying personal calibration offsets (still not clear if this is worth doing)). The problem is that there are a lot of potentially valid strings if we allow all instrument names (disto, DLE35, laser, compass, MC-15 etc). These boil down to a set of measurement names (length, gradient, depth etc) and a set of accuracy numbers (disto is better than tape). But the accuracy numbers go in the *SD command anyway so maybe we should limit the synonyms (but allow 'other' and 'unkown'). If we were just going to treat it as a free string then we might as well stick to using comments. >>> > (it would be nice if the synonym "centreline" was allowed as well as >>> > "centerline", then I wouldn't get an error every time I type it in :-) On >>> > the other hand there is a lot to be said for a strict data format). > >> >> You could have a strict data format whilst still allowing regional >> variant spellings if you had something like >> >> *lingua en-gb >> ; or >> *lingua en-us >> >> to specify which command set was in use. This way lies madness. >> I used to have a browser that understood >> as well as
, which was nice for viewing web pages which had >> been built in an ordinary text editor (like Wookey, I always type the >> familiar spelling), but not much use for testing pages that you were >> actually going to publish. If the DTD line at the top of the page >> would allow me to specify en-gb tags, that would make life much >> easier (but would make browsers more complex)-: We've had this argument over HTML and we all know what a mess accepting broken HTML was. We need to be strict about option names and spellings. In general I'd say that there should only be one spelling of centerline. The problem is that at the moment this line is aded by hand to a lot of survex files and all en-gb (or en-fr) spekaing people will get it wrong most of the time. The question is should therion allow both spellings until the need for hand-editing as a matter of course is removed? I suspect the answer is 'no' and we should just fix the conversion problem so this particular irritation goes away. (sorry about the repeats for people on both these lists BTW - but I think it's important for both user communities to agree on this stuff) 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/ Subject: Re: survex to therion data conversion From: Wookey Date: Thu, 6 Nov 2003 13:13:06 +0000 To: therion@speleo.sk, Survex User Group +++ Stacho Mudrak [03-11-06 12:47 +0100]: >> I'm sorry, but I'm busy now so just very briefly: >> >> 1. TEAM will be used in therion very soon to generate map legend item >> "Surveyed by". The fields we don't care at the moment - we've never >> noticed in fact the roles on the paper. The man, who drawn the notes is >> usually very clear, the rest are not important... OK. In that case it might be best to have neither program specify what should go in these fields until we decide how to use them - the current incompatibility (therion requires one of a set of tokens) serves no purpose. >> 2. "centreline" - I'll have to look at this - whether it's possible to change >> it. But I believe, it should be. But it will not be trivial - it can't be >> solved by adding a single item to parsing table... If it's not easy to do then we should probably put up with it (I just wanted to moan :-) , and automate the survex->therion data-reading process instead. >> 3. survexinclude - it can't be done just by changing the parsing table, but >> as a first aproximation, therion can call a perl script (C++ is not a good >> idea for the first approximation) and read data from the pipe (OK, Win32 pipe >> may be a problem, but on other systems this should work). OK - I'll look at it on that basis. The equates could be tricky... 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/ Subject: Re: [therion] Re: survex to therion data conversion From: Stacho Mudrak Date: Thu, 06 Nov 2003 15:25:46 +0100 To: therion@speleo.sk Just two small remarks: If the role should be used for something in the future, the keywords must be specified. If not, it should be removed to comments. I've understood this as a responsibility for some reading - and readings are standardized in DATA command. Adding "unknown" keyword is useless - this is the same, as nothing specified in this field (the most of the cases). So I'll add there words "instruments" and "insts". :) > In general I'd say that there should only be one spelling of > centerline. I disagree - even in survex you used "meters" and "metres" for the same thing. Here I don't see the problem. Regards, S. Subject: Re: [therion] Re: survex to therion data conversion From: Stacho Mudrak Date: Thu, 06 Nov 2003 11:00:52 +0100 To: therion@speleo.sk I'm sorry, but I'm busy now so just very briefly: 1. TEAM will be used in therion very soon to generate map legend item "Surveyed by". The fields we don't care at the moment - we've never noticed in fact the roles on the paper. The man, who drawn the notes is usually very clear, the rest are not important... 2. "centreline" - I'll have to look at this - whether it's possible to change it. But I believe, it should be. But it will not be trivial - it can't be solved by adding a single item to parsing table... 3. survexinclude - it can't be done just by changing the parsing table, but as a first aproximation, therion can call a perl script (C++ is not a good idea for the first approximation) and read data from the pipe (OK, Win32 pipe may be a problem, but on other systems this should work). 4. LRUD in centerline - this should be also implemented very soon, also other format incompatibilities 5. The rest, I'll write something to this later today or tomorrow... >> I'd be happy to collaborate on writing a 'survexinclude' thing for Therion >> if that's deemed to be the right answer, although I don't do C++ if I can >> help it :-) We would be very happy... S. Subject: Re: [therion] survex to therion data conversion From: Stacho Mudrak Date: Fri, 07 Nov 2003 10:43:19 +0100 To: therion@speleo.sk Hi everybody, I'm sorry for the previous mail - it was lost somewhere on the net - so I've sent it yesterday once more... :( Now I would like to write my opinions to other topics: > * In therion commands do not have a "*" prefix (lines starting with reserved > words that are not actually commands have a "!" prefix) This can't be changed no more :( . But this is probably the most simple thing to do in convertor. > * therion does not understand "export" > this is not a big deal, but it would probably be a good idea if it did I do not like this thing - it can happen, that you will not be able to join two datasets, because there will be two different stations exported with the same name. Or is it not true? > * therion uses # for comments, survex uses ; (by default) > this is just tiresome - especially for hand-editing conversion This has something to do with the very old concept of therion, at that time, it has been quite far away from survex syntax... > * Survex uses "begin ", therion uses "survey " > * Survex uses "end ", therion uses "endsurvey" endsurvey can be optionally followed by , than it's checked whether survey and endsurvey parameter match. It's because we have also other data than centreline: (line, area, map) > therion has no eqivalent of "dog" on the surveying team (general > checking-out of leads) . I think 'dog' is a colloquial UK term but there > should probably be something I still do not understand, what does the term "dog" mean :( Could you please explain it? The last, I thing very important difference is the station naming. Survex uses prefixes - we use suffixes (svx: survey.1 th: 1@survey). We've chosen this because we're naming also other objects than stations (scraps,maps etc...) and we wanted to be able at single look recognize what is an station/object name and what is a survey. That's all for now. Today we're leaving for some caving (hopefuly), but I believe, next week I'll be able to implement all "implementable" changes to therion. I have another question with SVX input. If somebody wants to maintain original survey data in survex format - wouldn't it be sufficient to write independent convertor and some makefiles and call therion via "make" command? This would be probably the most "clean" solution, and I'll add this feature to xtherion compiler (to run "make" instead of "therion"). Becuase sometimes also postprocessing will be used (for example to combine plan and elevation maps into one PDF file). Regards, S. Subject: Re: survex to therion data conversion From: Wookey Date: Fri, 7 Nov 2003 13:30:58 +0000 To: therion@speleo.sk, Survex User Group +++ Stacho Mudrak [03-11-07 10:43 +0100]: >>> >* In therion commands do not have a "*" prefix (lines starting with >>> >reserved >>> >words that are not actually commands have a "!" prefix) > >> >> This can't be changed no more :( . But this is probably the most simple >> thing to do in convertor. I am not proposing to change the two syntaxes to be identical (as you say it's probably too late for that, and it may well not be appropriate either) - but we do need a mechanism for using continuously-updated survex data as the therion baseline. If therion can just accept survex-systax data directly (by ignoring the "*"'s in this case when told to do so via a "survexinclude" command (for example), that should work fine. Obviously the fewer differences there are between the two syntaxes the better things are likely to work :-) >>> >* therion does not understand "export" >>> >this is not a big deal, but it would probably be a good idea if it did > >> >> I do not like this thing - it can happen, that you will not be able to join >> two datasets, because there will be two different stations exported with >> the same name. Or is it not true? 'export' only exports up one level - to the surrounding survey, so there are no 'global' names which might clash. So it is not true that you might not be able to join caves. However if therion does not want to support export than it can simply ignore it - it makes no practical difference. Then therion will work as it does now, and as survex does if there are no export commands: every station is implicitly exported. >>> >* therion uses # for comments, survex uses ; (by default) >>> >this is just tiresome - especially for hand-editing conversion > >> >> This has something to do with the very old concept of therion, at that >> time, it has been quite far away from survex syntax... If therion could accept both it would be handy. conversion of these chars is easy in theory but the problem is that ";" is/can be used in places where it does not mean 'comment' so a simple-minded replacement might make some comments a bit odd. It shouldn't break anything though. A converter replacing the first one on a line will probably always work. (counterexamples?) >>> >* Survex uses "begin ", therion uses "survey " >>> >* Survex uses "end ", therion uses "endsurvey" > >> >> endsurvey can be optionally followed by , than it's checked >> whether survey and endsurvey parameter match. I'm fairly sure I got errors in therion 0.2.15 when I tried this....this would certainly be better for making the converter simpler (it has to be careful about begin/end pairs that are do not start/end surveys. >>> >therion has no eqivalent of "dog" on the surveying team (general >>> >checking-out of leads) . I think 'dog' is a colloquial UK term but there >>> >should probably be something > >> >> I still do not understand, what does the term "dog" mean :( Could you >> please explain it? "assitant" was the best sensible term I could think of. Someone on the surveying team who may not actually be surveying but is looking round corners, up slopes, and behind boulders to be sure nothing is missed. >> The last, I thing very important difference is the station naming. Survex >> uses prefixes - we use suffixes (svx: survey.1 th: 1@survey). We've chosen >> this because we're naming also other objects than stations (scraps,maps >> etc...) and we wanted to be able at single look recognize what is an >> station/object name and what is a survey. Yes - this bit of the conversion could be 'interesting'. >> That's all for now. Today we're leaving for some caving (hopefuly), but I >> believe, next week I'll be able to implement all "implementable" changes to >> therion. OK - olly is away for another 8 days or so and it would be useful to hear what he thinks too before we fiddle with survex/therion and a converter script (as they need to be somewhat synchronsied. >> I have another question with SVX input. If somebody wants to maintain >> original survey data in survex format - wouldn't it be sufficient to write >> independent convertor and some makefiles and call therion via "make" >> command? >> >> This would be probably the most "clean" solution, Why is that cleaner than a 'survexinclude' directive which does necessary conversion?. I suppose it is more general, but going through make is going to be confusing to non-programmers I would have thought? The make target would need to create new files by converting the existing survex files, then insert them, or include them, in existing therion files - right? >> and I'll add this feature >> to xtherion compiler (to run "make" instead of "therion"). Becuase >> sometimes also postprocessing will be used (for example to combine plan and >> elevation maps into one PDF file). 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/ Subject: Re: [therion] Re: survex to therion data conversion From: Stacho Mudrak Date: Mon, 10 Nov 2003 10:18:03 +0100 To: therion@speleo.sk, Survex User Group > 'export' only exports up one level - to the surrounding survey, so there are no 'global' names which might clash. So it is not true that you might not be able to join caves. Then I've not understood the survex manual correctly :) >> >* therion uses # for comments, survex uses ; (by default) >> >this is just tiresome - especially for hand-editing conversion > > > If therion could accept both it would be handy. conversion of > these chars is easy in theory but the problem is that ";" is/can > be used in places where it does not mean 'comment' so a simple-minded replacement might make some comments a bit odd. > It shouldn't break anything though. A converter replacing the > first one on a line will probably always work. > (counterexamples?) No idea. I just have to check - how is it in therion - when the line is not commented from the beginning. >> >* Survex uses "begin ", therion uses "survey " >> >* Survex uses "end ", therion uses "endsurvey" >> >> endsurvey can be optionally followed by , than it's checked whether survey and endsurvey parameter match. > > > I'm fairly sure I got errors in therion 0.2.15 when I tried this....this > would certainly be better for making the converter simpler (it has to be > careful about begin/end pairs that are do not start/end surveys. I've checked this now - it works with my dataset. So if it doesn't work with your data, there must be a bug somewhere... > "assitant" was the best sensible term I could think of. Someone on the > surveying team who may not actually be surveying but is looking round > corners, up slopes, and behind boulders to be sure nothing is missed. Now I understand :) > Why is that cleaner than a 'survexinclude' directive which does necessary > conversion?. I suppose it is more general, but going through make is going > to be confusing to non-programmers I would have thought? I had in mind, that convertor would never be able to convert corretly all survex input data. Using make process - user (programmer) would be able to make corrections. But you're right, I've never thought about 'non- programmers' :( > The make target would need to create new files by converting the existing > survex files, then insert them, or include them, in existing therion files - > right? Yes. But I think, that the most important thing now is to create and test the conversion script - and then we can decide, how it will be implemented in therion. Regards, S. Subject: new 0.2.15 From: Stacho Mudrak Date: Fri, 14 Nov 2003 10:18:31 +0100 To: therion@speleo.sk Hello everybody, we've added several new features to therion - new 0.2.15 source code can be downloaded from http://therion.speleo.sk/download.html According to Wookey's suggestions, following things were added: * new team roles: instruments (insts), assistant (dog) * centerline/centreline syntax * new centerline data items: up ceiling down floor left right ignore (currently all of them are ignored). We need also some abbreviation for LRUD, to be used in *units LRUD metres I don't think that "LRUD" is the best choise. Something like "dimensions" or "walls"... Regards, S. Subject: Re: new 0.2.15 From: Wookey Date: Fri, 14 Nov 2003 17:49:12 +0000 To: therion@speleo.sk, s.m@group-s.sk +++ Stacho Mudrak [03-11-14 10:18 +0100]: >> Hello everybody, >> >> we've added several new features to therion - new 0.2.15 source code can be >> downloaded from erm - the last version was 0.2.15 - this one should probably be 0.2.16 :-) Will you change it or shall I do a 0.2.15b-1 debian release? >> According to Wookey's suggestions, following things were added: >> * new team roles: instruments (insts), assistant (dog) >> * centerline/centreline syntax >> * new centerline data items: up ceiling down floor left right ignore >> (currently all of them are ignored). great. >> We need also some abbreviation for LRUD, to be used in >> *units LRUD metres >> I don't think that "LRUD" is the best choise. Something like "dimensions" or >> "walls"... you are right that LRUD is not ideal. Especially for US users whpo call it LRCF. And no doubt french-speaking users call it something else. "Dimensions" seems good. 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/ Subject: Re: [therion] Re: new 0.2.15 From: Stacho Mudrak Date: Tue, 18 Nov 2003 08:54:13 +0100 To: therion@speleo.sk > erm - the last version was 0.2.15 - this one should probably be 0.2.16 :-) Yes. But we (Martin and me) need to synchronize our sources together (we can't use CVS, because we have a very problematic i-net connection - firewalls etc :() So 0.2.16 will be available probably next week. > Will you change it or shall I do a 0.2.15b-1 debian release? The second one :( . At least until next week. Regards, S. Subject: Therion 0.2.16 From: "Martin Budaj" Date: Mon, 24 Nov 2003 15:15:42 +0100 To: therion@speleo.sk Hi all, new version of Therion is available on the web. Improvements include - centerline command has new team roles: instruments (insts), assistant (dog) - centerline command has new data readings: up/ceiling, down/floor, left, right, ignore - centerline may be spelled as centreline - deg:min:sec syntax allowed for degree values - point, line and area commands have new option: visibility on/off See the file CHANGES for details. The Therion Book was also updated. Martin Subject: Translation From: Stacho Mudrak Date: Mon, 01 Dec 2003 14:17:47 +0100 To: therion@speleo.sk Is there an english expression used to name the set of symbols used in a map? Here is Slovakia we call it "map key". Regards, S. Subject: Re: [therion] Translation From: Michael Lake Date: Tue, 02 Dec 2003 10:03:01 +1100 To: therion@speleo.sk Stacho Mudrak wrote: >> Is there an english expression used to name the set of symbols used in a >> map? >> >> Here is Slovakia we call it "map key". >> >> Regards, S. >> legend Mike Lake UTS CRICOS Provider Code: 00099F DISCLAIMER ======================================================================== This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. ======================================================================== Subject: Re: [therion] Translation From: Stacho Mudrak Date: Tue, 02 Dec 2003 09:08:15 +0100 To: therion@speleo.sk >> legend >> >> Mike Lake I'm sorry, I've wronlgy formulated my question. I need some expression (if there exists some), we can use instead of "symbols" or "symbol set". Legend includes also scale, north arrow, surveyors etc... I've been searching a lot, and probably there does not exist such expression in english. So we will use "UIS symbols", "ASF symbols" etc... Regards, S. Subject: Re: [therion] Translation From: Michael Lake Date: Wed, 03 Dec 2003 13:45:00 +1100 To: therion@speleo.sk Stacho Mudrak wrote: >>>>legend >>>>Mike Lake >> I'm sorry, I've wronlgy formulated my question. >> I need some expression (if there exists some), we can use instead of >> "symbols" or "symbol set". Legend includes also scale, north arrow, >> surveyors etc... Umm... here we have a difference in understanding. In Australia adn Im sure in US and UK too, the legend is just a box (border or no border) that has a list of the symbols and what they are. The surveyors etc goes into the 'Title Box" with the name of the cave, survey dates etc. That Title box does not include the symbols listed in the legend. >> I've been searching a lot, and probably there does not exist such >> expression in english. So we will use "UIS symbols", "ASF symbols" Often though the word "Legend" does not get put on the map, sometimes it does. Internationalisation is not easy :-) Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. UTS CRICOS Provider Code: 00099F DISCLAIMER ======================================================================== This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. ======================================================================== Subject: Therion 0.2.17 From: "Martin Budaj" Date: Thu, 04 Dec 2003 11:59:25 +0100 To: therion@speleo.sk Good news for all MetaPost fans! Therion 0.2.17 supports * easy switching among predefined map symbol sets (symbol-set, symbol-assign, symbol-hide options of the layout command) * customized map symbols loaded in the run-time (new symbols may be defined inside of 'code metapost' section of the layout command) There is no need to recompile Therion when new symbols are added. * optical map scaling (base-scale option) Regards, Martin Subject: Re: Therion 0.2.17 From: Wookey Date: Mon, 22 Dec 2003 16:03:07 +0000 To: therion@speleo.sk +++ Martin Budaj [03-12-04 11:59 +0100]: >> Good news for all MetaPost fans! >> >> Therion 0.2.17 supports ... OK, Having been too slow to do 0.2.16 due to being on holiday I've debianised 0.2.17 (it gets easier every time as you guys incorporate most of my changes - thanx). The only thing stopping me from uploading is that the original source archive contains a 3Mb 'screendump' X image, which I suspect is there accidentally. Is that right? if it's a mistake then I'll remove it from the 'therion-0.2.17.orig.tar.gz' source tarball and build against that. This tarball should be exactly as released by the authors but it seems a shame to give them 3Mb of pointless screendump if they don't need it - so I'm checking with you guys first. And the new bac module seems to be designed to calculate blood alcohol levels after getting pissed - I can't quite see the (direct) relevance to cave drawing of this? What do I use it for? :-) 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/ Subject: Re: Therion 0.2.17 From: Stacho Mudrak Date: Tue, 23 Dec 2003 09:48:45 +0100 To: therion@speleo.sk >> The only thing stopping me from uploading is that the original source >> archive contains a 3Mb 'screendump' X image, which I suspect is there >> accidentally. Is that right? if it's a mistake then I'll remove it from the >> 'therion-0.2.17.orig.tar.gz' source tarball and build against that. Yes, it should not be there. >> And the new bac module seems to be designed to calculate blood alcohol >> levels after getting pissed - I can't quite see the (direct) relevance to >> cave drawing of this? What do I use it for? :-) It is only an experimental funny Help feature - therefore it's placed in the Help menu. From my experience, blood alcohol level has quite important influence on number of errors made, when drawing maps with xtherion - not very idiot resistant interface :) Regards, S. Subject: Re: Therion 0.2.17 From: Wookey Date: Mon, 29 Dec 2003 18:42:41 +0000 To: therion@speleo.sk +++ Stacho Mudrak [03-12-23 09:48 +0100]: >>> > The only thing stopping me from uploading is that the original source >>> > archive contains a 3Mb 'screendump' X image, which I suspect is there >>> > accidentally. Is that right? if it's a mistake then I'll remove it from the >>> > 'therion-0.2.17.orig.tar.gz' source tarball and build against that. > >> >> Yes, it should not be there. OK. I've now (finally) uploaded the new version after Debian and I both sorted ourselves out after the recent server breakin. Autobuilding will proceed slowly as things are still catching up. http://qa.debian.org/developer.php?login=wookey&comaint=yes and http://packages.qa.debian.org/t/therion.html 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/ Subject: Queries and comments on 0.2.17 From: Wookey Date: Tue, 10 Feb 2004 18:08:46 +0000 To: Therion List I've been writing an article about Therion for Compass points, which includes a complete tutorial on using therion to draw a simple survey. This process has generated a few queries, one of which needs answering for me to finish the article - others are mostly suggestions for improvements and a few bugs. I'm using 0.2.17 urgent queries: How do I control overlap at joins? I have drawn a couple of scraps and at the place where they join there are contour lines on one scrap and ceilinglines on another that sort of intermingle. When drawn up therion put one scrap on top of the other and invents a 'join line' that covers quite a lot of the neighboring scrap. I need transparency, or a complex 'join line'. What is the best way to deal with this? Do scraps have to have perfect joins? Can I draw a join line? Also I tried to control the join in more detail by specifying that the ends of lines join but the syntax didn't work. What's wrong with this: join farsidewest:0@farside2.river farsidewest2:end@farside.river (farsidewest are farsidewest2 are 'wall' lines). bugs: In .th files - if you use data normal ignore ignore ignore ignore newline tape compass clino then every LRUD line must be followed by a data line, including the last one If you s/ignore ignore ignore ignore/left right up down/ then it ignores absence of TCC part in the last line, but not in lines in the middle of a run. This is inconsistnet with survex behaviour (which will let you give LRUD info for a station and then stop - without subsequent TCC info) In the test editor, using above: data normal left right up down newline tape compass clino and then 'scan format' to get data table to have correct boxes is OK but when you enter data it appears as tape compass clino station left right up down which is the wrong order. When a created file is re-read every blank line gets a 'text' entry in the file commands section, and when saved ends up as 3 blank lines - whitespace text entries shouldn't appear. If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm file) Is this expected? It certainly makes it hard to draw boulders properly as I can;'t do stations very close together. The keys list suggets that I can hold down shift to create a station close to another station, but I have not suceeded - how exactly does it work? wishlist items: It would be _really_ good to have png support in Xtherion? GIFs are a pain for free software and pnm and ppm are huge. What needs to be done? Shortcuts for moving things between scraps would be helpful, otherwise it's 'move down' about 100 times. Is there a better way? Entering stations - ther is a space for 'id' but not name, which you need to enter for every station. Indeed why is the id not the name? It's very tedious if you need to change a number of entries - need shortcuts to move between boxes in RH-side or to scroll up and down items in the file summary. e.g if you need to change all the station ids to names. Need to be able to navigate file commands with keys. graphical stuff Air drafts need to be able to specify number of ticks - this is used to indicate wind strength The QMs ('continuation point) come out really small on my survey. Where do I control the size? The debris area symbol looks terrible. I want a quick way to fill in areas of rocks - needs randomised rocks of some sort with controls over size and density. Tunnel (java) has good code for this, with an arrow that control desity gradient. Borrow code? Areas need some way of working out if they are 'connected' or not. The current scheme is hopeless - very cryptic messages which give no clue which area is at fault. Editing them is a real pain as you find the text in the file (takes a while, especially with all the blank ones) but then as soon as you click on a line to adjust it you lose the text again. An entry method that lets you 'group' some lines into an area might be best - especially if it auto-allocated the names. There is a real problem with editing a file and using xtherion at the same time - even F1 and F2 type editing. Therion just saves the map version over any other version you might have created. It needs to check for 'newer on disk' or something. Until the map interface is better there is a real need to edit the file by hand too. This is a tricky problem but it definately needs work before many people will use it. Ticks are too close together on pitches. How do I change the default for contour lines to al have 'none' (no downside tick mark)? I don't want to add -tick none on every contour - I want to set a default. How does the slope line symbol work? It just seemst od raw a lot of overlapping lines for me. How does it differ from the contour line? 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/ Subject: Re: [therion] Queries and comments on 0.2.17 From: Stacho Mudrak Date: Wed, 11 Feb 2004 09:47:40 +0100 To: therion@speleo.sk I'm sorry, currently I'm short of time, but I'll try to write down at least some comments. > How do I control overlap at joins? I have drawn a couple of scraps and at > the place where they join there are contour lines on one scrap and > ceilinglines on another that sort of intermingle. When drawn up therion put > one scrap on top of the other and invents a 'join line' that covers quite a > lot of the neighboring scrap. I need transparency, or a complex 'join line'. > What is the best way to deal with this? Do scraps have > to have perfect joins? Can I draw a join line? I'm sorry, but this I do not understand :((( Could you please draw me exactly what you have in your mind? Joining two scraps together covers only joining the walls - not the lines inside. They can be joined only by detail specification, you mentioned below. > Also I tried to control the join in more detail by specifying that the ends > of lines join but the syntax didn't work. What's wrong with this: > join farsidewest:0@farside2.river farsidewest2:end@farside.river > (farsidewest are farsidewest2 are 'wall' lines). Nothing - it should work. If it does not - it's certainly a bug. Does therion generates an error or it simply does not join the lines? Did you tried this without :point specification (just farsidewest@farside2.river farsidewest2@farside.river)? This should work also. > bugs: > > In .th files - if you use > data normal ignore ignore ignore ignore newline tape compass clino then > every LRUD line must be followed by a data line, including the last one > If you s/ignore ignore ignore ignore/left right up down/ then it ignores > absence of TCC part in the last line, but not in lines in the middle of a run. > This is inconsistnet with survex behaviour (which will let you give LRUD > info for a station and then stop - without subsequent TCC info) OK. This is a bug. I'll write it down. > In the test editor, using above: data normal left right up down newline tape compass clino and > then 'scan format' to get data table to have correct boxes is OK but when > you enter data it appears as > tape compass clino > station left right up down > which is the wrong order. This is not a bug. I just thought, that putting interleaved (or how you call this style) data, is more natural when TO station is inserted and not FROM station. So I enter empty cells for TAPE, COMPASS, CLINO, enter the first STATION and it's LRUD data. Then I enter TCC data and TO station and it's LRUD. This can be changed or I can add there a check box, which style you like. > When a created file is re-read every blank line gets a 'text' entry in the > file commands section, and when saved ends up as 3 blank lines - whitespace > text entries shouldn't appear. I thought, I've removed all such bugs. But do not have this experience. Do you have a "text" item before each point, line? If yes, this has probably something to do EOLN characters. Do you have the same experience on each operating system? > If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm file) > Is this expected? 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems. > It certainly makes it hard to draw boulders properly as I > can;'t do stations very close together. The keys list suggets that I can > hold down shift to create a station close to another station, but I have not > suceeded - how exactly does it work? The keys list is wrong - it's Control key :) Thanks. > wishlist items: > > It would be _really_ good to have png support in Xtherion? GIFs are a pain > for free software and pnm and ppm are huge. What needs to be done? Tcl/Tk supports only these file types. But: Install Img plug-in into your Tcl installation. On Win32 ActiveTcl it's included. Add "package require Img" into your xtherion.ini file - and you'll be able to use all image files :))) (I've tryied it now and it worked - I was just too lazy before) Please let me know, if you will find out the linux version of this plug-in - it would be very usefull also for us :) OK, I'll add these two things to xtherion and if Img plug-in will be detected, all image file types will be supported also in the image open window. > Shortcuts for moving things between scraps would be helpful, otherwise it's > 'move down' about 100 times. Is there a better way? Right. No way right now. I'll think about it (adding a button move to scrap). > Entering stations - ther is a space for 'id' but not name, which you need to > enter for every station. Indeed why is the id not the name? This is hard to explain, may be later. > It's very tedious if you need to change a number of entries - need shortcuts > to move between boxes in RH-side or to scroll up and down items in the file > summary. e.g if you need to change all the station ids to names. Need to be > able to navigate file commands with keys. We have in our minds building much more intuitive user interface, but... Anyway, you can use text editor and regular expressions find and replace... > graphical stuff > > Air drafts need to be able to specify number of ticks - this is used to > indicate wind strength > > The QMs ('continuation point) come out really small on my survey. > Where do I control the size? Can be done via changing the metapost codes (and using scale option - may be, scale option works already now (I'm not sure - you can try) for the wind ticks). We will write something to this later. > The debris area symbol looks terrible. I want a quick way to fill in areas > of rocks - needs randomised rocks of some sort with controls over size and > density. Tunnel (java) has good code for this, with an arrow that control > desity gradient. Borrow code? Firstly, we had randomized symbols in therion. Than we've removed them and we're using only symbols (in most cases, it's enought). In the last time, we're again on a way to put them back to therion - so any ideas in this field are welcome. > Areas need some way of working out if they are 'connected' or not. The > current scheme is hopeless - very cryptic messages which give no clue which > area is at fault. Editing them is a real pain as you find the text in the > file (takes a while, especially with all the blank ones) but then as soon as > you click on a line to adjust it you lose the text again. An entry method > that lets you 'group' some lines into an area might be best - especially if > it auto-allocated the names. This is already in TODO list. > There is a real problem with editing a file and using xtherion at the same > time - even F1 and F2 type editing. Therion just saves the map version over > any other version you might have created. It needs to check for 'newer on disk' or > something. Until the map interface is better there is a real need to edit > the file by hand too. This is a tricky problem but it definately needs work > before many people will use it. Right. > Ticks are too close together on pitches. > > How do I change the default for contour lines to al have 'none' (no downside > tick mark)? I don't want to add -tick none on every contour - I want to set > a default. Again, you have to edit metapost code, and than in the layout use symbol-set CUCC :) > How does the slope line symbol work? It just seemst od raw a lot of > overlapping lines for me. How does it differ from the contour line? This is complicated, and there are also some bugs in metapost code. We will write about this later. Last thing: thanks a lot for your feedback. We'll think about it a lot... S. Subject: Re: [therion] Queries and comments on 0.2.17 From: Stacho Mudrak Date: Thu, 12 Feb 2004 10:18:00 +0100 To: therion@speleo.sk Answers to your questions part II: > When a created file is re-read every blank line gets a 'text' entry in the > file commands section, and when saved ends up as 3 blank lines - whitespace > text entries shouldn't appear. ??? I've been trying this, but without success. No blank lines converted to text appeared? Could you please send me one th2 file, where there is a lot of text entries? > Entering stations - ther is a space for 'id' but not name, which you need to > enter for every station. Indeed why is the id not the name? -id identifies the object it self (joins for example refer to id's). -name is a reference to survey station - it can not be ID, bacause you can not have two objects with the same ID in the same survey. > Air drafts need to be able to specify number of ticks - this is used to > indicate wind strength OK, the -scale does not work now. But the symbol can be easily redefined to change the number of ticks and not the size. > The debris area symbol looks terrible. I want a quick way to fill in areas > of rocks - needs randomised rocks of some sort with controls over size and > density. Tunnel (java) has good code for this, with an arrow that control > desity gradient. Borrow code? We will start working on this in the next release. > How does the slope line symbol work? It just seemst od raw a lot of > overlapping lines for me. How does it differ from the contour line? Click the l-size switch for one line point (optionally also orientation) and set the size to the desired slope width. This symbol generates gradient lines perpendicular (or in orientation) to main line with given size. S. Subject: Re: Queries and comments on 0.2.17 From: Wookey Date: Fri, 13 Feb 2004 17:55:31 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-02-11 09:47 +0100]: >> I'm sorry, currently I'm short of time, but I'll try to write down at least >> some comments. >> > >>> >How do I control overlap at joins? I have drawn a couple of scraps and at >>> >the place where they join there are contour lines on one scrap and >>> >ceilinglines on another that sort of intermingle. When drawn up therion put >>> >one scrap on top of the other and invents a 'join line' that covers quite a >>> >lot of the neighboring scrap. I need transparency, or a complex 'join >>> >line'. >>> >What is the best way to deal with this? Do scraps have >>> >to have perfect joins? Can I draw a join line? > >> >> I'm sorry, but this I do not understand :((( Could you please draw me >> exactly what you have in your mind? I have put a picture of a screen shot of the scrap join and the resulting PDF image online to illustrate how one scrap cuts off parts of the other at the join - how should this be done to produce a satisfactory effect? see http://www.chaos.org.uk/~wookey/stacho/ >> Joining two scraps together covers only joining the walls - not the lines >> inside. They can be joined only by detail specification, you mentioned >> below. OK - I hadn't appreciated that - this is important if there are features in the passage at the joins. Is it a requirment that there must be no passage features at the join that could be misaligned? If a whole cave has rocks or sand on the floor this could be a problem. >>> >Also I tried to control the join in more detail by specifying that the ends >>> >of lines join but the syntax didn't work. What's wrong with this: >>> >join farsidewest:0@farside2.river farsidewest2:end@farside.river >>> >(farsidewest are farsidewest2 are 'wall' lines). > >> >> Nothing - it should work. If it does not - it's certainly a bug. Does >> therion generates an error or it simply does not join the lines? >> Did you >> tried this without :point specification (just farsidewest@farside2.river >> farsidewest2@farside.river)? This should work also. Therion generates an error. 'invalid object name', but some more research on the various options shows that I get: join farside@river farside2@river works OK (except that it joins one (the south) wall of farside2 to a nearby column (the nearest wall) which is just wrong. join farsidewest1@farside.river farsidewest2.farside2@river Gives 'survey farside.river does not exist' - which is right but I mean scrap farside within survey river - have I got the syntax wrong? join [fsceil1:0]@farside.river [farsidewest3:8]@farside2.river 'invalid object name' - but mnaybe this is the same problem as the line above The best reuslt is obtained with no 'join' at all but then the walls don't quite join up (which is odd because the scraps are drawn on a survex plot and thus acurately scaled - the walls should join up almost exactly anyway...) >>> >In the test editor, using above: data normal left right up down newline >>> >tape compass clino and >>> >then 'scan format' to get data table to have correct boxes is OK but when >>> >you enter data it appears as >>> >tape compass clino >>> >station left right up down >>> >which is the wrong order. > >> >> This is not a bug. OK. I'll think about that a bit more - it not important. >>> >When a created file is re-read every blank line gets a 'text' entry in the >>> >file commands section, and when saved ends up as 3 blank lines - whitespace >>> >text entries shouldn't appear. > >> >> I thought, I've removed all such bugs. But do not have this experience. Do >> you have a "text" item before each point, line? If yes, this has probably >> something to do EOLN characters. Do you have the same experience on each >> operating system? I only tried it on Linux. I just tried again loading the fale and saving, but making no changes with 0.2.18 and the problem did not recurr. Maybe I have to make changes - maybe it is fixed - I'll send you an example if I can reproduce it. The file has LF only throughout. >>> >If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm >>> >file) >>> >Is this expected? > >> >> 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA >> buffer = 40MB = 60% of RAM. This may be a problem, especially on some >> operating systems. OK. So there is a need for original scans to be quite small, or lower colour depth (I have to scan greyscale because my scanner/software does not work properly in b/w). Now I'll reduce the colour depth of all the images and maybe chop them up for therion editing, because zoom is important and it's _very_ slow to load. I also just bought 128MB more ram, which should help. Presumably the software could be made to manage larger images better (like photo-editing software can load file _much_ bigger than the available memory). a 4MB scan shouldn't be 'too large to zoom' - it will catch users out. Perhaps the zoom should only attemtp to zoom the visible part of the image, not the whole thing. That would be sensible use of resources. Is this a TCL feature that it will be hard to change? >> Tcl/Tk supports only these file types. But: >> >> Install Img plug-in into your Tcl installation. OK - I'll try and find it. It's not obviously part of Debian, but it may well be there somewhere. >>> >Shortcuts for moving things between scraps would be helpful, otherwise it's >>> >'move down' about 100 times. Is there a better way? > >> >> Right. No way right now. I'll think about it (adding a button move to >> scrap). And a key! there are nothing like enough keyboard shortcuts. Mice are nasty and give you RSI :-) >>> >It's very tedious if you need to change a number of entries - need >>> >shortcuts >>> >to move between boxes in RH-side or to scroll up and down items in the file >>> >summary. e.g if you need to change all the station ids to names. Need to be >>> >able to navigate file commands with keys. > >> >> We have in our minds building much more intuitive user interface, but... >> >> Anyway, you can use text editor and regular expressions find and replace... Except for the fact that you have to unload the map editor first otherwise it will overwrite them, and then you can't remember which objects to edit... And because it takes 2-3mins to load again I don't like unloading and loading it each time to make an edit. Smaller scans will help, as will more memory, but there does need to be a better way if drawing a survey is to take less than 100 years :-) >>> >graphical stuff >> Last thing: thanks a lot for your feedback. We'll think about it a lot... thanx for taking it all seriously. I think we are getting to something that is useful, but various things are still too difficult or too slow. I'll send you the article text so far by the way, so you can check I didn't say anything wrong. 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/ Subject: Re: Queries and comments on 0.2.17 From: "Martin Budaj" Date: Mon, 16 Feb 2004 09:29:16 +0100 To: therion@speleo.sk > I have put a picture of a screen shot of the scrap join and the resulting > PDF image online to illustrate how one scrap cuts off parts of the other at > the join - how should this be done to produce a satisfactory effect? You may use `-clip off' option for all objects which shouldn't be clipped by the scrap border. However, it would be best to choose places for scrap joins where the passage is as simple as possible -- this saves a lot of work on defining IDs and joins for each object lying on the scrap join line. > Therion generates an error. 'invalid object name', but some more research on > the various options shows that I get: > join farside@river farside2@river > works OK (except that it joins one (the south) wall of farside2 to a nearby > column (the nearest wall) which is just wrong. > join farsidewest1@farside.river farsidewest2.farside2@river > Gives 'survey farside.river does not exist' - which is right but I mean > scrap farside within survey river - have I got the syntax wrong? Scraps don't create own namespace -- only surveys do. So join farside@river farside2@river is a variant of join which joins two scraps, and join farsidewest1@farside.river farsidewest2.farside2@river should be join farsidewest1@river farsidewest2@river >> >If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm >file) >> >Is this expected? >> 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems. > > > OK. So there is a need for original scans to be quite small, or lower colour > depth (I have to scan greyscale because my scanner/software does not work > properly in b/w). Now I'll reduce the colour depth of all the images and > maybe chop them up for therion editing, because zoom is important and it's > _very_ slow to load. I also just bought 128MB more ram, which should help. I'm afraid TclTk uses RGB model internally, so it converts even b/w images into RGB anyway. I've been using XTherion on Athlon 2000 with 512 MB RAM. It works quite well and fast with more 100 dpi scans in one file (about 1000*500 pixels each) @ 200% zoom. > And because it takes 2-3mins to load again I don't like unloading and > loading it each time to make an edit. Smaller scans will help, as will more > memory, but there does need to be a better way if drawing a survey is to > take less than 100 years :-) We are fully aware of the fact, that XTherion and espacially TclTk language is not ideal. It would be nice to make a completely new interface (which may be devoloped parallel with therion and xtherion), but it would require a lot of help from other programmers, too. We've put some ideas on http://labyrinth.speleo.sk Martin Subject: Re: Queries and comments on 0.2.17 From: Stacho Mudrak Date: Thu, 19 Feb 2004 12:22:42 +0100 To: therion@speleo.sk > Presumably the software could be made to manage larger images better (like > photo-editing software can load file _much_ bigger than the available > memory). a 4MB scan shouldn't be 'too large to zoom' - it will catch users out. I'm afraid, reducing memory usage would increase the processor usage. The only way how to solve this problem is hardware update. We've been programming therion with 150MHz and 48MB RAM. But when we started to enter real data - we were forced to upgrade. Now it looks, that 2GHz and 512MB ram is OK for A4 scans at 100dpi. > Perhaps the zoom should only attemtp to zoom the visible part of the image, > not the whole thing. That would be sensible use of resources. Is this a TCL > feature that it will be hard to change? This would take too much effort... Handling bitmap images in TCL is very limited. Anyway, you can spit images by your self in Photoshop or Gimp and turn on/off selected pictures visibility (last check box in the [Background images]). We've done it this way and it helped us a lot. In the file menu, there is also option Open XP (Excluding pictures). This is also very usefull for debugging. > And a key! there are nothing like enough keyboard shortcuts. Mice are nasty > and give you RSI :-) Could you please write down all the key-bindings (with exact keys) you would like to have in xtherion. Than I can add them in the next release. S. Subject: Re: [therion] Queries and comments on 0.2.17 From: Stacho Mudrak Date: Mon, 23 Feb 2004 09:57:06 +0100 To: therion@speleo.sk > The QMs ('continuation point) come out really small on my survey. > Where do I control the size? > > Ticks are too close together on pitches. I've noticed (in the file soundriverpln.pdf), that you're using scale 1:200 even if it's really a huge cave (you've probably been mapping in 1:500 or even smaller scale). When exporting such a large caves, you should use the scale, you've been mapping in (1:500) or if you want to have bigger symbols in the 1:200 scale, specify -layout-base-scale 1 500 - than each symbol will be 2.5x bigger (including QM and pitch ticks). Another point - in the layout: scale and base-scale is specified like: scale 1 500 I believe, the number "1" is not needed there, and probably scales should be specified just by number 500 (I've never seen on any map scale 2:1000 or something like that). What do you think? > How do I change the default for contour lines to al have 'none' (no downside > tick mark)? I don't want to add -tick none on every contour - I want to set > a default. In the new version of therion, this will be default. So you can forget about this. I know changing default behaviour is not standard way, but in this case, I believe it will help. Regards, S. Subject: Re: Queries and comments on 0.2.17 From: Wookey Date: Mon, 23 Feb 2004 15:53:14 +0000 To: Therion List +++ Stacho Mudrak [04-02-23 09:57 +0100]: >> > >>> >The QMs ('continuation point) come out really small on my survey. >>> >Where do I control the size? >>> > >>> >Ticks are too close together on pitches. > >> >> I've noticed (in the file soundriverpln.pdf), that you're using scale 1:200 >> even if it's really a huge cave (you've probably been mapping in 1:500 or >> even smaller scale). When exporting such a large caves, you should use the >> scale, you've been mapping in (1:500) or if you want to have bigger symbols >> in the 1:200 scale, specify -layout-base-scale 1 500 - than each symbol >> will be 2.5x bigger (including QM and pitch ticks). OK - yes 1:200 must be a default? I normally use 1:500. For this system 1:1000 or 1:2000 will be appropriate. Well spotted. >> Another point - in the layout: scale and base-scale is specified like: >> >> scale 1 500 >> >> I believe, the number "1" is not needed there, and probably scales should >> be specified just by number 500 (I've never seen on any map scale 2:1000 or >> something like that). What do you think? I have never seen 2: either, so I suppose you are right, but "scale 1 500" is perhaps more obvious than "scale 500" to a surveyor so maybe just leave it even though it is not very satisfactory from a computer-science point of view? I am not sure. >>> >How do I change the default for contour lines to al have 'none' (no >>> >downside >>> >tick mark)? I don't want to add -tick none on every contour - I want to set >>> >a default. > >> >> In the new version of therion, this will be default. So you can forget >> about this. I know changing default behaviour is not standard way, but in >> this case, I believe it will help. Except now people who _do_ want a tick on every contour will need to add -tick each time. This doesn't really address the problem of setting defaults for things like this. Does the UIS symbol set have ticks on contours? I know defaults should be set by specifying a symbol set, but that is going to be difficult for 'most users' who don't want to get into writing MetaPost. Once we have a wide choice of symbol sets than most people should be happy I suppose, but I think many surveyors like to have a few little 'artisitic differences' in their surveys and not always use _all_ the standard symbols. Something to think about. 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/ Subject: [therion] Re: Queries and comments on 0.2.17 From: Martin Sluka Date: Mon, 23 Feb 2004 18:38:50 +0100 To: therion@speleo.sk At 15:53 +0000 23.2.2004, Wookey wrote: ******************************************* > I have never seen 2: either An old Austrio-Hungarian map - something as 2 inches to 1 mile. :) Martin -- Subject: Re: [therion] Re: Queries and comments on 0.2.17 From: Stacho Mudrak Date: Tue, 24 Feb 2004 08:26:11 +0100 To: therion@speleo.sk > OK - yes 1:200 must be a default? I normally use 1:500. For this system > 1:1000 or 1:2000 will be appropriate. Well spotted. Well, we're surveying caves where passage is in average 2m width, so we've set up this scale as default. Anyway, I'll think how to set up default layout (including symbols and all other stuff) in therion.ini. This should be the solution I believe. > Except now people who _do_ want a tick on every contour will need to add > -tick each time. This doesn't really address the problem of setting defaults > for things like this. Does the UIS symbol set have ticks on contours? > > I know defaults should be set by specifying a symbol set, but that is going > to be difficult for 'most users' who don't want to get into writing > MetaPost. Once we have a wide choice of symbol > sets than most people should be happy I suppose, but I think many surveyors > like to have a few little 'artisitic differences' in their surveys and not > always use _all_ the standard symbols. Something to think about. Yes, you're right. Martin also pointed me this problem, so we've left behaviour on the macro. Now it decides, whether to put tick or not, if no user wish is present. Now two macros exists: l_contour_SKBB (with tick by default) and l_contour_UIS (without tick by default). I think, we will be able to live for a while with this state. So if you will use -layout-symbol-set UIS, no contour ticks should be present (I believe, this afternoon we will put on the server new developement release). S. Subject: Re: Queries and comments on 0.2.17 From: Stacho Mudrak Date: Mon, 01 Mar 2004 10:38:18 +0100 To: therion@speleo.sk > bugs: > > In .th files - if you use > data normal ignore ignore ignore ignore newline tape compass clino then > every LRUD line must be followed by a data line, including the last one > If you s/ignore ignore ignore ignore/left right up down/ then it ignores > absence of TCC part in the last line, but not in lines in the middle of a run. > This is inconsistnet with survex behaviour (which will let you give LRUD > info for a station and then stop - without subsequent TCC info) I've started work on 3D on weekend, and I do not understand what you've written. I've tried centreline data normal station up down left right newline compass clino tape 0 2 3 4 5 100 -10 10 1 1 2 3 4 endcentreline and it works (in therion). Probably, I've not understood what is inconsistent behaviour. Could you please send me some examples? I would be also interested in, how should "data dimenstions" work. Regards, S. Subject: 0.2.18 From: Stacho Mudrak Date: Thu, 12 Feb 2004 15:49:14 +0100 To: therion@speleo.sk On the server, you can find new release of therion. We've made huge improvements especially in automatical map header generation, SQL export (very usefull for finding info about cave you want) and a lot of new map layout features is present. Everything is documented in thbook. There is one thing missing: if you have Img Tcl/Tk plug-in installed, also jpeg and png images are supported in x-therion. Now we will focus on removing bugs and generating random passage fills (debris, sand, etc...) ThTeam. Subject: Re: 0.2.18 From: Wookey Date: Fri, 13 Feb 2004 15:55:52 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-02-12 15:49 +0100]: >> On the server, you can find new release of therion. We've made huge >> improvements especially in automatical map header generation, SQL export >> (very usefull for finding info about cave you want) and a lot of new map >> layout features is present. Everything is documented in thbook. OK, Debianised and uploaded. This one was nice and easy :-) 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/ Subject: feedback on 0.2.18 From: Wookey Date: Fri, 27 Feb 2004 10:20:43 +0000 To: Therion List Here's another batch of Therion feedback from my continuing efforts. I debianized and compiled 0.2.200400224 (is there any reason for not just calling this 0.2.19? - this is the 3rd decimal version number so it might as well go up with each new version you put out) My mulu dataset which worked OK with 0.2.18 gives: therion: warning -- thconfig [7] -- no selected projection data -- plan The jsv test dataset works OK. Downgrading to 0.2.18 also still works, so something is amiss. Copy of thconfig, soundriver.th and soundriver.th2 attached. version 0.2.18 thbook says -clip but it's -clip like most other options - confusing - I tried 0, false before getting it right. Make the docs consistent. search for 'area' finds them in the File Commands box but there is no clue where it is on screen. Highlighting the associated paths would be really good. Finding lines instead of points is tricky - you can click on point, but not line. Especially with big rocks that have a lot of lines, it's hard to know that you have the right line. Highlighting the point at the other end of the line too or something would be good if not the line itself. In the File Commands box there is an underlined entry you can move with the cursor keys and a highlighted entry (the thing currently highlighted on screen) which you can only move with the mouse. WHy do both these things exist? It'd be more useful to be able to move the highlighed entry with the cursor keys, so that you can step through items and _see_ what they refer to. What is the intended use of Rock-edge and rock border? Can you explain what base-scale actually does and how scale interacts - I don't feel I understand properly from reading the thbook. You may have answered this from looking at the article... I still can't get join [id:pt]@survey style to work: I get 'invalid object' join [fsceil1:0]@river [farsidewest3:8]@river. commented out in attached .th file. In the legend 'Topo' is not english - need to be able to change that text. We have 'surveyed', 'explored' and 'drawn' normally. Also 'pit' is 'pitch' in UK english - only American's call them pits. Indeed UK and US caving english are quite different, if Therion takes account of translations - that's why survex has en-gb and en-us translations. How do I deal with this situation: a wall round a corner and a pitch edge goes across the corner; I want to area fill up to the pitch edge? In the attached files this is sbr3(pitch edge), farsidewest2(wall) etc. The problem is that when describing the paths comprising the area you want to go wall, pitch, wall, but the wall has only one ID, so I put area sand sbr1 farsidewest3 sbr2 farsidewest2 sbr3 farsidewest2 endarea in the area coomand, but the sbr3 is ignored and the fill goes right up to the wall. do I have to split the wall into two paths or can the area command be made smart enough to do what is intended here? Is there an easy way of splitting lines without re-drawing? Needed for various situations, the above being just one example. At the moment I am deleting and re-drawing things when I want to split them, which is a pain. encoding utf-8 select evening.soundriver source soundriver.th export model -fmt survex export map -proj plan -layout-base-scale 1 500 -o soundriverpln.pdf # or to use full layout below # export map -proj plan -layout elevator -o soundriverpln.pdf # export atlas -proj plan -o soundriveratlas.pdf layout elevator base-scale 1 500 doc-author "Wookey" endlayout encoding utf-8 survey soundriver map elevator -title "Terikan: Elevator Entrance" farside@river farside2@river endmap #connections # join farside@river farside2@river join farsidewest1@river farsidewest2@river # join [fsceil1:0]@river [farsidewest3:8]@river centerline equate 17@evening 53@river equate 24@evening 1@river #*equate 4@river2 6@evening ; was it stn 6 cairn? closure suggests not equate 1@rifticious 2@evening equate 5@rifticious 12@evening equate 1@pooh 50@river equate 22@rifticious 1@rifticious2 equate 10@penthouse 27@river endcenterline survey evening -title "Top of the Evening" centerline #export 25 2 12 17 24 date 2003.02.02 team "Wookey" notes team "Andy Eavis" clino compass tape #CUCC set #2, Fisco ranger tape? #surveying in, looking in 2 1 18.15 191 -03 3 2 30.00 140 -01 4 3 17.25 179 -01 5 4 21.25 215 +01 6 5 28.1 271 +01 7 6 30.0 305 +10 8 7 30 286 -03 9 8 30.00 290 -12 10 9 16.2 298 -07 9 11 1.4 - down 12 10 30 321 +01 13 12 23.95 214 -17 14 13 17.8 194 -25 15 14 28.0 216 -10 16 15 22.0 195 +11 16 17 15.4 140 +36 18 17 23.0 203 +25 19 18 21.9 230 +27 20 19 30 241 +04 21 20 27.35 251 -08 22 21 13.0 213 +12 23 22 13.5 242 +02 24 23 30 204 -02 1 25 9.0 230 +08 #2 4 6 ~20 2 ; cairn (Andy's Head) #1 2(12) 5 10(17) 0.6 ; Nester's cairn (actual) #3 1 4 10 1.7 ; AH/WH #4 1 6 10+ 1.7 ; Head - rock on floor #5 7 4/20+ - 1.7 ; AH - arrow on floor #6 1(~9) 12 36 1.7 ;Kneeling over cairn (up with disto) #7 ~20 3 ~25 1.7 ; AH, cairn #8 15 10 25 2 ; AH #25 3(15) 7 8(18) 2 ; WH over cairn - last station on previous survey (escalator.pt3)(looking in) #9 9 12 8 2 ; WH above cairn, note #10 1 10 ~10 3 ; AH on rock #11 as 9 0.3 ; cairn, note #12 14 14 - - ; AH, cairn, note #13 ~20 ~20 ~8 - ; #14 10 9 7 1.5 #15 ~20 ~20 ~20 2 ;AH #16 - - - - #17 lots 10 ~30 3.5 ; big cairn, top of passage '17' in pencil #18 10 15 ~30 2 ; AH #19 9 ~23 8 2 ;AH #20 12 8 13 2 ;AH, cairn, note #21 ~16 2 5 4 ; AH on stal bridge #22 12 3 6 1.7 ; AH #23 15? 4 3 2 ;AH #24 4 15 8 2.5 ;AH endcenterline endsurvey evening survey river input soundriver.th2 centerline #export 1 27 40 43 50 53 title "River of Sound" date 2003.02.03 team Wookey notes team "Robbie Shone" clino compass team "James Alker" tape #CUCC insts set #2 1 2 30.00 047 00 2 3 28.25 318 -13 2 4 21.60 020 -13 2 5 19.0 112 +04 5 6 25.6 038 -03 4 7 1.1 335 00 7 8 5.4 - down 8 9 30.0 082 -01 9 10 15.2 093 +02 10 11 28.7 085 -01 11 12 30.0 021 +01 12 13 22.8 050 +06 13 14 15.9 064 -12 14 15 18.7 139 +04 15 16 30.0 135 +08 16 17 30.0 037 +02 17 18 15.6 103 +16 18 19 24.0 170 -22 # clino surveyed on later trip! 19 20 30.0 071 +01 20 21 28.6 038 +09 21 22 17.1 351 +17 22 23 7.2 - down 23 24 28.0 314 -05 24 25 30.0 019 +03 25 26 30.0 037 -01 26 27 30.0 062 00 27 28 30.0 039 +01 28 29 30.0 029 -01 29 30 30.0 042 +04 30 31 30.0 023 -03 31 32 14.3 028 +08 32 33 9.1 320 -18 33 34 30.0 268 -18 34 35 16.5 258 00 35 36 15.0 242 -12 36 37 11.0 267 -02 37 38 11.3 320 +22 38 39 6.4 336 +04 33 41 25.5 033 -02 41 42 28.3 081.5 -15 32 43a 20.2 055 +01 31 44 28.0 092 +10 39 40 23.1 345 +03 42 43 11.3 110 +02 3 45 30.0 303 -06 45 46 30.0 231 -02 46 47 30.0 214 00 47 48 30.0 219 00 48 49 18.0 228 -01 49 50 30.0 255 -03 50 51 30.0 172 +17 # was -17 in notes - can't be right 51 52 27.3 165 +29 52 53 19.2 158 +28 #1 - - - - Stn 24 of last survey. Head on cairn #2 5 ~8 ~6 1.8 ; head #3 8 ~20 6 2 ; stal (S corner) #4 10 ? 3 2 ; head by stal column #5 ? 15 3 1.7 ; head #6 - - ~8 0.8 ; tip of stal at prow #7 - - - - ; Over drop #8 8 1 ~8 1.7 ; top of drop #9 3.5 7(~40) ~20 2 ; head #10 5 6 15+ 2 ; edge of 4m drop, head #11 10 (2)8 20 2 ; head #12 ~10 2 - - ; head #13 10 5(12) 20+ 1.5 ; head #14 6(12) 6(12) ~15 2 ; head #15 - - - - ; head #16 40 9 20 8 ; head #20 8(25+) 0 6(15+) 1.8 ; head #21 - 8 - - #19 - 0 - 1.8 #24 2 5 5(7) 1.8 #23 1 6 ~12 1.5 #25 6 3 30+ 1.7 #26 3 7(30+) 9(+) 1.7 #27 2 10 9 2 #28 1(7) 5 7 4 #29 9 1(6) 15 4 #30 ~15 2 ~30 2(10?) ; head #31 4 10 6 2 ; head #32 - 4 - 2 ; head #33 - - 0.4 ~10 ; tip of boulder '33' #34 5 8 - 1 ; sitting head #35 5 2 3 1(5) ; sitting head #36 6 1 1 1 ; sitting head #37 2 8 1(5) 0.5 ; sitting head '37' written in mud #38 5 1 7 3 ; head #39 5 3 6 1 ; sitting head, note #40 7 1 2 1 ; sitting head, note #43 ? 6 2.5 2 ; sitting head, note #41 10 ? - - ; sitting head #42 2 3 1 1.5 ; 0.4 above cairn #43 6 5.5 2 1 ; point of rock #44 8 8 2 1 ; cairn on boulders (actual) #45 20 0 10 4 ; head #46 5 5 9 1.8 ; head #47 4 4 10 1.8 ; head #48 5 8 10 1.8 ; head #49 1(8) 4(10) 10 1.8 ; head #50 6 5 8 2 ; head #51 8 8 lots 2 ; head #52 15 15 - - ; head #53 ; cairn '17' on top endcenterline endsurvey river survey rifticious centerline #export 1 5 22 date 2003.02.03 team "Wookey" notes team "Robbie Shone" clino compass team "Colin Boothroyd" tape #CUCC set #2, Fisco ranger tape? #surveying in, looking in # RH side of passage 1 2 18.7 021 +01 2 3 24.0 022 +01 3 4 16.8 350 00 #1 3 4 ~12 2.5 ; =stn 2, wook & Andy stn 3, 2003-02-02 #2 3.5 6 +10 2 #3 6 2(+4) ~25 3 #4 ; stn 6 of above survey # SW trending lead from lower corner of Top of the Evening 5 6 30.0 217 -11 6 7 30 190.5 00 7 8 10.5 194.5 +12 8 9 15.9 217 -24 9 10 8.0 182 +07 10 11 7.7 170 +18 11 12 5.5 126 +12 12 13 14.8 224 -06 13 14 18.0 191 -01 14 15 13.7 195 00 15 16 2.000 119 -19 16 17 10.6 210.5 +08 17 18 22.20 205.5 00 18 19 13.70 201 00 19 20 15.00 221 -28 20 21 9.10 268 -46 21 22 6.50 293 -53 19 23 13.2 100 +55 23 24 7.20 184 +31 24 25 7.70 062 +55 25 26 8 060 +26 # grade3 #LRUD to come endcenterline endsurvey rifticious survey pooh centerline #export 1 date 2003.02.03 team "Wookey" tape #and dog team "Robbie Shone" clino compass team "Colin Boothroyd" notes pictures # same day as rifticious survey #CUCC set #2, Fisco ranger tape? data normal station left right up down newline tape compass clino 1 - - - - # stn 50 of 2003-02-03 survey 17.4 241 -05 2 2.5 6 0+8 1 19.08 253.5 -18 # could be 233.5? 3 5 3 4 1.2 7.18 238 -15 4 0 5 3.5 1.5 17.94 000 +20 5 4 3 8 2 8.72 251 -28 6 0.5 2 3 1 21.26 353 +09 7 1 2.5 4 1.6 11.50 033 +07 8 2 4 8 1 10.13 080 +01 9 3.5 2 1 2.5 14.49 021.5 -06 10 3.5 1.5 1.8 1.5 # cairn endcenterline endsurvey pooh survey rifticious2 centerline #export 1 3 #pitch connection between rifticious and menagerie - done on following day date 2003.02.06 team "James Alker" dog team "Robbie shone" notes insts tape 1 2 10.6 292 -44 # 0.6 length in notes - lost '1'? 2 3 15.4 - down # measured rope length endcenterline endsurvey rifticious2 survey penthouse centerline #export 10 date 2003.02.06 team "James Alker" notes tape team "Robbie shone" clino compass #Entrance on shelf before narrowing on way to farside data normal station left right up down newline tape compass clino #CUCC insts 2 2 8 8 6 2 30 046 +9 1 6 4 4 2 0 0 0 # faked data to make therion happy 2 - - - - 30 223 -2 3 8 7 6 2 30 220 0 4 4 20 5 2 28.6 239 -1 5 5 0 3 0.5 9.8 278 -12 6 4 2 5 0.5 20.2 204 +1 7 2 40 5 2 23.0 300 -7 8 20 20 10 2 18.6 0 -25 9 2 40 15 1 # on a stal 5.3 54 -12 10 2 10 15 2 # entrance # entrance 1 # entrance 10 endcenterline endsurvey penthouse endsurvey encoding utf-8 ##XTHERION## xth_me_area_adjust -128 -1247 1800 1328 ##XTHERION## xth_me_area_zoom_to 200 ##XTHERION## xth_me_image_insert {0 1 1.0} 1200 soundriver1pln.pnm 0 {} scrap farside2 -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] line wall -id wall1 51.0 244.0 51.0 244.0 64.55 227.73 78.0 206.0 91.0 185.0 97.0 179.0 97.0 179.0 smooth off 107.0 167.0 107.0 167.0 109.0 159.0 117.0 144.0 125.0 129.0 133.0 111.0 133.0 111.0 smooth off endline point 1013.0 -911.0 station -name 25 #point 983.0 -677.0 station -name 26 #point 1055.0 -455.0 station -name 27 #point 1035.0 -220.0 station -name 28 #point 970.0 9.0 station -name 29 #point 961.0 244.0 station -name 30 point 618.0 413.0 station -name 34 point 546.0 303.0 station -name 35 point 511.0 195.0 station -name 36 point 451.0 125.0 station -name 37 point 360.0 136.0 station -name 38 point 317.0 153.0 station -name 39 point 158.0 244.0 station -name 40 point 165.0 151.0 debris point 131.0 161.0 debris point 139.0 141.0 debris point 181.0 160.0 debris point 169.0 181.0 debris point 159.0 159.0 debris point 243.0 212.0 air-draught -orientation 300.9 point 646.0 505.0 air-draught -orientation 205.7 point 661.0 353.0 air-draught -orientation 210.6 point 474.0 66.0 continuation point 332.0 -61.0 continuation point 243.0 270.0 continuation point 179.0 107.0 continuation point 68.0 279.0 continuation point 105.0 229.0 air-draught -orientation 321.7 line wall -close on 397.0 89.0 393.0 100.0 393.0 100.0 409.0 121.0 413.0 123.0 417.0 125.0 421.0 130.0 423.0 120.0 smooth off 419.0 109.0 397.0 89.0 397.0 89.0 smooth off endline line wall 358.0 -42.0 374.0 -18.0 402.0 34.0 400.0 65.0 smooth off 420.0 75.0 412.0 96.0 439.0 104.0 smooth off 450.0 92.0 453.0 85.0 459.0 72.0 smooth off endline line border -id sbr1 -subtype invisible 652.0 386.0 652.0 386.0 671.0 498.0 626.0 554.0 smooth off endline point 595.0 302.0 debris point 674.0 504.0 debris line wall -id farsidewest3 471.0 83.0 454.0 116.0 454.0 116.0 465.0 106.0 483.0 110.0 501.0 114.0 534.0 136.0 542.0 164.0 550.0 192.0 539.0 237.0 549.0 252.0 559.0 267.0 589.0 284.0 599.0 295.0 625.17 323.78 639.0 366.0 652.0 386.0 660.99 399.83 741.0 478.0 741.0 478.0 smooth off 746.0 452.0 742.63 391.23 849.0 427.0 smooth off endline #Rocks inside wall1, wall2, rb1, rb2 area debris wall1 rb1 wall2 rb2 endarea line rock-border -id rb2 175.0 199.0 107.0 167.0 endline line rock-border -id rb1 133.0 111.0 202.0 151.0 endline line wall -id wall2 202.0 151.0 175.0 199.0 175.0 199.0 185.0 211.0 201.0 206.0 217.0 201.0 285.0 148.0 291.0 142.0 297.0 136.0 327.0 107.0 333.0 83.0 339.0 59.0 343.0 28.0 317.0 -27.0 smooth off endline line pit -id sbr2 536.0 312.0 558.0 285.0 563.0 266.0 endline area sand sbr1 farsidewest3 sbr2 farsidewest2 sbr3 farsidewest2 endarea line wall -id farsidewest2 359.0 142.0 359.0 142.0 375.0 176.0 383.0 183.0 391.0 190.0 390.0 180.0 398.0 188.0 406.0 196.0 445.84 222.97 447.0 216.0 448.0 210.0 473.0 203.0 473.0 189.0 473.0 175.0 461.0 154.0 461.0 154.0 smooth off 461.0 154.0 484.0 161.0 495.0 176.0 506.0 191.0 509.0 221.0 509.0 234.0 509.0 247.0 505.0 280.0 510.0 303.0 515.0 326.0 543.0 306.0 536.0 312.0 529.0 318.0 562.0 346.0 568.0 358.0 574.0 370.0 584.0 396.0 577.0 399.0 570.0 402.0 537.0 371.0 531.0 378.0 525.0 385.0 533.0 389.0 533.0 389.0 smooth off 533.0 389.0 573.0 460.0 583.0 461.0 593.0 462.0 601.0 449.0 601.0 449.0 smooth off 601.0 449.0 614.0 461.0 616.0 480.0 618.0 499.0 626.0 541.0 626.0 554.0 626.0 567.0 629.0 590.0 629.0 590.0 smooth off endline line wall 254.0 258.0 277.11 221.68 345.0 160.0 359.0 142.0 smooth off endline line wall 112.0 282.0 145.0 243.0 145.0 243.0 149.0 263.0 171.0 266.0 202.11 270.24 245.0 236.0 245.0 236.0 smooth off 245.0 236.0 239.0 247.0 237.0 254.0 smooth off endline line pit -id sbr3 560.0 388.0 558.0 397.0 549.0 405.0 541.0 405.0 smooth off endline line contour 480.0 119.0 480.0 119.0 505.0 125.0 520.0 143.0 535.0 161.0 535.0 165.0 537.0 181.0 539.0 197.0 538.0 220.0 539.0 233.0 540.0 246.0 546.7 266.32 552.0 271.0 555.23 273.85 560.0 280.5 558.0 285.0 smooth off endline line contour 475.0 127.0 475.0 127.0 512.0 151.0 518.0 159.0 524.0 167.0 529.0 172.0 531.0 182.0 533.0 192.0 533.0 226.0 535.0 239.0 537.0 252.0 548.0 278.0 551.0 281.0 555.47 285.47 552.0 292.0 552.0 292.0 smooth off endline line arrow 735.0 515.0 712.0 517.0 endline line arrow 728.0 477.0 698.0 481.0 endline line contour -clip off 692.0 432.0 692.0 432.0 696.92 439.2 710.0 477.0 723.08 514.8 728.0 536.0 728.0 536.0 smooth off endline line pit -clip off 657.0 411.0 657.0 411.0 647.11 386.22 665.0 422.0 682.89 457.78 669.38 427.77 684.0 465.0 698.62 502.23 707.0 529.0 707.0 529.0 smooth off endline line pit 352.0 91.0 352.0 91.0 368.0 111.0 372.0 120.0 smooth off endline endscrap scrap farside -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] point 875.0 460.0 station -name 31 point 968.0 805.0 air-draught -orientation 230.6 point 844.0 567.0 station -name 32 point 775.0 574.0 station -name 33 point 873.0 726.0 station -name 43a point 948.0 977.0 station -name 43 point 867.0 942.0 station -name 42 point 736.0 770.0 station -name 41 point 1035.0 606.0 station -name 44 line wall 919.0 1102.0 987.0 995.0 endline line arrow 987.0 616.0 949.0 588.0 endline line arrow 1006.0 548.0 969.0 519.0 endline point 973.0 871.0 continuation point 898.0 1109.0 continuation line contour 1032.0 521.0 1032.0 521.0 1012.0 556.0 1007.0 581.0 1002.0 606.0 1001.0 615.0 999.0 624.0 997.0 633.0 996.0 643.0 998.0 654.0 smooth off endline line contour 995.0 484.0 995.0 484.0 964.0 565.0 964.0 593.0 964.0 621.0 967.0 630.0 967.0 630.0 smooth off endline line ceiling-step -id fsceil1 -clip off 741.0 478.0 741.0 478.0 750.0 533.0 769.0 579.0 788.0 625.0 802.0 630.0 817.0 635.0 smooth off endline line contour -reverse on -clip off 868.0 587.0 868.0 587.0 848.0 592.0 823.0 568.0 798.0 544.0 795.0 516.0 795.0 516.0 smooth off 795.0 516.0 773.0 521.0 743.0 490.0 smooth off endline line contour -reverse on -clip off 869.0 579.0 869.0 579.0 844.0 563.0 833.0 550.0 822.0 537.0 807.0 504.0 807.0 504.0 smooth off 807.0 504.0 788.5 504.5 745.5 474.5 smooth off endline line contour -id rbr5c 969.0 448.0 969.0 448.0 945.0 494.0 943.0 514.0 941.0 534.0 940.0 555.0 938.0 573.0 936.89 582.99 940.0 600.0 943.0 612.0 smooth off endline line wall -id rbr5b 1075.0 556.0 1075.0 556.0 1037.0 531.0 1001.0 490.0 965.0 449.0 960.0 437.0 955.0 426.0 smooth off endline line label -text choked 1149.0 645.0 1104.0 713.0 endline line wall -id rbr5a 1125.0 589.0 subtype presumed 1075.0 556.0 endline line wall -id rbr5e 1005.0 656.0 subtype presumed 1072.0 704.0 endline point 817.0 583.0 debris point 863.0 609.0 debris point 836.0 616.0 debris point 814.0 610.0 debris area debris rbr5a rbr5b rbr5c rbr5d rbr5e rbr5f endarea line border -id rbr5f 1028.0 673.0 1028.0 673.0 1050.0 601.0 1092.0 565.0 smooth off endline line wall -id rbr5d 936.0 740.0 936.0 740.0 914.0 717.0 893.0 667.0 872.0 617.0 864.0 584.0 869.0 579.0 883.3 564.7 948.0 613.0 1005.0 656.0 smooth off endline line wall 975.0 782.0 subtype presumed 936.0 740.0 endline line border -id blockage1 -close on -subtype invisible 987.0 995.0 957.0 966.0 934.0 928.0 940.0 917.0 968.0 938.0 983.0 959.0 1002.0 972.0 987.0 995.0 endline area debris -id blk1area -clip off blockage1 endarea point 728.0 688.0 debris point 731.0 702.0 debris point 711.0 698.0 debris point 703.0 709.0 debris point 683.0 701.0 debris point 682.0 679.0 debris point 682.0 629.0 debris point 673.0 659.0 debris point 722.0 801.0 debris point 676.0 735.0 debris line pit 727.0 737.0 727.0 737.0 702.0 726.0 665.0 720.0 smooth off endline line pit 741.0 845.0 741.0 845.0 726.0 823.0 750.0 803.0 smooth off endline line rock-edge 797.0 825.0 801.0 836.0 811.0 839.0 endline line rock-edge 831.0 842.0 812.0 832.0 811.0 844.0 829.0 849.0 endline line rock-edge -close on 842.0 843.0 836.0 854.0 829.0 849.0 831.0 842.0 842.0 843.0 endline line rock-edge -close on 853.0 868.0 846.0 871.0 837.0 865.0 844.0 850.0 860.0 859.0 853.0 868.0 endline line rock-edge 871.0 871.0 870.0 858.0 860.0 859.0 853.0 868.0 866.0 881.0 endline line rock-edge -reverse on 871.0 905.0 880.0 892.0 876.0 886.0 866.0 881.0 871.0 871.0 884.0 877.0 880.0 892.0 endline line wall -reverse on -subtype blocks 886.0 927.0 871.0 905.0 endline line wall -reverse on -subtype blocks 924.0 941.0 924.0 941.0 922.0 949.0 913.0 950.0 904.0 951.0 895.0 942.0 895.0 942.0 smooth off 886.0 940.0 886.0 927.0 endline line wall 940.0 917.0 subtype presumed 924.0 941.0 endline line wall 987.0 995.0 subtype presumed 1011.0 958.0 endline line wall -id farsidewest1 629.0 590.0 632.0 624.0 636.0 655.0 642.0 723.0 642.0 723.0 651.0 772.0 663.0 791.0 671.44 804.37 705.0 826.0 705.0 826.0 smooth off 720.0 833.0 739.0 857.0 748.0 862.0 753.0 870.0 762.0 871.0 769.0 874.0 773.0 881.0 782.0 881.0 782.0 881.0 790.0 885.0 793.0 890.0 796.0 895.0 800.62 903.69 806.0 906.0 813.0 909.0 820.0 912.0 820.0 912.0 smooth off 828.0 915.0 875.0 976.0 875.0 976.0 smooth off 874.0 987.0 874.0 987.0 900.0 1017.0 897.0 1029.0 894.0 1041.0 880.0 1071.0 880.0 1071.0 smooth off endline line rock-edge -close on 830.0 818.0 812.0 832.0 781.0 818.0 791.0 792.0 818.0 805.0 830.0 818.0 endline line rock-edge 752.0 781.0 732.0 791.0 722.0 754.0 742.0 750.0 endline line rock-edge -close on 787.0 768.0 758.0 788.0 752.0 781.0 752.0 781.0 752.0 770.0 750.0 763.0 748.0 756.0 742.0 750.0 742.0 750.0 smooth off 751.0 724.0 751.0 724.0 764.0 717.0 764.0 723.0 764.0 729.0 767.0 731.0 774.0 731.0 781.0 731.0 774.0 744.0 774.0 744.0 smooth off 787.0 768.0 endline line rock-edge -close on 689.0 669.0 689.0 669.0 688.0 702.0 694.0 703.0 700.0 704.0 708.0 678.0 708.0 678.0 smooth off 689.0 669.0 endline line rock-edge -clip off 687.0 613.0 660.0 538.0 671.0 530.0 endline line rock-edge -clip off 671.0 530.0 694.0 536.0 endline line rock-edge -clip off 660.0 538.0 669.0 544.0 endline line rock-edge -close on -clip off 687.0 613.0 687.0 613.0 701.0 621.0 708.0 614.0 715.0 607.0 716.0 596.0 713.0 589.0 710.0 582.0 694.0 536.0 694.0 536.0 smooth off 669.0 544.0 687.0 613.0 endline line rock-edge -close on 851.0 555.0 867.0 546.0 869.0 561.0 857.0 564.0 851.0 555.0 endline point 901.0 465.0 debris line arrow endline line wall -close on 924.0 475.0 931.0 481.0 936.0 473.0 930.0 468.0 924.0 463.0 917.0 469.0 924.0 475.0 endline line wall -close on 909.0 501.0 909.0 501.0 902.0 504.0 898.0 501.0 894.0 498.0 889.0 496.0 894.0 492.0 899.0 488.0 909.0 501.0 909.0 501.0 smooth off endline area debris rbr3 rbr5d endarea line border -id rbr3 -subtype invisible 936.0 740.0 914.0 816.0 860.0 859.0 830.0 818.0 787.0 761.0 788.0 726.0 773.0 705.0 754.0 704.0 695.0 502.0 718.0 492.0 788.0 571.0 769.0 594.0 777.0 623.0 809.0 643.0 883.5 637.5 endline #rb3 and nearby wall surrounds rocky area area debris rbr3 rbr5d endarea line pit 897.0 1029.0 905.0 1020.0 905.0 1020.0 910.0 990.0 921.0 987.0 932.0 984.0 948.0 989.0 949.0 994.0 950.0 999.0 943.0 1010.0 941.0 1023.0 939.0 1036.0 947.0 1057.0 937.0 1073.0 smooth off endline line pit 880.0 1071.0 880.0 1071.0 878.0 1057.0 908.0 1066.0 938.0 1075.0 933.0 1086.0 933.0 1086.0 smooth off endline endscrap Subject: Re: feedback on 0.2.18 From: "Martin Budaj" Date: Fri, 27 Feb 2004 15:37:56 +0100 To: therion@speleo.sk > I debianized and compiled 0.2.200400224 (is there any reason for not just > calling this 0.2.19? - this is the 3rd decimal version number so it might > as well go up with each new version you put out) Sometimes there is a new version each day -- this is only something like CVS depository with up-to-date sources for developers. Numbered versions should have CHANGES and other documentation updated. > thbook says -clip but it's -clip like most other options - > confusing - I tried 0, false before getting it right. Make the docs > consistent. Will be fixed > What is the intended use of Rock-edge and rock border? rock-border is the outer border, rock-edge marks edges inside a large block (is usually omited in smaller blocks) > Can you explain what base-scale actually does and how scale interacts - I > don't feel I understand properly from reading the thbook. You may have > answered this from looking at the article... scale is the output scale. If you specify also base-scale, it has the effect as if you did the following steps: * print a map in base-scale * go to a copy shop and say 'I want a copy of this in the scale' both maps are finally in scale but with different line widths and symbol sizes. > I still can't get join [id:pt]@survey style to work: I get 'invalid object' > join [fsceil1:0]@river [farsidewest3:8]@river. commented out in attached > .th file. omit the brackets. Unfortunately therionbook is misleading in this point. > In the legend 'Topo' is not english - need to be able to change that text. > We have 'surveyed', 'explored' and 'drawn' normally. Would it be correct to say Surveyed: A.B., C.D. Drawn: X.Y. ? > Also 'pit' is 'pitch' in UK english - only American's call them pits. Indeed > UK and US caving english are quite different, if Therion takes account of > translations - that's why survex has en-gb and en-us translations. well, it is possible to use en-us and en-uk subtypes, but only for texts in the output files. > Is there an easy way of splitting lines without re-drawing? Needed for > various situations, the above being just one example. At the moment I am > deleting and re-drawing things when I want to split them, which is a pain. select a point where the line should be splitted; than Line control->Edit line->Split line Martin Subject: Re: [therion] feedback on 0.2.18 From: Stacho Mudrak Date: Fri, 27 Feb 2004 16:39:39 +0100 To: therion@speleo.sk >> My mulu dataset which worked OK with 0.2.18 gives: >> therion: warning -- thconfig [7] -- no selected projection data -- plan We've changed the behaviour of "select" command. If there is select only maps from survey are exported. This is very useful if you have huge datasets. So look for the select command select evening.soundriver in your thconfig file. You've selected survey for export, where no maps are given. You have to change it to "select soundriver", or use another select: select elevator@soundriver or remove all selects at all. >> search for 'area' finds them in the File Commands box but there is no clue >> where it is on screen. Highlighting the associated paths would be really >> good. You've probably not noticed "Show" button in the area control :))) >> Finding lines instead of points is tricky - you can click on point, but not >> line. Especially with big rocks that have a lot of lines, it's hard to know >> that you have the right line. Highlighting the point at the other end of the >> line too or something would be good if not the line itself. OK. >> In the File Commands box there is an underlined entry you can move with the >> cursor keys and a highlighted entry (the thing currently highlighted on >> screen) which you can only move with the mouse. >> >> WHy do both these things exist? It'd be more useful to be able to move the >> highlighed entry with the cursor keys, so that you can step through items >> and _see_ what they refer to. This behaviour I "can not" change (I was also wondering). This is because of BWidgets. You have to move "underlined cursor" to desired position and press "Space". I'll look at it. >> What is the intended use of Rock-edge and rock border? >> rock-border is the outer border, rock-edge marks edges inside a large block >> (is usually omited in smaller blocks) ... and in the new version, if the rock border will be closed-line - it will be filled with background color and overlap all items below. Like this, you'll be able to draw rocks on some area (sand, debris, water) also. >> Also 'pit' is 'pitch' in UK english - only American's call them pits. Indeed >> UK and US caving english are quite different, if Therion takes account of >> translations - that's why survex has en-gb and en-us translations. OK, I've added it into output en_UK translation (to the legend). It would be also very easy to add it into input parsing table, but I'm not sure, whether it makes sense (a lot of equivalents can lead to chaos). You have to decide (at least, we support centreline/centerline so I think pitch/pit could be also supported, because pitch is quite important. But I'm not sure about popcorn (cauliflowercalcite in UIS signatures :)) or other items like that... Hope this helps, S. Subject: Re: feedback on 0.2.18 From: Wookey Date: Fri, 27 Feb 2004 15:49:48 +0000 To: therion@speleo.sk +++ Martin Budaj [04-02-27 15:37 +0100]: >>> >What is the intended use of Rock-edge and rock border? > >> >> rock-border is the outer border, rock-edge marks edges inside a large block >> (is usually omited in smaller blocks) The outer border of an individual large rock? (as opposed to the border of an area of rocks, or a rocky wall (that is wall -subtype blocks, right?) >>> >Can you explain what base-scale actually does and how scale interacts - I >>> >don't feel I understand properly from reading the thbook. You may have >>> >answered this from looking at the article... > >> >> scale is the output scale. If you specify also base-scale, it has the >> effect as if you did the following steps: >> >> * print a map in base-scale >> * go to a copy shop and say 'I want a copy of this in the scale' OK - I suggest you put it like that in the thbook - it is easy to understand when put like that. >>> >I still can't get join [id:pt]@survey style to work: I get 'invalid object' >>> > join [fsceil1:0]@river [farsidewest3:8]@river. commented out in attached >>> >.th file. > >> >> omit the brackets. Unfortunately therionbook is misleading in this point. I tried it without the brackets too: it says 'line mark not a keyword -- fsceil1:0@river' >>> >In the legend 'Topo' is not english - need to be able to change that text. >>> >We have 'surveyed', 'explored' and 'drawn' normally. > >> >> Would it be correct to say >> Surveyed: A.B., C.D. >> Drawn: X.Y. ? Yes, or 'Surveyed by:...' 'Drawn by:...' - either is OK Actually I would use Surveyed: , Surveyed by: and Drawn: , Drawn by: 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/ Subject: [therion] Re: feedback on 0.2.18 From: Stacho Mudrak Date: Fri, 27 Feb 2004 17:23:59 +0100 To: therion@speleo.sk >> I tried it without the brackets too: it says 'line mark not a keyword -- >> fsceil1:0@river' Congratulations! This is a real BUG :))) Temporary - you can fixed it using: join fsceil1:0 farsidewest3:7 behind "survey river" command. I believe, I'll fix this bug over weekend. I have another question. I saw, that you're using "arrows" to show the gradient of the floor. Until now we have only "point gradient", that should be used like this. Probably, you would welcome also "line gradient". Because in fact "line arrow" serves (from our point of view) for showing the relation between labels (or sections) to the places in the passage. And there will be a symbol conflict, if you will use arrows and "point gradient" for the same thing. Regards, S. >> >> > >>>> > >In the legend 'Topo' is not english - need to be able to change that text. >>>> > >We have 'surveyed', 'explored' and 'drawn' normally. >> >>> > >>> > Would it be correct to say >>> > Surveyed: A.B., C.D. >>> > Drawn: X.Y. ? > >> >> Yes, or 'Surveyed by:...' 'Drawn by:...' - either is OK >> >> Actually I would use Surveyed: , Surveyed by: and >> Drawn: , Drawn by: >> >> Wookey Subject: Re: feedback on 0.2.18 From: Wookey Date: Fri, 27 Feb 2004 16:36:49 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-02-27 16:39 +0100]: >>> > My mulu dataset which worked OK with 0.2.18 gives: >>> > therion: warning -- thconfig [7] -- no selected projection data -- plan > >> >> We've changed the behaviour of "select" command. If there is OK, thanx >> >> You've probably not noticed "Show" button in the area control :))) Ah, yes - that's better, although it would still be good if an 'area' search 'pushed' this button automatically then it would seem like searching for other items (they highlight when found). >> This behaviour I "can not" change (I was also wondering). This is >> because of BWidgets. You have to move "underlined cursor" to desired >> position and press "Space". I'll look at it. ah - another useful key. Here's a thing for the wishlist - add a list of keys to the help menu - that would help users a lot as they are easy to forget. >>> > What is the intended use of Rock-edge and rock border? > >> > >>> > rock-border is the outer border, rock-edge marks edges inside a large block >>> > (is usually omited in smaller blocks) > >> >> ... and in the new version, if the rock border will be closed-line >> - it will be filled with background color and overlap all items below. >> Like this, you'll be able to draw rocks on some area (sand, debris, water) also. ahh - excellent. >>> > Also 'pit' is 'pitch' in UK english - only American's call them pits. Indeed >>> > UK and US caving english are quite different, if Therion takes account of >>> > translations - that's why survex has en-gb and en-us translations. > >> >> OK, I've added it into output en_UK translation (to the legend). It >> would be also very easy to add it into input parsing table, but I'm not >> sure, whether it makes sense (a lot of equivalents can lead to chaos). >> You have to decide (at least, we support centreline/centerline so I >> think pitch/pit could be also supported, because pitch is quite >> important. But I'm not sure about popcorn (cauliflowercalcite in UIS >> signatures :)) or other items like that... You are right that this is tricky. Normally it would be best to say 'the format is the format' and it's only in one language. However in this application a lot of the spelling and syntax is exposed to the user (entering options for example), so 'foreign' spellings are a problem (I remember once spending hours wondering why didn't work in my HTML - it has to be
, of course). Therion users are likley to have similar problems but I agree that trying to enter every translation into the syntax is a mistake. Some of the UIS names are a bit odd to any english speaker - they are 'swiss english' :-) Allowing alternatives for 'really common' items probably makes sense, but no more, and hiding things behind translatable widgets is also a good idea in this context. 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/ Subject: Re: feedback on 0.2.18 From: Wookey Date: Fri, 27 Feb 2004 16:41:34 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-02-27 17:23 +0100]: >> I have another question. >> >> I saw, that you're using "arrows" to show the gradient of the floor. yes. I got this from German surveyors. I thought that contours+gradient arrows was 'UIS' symbols, but maybe I am wrong? - this is why I didn't want contour ticks. >> Until now we have only "point gradient", that should be used like this. >> Probably, you would welcome also "line gradient". Yes. At some point I will try and do a BCRA symbol set, but I try to use approximately UIS symbols myself. >> Because in fact "line arrow" serves (from our point of view) for showing >> the relation between labels (or sections) to the places in the passage. >> And there will be a symbol conflict, if you will use arrows and "point >> gradient" for the same thing. understood. 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/ Subject: Re: [therion] Re: feedback on 0.2.18 From: John Pybus Date: Fri, 27 Feb 2004 16:59:24 +0000 To: therion@speleo.sk Stacho Mudrak wrote: > I have another question. > > I saw, that you're using "arrows" to show the gradient of the floor. > Until now we have only "point gradient", that should be used like this. > Probably, you would welcome also "line gradient". > Because in fact "line arrow" serves (from our point of view) for showing > the relation between labels (or sections) to the places in the passage. > And there will be a symbol conflict, if you will use arrows and "point > gradient" for the same thing. I would certainly appreciate this. I currently mark all the places I substitute similar symbols for the ones I really want with a comment so that I can easily go back and change them as functionality increases, or I find the time to look at defining the symbols I want. Yours, John Subject: Re: feedback on 0.2.18 From: Stacho Mudrak Date: Mon, 01 Mar 2004 10:26:33 +0100 To: therion@speleo.sk > > >I still can't get join [id:pt]@survey style to work: I get 'invalid object' > > > join [fsceil1:0]@river [farsidewest3:8]@river. commented out in attached > > >.th file. > > > > omit the brackets. Unfortunately therionbook is misleading in this point. > > I tried it without the brackets too: it says 'line mark not a keyword -- > fsceil1:0@river' Finally it wasn't a bug, but we've forgotten, how we've done it :))) (We're almost not using this feature). So join fsceil1@river:0 farsidewest3@river:7 should work with current version of therion. We will update thbook. S. Subject: Re: feedback on 0.2.18 From: Wookey Date: Mon, 1 Mar 2004 12:13:01 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-03-01 10:26 +0100]: >> > >>>>> >> >I still can't get join [id:pt]@survey style to work: I get 'invalid >> >>> >object' >> >>>>> >> > join [fsceil1:0]@river [farsidewest3:8]@river. commented out in >> >>> >attached >> >>>>> >> >.th file. >>> >>>> >> >>>> >> omit the brackets. Unfortunately therionbook is misleading in this point. >> >>> > >>> >I tried it without the brackets too: it says 'line mark not a keyword -- >>> >fsceil1:0@river' > >> >> Finally it wasn't a bug, but we've forgotten, how we've done it :))) (We're >> almost not using this feature). So >> >> join fsceil1@river:0 farsidewest3@river:7 >> >> should work with current version of therion. We will update thbook. OK, checked it - does. Makes my pic look noticeably better. That's actually a rather odd syntax don't you think? The syntax in thbook seems rather more sensible to me (with the smaller parts to the left). Thinking about it 0:fsceil1@river would actually be the most logical, but somehow that doesn't seem as clear as fsceil1:0@river 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/ Subject: Re: feedback on 0.2.18 From: "Martin Budaj" Date: Mon, 01 Mar 2004 13:30:06 +0100 To: therion@speleo.sk >> join fsceil1@river:0 farsidewest3@river:7 > > > That's actually a rather odd syntax don't you think? The syntax in thbook > seems rather more sensible to me (with the smaller parts to the left). > Thinking about it 0:fsceil1@river would actually be the most logical, but > somehow that doesn't seem as clear as fsceil1:0@river If we take 'fsceil1@river' as a full-ID, then the current syntax means :, which is odd, but consistent -- isn't it? Martin Subject: Re: [therion] Re: feedback on 0.2.18 From: Stacho Mudrak Date: Mon, 01 Mar 2004 13:39:57 +0100 To: therion@speleo.sk > OK, checked it - does. Makes my pic look noticeably better. > > That's actually a rather odd syntax don't you think? Yes, it's not natural. At the first approach, we had syntax "fsceil1:0@river", (when I started to fix the bug, I realized, that I have just to uncomment some lines :))) but than we've changed it. The problem is, I can't remeber why :(((, but I believe we had a serious reason. But the second think is - that joining lines at given points is really very rare situation. Firstly, when we had no "join scrap1 scrap2 -count 2", it was quite common. But now, we're almost not using it... (when you first think a little bit, where the scraps will join). The last think, in naming we were inspired by internet (@ and ":" as separators). And there you also specify port using ":" behind the machine. In fact, there is a lot of stuff like this in therion, we've left on "more sophisticated user interface", where you will just drag line from one line point to another. I've put new developement version (20040229) on the server. We would like to release version 0.2.29 tomorrow, when Martin will include his changes and modify thbook. But if you're interested in, there should work line highlighting, selected line is red, area is automatically showed when selected and also moving commands to specific position in the file is possible. S. Subject: Re: feedback on 0.2.18 From: Wookey Date: Mon, 1 Mar 2004 12:40:20 +0000 To: therion@speleo.sk +++ Martin Budaj [04-03-01 13:30 +0100]: >>>> >>join fsceil1@river:0 farsidewest3@river:7 >> >>> > >>> >That's actually a rather odd syntax don't you think? The syntax in thbook >>> >seems rather more sensible to me (with the smaller parts to the left). >>> >Thinking about it 0:fsceil1@river would actually be the most logical, but >>> >somehow that doesn't seem as clear as fsceil1:0@river > >> >> If we take 'fsceil1@river' as a full-ID, then the current syntax means >> :, which is odd, but consistent -- isn't it? yes. fair enough. 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/ Subject: Re: feedback on 0.2.18 From: "Martin Budaj" Date: Tue, 02 Mar 2004 08:42:05 +0100 To: therion@speleo.sk John Pybus writes: > I would certainly appreciate this. I currently mark all the places I substitute similar symbols for the ones I really want with a comment so that I can easily go back and change them as functionality increases, or I find the time to look at defining the symbols I want. BTW, why don't you ask for some new features which you really want in this conference? We're used to drawing caves in one way so we can't imagine what ever would others need... Regards, Martin Subject: Example of spurious text appearing From: Wookey Date: Fri, 27 Feb 2004 01:58:37 +0000 To: Therion List OK, I've reproduced the 'text between every item' bug. Take the attached soundriver.orig file and load it into Xtherion (I used the 20040224 release). In File Commands there is a 'text' item between each real item. Most of them are just a blank line. If you save there is no change in the file, but if you add a line (and then delete it), then save, then each turns into , resulting in soundriver.th2, attached. Hoipe this helps track it down. This is on Debian GNU/Linux 'testing' release. Wookey encoding utf-8 ##XTHERION## xth_me_area_adjust -128 -1247 1800 1328 ##XTHERION## xth_me_area_zoom_to 200 ##XTHERION## xth_me_image_insert {0 1 1.0} 1200 soundriver1pln.pnm 0 {} scrap farside2 -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] line wall -id wall1 51.0 244.0 51.0 244.0 64.55 227.73 78.0 206.0 91.0 185.0 97.0 179.0 97.0 179.0 smooth off 107.0 167.0 107.0 167.0 109.0 159.0 117.0 144.0 125.0 129.0 133.0 111.0 133.0 111.0 smooth off endline point 1013.0 -911.0 station -name 25 #point 983.0 -677.0 station -name 26 #point 1055.0 -455.0 station -name 27 #point 1035.0 -220.0 station -name 28 #point 970.0 9.0 station -name 29 #point 961.0 244.0 station -name 30 point 618.0 413.0 station -name 34 point 546.0 303.0 station -name 35 point 511.0 195.0 station -name 36 point 451.0 125.0 station -name 37 point 360.0 136.0 station -name 38 point 317.0 153.0 station -name 39 point 158.0 244.0 station -name 40 point 165.0 151.0 debris point 131.0 161.0 debris point 139.0 141.0 debris point 181.0 160.0 debris point 169.0 181.0 debris point 159.0 159.0 debris point 243.0 212.0 air-draught -orientation 300.9 point 646.0 505.0 air-draught -orientation 205.7 point 661.0 353.0 air-draught -orientation 210.6 point 474.0 66.0 continuation point 332.0 -61.0 continuation point 243.0 270.0 continuation point 179.0 107.0 continuation point 68.0 279.0 continuation point 105.0 229.0 air-draught -orientation 321.7 line wall -close on 397.0 89.0 393.0 100.0 393.0 100.0 409.0 121.0 413.0 123.0 417.0 125.0 421.0 130.0 423.0 120.0 smooth off 419.0 109.0 397.0 89.0 397.0 89.0 smooth off endline line wall 358.0 -42.0 374.0 -18.0 402.0 34.0 400.0 65.0 smooth off 420.0 75.0 412.0 96.0 439.0 104.0 smooth off 450.0 92.0 453.0 85.0 459.0 72.0 smooth off endline line border -id sbr1 -subtype invisible 652.0 386.0 652.0 386.0 671.0 498.0 626.0 554.0 smooth off endline point 595.0 302.0 debris point 674.0 504.0 debris line wall -id farsidewest3 471.0 83.0 454.0 116.0 454.0 116.0 465.0 106.0 483.0 110.0 501.0 114.0 534.0 136.0 542.0 164.0 550.0 192.0 539.0 237.0 549.0 252.0 559.0 267.0 589.0 284.0 599.0 295.0 625.17 323.78 639.0 366.0 652.0 386.0 660.99 399.83 741.0 478.0 741.0 478.0 smooth off 746.0 452.0 742.63 391.23 849.0 427.0 smooth off endline #Rocks inside wall1, wall2, rb1, rb2 area debris wall1 rb1 wall2 rb2 endarea line rock-border -id rb2 175.0 199.0 107.0 167.0 endline line rock-border -id rb1 133.0 111.0 202.0 151.0 endline line wall -id wall2 202.0 151.0 175.0 199.0 175.0 199.0 185.0 211.0 201.0 206.0 217.0 201.0 285.0 148.0 291.0 142.0 297.0 136.0 327.0 107.0 333.0 83.0 339.0 59.0 343.0 28.0 317.0 -27.0 smooth off endline line pit -id sbr2 536.0 312.0 558.0 285.0 563.0 266.0 endline area sand sbr1 farsidewest3 sbr2 farsidewest2 sbr3 farsidewest2 endarea line wall -id farsidewest2 359.0 142.0 359.0 142.0 375.0 176.0 383.0 183.0 391.0 190.0 390.0 180.0 398.0 188.0 406.0 196.0 445.84 222.97 447.0 216.0 448.0 210.0 473.0 203.0 473.0 189.0 473.0 175.0 461.0 154.0 461.0 154.0 smooth off 461.0 154.0 484.0 161.0 495.0 176.0 506.0 191.0 509.0 221.0 509.0 234.0 509.0 247.0 505.0 280.0 510.0 303.0 515.0 326.0 543.0 306.0 536.0 312.0 529.0 318.0 562.0 346.0 568.0 358.0 574.0 370.0 584.0 396.0 577.0 399.0 570.0 402.0 537.0 371.0 531.0 378.0 525.0 385.0 533.0 389.0 533.0 389.0 smooth off 533.0 389.0 573.0 460.0 583.0 461.0 593.0 462.0 601.0 449.0 601.0 449.0 smooth off 601.0 449.0 614.0 461.0 616.0 480.0 618.0 499.0 626.0 541.0 626.0 554.0 626.0 567.0 629.0 590.0 629.0 590.0 smooth off endline line wall 254.0 258.0 277.11 221.68 345.0 160.0 359.0 142.0 smooth off endline line wall 112.0 282.0 145.0 243.0 145.0 243.0 149.0 263.0 171.0 266.0 202.11 270.24 245.0 236.0 245.0 236.0 smooth off 245.0 236.0 239.0 247.0 237.0 254.0 smooth off endline line pit -id sbr3 560.0 388.0 558.0 397.0 549.0 405.0 541.0 405.0 smooth off endline line contour 480.0 119.0 480.0 119.0 505.0 125.0 520.0 143.0 535.0 161.0 535.0 165.0 537.0 181.0 539.0 197.0 538.0 220.0 539.0 233.0 540.0 246.0 546.7 266.32 552.0 271.0 555.23 273.85 560.0 280.5 558.0 285.0 smooth off endline line contour 475.0 127.0 475.0 127.0 512.0 151.0 518.0 159.0 524.0 167.0 529.0 172.0 531.0 182.0 533.0 192.0 533.0 226.0 535.0 239.0 537.0 252.0 548.0 278.0 551.0 281.0 555.47 285.47 552.0 292.0 552.0 292.0 smooth off endline line arrow 735.0 515.0 712.0 517.0 endline line arrow 728.0 477.0 698.0 481.0 endline line contour -clip off 692.0 432.0 692.0 432.0 696.92 439.2 710.0 477.0 723.08 514.8 728.0 536.0 728.0 536.0 smooth off endline line pit -clip off 657.0 411.0 657.0 411.0 647.11 386.22 665.0 422.0 682.89 457.78 669.38 427.77 684.0 465.0 698.62 502.23 707.0 529.0 707.0 529.0 smooth off endline line pit 352.0 91.0 352.0 91.0 368.0 111.0 372.0 120.0 smooth off endline endscrap scrap farside -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] point 875.0 460.0 station -name 31 point 968.0 805.0 air-draught -orientation 230.6 point 844.0 567.0 station -name 32 point 775.0 574.0 station -name 33 point 873.0 726.0 station -name 43a point 948.0 977.0 station -name 43 point 867.0 942.0 station -name 42 point 736.0 770.0 station -name 41 point 1035.0 606.0 station -name 44 line wall 919.0 1102.0 987.0 995.0 endline line arrow 987.0 616.0 949.0 588.0 endline line arrow 1006.0 548.0 969.0 519.0 endline point 973.0 871.0 continuation point 898.0 1109.0 continuation line contour 1032.0 521.0 1032.0 521.0 1012.0 556.0 1007.0 581.0 1002.0 606.0 1001.0 615.0 999.0 624.0 997.0 633.0 996.0 643.0 998.0 654.0 smooth off endline line contour 995.0 484.0 995.0 484.0 964.0 565.0 964.0 593.0 964.0 621.0 967.0 630.0 967.0 630.0 smooth off endline line ceiling-step -id fsceil1 -clip off 741.0 478.0 741.0 478.0 750.0 533.0 769.0 579.0 788.0 625.0 802.0 630.0 817.0 635.0 smooth off endline line contour -reverse on -clip off 868.0 587.0 868.0 587.0 848.0 592.0 823.0 568.0 798.0 544.0 795.0 516.0 795.0 516.0 smooth off 795.0 516.0 773.0 521.0 743.0 490.0 smooth off endline line contour -reverse on -clip off 869.0 579.0 869.0 579.0 844.0 563.0 833.0 550.0 822.0 537.0 807.0 504.0 807.0 504.0 smooth off 807.0 504.0 788.5 504.5 745.5 474.5 smooth off endline line contour -id rbr5c 969.0 448.0 969.0 448.0 945.0 494.0 943.0 514.0 941.0 534.0 940.0 555.0 938.0 573.0 936.89 582.99 940.0 600.0 943.0 612.0 smooth off endline line wall -id rbr5b 1075.0 556.0 1075.0 556.0 1037.0 531.0 1001.0 490.0 965.0 449.0 960.0 437.0 955.0 426.0 smooth off endline line label -text choked 1149.0 645.0 1104.0 713.0 endline line wall -id rbr5a 1125.0 589.0 subtype presumed 1075.0 556.0 endline line wall -id rbr5e 1005.0 656.0 subtype presumed 1072.0 704.0 endline point 817.0 583.0 debris point 863.0 609.0 debris point 836.0 616.0 debris point 814.0 610.0 debris area debris rbr5a rbr5b rbr5c rbr5d rbr5e rbr5f endarea line border -id rbr5f 1028.0 673.0 1028.0 673.0 1050.0 601.0 1092.0 565.0 smooth off endline line wall -id rbr5d 936.0 740.0 936.0 740.0 914.0 717.0 893.0 667.0 872.0 617.0 864.0 584.0 869.0 579.0 883.3 564.7 948.0 613.0 1005.0 656.0 smooth off endline line wall 975.0 782.0 subtype presumed 936.0 740.0 endline line border -id blockage1 -close on -subtype invisible 987.0 995.0 957.0 966.0 934.0 928.0 940.0 917.0 968.0 938.0 983.0 959.0 1002.0 972.0 987.0 995.0 endline area debris -id blk1area -clip off blockage1 endarea point 728.0 688.0 debris point 731.0 702.0 debris point 711.0 698.0 debris point 703.0 709.0 debris point 683.0 701.0 debris point 682.0 679.0 debris point 682.0 629.0 debris point 673.0 659.0 debris point 722.0 801.0 debris point 676.0 735.0 debris line pit 727.0 737.0 727.0 737.0 702.0 726.0 665.0 720.0 smooth off endline line pit 741.0 845.0 741.0 845.0 726.0 823.0 750.0 803.0 smooth off endline line rock-edge 797.0 825.0 801.0 836.0 811.0 839.0 endline line rock-edge 831.0 842.0 812.0 832.0 811.0 844.0 829.0 849.0 endline line rock-edge -close on 842.0 843.0 836.0 854.0 829.0 849.0 831.0 842.0 842.0 843.0 endline line rock-edge -close on 853.0 868.0 846.0 871.0 837.0 865.0 844.0 850.0 860.0 859.0 853.0 868.0 endline line rock-edge 871.0 871.0 870.0 858.0 860.0 859.0 853.0 868.0 866.0 881.0 endline line rock-edge -reverse on 871.0 905.0 880.0 892.0 876.0 886.0 866.0 881.0 871.0 871.0 884.0 877.0 880.0 892.0 endline line wall -reverse on -subtype blocks 886.0 927.0 871.0 905.0 endline line wall -reverse on -subtype blocks 924.0 941.0 924.0 941.0 922.0 949.0 913.0 950.0 904.0 951.0 895.0 942.0 895.0 942.0 smooth off 886.0 940.0 886.0 927.0 endline line wall 940.0 917.0 subtype presumed 924.0 941.0 endline line wall 987.0 995.0 subtype presumed 1011.0 958.0 endline line wall -id farsidewest1 629.0 590.0 632.0 624.0 636.0 655.0 642.0 723.0 642.0 723.0 651.0 772.0 663.0 791.0 671.44 804.37 705.0 826.0 705.0 826.0 smooth off 720.0 833.0 739.0 857.0 748.0 862.0 753.0 870.0 762.0 871.0 769.0 874.0 773.0 881.0 782.0 881.0 782.0 881.0 790.0 885.0 793.0 890.0 796.0 895.0 800.62 903.69 806.0 906.0 813.0 909.0 820.0 912.0 820.0 912.0 smooth off 828.0 915.0 875.0 976.0 875.0 976.0 smooth off 874.0 987.0 874.0 987.0 900.0 1017.0 897.0 1029.0 894.0 1041.0 880.0 1071.0 880.0 1071.0 smooth off endline line rock-edge -close on 830.0 818.0 812.0 832.0 781.0 818.0 791.0 792.0 818.0 805.0 830.0 818.0 endline line rock-edge 752.0 781.0 732.0 791.0 722.0 754.0 742.0 750.0 endline line rock-edge -close on 787.0 768.0 758.0 788.0 752.0 781.0 752.0 781.0 752.0 770.0 750.0 763.0 748.0 756.0 742.0 750.0 742.0 750.0 smooth off 751.0 724.0 751.0 724.0 764.0 717.0 764.0 723.0 764.0 729.0 767.0 731.0 774.0 731.0 781.0 731.0 774.0 744.0 774.0 744.0 smooth off 787.0 768.0 endline line rock-edge -close on 689.0 669.0 689.0 669.0 688.0 702.0 694.0 703.0 700.0 704.0 708.0 678.0 708.0 678.0 smooth off 689.0 669.0 endline line rock-edge -clip off 687.0 613.0 660.0 538.0 671.0 530.0 endline line rock-edge -clip off 671.0 530.0 694.0 536.0 endline line rock-edge -clip off 660.0 538.0 669.0 544.0 endline line rock-edge -close on -clip off 687.0 613.0 687.0 613.0 701.0 621.0 708.0 614.0 715.0 607.0 716.0 596.0 713.0 589.0 710.0 582.0 694.0 536.0 694.0 536.0 smooth off 669.0 544.0 687.0 613.0 endline line rock-edge -close on 851.0 555.0 867.0 546.0 869.0 561.0 857.0 564.0 851.0 555.0 endline point 901.0 465.0 debris line arrow endline line wall -close on 924.0 475.0 931.0 481.0 936.0 473.0 930.0 468.0 924.0 463.0 917.0 469.0 924.0 475.0 endline line wall -close on 909.0 501.0 909.0 501.0 902.0 504.0 898.0 501.0 894.0 498.0 889.0 496.0 894.0 492.0 899.0 488.0 909.0 501.0 909.0 501.0 smooth off endline area debris rbr3 rbr5d endarea line border -id rbr3 -subtype invisible 936.0 740.0 914.0 816.0 860.0 859.0 830.0 818.0 787.0 761.0 788.0 726.0 773.0 705.0 754.0 704.0 695.0 502.0 718.0 492.0 788.0 571.0 769.0 594.0 777.0 623.0 809.0 643.0 883.5 637.5 endline #rb3 and nearby wall surrounds rocky area area debris rbr3 rbr5d endarea line pit 897.0 1029.0 905.0 1020.0 905.0 1020.0 910.0 990.0 921.0 987.0 932.0 984.0 948.0 989.0 949.0 994.0 950.0 999.0 943.0 1010.0 941.0 1023.0 939.0 1036.0 947.0 1057.0 937.0 1073.0 smooth off endline line pit 880.0 1071.0 880.0 1071.0 878.0 1057.0 908.0 1066.0 938.0 1075.0 933.0 1086.0 933.0 1086.0 smooth off endline endscrap encoding utf-8 ##XTHERION## xth_me_area_adjust -128 -1247 1800 1328 ##XTHERION## xth_me_area_zoom_to 200 ##XTHERION## xth_me_image_insert {0 1 1.0} 1200 soundriver1pln.pnm 0 {} scrap farside2 -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] line wall -id wall1 51.0 244.0 51.0 244.0 64.55 227.73 78.0 206.0 91.0 185.0 97.0 179.0 97.0 179.0 smooth off 107.0 167.0 107.0 167.0 109.0 159.0 117.0 144.0 125.0 129.0 133.0 111.0 133.0 111.0 smooth off endline point 1013.0 -911.0 station -name 25 #point 983.0 -677.0 station -name 26 #point 1055.0 -455.0 station -name 27 #point 1035.0 -220.0 station -name 28 #point 970.0 9.0 station -name 29 #point 961.0 244.0 station -name 30 point 618.0 413.0 station -name 34 point 546.0 303.0 station -name 35 point 511.0 195.0 station -name 36 point 451.0 125.0 station -name 37 point 360.0 136.0 station -name 38 point 317.0 153.0 station -name 39 point 158.0 244.0 station -name 40 point 165.0 151.0 debris point 131.0 161.0 debris point 139.0 141.0 debris point 181.0 160.0 debris point 169.0 181.0 debris point 159.0 159.0 debris point 243.0 212.0 air-draught -orientation 300.9 point 646.0 505.0 air-draught -orientation 205.7 point 661.0 353.0 air-draught -orientation 210.6 point 474.0 66.0 continuation point 332.0 -61.0 continuation point 243.0 270.0 continuation point 179.0 107.0 continuation point 68.0 279.0 continuation point 105.0 229.0 air-draught -orientation 321.7 line wall -close on 397.0 89.0 393.0 100.0 393.0 100.0 409.0 121.0 413.0 123.0 417.0 125.0 421.0 130.0 423.0 120.0 smooth off 419.0 109.0 397.0 89.0 397.0 89.0 smooth off endline line wall 358.0 -42.0 374.0 -18.0 402.0 34.0 400.0 65.0 smooth off 420.0 75.0 412.0 96.0 439.0 104.0 smooth off 450.0 92.0 453.0 85.0 459.0 72.0 smooth off endline line border -id sbr1 -subtype invisible 652.0 386.0 652.0 386.0 671.0 498.0 626.0 554.0 smooth off endline point 595.0 302.0 debris point 674.0 504.0 debris line wall -id farsidewest3 471.0 83.0 454.0 116.0 454.0 116.0 465.0 106.0 483.0 110.0 501.0 114.0 534.0 136.0 542.0 164.0 550.0 192.0 539.0 237.0 549.0 252.0 559.0 267.0 589.0 284.0 599.0 295.0 625.17 323.78 639.0 366.0 652.0 386.0 660.99 399.83 741.0 478.0 741.0 478.0 smooth off 746.0 452.0 742.63 391.23 849.0 427.0 smooth off endline #Rocks inside wall1, wall2, rb1, rb2 area debris wall1 rb1 wall2 rb2 endarea line rock-border -id rb2 175.0 199.0 107.0 167.0 endline line rock-border -id rb1 133.0 111.0 202.0 151.0 endline line wall -id wall2 202.0 151.0 175.0 199.0 175.0 199.0 185.0 211.0 201.0 206.0 217.0 201.0 285.0 148.0 291.0 142.0 297.0 136.0 327.0 107.0 333.0 83.0 339.0 59.0 343.0 28.0 317.0 -27.0 smooth off endline line pit -id sbr2 536.0 312.0 558.0 285.0 563.0 266.0 endline area sand sbr1 farsidewest3 sbr2 farsidewest2 sbr3 farsidewest2 endarea line wall -id farsidewest2 359.0 142.0 359.0 142.0 375.0 176.0 383.0 183.0 391.0 190.0 390.0 180.0 398.0 188.0 406.0 196.0 445.84 222.97 447.0 216.0 448.0 210.0 473.0 203.0 473.0 189.0 473.0 175.0 461.0 154.0 461.0 154.0 smooth off 461.0 154.0 484.0 161.0 495.0 176.0 506.0 191.0 509.0 221.0 509.0 234.0 509.0 247.0 505.0 280.0 510.0 303.0 515.0 326.0 543.0 306.0 536.0 312.0 529.0 318.0 562.0 346.0 568.0 358.0 574.0 370.0 584.0 396.0 577.0 399.0 570.0 402.0 537.0 371.0 531.0 378.0 525.0 385.0 533.0 389.0 533.0 389.0 smooth off 533.0 389.0 573.0 460.0 583.0 461.0 593.0 462.0 601.0 449.0 601.0 449.0 smooth off 601.0 449.0 614.0 461.0 616.0 480.0 618.0 499.0 626.0 541.0 626.0 554.0 626.0 567.0 629.0 590.0 629.0 590.0 smooth off endline line wall 254.0 258.0 277.11 221.68 345.0 160.0 359.0 142.0 smooth off endline line wall 112.0 282.0 145.0 243.0 145.0 243.0 149.0 263.0 171.0 266.0 202.11 270.24 245.0 236.0 245.0 236.0 smooth off 245.0 236.0 239.0 247.0 237.0 254.0 smooth off endline line pit -id sbr3 560.0 388.0 558.0 397.0 549.0 405.0 541.0 405.0 smooth off endline line contour 480.0 119.0 480.0 119.0 505.0 125.0 520.0 143.0 535.0 161.0 535.0 165.0 537.0 181.0 539.0 197.0 538.0 220.0 539.0 233.0 540.0 246.0 546.7 266.32 552.0 271.0 555.23 273.85 560.0 280.5 558.0 285.0 smooth off endline line contour 475.0 127.0 475.0 127.0 512.0 151.0 518.0 159.0 524.0 167.0 529.0 172.0 531.0 182.0 533.0 192.0 533.0 226.0 535.0 239.0 537.0 252.0 548.0 278.0 551.0 281.0 555.47 285.47 552.0 292.0 552.0 292.0 smooth off endline line arrow 735.0 515.0 712.0 517.0 endline line arrow 728.0 477.0 698.0 481.0 endline line contour -clip off 692.0 432.0 692.0 432.0 696.92 439.2 710.0 477.0 723.08 514.8 728.0 536.0 728.0 536.0 smooth off endline line pit -clip off 657.0 411.0 657.0 411.0 647.11 386.22 665.0 422.0 682.89 457.78 669.38 427.77 684.0 465.0 698.62 502.23 707.0 529.0 707.0 529.0 smooth off endline line pit 352.0 91.0 352.0 91.0 368.0 111.0 372.0 120.0 smooth off endline endscrap scrap farside -projection plan -scale [-128 -1247 1800 -1247 0.0 0.0 48.9712 0.0 m] point 875.0 460.0 station -name 31 point 968.0 805.0 air-draught -orientation 230.6 point 844.0 567.0 station -name 32 point 775.0 574.0 station -name 33 point 873.0 726.0 station -name 43a point 948.0 977.0 station -name 43 point 867.0 942.0 station -name 42 point 736.0 770.0 station -name 41 point 1035.0 606.0 station -name 44 line wall 919.0 1102.0 987.0 995.0 endline line arrow 987.0 616.0 949.0 588.0 endline line arrow 1006.0 548.0 969.0 519.0 endline point 973.0 871.0 continuation point 898.0 1109.0 continuation line contour 1032.0 521.0 1032.0 521.0 1012.0 556.0 1007.0 581.0 1002.0 606.0 1001.0 615.0 999.0 624.0 997.0 633.0 996.0 643.0 998.0 654.0 smooth off endline line contour 995.0 484.0 995.0 484.0 964.0 565.0 964.0 593.0 964.0 621.0 967.0 630.0 967.0 630.0 smooth off endline line ceiling-step -id fsceil1 -clip off 741.0 478.0 741.0 478.0 750.0 533.0 769.0 579.0 788.0 625.0 802.0 630.0 817.0 635.0 smooth off endline line contour -reverse on -clip off 868.0 587.0 868.0 587.0 848.0 592.0 823.0 568.0 798.0 544.0 795.0 516.0 795.0 516.0 smooth off 795.0 516.0 773.0 521.0 743.0 490.0 smooth off endline line contour -reverse on -clip off 869.0 579.0 869.0 579.0 844.0 563.0 833.0 550.0 822.0 537.0 807.0 504.0 807.0 504.0 smooth off 807.0 504.0 788.5 504.5 745.5 474.5 smooth off endline line contour -id rbr5c 969.0 448.0 969.0 448.0 945.0 494.0 943.0 514.0 941.0 534.0 940.0 555.0 938.0 573.0 936.89 582.99 940.0 600.0 943.0 612.0 smooth off endline line wall -id rbr5b 1075.0 556.0 1075.0 556.0 1037.0 531.0 1001.0 490.0 965.0 449.0 960.0 437.0 955.0 426.0 smooth off endline line label -text choked 1149.0 645.0 1104.0 713.0 endline line wall -id rbr5a 1125.0 589.0 subtype presumed 1075.0 556.0 endline line wall -id rbr5e 1005.0 656.0 subtype presumed 1072.0 704.0 endline point 817.0 583.0 debris point 863.0 609.0 debris point 836.0 616.0 debris point 814.0 610.0 debris area debris rbr5a rbr5b rbr5c rbr5d rbr5e rbr5f endarea line border -id rbr5f 1028.0 673.0 1028.0 673.0 1050.0 601.0 1092.0 565.0 smooth off endline line wall -id rbr5d 936.0 740.0 936.0 740.0 914.0 717.0 893.0 667.0 872.0 617.0 864.0 584.0 869.0 579.0 883.3 564.7 948.0 613.0 1005.0 656.0 smooth off endline line wall 975.0 782.0 subtype presumed 936.0 740.0 endline line border -id blockage1 -close on -subtype invisible 987.0 995.0 957.0 966.0 934.0 928.0 940.0 917.0 968.0 938.0 983.0 959.0 1002.0 972.0 987.0 995.0 endline area debris -id blk1area -clip off blockage1 endarea point 728.0 688.0 debris point 731.0 702.0 debris point 711.0 698.0 debris point 703.0 709.0 debris point 683.0 701.0 debris point 682.0 679.0 debris point 682.0 629.0 debris point 673.0 659.0 debris point 722.0 801.0 debris point 676.0 735.0 debris line pit 727.0 737.0 727.0 737.0 702.0 726.0 665.0 720.0 smooth off endline line pit 741.0 845.0 741.0 845.0 726.0 823.0 750.0 803.0 smooth off endline line rock-edge 797.0 825.0 801.0 836.0 811.0 839.0 endline line rock-edge 831.0 842.0 812.0 832.0 811.0 844.0 829.0 849.0 endline line rock-edge -close on 842.0 843.0 836.0 854.0 829.0 849.0 831.0 842.0 842.0 843.0 endline line rock-edge -close on 853.0 868.0 846.0 871.0 837.0 865.0 844.0 850.0 860.0 859.0 853.0 868.0 endline line rock-edge 871.0 871.0 870.0 858.0 860.0 859.0 853.0 868.0 866.0 881.0 endline line rock-edge -reverse on 871.0 905.0 880.0 892.0 876.0 886.0 866.0 881.0 871.0 871.0 884.0 877.0 880.0 892.0 endline line wall -reverse on -subtype blocks 886.0 927.0 871.0 905.0 endline line wall -reverse on -subtype blocks 924.0 941.0 924.0 941.0 922.0 949.0 913.0 950.0 904.0 951.0 895.0 942.0 895.0 942.0 smooth off 886.0 940.0 886.0 927.0 endline line wall 940.0 917.0 subtype presumed 924.0 941.0 endline line wall 987.0 995.0 subtype presumed 1011.0 958.0 endline line wall -id farsidewest1 629.0 590.0 632.0 624.0 636.0 655.0 642.0 723.0 642.0 723.0 651.0 772.0 663.0 791.0 671.44 804.37 705.0 826.0 705.0 826.0 smooth off 720.0 833.0 739.0 857.0 748.0 862.0 753.0 870.0 762.0 871.0 769.0 874.0 773.0 881.0 782.0 881.0 782.0 881.0 790.0 885.0 793.0 890.0 796.0 895.0 800.62 903.69 806.0 906.0 813.0 909.0 820.0 912.0 820.0 912.0 smooth off 828.0 915.0 875.0 976.0 875.0 976.0 smooth off 874.0 987.0 874.0 987.0 900.0 1017.0 897.0 1029.0 894.0 1041.0 880.0 1071.0 880.0 1071.0 smooth off endline line rock-edge -close on 830.0 818.0 812.0 832.0 781.0 818.0 791.0 792.0 818.0 805.0 830.0 818.0 endline line rock-edge 752.0 781.0 732.0 791.0 722.0 754.0 742.0 750.0 endline line rock-edge -close on 787.0 768.0 758.0 788.0 752.0 781.0 752.0 781.0 752.0 770.0 750.0 763.0 748.0 756.0 742.0 750.0 742.0 750.0 smooth off 751.0 724.0 751.0 724.0 764.0 717.0 764.0 723.0 764.0 729.0 767.0 731.0 774.0 731.0 781.0 731.0 774.0 744.0 774.0 744.0 smooth off 787.0 768.0 endline line rock-edge -close on 689.0 669.0 689.0 669.0 688.0 702.0 694.0 703.0 700.0 704.0 708.0 678.0 708.0 678.0 smooth off 689.0 669.0 endline line rock-edge -clip off 687.0 613.0 660.0 538.0 671.0 530.0 endline line rock-edge -clip off 671.0 530.0 694.0 536.0 endline line rock-edge -clip off 660.0 538.0 669.0 544.0 endline line rock-edge -close on -clip off 687.0 613.0 687.0 613.0 701.0 621.0 708.0 614.0 715.0 607.0 716.0 596.0 713.0 589.0 710.0 582.0 694.0 536.0 694.0 536.0 smooth off 669.0 544.0 687.0 613.0 endline line rock-edge -close on 851.0 555.0 867.0 546.0 869.0 561.0 857.0 564.0 851.0 555.0 endline point 901.0 465.0 debris line arrow endline line wall -close on 924.0 475.0 931.0 481.0 936.0 473.0 930.0 468.0 924.0 463.0 917.0 469.0 924.0 475.0 endline line wall -close on 909.0 501.0 909.0 501.0 902.0 504.0 898.0 501.0 894.0 498.0 889.0 496.0 894.0 492.0 899.0 488.0 909.0 501.0 909.0 501.0 smooth off endline area debris rbr3 rbr5d endarea line border -id rbr3 -subtype invisible 936.0 740.0 914.0 816.0 860.0 859.0 830.0 818.0 787.0 761.0 788.0 726.0 773.0 705.0 754.0 704.0 695.0 502.0 718.0 492.0 788.0 571.0 769.0 594.0 777.0 623.0 809.0 643.0 883.5 637.5 endline #rb3 and nearby wall surrounds rocky area area debris rbr3 rbr5d endarea line pit 897.0 1029.0 905.0 1020.0 905.0 1020.0 910.0 990.0 921.0 987.0 932.0 984.0 948.0 989.0 949.0 994.0 950.0 999.0 943.0 1010.0 941.0 1023.0 939.0 1036.0 947.0 1057.0 937.0 1073.0 smooth off endline line pit 880.0 1071.0 880.0 1071.0 878.0 1057.0 908.0 1066.0 938.0 1075.0 933.0 1086.0 933.0 1086.0 smooth off endline endscrap Subject: [therion] Re: Example of spurious text appearing From: Stacho Mudrak Date: Fri, 27 Feb 2004 17:48:49 +0100 To: therion@speleo.sk Looks strange, on my machine all goes OK (I'm not able to reproduce the file with manu 's). Could you please send me these two files once more .tar.gz-ipped. May be some characters dissappeared when they were MIME en(de)coded. S. On Fri, 2004-02-27 at 02:58, Wookey wrote: >> OK, I've reproduced the 'text between every item' bug. >> >> Take the attached soundriver.orig file and load it into Xtherion (I used the >> 20040224 release). In File Commands there is a 'text' item between each real >> item. Most of them are just a blank line. >> >> If you save there is no change in the file, but if you add a line (and then >> delete it), then save, then each turns into , >> resulting in soundriver.th2, attached. >> >> Hoipe this helps track it down. This is on Debian GNU/Linux 'testing' release. >> >> Wookey Subject: 0.2.19 From: Stacho Mudrak Date: Tue, 02 Mar 2004 11:20:38 +0100 To: therion@speleo.sk Here is list of changes in the new version of therion, which is able to download. therion: * input language changes: - place option of point, line, area commands: none renamed to default - area command: place bottom is default - line command: if contour has no gradient specified, visualization is symbol-set dependent (no gradient tick in UIS, tick in the middle in SKBB) - line command: pit may be spelled as pitch - line command has new type: gradient - survey command has new option: person-rename * configuration file changes: - layout command has new option: debug - select command: new rules for selection if there is no map selected * scrap transformation improved, distortion logged in the log file * debugging map mode shows scrap distortions * bug fixed in PLT export xtherion: * Map editor: status bar displays command preview * Map editor: new Area control * Map editor: `Move to' in File commands added * Map editor: name of the edited scrap displayed in Title bar * Map editor: edited line is highlited * Map editor: selected area is highlited * Map editor: orientation tick at the beginning of line symbols * Help/Control dialog with key and mouse shortcuts * input (keyboard) encoding menu Yours, thTeam Subject: Re: therion and contours From: Wookey Date: Tue, 2 Mar 2004 11:53:22 +0000 To: Erin Lynch CC: Therion List +++ Erin Lynch [04-03-01 20:18 -0800]: >> Hi Wooks, >> >> Just wanted to let you know that we're thinking about using Therion to >> trace contours and then writing a script to convert from Therion to >> survex legs. Interesting idea. If you need this then maybe Therion should incorporate something like it more directly, although I'm not sure how exactly... >> It should be doable, but we're having a few problems with >> our installation of Therion. The biggest one is that if you zoom in on >> a big map the whole thing just becomes unfeasibly slow. Dunks thinks >> it's probably making a bitmap (or something) of the entire image at >> high res, which is why it's so slow. Any ideas? Yep - that's right, in fact there is more than one copy. I found the same problem. (on a 64MB machine attemting to zoom to 200% on a 4MB scan makes the whole thing disapear in a puff of smoke). Complaining to the Therion list elicited this explanation: >> 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA >> buffer = 40MB = 60% of RAM. This may be a problem, especially on some >> operating systems. The problem is that tcl's functions are used for the image management. tcl stores images internally as full RGB, so making them b/w or greyscale doesn't save any RAM, and it doesn't do anything clever like image-manipulation programs to only expand the visible tile. Something could probably be done to improve this but it's not trivial. This is a tradeoff of using a quick-prototyping language for the GUI rather than doing it the hard way. For the tme being you need to work with either a machine with loads of RAM or smaller images. Some work to see if TCL's handing can be improved in this regard would also be a good idea. I agree it's a serious problem, stacho doesn't seem entirely convinced yet. >> The other problem is that the lines, control points and handles are all >> a bit too chunky to be useable. Any idea what magic rune we need to >> change in order to make them a bit smaller? Nope - ask the list - they are _really_ helpful. (the ctrl modified lets you place points very close to other points which helps with the 'can't zoom' problem). cc:ed to Therion list 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/ Subject: [therion] Re: therion and contours From: Stacho Mudrak Date: Tue, 02 Mar 2004 16:28:35 +0100 To: therion@speleo.sk > For the tme being you need to work with either a machine with loads of RAM or > smaller images. Some work to see if TCL's handing can be improved in this > regard would also be a good idea. I agree it's a serious problem, stacho > doesn't seem entirely convinced yet. No comment. You can try, if you do not believe. The only solution is writing Tcl extension in C... > > The other problem is that the lines, control points and handles are all > > a bit too chunky to be useable. Any idea what magic rune we need to > > change in order to make them a bit smaller? Will be configurable from xtherion.ini in the next release. S. Subject: Re: therion and contours From: Wookey Date: Tue, 2 Mar 2004 15:47:05 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-03-02 16:28 +0100]: >> > >>> >For the tme being you need to work with either a machine with loads of RAM >>> >or >>> >smaller images. Some work to see if TCL's handing can be improved in this >>> >regard would also be a good idea. I agree it's a serious problem, stacho >>> >doesn't seem entirely convinced yet. > >> >> No comment. You can try, if you do not believe. The only solution is >> writing Tcl extension in C... I didn't mean that writing it would not be difficult, I meant that the problem of not being able to zoom large images is a serious useability problem for real users (we have <10 I am aware of and two of them have complained already :-) . You suggested 'buy a bigger machine', which is OK up to a point but I'd much prefer making the software smarter. I realise that this is not easy. 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/ Subject: Re: [therion] Re: therion and contours From: John Pybus Date: Wed, 03 Mar 2004 12:10:27 +0000 To: therion@speleo.sk Wookey wrote: > +++ Stacho Mudrak [04-03-02 16:28 +0100]: > >>> For the tme being you need to work with either a machine with loads of RAM or >>> smaller images. Some work to see if TCL's handing can be improved in this >>> regard would also be a good idea. I agree it's a serious problem, stacho >>> doesn't seem entirely convinced yet. >> >> >> No comment. You can try, if you do not believe. The only solution is writing Tcl extension in C... > > > > I didn't mean that writing it would not be difficult, I meant that the > problem of not being able to zoom large images is a serious useability > problem for real users (we have <10 I am aware of and two of them have > complained already :-) . > You suggested 'buy a bigger machine', which is OK up to a point but I'd much > prefer making the software smarter. I realise that this is not easy. On the other hand, would this be a good us of limited developer resources? The smallest machine I still use, my laptop, has 256Mb of RAM, and this is capable (just about) of handling a 10Mb gif of a >A4 scan. Admittedly, if you zoom to 200% it hits the VM system pretty hard (340Mb process size) but it is usable once you've waited for the scaling operation to finish. As time goes by, any efforts to support small memory systems will bring diminishing returns as average system sizes increase. Personally, I'd rather see effort to support other vector output formats such as SVG, which would be easier to import into other editing and publishing tools for further manipulation or inclusion in larger publications. Yours, John Subject: Re: therion and contours From: Wookey Date: Wed, 3 Mar 2004 12:42:26 +0000 To: therion@speleo.sk +++ John Pybus [04-03-03 12:10 +0000]: >> Wookey wrote: > >>> >+++ Stacho Mudrak [04-03-02 16:28 +0100]: >>> >You suggested 'buy a bigger machine', which is OK up to a point but I'd >>> >much prefer making the software smarter. I realise that this is not easy. > >> >> On the other hand, would this be a good us of limited developer >> resources? The smallest machine I still use, my laptop, has 256Mb of >> RAM, OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, excluding ARM machines and PDAs)! The only one I have access to with >256 Mb of RAM is the server here and that already jammed up against it's memory limits doing other things anyway. I can accept that my machine can't really cope with the 28000x16000 scan I tried to autotrace recently, but I think I ought to be able to zoom in on a 4MB image without it exploding (having doubled up my ram to 128MB I can now just about do that). Erin and duncan are in china and are skint - they are likely to be working with less-than-state-of-the-art equipment too. >> Personally, I'd rather see effort to support other vector output formats >> such as SVG, which would be easier to import into other editing and >> publishing tools for further manipulation or inclusion in larger >> publications. Fair enough, and of course Stacho can decide what he wants to do too - this is very much a 'scratch your own itch' project. I'm just asserting that the current limitations are a problem for me, and for Erin, and I think they'll bite quite a few others too. Obviously if no-one wants to actually do anything about it, then things will stay as they are, but it will affect the uptake of Therion. The other argument for better efficiency in this regard is using therion on small machines in the field, which is something I'd like to see be possible at some point, but that might require a move away from TCL anyway in the interests of efficiency, in which case this particular problem goes away/changes anyway. 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/ Subject: [therion] Re: therion and contours From: Martin Sluka Date: Sat, 6 Mar 2004 09:48:16 +0100 To: therion@speleo.sk At 12:42 +0000 3.3.2004, Wookey wrote: ******************************************* > OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, > excluding ARM machines and PDAs)! The only one I have access to with >256 Mb > of RAM is the server here and that already jammed up against it's memory > limits doing other things anyway. TCL and RGB - TCL must calculate each pixel as RGB, mostly all monitors are RGB, BW monitors are exception. TCL must send RGB data to video. Wookey, I apologize myself, I know, I do quite different things on my comps (DTP, picture manipulations in Photoshop and so on.), but one of the best time saving investment in my life was to buy 1 GB (or more) RAM for each comp I use. We live in time when one may compare price of one RAM chip to price of beers drinked in one night ;))) . I remember many many times more expensive ones. Only several words from an old man :o)> Martin -- Subject: Re: therion and contours From: Wookey Date: Tue, 16 Mar 2004 13:12:35 +0000 To: therion@speleo.sk +++ Martin Sluka [04-03-06 09:48 +0100]: >> At 12:42 +0000 3.3.2004, Wookey wrote: >> ******************************************* >> > >>> >OK, but I don't own _any_ machines with that _much_ ram (and I've got 5, >>> >excluding ARM machines and PDAs)! The only one I have access to with >256 >>> >Mb of RAM is the server here and that already jammed up against it's >>> >memory limits doing other things anyway. > >> >> TCL and RGB - TCL must calculate each pixel as RGB, mostly all >> monitors are RGB, BW monitors are exception. TCL must send RGB data >> to video. That's irrelevant - it's not TCL that sends the signals directly to the monitor - that's framebuffer/video drivers/X/video hardware. When working with B&W TCL could perfectly well use 1 byte or even 1bit image representations. I realise that it doesn't, but it still doesn't need to zoom all the image which is off-screen. Smart image manipulation software works in tiles to keep memory requirements sensible. >> Wookey, I apologize myself, I know, I do quite different things on my >> comps (DTP, picture manipulations in Photoshop and so on.), but one >> of the best time saving investment in my life was to buy 1 GB (or >> more) RAM for each comp I use. >> >> We live in time when one may compare price of one RAM chip to price >> of beers drinked in one night ;))) . I remember many many times more >> expensive ones. That's only true if the hardware you have has the capacity for lots of RAM. My laptop can only have a max of 256 fitted, my desktop 512 the servers here 256 and 512 respectively. If you have to buy new motherboards (which means new cases - AT->ATX) new IO cards (ISA/VLBUS->PCI) and so on, then it is not simply the matter of the memory cost. I realise new hardware is relatively cheap these days but in this case (displaying a scanned image at arbitrary resolution) I don't believe the correct answer to crappy memory management in the underlying language is 'go and buy a new computer'. When you can't zoom a 4MB image to 200% on a 64MB computer with a virual memory system then the software is deeply inefficient and that should be addressed, not simply accepted. That way leads to massive software bloat. I can zoom the very same image several thousand pecent on the same machine using the GIMP, showing that it is perfectly feasible (which is obvious anyway of course). I understand that Stacho has better things to do right now than worry about TCL's crummy image-handling, but I can't accept the 'just buy a new computer' argument - we should have higher intellectual standards than that, and more to the point I don't have the money to splash around on new computers - I just bought one to play DVDs, so that's my budget for the couple of years spent... 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/ Subject: Re: therion and contours From: "Martin Budaj" Date: Tue, 16 Mar 2004 15:43:57 +0100 To: therion@speleo.sk Wookey writes: > I understand that Stacho has better things to do right > now than worry about TCL's crummy image-handling, but I can't accept the > 'just buy a new computer' argument - we should have higher intellectual > standards than that, and more to the point I don't have the money to splash > around on new computers - I just bought one to play DVDs, so that's my > budget for the couple of years spent... I see following possible solutions: * invest a _lot_ of effort to overcome TCL's limitations. This may be only time-vaste if we would eventually reimplement XTherion from scratch -- see the next point. (It's like trying to upgrade an old car -- it's usually better and cheaper to buy a new one.) * rewrite XTherion from scratch in C++ or other non-interpreted language. This would also require great amount of work, but it could benefit from compiled and optimized code and a completely new design with all TCL-Xtherion's shiftiness in mind. We suggested some ideas for discussion a couple of weeks ago (link to http://labyrinth.speleo.sk on this list), but there was no response. If we could form a group of developers which would 1) discuss 2) implement it, we could have easy-to-use and efficient user interface. But this is possible only as a team work. * buy a better computer and use XTherion Any ideas? Martin Subject: [therion] Re: therion and contours From: Stacho Mudrak Date: Wed, 17 Mar 2004 07:34:23 +0100 To: therion@speleo.sk Hi Wookey, could you please test attached version of xtherion? I've slightly modified the image handling and it seems to be a little bit faster, when zooming large images... Please let me know, whether it has helped you. Regards, S. Subject: Re: [therion] Re: therion and contours From: "Matt Ryan" Date: Wed, 17 Mar 2004 23:49:18 +0800 To: >>>> We live in time when one may compare price of one RAM chip to price >>>> of beers drinked in one night ;))) . I remember many many times more >>>> expensive ones. Indeed, buying RAM definitely is the way to improve computing performance and the time saved is well worth the money - but as Wookey says, buying RAM sometimes just isn't possible - if it's not your machine for example or is an older / laptop motherboard. I played with Therion a year or so back and like the idea, more or less drew a map before giving up and doing it by hand and tracing that in Photoshop. I've not used it since then (no time and no caves to draw!) although I've lurked here watching new developments. I've got a list of other things to do as long as my arm, but I would be prepared to spend a little bit of time helping to port XTherion to C++ (wxWindows?). It's certainly a very worthwhile project. Don't expect anything from me anytime soon though... -Matt Subject: 0.2.19 debianization From: Wookey Date: Fri, 5 Mar 2004 15:04:11 +0000 To: Therion List OK, I downloaded 0.2.19 and debianised it (nice and easy). However on running xtherion I find I am getting an awful lot of debug info like this: 259 - 261:[1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 0] 260 - 262:[1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 0] These occur when loading the .th2 file in the map editor. and there are 260 numbered lines in the file (I like the line numbers in the command window - I think that'll help a lot). It looks there is a count from 1-n for each line n. I don't know if this is something to do with the 'why do extra 'text' lines appear' problem, but that is still present in this version. As Stacho can't repeat it I'd better try and work out what's going on myself. I was going to upload this version as it seems to work, but can't with all this debug info - if you tell me where it is I'll noble it. BTW, for my little soundriver survey, this version gives a 127K PDF. v0.2.18 gave a 32K PDF. Is this dramatic increase expected? I'm away for a week in norway, so nothing more till I get back. 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/ Subject: Re: [therion] 0.2.19 debianization From: Stacho Mudrak Date: Fri, 05 Mar 2004 16:56:13 +0100 To: therion@speleo.sk >> I don't know if this is something to do with the 'why do extra 'text' lines >> appear' problem, but that is still present in this version. As Stacho can't >> repeat it I'd better try and work out what's going on myself. Sorry for that :((( I forgot to remove this debugging line. Please comment out line 204 in me_cmds.tcl (puts "$f - $t [llength ...) and make once again. Will be fixed in new release. >> BTW, for my little soundriver survey, this version gives a 127K PDF. v0.2.18 >> gave a 32K PDF. Is this dramatic increase expected? Yes. We've changed the behaviour of area command. Now the sand is filled randomly - it looks much better on the map, but it takes much more space (because every dot is given by coordinates, before it was pattern with three dots). We are on the way to find a compromise - randomly filled pattern big enought, that it will not be too much visible, that it is a pattern. We would like to add "area blocks", where random blocks are definitely needed (it can not be pattern). Therefore we've changed the management of area commands - and "area sand" was used as a test (randomly generated dots clipped to area border). Regards, S. Subject: Re: 0.2.19 debianization From: Wookey Date: Fri, 5 Mar 2004 16:24:49 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-03-05 16:56 +0100]: >>> > I don't know if this is something to do with the 'why do extra 'text' lines >>> > appear' problem, but that is still present in this version. As Stacho can't >>> > repeat it I'd better try and work out what's going on myself. > >> >> Sorry for that :((( I forgot to remove this debugging line. Please >> comment out line 204 in me_cmds.tcl (puts "$f - $t [llength ...) and >> make once again. Will be fixed in new release. OK, building....built and tested OK. uploading... >>> > BTW, for my little soundriver survey, this version gives a 127K PDF. v0.2.18 >>> > gave a 32K PDF. Is this dramatic increase expected? > >> >> Yes. We've changed the behaviour of area command. Now the sand is filled >> randomly - it looks much better on the map, but it takes much more space >> (because every dot is given by coordinates, before it was pattern with >> three dots). >> >> We are on the way to find a compromise - randomly filled pattern big >> enought, that it will not be too much visible, that it is a pattern. yes - the filesize increase is perhaps a bit much for the visual gain here. A compromise would be good. >> We would like to add "area blocks", where random blocks are definitely >> needed (it can not be pattern). Therefore we've changed the management >> of area commands - and "area sand" was used as a test (randomly >> generated dots clipped to area border). Right - that makes sense - I'm looking forward to that feature :-) 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/ Subject: Can I rotate a map? From: Wookey Date: Thu, 25 Mar 2004 13:51:18 +0000 To: Therion List I've had a request from the editor to send him a therion map rotated 90 degrees so it fits better on the page. We can simply rotate the whole image, but it is possible to print a map with the text upright but north rotated? This is often useful for getting maps to fit on a page more efficiently (I've done it before for paper surveys), so if it's not currently a feature can we add it to the wishlist? I read the layout command, and whilst finding various fun things I didn't see a way to address this problem 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/ Subject: Re: Can I rotate a map? From: Stacho Mudrak Date: Thu, 25 Mar 2004 16:12:21 +0100 To: therion@speleo.sk No, BUT ... > fit on a page more efficiently (I've done it before for paper surveys), so > if it's not currently a feature can we add it to the wishlist? It's already there (I should translate at least some parts of TODO from Slovak into English :))) > I read the layout command, and whilst finding various fun things I didn't > see a way to address this problem But it is still possible to do it (using very dirty trick) with your current version - you can set declination for the top-survey surrounding entire cave. -declination [90 deg] will rotate entire output 90 degrees clockwise. Hope it helps. Regards, S. P.S. What about zooming large images in xtherion. Did the new version of xtherion solved your memory problems? P.S.2. When I've tried to set -declination [90 deg] with latest version of therion (0.3.0 - will be hopefully published on Eastern) - it didn't worked. But with 0.2.19, it was OK. So you have pointed me to some serious bug I've introduced to the code :) Thanks. Subject: Re: Can I rotate a map? From: Wookey Date: Thu, 25 Mar 2004 15:29:48 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-03-25 16:12 +0100]: >> No, BUT ... >> > >>> >fit on a page more efficiently (I've done it before for paper surveys), so >>> >if it's not currently a feature can we add it to the wishlist? > >> >> It's already there (I should translate at least some parts of TODO from >> Slovak into English :))) that would be useful - I have no idea what is currently on the list :-) >>> >I read the layout command, and whilst finding various fun things I didn't >>> >see a way to address this problem > >> >> But it is still possible to do it (using very dirty trick) with your >> current version - >> you can set declination for the top-survey surrounding entire cave. >> >> -declination [90 deg] >> >> will rotate entire output 90 degrees clockwise. thanx - that'll do for now (I get the north arrow pointing the wrong way(?) but that doesn't matter in this case) OK, that works but now I have another query. The page size of the PDF seems to be determined by the size of the background image, rather than the actual drawn lines. In the old version there was a lot of space below the cave, now there is a lot of space to the left of the cave, and this means the centred legend is hanging in a lot of whitespace. Is there a clip layout control I can use? The Thbook tells me there is age-setup for atlas mode only, and size for Map mode, but this only works is page-grid is on (I tried that and it didn't look nice on this survey - partly due to the huge white-space area) Oh yes and setting doc-title in layout doesn't change the title of the survey - it is still just the survey name 'river'. How do I specify that I want the output survey to be called 'Terikan River Cave'? >> P.S. What about zooming large images in xtherion. Did the new version of >> xtherion solved your memory problems? I haven't had time to try it yet - I just copied from mail to my 'therion' machine today to try. 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/ Subject: Re: [therion] Re: Can I rotate a map? From: Stacho Mudrak Date: Thu, 25 Mar 2004 16:47:27 +0100 To: therion@speleo.sk > that would be useful - I have no idea what is currently on the list :-) A lot of ugly things :))) > thanx - that'll do for now (I get the north arrow pointing the wrong > way(?) but that doesn't matter in this case) You can change the MP macro via layout :))) OK, it's even more dirty... > OK, that works but now I have another query. The page size of the PDF seems > to be determined by the size of the background image, rather than the actual > drawn lines. This is not true. > In the old version there was a lot of space below the cave, now > there is a lot of space to the left of the cave, and this means the centred > legend is hanging in a lot of whitespace. Is there a clip layout control I > can use? I don't think so. I've been also asking for such a things, but this is the area of Martin and he is currently in Paris. He should be back on Monday. Anyway - as far as I remember - this was also a bug in 0.2.18 and I'm not sure, whether is was fixed in 0.2.19. It was happening, when you've been exporting atlas and map from one thconfig file. So if this is the case, just comment out the "export atlas", may be it will help. The background images have for sure nothing to do with PDF size. It is strictly determined by drawn objects. May be - there is something drawn on the map, but you can no see it (degenerated background???). I do not know? If you can send me those sources, I can have a look at it. > Oh yes and setting doc-title in layout doesn't change the title of the > survey - it is still just the survey name 'river'. How do I specify that I > want the output survey to be called 'Terikan River Cave'? Doc-title was only a temporary think, it was removed in version 0.2.19. The "river" comes either from survey (most probably), or from map name. All you need to do is to specify title for survey. E.g. survey river -title "Terikan River Cave" or title for map map river -title "Terikan River Cave" Probably you are the first case. Survey and titles are shown on the "Survey structure" or "Map structure" TAB in the compiler. S. Subject: Re: Can I rotate a map? From: Wookey Date: Thu, 25 Mar 2004 16:05:20 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-03-25 16:47 +0100]: >> > >>> >OK, that works but now I have another query. The page size of the PDF seems >>> >to be determined by the size of the background image, rather than the >>> >actual >>> >drawn lines. > >> >> This is not true. I did wonder... It just seemed to be about that size 'extra' >>> > In the old version there was a lot of space below the cave, now >>> >there is a lot of space to the left of the cave, and this means the centred >>> >legend is hanging in a lot of whitespace. Is there a clip layout control I >>> >can use? > >> >> I don't think so. I've been also asking for such a things, but this is the >> area of Martin and he is currently in Paris. He should be back on Monday. >> >> Anyway - as far as I remember - this was also a bug in 0.2.18 and I'm not >> sure, whether is was fixed in 0.2.19. It was happening, when you've been >> exporting atlas and map from one thconfig file. So if this is the case, >> just comment out the "export atlas", may be it will help. There is no atlas exported (it's already commented out :-) . In fact I have fixed it by changing scale and base-scale till I get something 'about right'. It works OK when cave is small in comparison to Legend, but not with big cave and tiny legend. I will investigate more. >> The background >> images have for sure nothing to do with PDF size. It is strictly determined >> by drawn objects. May be - there is something drawn on the map, but you can >> no see it (degenerated background???). I do not know? If you can send me >> those sources, I can have a look at it. I expect you are right - If I can't understand myself I'll send you a copy. >>> >Oh yes and setting doc-title in layout doesn't change the title of the >>> >survey - it is still just the survey name 'river'. How do I specify that I >>> >want the output survey to be called 'Terikan River Cave'? > >> >> Doc-title was only a temporary think, it was removed in version 0.2.19. The >> "river" comes either from survey (most probably), or from map name. All >> you need to do is to specify title for survey. E.g. >> >> survey river -title "Terikan River Cave" this works, but having title "Terikan River Cave" inside this survey didn't - is that right? >> map river -title "Terikan River Cave" but this: export map -proj plan -title "Terikan River Cave (east)" -layout elevator -o soundriverpln.pdf gives the error 'unrecognised option -title' It would be nice to specify the title on the map layout in this case rather than as part of one component survey. >> Probably you are the first case. Survey and titles are shown on the "Survey >> structure" or "Map structure" TAB in the compiler. OK - I was avoiding loading xtherion up (takes time :-) thanx again - I've now got a survey good enough for the compass Pints front cover :-) 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/ Subject: Re: Can I rotate a map? From: Stacho Mudrak Date: Fri, 26 Mar 2004 09:44:41 +0100 To: therion@speleo.sk > In fact I have fixed it by changing scale and base-scale till I get > something 'about right'. It works OK when cave is small in comparison to > Legend, but not with big cave and tiny legend. I will investigate more. Look carefully on your map - you have there a survey station 25 in the lower left corner :) You have forgotten to comment out line point 1013.0 -911.0 station -name 25 in your soundriver.th2 file. > > The background > > images have for sure nothing to do with PDF size. It is strictly determined > > by drawn objects. May be - there is something drawn on the map, but you can > > no see it (degenerated background???). I do not know? If you can send me > > those sources, I can have a look at it. > > I expect you are right - If I can't understand myself I'll send you a copy. Well, I'm not rigth completely. Also objects that are clipped have impact on PDF page size. This should be probably changed. > this works, but having > title "Terikan River Cave" > inside this survey didn't - is that right? Yes. Title is the property of survey and map objects. > > map river -title "Terikan River Cave" > > but this: > export map -proj plan -title "Terikan River Cave (east)" -layout elevator -o soundriverpln.pdf > > gives the error 'unrecognised option -title' Yes. In fact, export has no title. > It would be nice to specify the title on the map layout in this case rather than as > part of one component survey. We always specify the titles for the surveys. It's allways easier to read "Passage above English hall", like "paeh" - the survey name. But there is also possibility to specify map title in the layout (but only between "layout" and "endlayout" commands). Also other things can be changed in the layout. Try to add following lines to your map layout: code tex-map \cavename={Terikan River Cave} \topotitle={Surveyed by} \cartotitle={Drawn by} \explotitle={Explored by} This is probably do, what you would like to. When I've been studying your code yesterday, I've found some thing, which I would like to comment: 1. soundriver.th 2 8 8 6 2 30 046 +9 1 6 4 4 2 0 0 0 # faked data to make therion happy 2 - - - - 30 223 -2 3 8 7 6 2 Therion would be very happy, if you would put break instead of 0 0 0 line. If there is a break in interleaved data, it should be explicitely defined in therion. 2 8 8 6 2 30 046 +9 1 6 4 4 2 break 2 - - - - 30 223 -2 3 8 7 6 2 will definitely make therion happy :))) This is because of following, assume: data normal station up down newline compass clino tape 1 2 3 2 3 4 3 4 5 4 5 6 6 7 8 5 3 4 7 8 9 10 10 10 In this case, therion is unable to say, where the break occurs. 2. All inner walls (walls that form holes in the scrap outline) must have specified -outline in. Otherwise the clipping and filling path will not be correct. And you will have also problems when 3D model will be generated from such a degenerated outline. 3. Scraps should touch each other - to look OK if they're shaded. So you should add invisible walls there (wall -subtype invisible). Thanks again for your feedback - it seems to me, that therion tutor document is more than necessary. We should probably put it on the first place in the TODO list. S. P.S. I've attached two pictures, to illustrate things I've changed in your file. Subject: Re: drawing up - seeking advice From: Wookey Date: Wed, 31 Mar 2004 14:59:47 +0100 To: Martin Sluka CC: Therion List +++ Martin Sluka [04-03-31 10:05 +0200]: >> At 15:50 +0100 30.3.2004, Wookey wrote: >> ******************************************* >> > >>> >A comparison of therion, TunnelX and Carto would be very useful, but I >>> >don't >>> >know of anyone who's tried all three. > >> >> Only a note: Check automatic overlap feature of therion - there is a >> sample on therion page. >> >> http://therion.speleo.sk/img/sample.png neat. Although I strongly contend that lines which go underneath should have a small gap so that they do not touch the wall which they are going under. This makes for much clearer pictures. Althernatively the greying could occur before the wall/clipping zone. 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/ Subject: [therion] Re: drawing up - seeking advice From: Stacho Mudrak Date: Wed, 31 Mar 2004 16:12:49 +0200 To: therion@speleo.sk >> neat. Although I strongly contend that lines which go underneath should have >> a small gap so that they do not touch the wall which they are going under. >> This makes for much clearer pictures. Althernatively the greying could occur >> before the wall/clipping zone. You're right - this would help a lot, but... ... our scrap outline is given by bezier curves. And as far as I know, problem of finding parallel curve to given bezier curve has no analytical solution (numerical isn't possible to do in metapost - too slow). Any ideas? S. therion Digest of: get.101_200 Topics (messages 101 through 200): Re: drawing up - seeking advice 101 by: Martin Sluka 102 by: Stacho Mudrak Therion 0.3.0 103 by: m.b.speleo.sk 104 by: Wookey 105 by: Stacho Mudrak 106 by: Martin Budaj 107 by: Wookey 108 by: Martin Budaj 109 by: Stacho Mudrak 115 by: Wookey 116 by: Stacho Mudrak 'subtype' syntax change proposal 110 by: Martin Budaj 111 by: Ladislav Bla¾ek 112 by: Wookey 113 by: Ladislav Bla¾ek 114 by: Wookey 117 by: Stacho Mudrak 118 by: Wookey 119 by: Ladislav Bla¾ek 120 by: Stacho Mudrak 121 by: Ladislav Bla¾ek therion 0.3.1 122 by: Stacho Mudrak Survex vs Therion 123 by: Olly Betts 124 by: Stacho Mudrak problem with 0.3.1 125 by: Wookey 126 by: Stacho Mudrak 127 by: Wookey 128 by: Wookey new user .... 129 by: Eric Madelaine 130 by: Martin Budaj 131 by: Stacho Mudrak 132 by: Stacho Mudrak 133 by: Eric Madelaine 134 by: Martin Sluka 135 by: Ladislav Blazek 136 by: Ladislav Blazek 137 by: Stacho Mudrak 141 by: Olly Betts 142 by: Wookey Re: Visit in Prague 138 by: Eric Madelaine 139 by: Martin Sluka 140 by: Eric Madelaine 150 by: Eric Madelaine 151 by: Martin Sluka Wook's persistent Therion bug 143 by: Wookey 144 by: Stacho Mudrak 145 by: Wookey 146 by: Martin Budaj 147 by: Wookey 148 by: Stacho Mudrak Re: french translation (fwd) 149 by: Eric Madelaine Re: Report on Therion Visit in Prague 152 by: Eric Madelaine 153 by: Michael Lake Extended Elevation, and other questions. 154 by: Eric Madelaine 155 by: Martin Budaj 156 by: Stacho Mudrak 157 by: Eric Madelaine 158 by: Martin Budaj Therion 0.3.2 159 by: Martin Budaj Re: Left-right-up data 160 by: Stacho Mudrak 164 by: Julian Todd how to connect scraps 161 by: Simeon Warner 162 by: Martin Sluka 163 by: Stacho Mudrak demo-rabbit doesn't process 165 by: Olly Betts 166 by: Martin Budaj 167 by: Olly Betts 168 by: Stacho Mudrak 172 by: Olly Betts 173 by: Stacho Mudrak Therion 0.3.3 announce 169 by: Martin Budaj Havranik 170 by: Martin Sluka 171 by: Martin Sluka How to change settings for just a few readings? 174 by: Olly Betts 175 by: Stacho Mudrak 176 by: Olly Betts 177 by: John Pybus 178 by: Stacho Mudrak 179 by: John Pybus 180 by: Stacho Mudrak 181 by: Stacho Mudrak snow and ice 182 by: Olly Betts 184 by: Stacho Mudrak 189 by: Olly Betts 190 by: Stacho Mudrak Example models? 183 by: Wookey 185 by: Stacho Mudrak 186 by: Stacho Mudrak 187 by: Wookey 188 by: Stacho Mudrak Unhelpful metapost error 191 by: Olly Betts 193 by: Olly Betts 194 by: Olly Betts 195 by: Stacho Mudrak 196 by: Stacho Mudrak 197 by: Olly Betts thbook typo corrections 192 by: Olly Betts Fixed station symbols 198 by: zillig.hoki.ibp.fhg.de 199 by: zillig.hoki.ibp.fhg.de Re: Models. 200 by: Wookey Administrivia: --- Administrative commands for the therion list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: For help and a description of available commands, send a message to: To subscribe to the list, send a message to: To remove your address from the list, just send a message to the address in the ``List-Unsubscribe'' header of any list message. If you haven't changed addresses since subscribing, you can also send a message to: For addition or removal of addresses, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete the transaction. If you need to get in touch with the human owner of this list, please send a message to: Please include a FORWARDED list message with ALL HEADERS intact to make it easier to help you. --- Enclosed is a copy of the request I received. Return-Path: Received: (qmail 17059 invoked from network); 15 Apr 2005 07:44:18 -0000 Received: from unknown (HELO av3.stonline.sk) (213.81.152.134) by platon.atlantis.sk with DES-CBC3-SHA encrypted SMTP; 15 Apr 2005 07:44:18 -0000 Received: from smtp.stonline.sk (localhost [127.0.0.1]) by av3.stonline.sk (8.12.11/8.12.11) with ESMTP id j3F7gBnv008656; Fri, 15 Apr 2005 09:42:32 +0200 X-Virus-Scanner: This message was checked by NOD32 Antivirus system NOD32 for Linux Mail Server. For more information on NOD32 Antivirus System, please, visit our website: http://www.nod32.com/. Received: from [10.0.0.10] (adsl-data-21.84-47-107.telecom.sk [84.47.107.21]) by smtp2.stonline.sk (STOnline ESMTP Server) with ESMTPA id <0IEZ0000Q9DMX1@smtp2.stonline.sk>; Fri, 15 Apr 2005 09:41:47 +0200 (MEST) Date: Fri, 15 Apr 2005 09:41:45 +0200 From: Stacho Mudrak Subject: (no subject) Sender: groupssl@stonline.sk To: therion-get.1_100@speleo.sk, therion-get.101_200@speleo.sk, therion-get.201_300@speleo.sk, therion-get.301_400@speleo.sk, therion-get.401_500@speleo.sk, therion-get.501_600@speleo.sk, therion-get.601_700@speleo.sk Message-id: <425F7039.6090102@speleo.sk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-NOD32Result: clean ---------------------------------------------------------------------- Subject: [therion] Re: drawing up - seeking advice From: Martin Sluka Date: Thu, 1 Apr 2004 07:51:37 +0200 To: therion@speleo.sk At 16:12 +0200 31.3.2004, Stacho Mudrak wrote: ******************************************* > > neat. Although I strongly contend that lines which go underneath should have > >> a small gap so that they do not touch the wall which they are going under. >> This makes for much clearer pictures. Althernatively the greying could occur >> before the wall/clipping zone. > > > You're right - this would help a lot, but... > > ... our scrap outline is given by bezier curves. And as far as I know, > problem of finding parallel curve to given bezier curve has no > analytical solution (numerical isn't possible to do in metapost - too > slow). Any ideas? > > S. From my prepress experience - there is quite easy way to add contour to bezier if you copy the curve exactly UNDER actual curve and change the width (increase it), color, ... of the underlaying one. Martin -- Subject: Re: [therion] Re: drawing up - seeking advice From: Stacho Mudrak Date: Thu, 01 Apr 2004 08:53:26 +0200 To: therion@speleo.sk > From my prepress experience - there is quite easy way to add contour to bezier if you copy the curve exactly UNDER actual curve and change the width (increase it), color, ... of the underlaying one. I'm afraid, this would not help in this case. The reson is very simple: When you're attaching two scraps from different levels - they need to be connected exactly. But if you would write this white line - there will be also a thin space between walls, you have specified that have to join exactly :( But some modification of this approach can be the solution. S. Subject: Therion 0.3.0 From: m.b@speleo.sk Date: Fri, 16 Apr 2004 11:25:29 +0200 (CEST) To: therion@speleo.sk Hi everybody! Therion 0.3.0 is available. Substantial changes: * Therion goes 3D: vrml, 3dmf and native therion formats with passages reconstructed from 2D maps * completely new Win32 installation with TeX and Tcl/Tk included XTherion: * 3D model viewer added * Map editor: only the visible part of background images is zoomed (less memory consumption and speed improvement) * Map editor: support for JPEG and PNG images if tkImg extension is installed M. Subject: Re: Therion 0.3.0 From: Wookey Date: Mon, 19 Apr 2004 15:29:44 +0100 To: therion@speleo.sk +++ m.b@speleo.sk [04-04-16 11:25 +0200]: >> Hi everybody! >> >> Therion 0.3.0 is available. Substantial changes: >> >> * Therion goes 3D: vrml, 3dmf and native therion formats with >> passages reconstructed from 2D maps >> * completely new Win32 installation with TeX and Tcl/Tk included >> >> XTherion: >> >> * 3D model viewer added >> * Map editor: only the visible part of background images is zoomed >> (less memory consumption and speed improvement) >> * Map editor: support for JPEG and PNG images if tkImg extension >> is installed wow - lots of activity. I've debianised this version and it seems to work well. I like the new zooming, which is definately a lot faster. One thing. I noticed the map-header syntax has changed (for the better) because my files gave an error, (glad to see the thbook stays in sync - comendable!) so I ought to change the thconvert script to modify this too. Are there any other incompatible syntax changes that should be converted? BTW my 'extra line' problem remains (not suprisingly). I haven't had time to analyse this (due to drawing surveys the old-fashioned way), but I'll get a minimal example to send you soon. 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/ Subject: Re: [therion] Re: Therion 0.3.0 From: Stacho Mudrak Date: Mon, 19 Apr 2004 16:33:30 +0200 To: therion@speleo.sk > BTW my 'extra line' problem remains (not suprisingly). I haven't had time to > analyse this (due to drawing surveys the old-fashioned way), but I'll get a > minimal example to send you soon. I've received today a file from Martin Sluka, where this extra line problem is also present. I believe, now I can fix it very fast. Regards, S. Subject: Re: [therion] Re: Therion 0.3.0 From: "Martin Budaj" Date: Mon, 19 Apr 2004 16:45:51 +0200 (CEST) To: therion@speleo.sk >> Are there any other incompatible syntax changes that should be converted? Only those mentioned in the CHANGES file: - centreline command: fix doesn't accept covariances specification - layout command: map-header improved - removed item in cfg file: path-cavern M. Subject: Re: Therion 0.3.0 From: Wookey Date: Mon, 19 Apr 2004 16:51:55 +0100 To: therion@speleo.sk +++ Martin Budaj [04-04-19 16:45 +0200]: >>> > Are there any other incompatible syntax changes that should be converted? > >> >> Only those mentioned in the CHANGES file: OK, thanx >> - centreline command: fix doesn't accept covariances specification Oh yes, I meant to ask about that - why have you moved the loop closure inside Therion (out of survex) and not even accepted the covariance numbers (even if not processing them)? It has taken many years to get the loop closure in Survex working right - and whilst it is easier to re-implment in C++ than it was to do in C originally I wonder why bother - it is very likely to have bugs in, and it seems to me that using the external program made a lot of sense here. (or have you used the actual code rather than re-implemented?) Also the co-variances are important for fixed points (especially GPS fixed points which often aren't very 'fixed' at all). At the very least the information should be retained in the files even if it is not currently used. This seems like a retrograde step. If survex is not doing quite what you want then fixing survex ought to be a better plan. We need better Therion/survex cooperation. I must get Olly to start reading this list. I don't mean to sound too critical, but this seems an odd an retrograde step to me. Survex/Therion incompatibilites are already a problem, and this seems like adding a new one, for no obvious gain. 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/ Subject: Re: [therion] Re: Therion 0.3.0 From: "Martin Budaj" Date: Tue, 20 Apr 2004 07:51:54 +0200 (CEST) To: therion@speleo.sk >> Oh yes, I meant to ask about that - why have you moved the loop closure >> inside Therion (out of survex) Well, there were some good reasons to do it: - installation is simpler now - there were some problems with survex' msg files -- if msg file was missing, cavern didn't start at all; if cavern used the file, we had problems with parsing the translated log file for information about centreline (e.g. E-W range) - we had somehow to parse err file to get information about loop errors (this will go to SQL export; bad loops may be highlighted in the map...) >> Also the co-variances are important for fixed points (especially GPS fixed >> points which often aren't very 'fixed' at all). At the very least the >> information should be retained in the files even if it is not currently >> used. That sounds sensible. I only wonder if some GPS device provides info about covariances. >> This seems like a retrograde step. If survex is not doing quite what you >> want then fixing survex ought to be a better plan. We need better >> Therion/survex cooperation. I must get Olly to start reading this list. We waited for cavern-library (promised in the SPUD to-do for more than 2 years) and would be happy to use it. In Therion everything is prepared to link such a library. >> I don't mean to sound too critical, but this seems an odd an retrograde >> step >> to me. Survex/Therion incompatibilites are already a problem, and this >> seems >> like adding a new one, for no obvious gain. Only one note: even if the algorithm used now is not working perfectly, it doesn't damage your data. If it will be improved or replaced, simply recompile your data and get perfect maps :) With regards, Martin Subject: Re: [therion] Re: Therion 0.3.0 From: Stacho Mudrak Date: Tue, 20 Apr 2004 09:04:19 +0200 To: therion@speleo.sk > Oh yes, I meant to ask about that - why have you moved the loop closure > inside Therion (out of survex) and not even accepted the covariance numbers > (even if not processing them)? First of all - we have an experience, that allowing users to specify too many things (that are not processed) is quite misleading. Therefore we have decided to strictly remove all the stuff, that is not used and will not be used in the next major version (user can use comments in any case). > Also the co-variances are important for fixed points (especially GPS fixed > points which often aren't very 'fixed' at all). At the very least the > information should be retained in the files even if it is not currently used. Here I have some doubts. Do you know anybody, who has ever inserted these covariances in reality ??? As far as I understand the process of GPS - these variance/covariances strongly depend on current positions of satelites and local landscape. Therefore I do not believe, that you're able to read somewhere variances/covariances that make a lot of sense. > C++ than it was to do in C originally I wonder why bother - it is very > likely to have bugs in, and it seems to me that using the external program > made a lot of sense here. (or have you used the actual code rather than > re-implemented?) I've tried to use actual code - but it was not possible to integrate it into therion. So I've implemented my own very simple loop closure algorithm. > This seems like a retrograde step. If survex is not doing quite what you > want then fixing survex ought to be a better plan. We need better > Therion/survex cooperation. I must get Olly to start reading this list. I agree - survex has a very sophisticated loop closure, and from this point of view - replacing it was a retrograde step, but: 1. our ultimate priority was to have windows standalone installation (a lot of people asked for it) - and it was not possible to integrate survex in it 2. the quality of loop closure is very relative - if you have blunders in it, no loop closure is good. If not - every loop closure produces results, that looks OK :) 3. I've been missing one thing in survex - and this is the system of real closed loops with minimal number of shots. When we've closed a large loop in the cave, I was not able to read from err-files the real error on this loop. All I was able to get was survex error correction on some segments of it - but this is only a partial and not interpretable number, that depends on loop closure algorithm. > I don't mean to sound too critical, but this seems an odd an retrograde step > to me. Survex/Therion incompatibilites are already a problem, and this seems > like adding a new one, for no obvious gain. Please, be very critical! If you would not be - I would never do a fast zooming in xtherion. Now (thanks only to you, everybody else was not enought critical) it works and even on my "fast" computer with a "lots" of RAM it saves me a huge amount of time. In fact, survex loop closure was not removed from source code. Using a simple switch (at the begining of thdb1d.cxx file), you can turn it back for you (if therion loop closure is not good enought). In the future, this can be also option in the initialization file - which loop closure should be used. But until it will not be possible to link survex as independent library, we will use this alternative... S. Subject: Re: Therion 0.3.0 From: Wookey Date: Thu, 22 Apr 2004 18:58:48 +0100 To: therion@speleo.sk +++ m.b@speleo.sk [04-04-16 11:25 +0200]: >> Hi everybody! >> >> Therion 0.3.0 is available. Substantial changes: Just to check - does this remove the need for Survex entirely now, or is it still used for something? (I need to change dependencies in Debian) Thanx for replies on why - you make some good points. I have passed them on to Olly to discuss further, and maybe make survex-lib happen sooner, but I have also accidentally deleted them - oops (hence reply to messsage earlier in thread). 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/ Subject: Re: [therion] Re: Therion 0.3.0 From: Stacho Mudrak Date: Fri, 23 Apr 2004 09:19:13 +0200 To: therion@speleo.sk > > > Just to check - does this remove the need for Survex entirely now, or is it > still used for something? (I need to change dependencies in Debian) Yes. It is not needed now for data processing. But we're still using survex .3d viewer. S. Subject: 'subtype' syntax change proposal From: "Martin Budaj" Date: Wed, 21 Apr 2004 13:04:15 +0200 (CEST) To: therion@speleo.sk Topic for discussion: incompatible change of -subtype option for line symbols Working on 2D export and 3D reconstruction we came to incredible obstacles caused by the -subtype syntax: it currently applies to an arbitrary subpath of the line. Proposed new behaviour is to allow only one global -subtype specification for the whole line. Would it cause big troubles to split lines in every point where subtype is changing in your existing data? Martin Subject: Re: [therion] 'subtype' syntax change proposal From: Ladislav Blažek Date: Thu, 22 Apr 2004 08:46:46 +0200 (CEST) To: therion@speleo.sk >> Topic for discussion: incompatible change >> of -subtype option for line symbols >> >> Working on 2D export and 3D reconstruction >> we came to incredible obstacles >> caused by the -subtype syntax: it currently >> applies to an arbitrary >> subpath of the line. Proposed new behaviour >> is to allow only one global >> -subtype specification for the whole line. >> >> Would it cause big troubles to split lines >> in every point where subtype is >> changing in your existing data? Hi, I didn't know about this possibility (-subtype for subpath of line) so I use separate lines for each -subtype. No problem for me. Lada Blazek -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz Subject: Re: 'subtype' syntax change proposal From: Wookey Date: Thu, 22 Apr 2004 16:41:15 +0100 To: therion@speleo.sk +++ Martin Budaj [04-04-21 13:04 +0200]: >> Topic for discussion: incompatible change of -subtype option for line symbols >> >> Working on 2D export and 3D reconstruction we came to incredible obstacles >> caused by the -subtype syntax: it currently applies to an arbitrary >> subpath of the line. Proposed new behaviour is to allow only one global >> -subtype specification for the whole line. >> >> Would it cause big troubles to split lines in every point where subtype is >> changing in your existing data? I suspect that using xtherion one normally selects whole paths to apply type/subtype to. I don't think I have any lines which partly have one subtype and partly not. But so far I actaully have only 2 scraps so it doesn't matter anyway for me. I suppose I may have 'invisible' as part of a line... I do thing that the list of linetype/subtypes could be improved. I wanted to have a 'presumed' where 'presumed' wasn't a valid subtype for it. This seemed a bit arbitrary - why can I have a presumed wall but not a presumed rock-edge (Something like that - I forget exactly what it was). It seems to me that nearly everything could be 'presumed' or 'invisible', and also perhaps that some subtype should be main types. We could usefully review the list to see if it still makes sense. 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/ Subject: Re: [therion] Re: 'subtype' syntax change proposal From: Ladislav Blažek Date: Thu, 22 Apr 2004 17:52:31 +0200 (CEST) To: therion@speleo.sk >> I do thing that the list of >> linetype/subtypes could be improved. I >> wanted to >> have a 'presumed' where >> 'presumed' wasn't a valid subtype for it. >> This seemed a bit arbitrary - why can I >> have a presumed wall but not a >> presumed rock-edge (Something like that - I >> forget exactly what it was). It >> seems to me that nearly everything could be >> 'presumed' or 'invisible', and >> also perhaps that some subtype should be >> main types. We could usefully >> review the list to see if it still makes >> sense. Presumed = presumed. It means that I presume continuation but I don't know what's the type of continuation. Simply I presume that it is "wall". If you know that it is rock-border, why you need presumed rock-border? Lada -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz Subject: Re: 'subtype' syntax change proposal From: Wookey Date: Thu, 22 Apr 2004 17:13:50 +0100 To: therion@speleo.sk +++ Ladislav Bla?ek [04-04-22 17:52 +0200]: >>> > I do thing that the list of >>> > linetype/subtypes could be improved. I >>> > wanted to >>> > have a 'presumed' where >>> > 'presumed' wasn't a valid subtype for it. >>> > This seemed a bit arbitrary - why can I >>> > have a presumed wall but not a >>> > presumed rock-edge (Something like that - I >>> > forget exactly what it was). It >>> > seems to me that nearly everything could be >>> > 'presumed' or 'invisible', and >>> > also perhaps that some subtype should be >>> > main types. We could usefully >>> > review the list to see if it still makes >>> > sense. > >> >> Presumed = presumed. It means that I presume continuation but I >> don't know what's the type of continuation. Simply I presume that >> it is "wall". If you know that it is rock-border, why you need >> presumed rock-border? Because I am looking over an edge and I can see one side of a big rock, but not the other. The passage shape makes me think that this is a rock not a wall so the part I can see is 'rock border', but the part where it goes out of sight would be drawn as 'presumed rock border' - ie "- - -" with correct line thickness. Or I can see along a passage and one side is wall, the other is a big boulder. I cannot see beyond so both sides need to be drawn as 'presumed continuation', but it looks wrong if the rock side suddenly changes line thickness to be a wall at the point it becomes presumed. (this would be the case if I followed your suggestion above). Also what about the situation where the wall is made of blocks - so now it is 'wall, subtype blocks', but I also want to make it 'presumed' at the point I cannot see. I don't think we can have two subtypes, but there should be a way to draw this...(this illustrates what I mean about reviewing walltypes and subtypes. 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/ Subject: [therion] Re: 'subtype' syntax change proposal From: Stacho Mudrak Date: Fri, 23 Apr 2004 09:50:58 +0200 To: therion@speleo.sk > I do thing that the list of linetype/subtypes could be improved. I agree at this point. -subtype option comes from times, when we had intention to make things universal and complex (and complicated :) . I'm not sure, but my feeling is that option -subtype should be removed at all. The reason is simple. If you do not specify the subtype, some subtype is assumed as default anyway. So it is just complicating things. I think, having types: wall wall-blocks wall-sand wall-debris would be better, than specifying all the time the subtype. What do you think? S. Subject: Re: 'subtype' syntax change proposal From: Wookey Date: Fri, 23 Apr 2004 10:12:40 +0100 To: therion@speleo.sk +++ Stacho Mudrak [04-04-23 09:50 +0200]: >> > >>> >I do thing that the list of linetype/subtypes could be improved. > >> >> I agree at this point. >> >> -subtype option comes from times, when we had intention to make things >> universal and complex (and complicated :) . I'm not sure, but my feeling is >> that option -subtype should be removed at all. The reason is simple. If you >> do not specify the subtype, some subtype is assumed as default anyway. So >> it is just complicating things. >> >> I think, having types: >> >> wall >> wall-blocks >> wall-sand >> wall-debris >> >> would be better, than specifying all the time the subtype. What do you >> think? I am inclinded to agree, although I'm not sure I have used it in enough detail to be confident. There are two main thing to consider - what the line represents and 'modifiers' to how that line appears or is used. So above is a list of what the line represents, but things like 'invisbile', 'presumed', and maybe others are modifiers (or 'subtypes' if you like). These things are orthogonal. A good look at the full list thinking in this way, and considered how you want real surveys to look/be drawn would be a good way to rationalise the list. So, yes I think I agree that wall and wall-blocks should both be types, but wall-blocks-presumed possibly shouldn't be. Theother thing to consider is the interface. Exactly how we specify the data is probably a bit arbitrary, but if the new version produces a very long drop-down list that is inconvenient to use then maybe the interface needs to change (so you still select wall, then blocks) or maybe it is not actually worth changing the spec. That is some things to think about really, rather than an actual opinion on what is best. 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/ Subject: Re: [therion] Re: 'subtype' syntax change proposal From: Ladislav Blažek Date: Fri, 23 Apr 2004 11:39:19 +0200 (CEST) To: therion@speleo.sk I agree with Wookey that "...very long drop-down list is inconvenient to use...". I think that much more better are two list - one for line type, second for subtype. So I am for GUI change but not for syntax change. Lada B. -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz Subject: Re: [therion] Re: 'subtype' syntax change proposal From: Stacho Mudrak Date: Fri, 23 Apr 2004 11:46:47 +0200 To: therion@speleo.sk > So, yes I think I agree that wall and wall-blocks should both be types, but > wall-blocks-presumed possibly shouldn't be. OK, but I've never seen in any cave symbol list "presumed wall probably formed by blocks" :))), but I've seen many times "presumed wall" or something simmilar - so I think wall-presumed will be enought. And in any case - for each combination of type/subtype - you need a separate symbol. Therefore I think we need only types... Another point - wall-invisible or wall -subtype invisible is completely not realistic. Therefore it should be probably renamed to outline or something like this... > Theother thing to consider is the interface. Exactly how we specify the data > is probably a bit arbitrary, Yes, I've intention to change it in any case - the combobox is not very lucky solution. S. Subject: Re: [therion] Re: 'subtype' syntax change proposal From: Ladislav Blažek Date: Fri, 23 Apr 2004 12:39:18 +0200 (CEST) To: therion@speleo.sk >> Yes, I've intention to change it in any >> case - the combobox is not very >> lucky solution. What about tree structure of the menu... - wall - normal - debris - sand - ... - rock - border - edge - ... L.B. -- Surfujete pres VOLNY? Tak proc jeste nejste ve VOLNY klubu? Nyni exkluzivne pro cleny klubu soutez o skvele ceny. http://klub.volny.cz Subject: therion 0.3.1 From: Stacho Mudrak Date: Mon, 26 Apr 2004 09:00:18 +0200 To: therion@speleo.sk Hi, last friday, we've released version 0.3.1, in which some important bugs have been fixed. S. Subject: Survex vs Therion From: Olly Betts Date: Wed, 28 Apr 2004 01:33:35 +0100 To: therion@speleo.sk On Thu, Apr 22, 2004 at 11:31:49AM +0100, Wookey wrote: >> It would probably help things like this a lot if you were able to monitor >> the Therion list Wookey forwarded me some recent messages. I'm now subscribed (well, it says I am - nothing has arrived yet). >> This seems like a retrograde step. If survex is not doing quite what you >> want then fixing survex ought to be a better plan. We need better >> Therion/survex cooperation. I must get Olly to start reading this list. It would be better to try to coordinate what we're up to to prevent duplicating work, or worse working against each other. I did actually try to start to encourage a bit of cooperation a while ago - in particular regarding the details of therion's "charset" command which Survex could usefully implement. But I didn't get a useful response... >>> > Oh yes, I meant to ask about that - why have you moved the loop closure >>> > inside Therion (out of survex) > >> >> Well, there were some good reasons to do it: >> >> - installation is simpler now >> - there were some problems with survex' msg files -- if msg >> file was missing, cavern didn't start at all; >> if cavern used the file, we had problems with parsing >> the translated log file for information about centreline >> (e.g. E-W range) Survex programs don't have any version of the messages compiled in, save for a handful of messages needed to report errors in loading the messages (unlike programs using GNU gettext which always compiles in all the English messages). The survex message code actually predates GNU gettext. It's much more frugal on memory, so I'm reluctant to chuck it away - on PDAs this still genuinely matters. Anyway, the upshot is that cavern simply *can't* run without the message files - it couldn't output anything! But if you just want to hide cavern inside therion, it wouldn't be hard to compile in messages. You could even have your own set of "translations" providing easy to machine parse output for E-W range, etc. The pieces needed to provide a mechanism to compile in a single translation are already mostly there. >> - we had somehow to parse err file to get information about >> loop errors (this will go to SQL export; bad loops may be >> highlighted in the map...) Again, it would be pretty easy to add code to allow a custom-built cavern to output error statistics in whatever format you desire. >>> > This seems like a retrograde step. If survex is not doing quite what you >>> > want then fixing survex ought to be a better plan. We need better >>> > Therion/survex cooperation. I must get Olly to start reading this list. > >> >> We waited for cavern-library (promised in the SPUD to-do for more than 2 >> years) and would be happy to use it. In Therion everything is prepared to >> link such a library. Nobody's mentioned to me that they're waiting for loop closure to become a library. I've got a list of things to do, and I have to decide on a sensible order. So far, making loop closure a library has been well down the list because there are other items which will do more to improve the user's "survex experience". If the code would be useful, perhaps this should be higher priority... >>> >Oh yes, I meant to ask about that - why have you moved the loop closure >>> >inside Therion (out of survex) and not even accepted the covariance numbers >>> >(even if not processing them)? > >> >> First of all - we have an experience, that allowing users to specify too >> many things (that are not processed) is quite misleading. Therefore we have >> decided to strictly remove all the stuff, that is not used and will not be >> used in the next major version (user can use comments in any case). Changing these fields to comments would require the user to edit the file though. And then remember to change it back. >> Here I have some doubts. Do you know anybody, who has ever inserted these >> covariances in reality ??? As far as I understand the process of GPS - >> these variance/covariances strongly depend on current positions of >> satelites and local landscape. Therefore I do not believe, that you're able >> to read somewhere variances/covariances that make a lot of sense. http://www.hartrao.ac.za/geodesy/gps.html (Search for "covariance"). A consumer grade GPS probably won't report them (some report DOP I think). Survey grade units will though, and since the loop closure algorithm can make use of the information, it's a shame not to be able to specify it when you have it. >> 3. I've been missing one thing in survex - and this is the system of real >> closed loops with minimal number of shots. When we've closed a large loop >> in the cave, I was not able to read from err-files the real error on this >> loop. All I was able to get was survex error correction on some segments of >> it - but this is only a partial and not interpretable number, that depends >> on loop closure algorithm. Sadly the idea of loop closure statistics for "complete loops" seems obvious but isn't really very meaningful. The closure is done on those segments, and to report information for "complete loops", you have to combine those segments in some arbitrary way. And by combining them you lose information - in particular large errors which indicate possible blunders will be less obvious. "Minimal number of shots" seems particularly arbitrary. "Minimum length" seems a bit more justifiable. But either is going to prefer to pick out the survey loop around the walls of the chamber near the entrance rather than your magnificent new closure involving several kms of survey. The most sensible approach is to display the information graphically. Then where the "complete loops" are is no longer an issue. And if you want to know the closure on a particular loop, you can highlight it with the mouse and ask. Cheers, Olly Subject: [therion] Re: Survex vs Therion From: Stacho Mudrak Date: Wed, 28 Apr 2004 10:50:19 +0200 To: therion@speleo.sk > I did actually try to start to encourage a bit of cooperation a while > ago - in particular regarding the details of therion's "charset" command > which Survex could usefully implement. But I didn't get a useful > response... I'm sorry. Are there any problems concernign the character sets? > But if you just want to hide cavern inside therion, it wouldn't be > hard to compile in messages. You could even have your own set of > "translations" providing easy to machine parse output for E-W range, > etc. The pieces needed to provide a mechanism to compile in a single > translation are already mostly there. I've tried this - but without success. The problem were not the messages, but entire compilation. It's very dependent on a compiler configuration - and I'm not very familiar with automake and autoconf. > Nobody's mentioned to me that they're waiting for loop closure to > become a library. I've got a list of things to do, and I have to decide > on a sensible order. So far, making loop closure a library has been > well down the list because there are other items which will do more to > improve the user's "survex experience". You're right. But therion worked as it worked for a long time, and we have no problems with it, until we've urgently needed a simple standalone windows installation. > If the code would be useful, perhaps this should be higher priority... It would helped us a lot. > A consumer grade GPS probably won't report them (some report DOP I > think). Survey grade units will though, and since the loop closure > algorithm can make use of the information, it's a shame not to be > able to specify it when you have it. OK, I see you're right. I'll add these covariances back. I just thought, nobody has never used them... Or do you really know somebody? > Sadly the idea of loop closure statistics for "complete loops" seems > obvious but isn't really very meaningful. The closure is done on those > segments, and to report information for "complete loops", you have to > combine those segments in some arbitrary way. And by combining them > you lose information - in particular large errors which indicate > possible blunders will be less obvious. > > "Minimal number of shots" seems particularly arbitrary. "Minimum > length" seems a bit more justifiable. But either is going to prefer to > pick out the survey loop around the walls of the chamber near the > entrance rather than your magnificent new closure involving several kms > of survey. > > The most sensible approach is to display the information graphically. > Then where the "complete loops" are is no longer an issue. And if you > want to know the closure on a particular loop, you can highlight it with > the mouse and ask. This is interesting. I've never thought about it this way... I'll probably try some examples to see, whether it really workes this way... I'm very curious. Thanks a lot for your explanation and comments. S. Subject: problem with 0.3.1 From: Wookey Date: Tue, 25 May 2004 17:49:54 +0100 To: Therion List I've upgraded to 0.3.0/0.3.1 and it does indeed fix the 'extra newline problem' which is great but it won't compile my dataset that was working OK with 0.2.19. I get: "Invalid command context" at line 6 in this file: 1 encoding utf-8 2 survey soundriver 3 4 map elevator -title "Terikan: Elevator Entrance" 5 farside@river 6 farside2@river 7 endmap 8 ........ Why might that happen? 0.3.0 is now current in Debian. I'd like to fix this problem before uploading 0.3.1. 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/ Subject: Re: problem with 0.3.1 From: Stacho Mudrak Date: Wed, 26 May 2004 09:22:10 +0200 To: therion@speleo.sk At 18:49 25. 5. 2004, you wrote: > I've upgraded to 0.3.0/0.3.1 and it does indeed fix the 'extra newline > problem' which is great but it won't compile my dataset that was working OK > with 0.2.19. I've checked this (running 0.3.1 with your dataset), and on my machine (Mandrake 9.2, and WinXP) it did not generated this error. In any case, there is no error in the input data, so we have to search for error somewhere else. I can imagine following errors: 1. Something is still not OK with end-of-line (I do not believe, but it may be the case). My be, you should run threpair-files in your data directory. Also the binary screenshot of the begining of this file would help a lot. Something like 00000 65 6E 63 6F ¦ 64 69 6E 67 ¦ 20 20 75 74 ¦ 66 2D 38 0A encoding utf-8. 00010 73 75 72 76 ¦ 65 79 20 73 ¦ 6F 75 6E 64 ¦ 72 69 76 65 survey soundrive 00020 72 0A 20 0A ¦ 20 20 6D 61 ¦ 70 20 65 6C ¦ 65 76 61 74 r. . map elevat 00030 6F 72 20 2D ¦ 74 69 74 6C ¦ 65 20 22 54 ¦ 65 72 69 6B or -title "Terik 00040 61 6E 3A 20 ¦ 45 6C 65 76 ¦ 61 74 6F 72 ¦ 20 45 6E 74 an: Elevator Ent 00050 72 61 6E 63 ¦ 65 22 0A 20 ¦ 20 20 20 66 ¦ 61 72 73 69 rance". farsi 00060 64 65 40 72 ¦ 69 76 65 72 ¦ 0A 20 20 20 ¦ 20 66 61 72 de@river. far 00070 73 69 64 65 ¦ 32 40 72 69 ¦ 76 65 72 0A ¦ 20 20 65 6E side2@river. en 00080 64 6D 61 70 ¦ 20 20 0A 0A ¦ 20 0A 20 20 ¦ 23 63 6F 6E dmap .. . #con 00090 6E 65 63 74 ¦ 69 6F 6E 73 ¦ 0A 20 20 0A ¦ 20 20 6A 6F nections. . jo 000A0 69 6E 20 66 ¦ 61 72 73 69 ¦ 64 65 77 65 ¦ 73 74 31 40 in farsidewest1@ 2. It is more serious error - but then it would be great, if you can compile debug version of therion (make config-debug; make). Then run this debug version with your data and send us the exact error message (there will be source position also included). Because there is no error in your input file => error must be in therion. Thanks, S. Subject: Re: problem with 0.3.1 From: Wookey Date: Wed, 26 May 2004 19:03:13 +0100 To: therion@speleo.sk +++ Stacho Mudrak [04-05-26 09:22 +0200]: >> At 18:49 25. 5. 2004, you wrote: > >>> >I've upgraded to 0.3.0/0.3.1 and it does indeed fix the 'extra newline >>> >problem' which is great but it won't compile my dataset that was working OK >>> >with 0.2.19. > >> >> I've checked this (running 0.3.1 with your dataset), and on my machine >> (Mandrake 9.2, and WinXP) it did not generated this error. In any case, >> there is no error in the input data, so we have to search for error >> somewhere else. I can imagine following errors: >> >> 1. Something is still not OK with end-of-line (I do not believe, but it may >> be the case). My be, you should run threpair-files in your data directory. >> Also the binary screenshot of the begining of this file would help a lot. >> Something like >> >> 00000 65 6E 63 6F ? 64 69 6E 67 ? 20 20 75 74 ? 66 2D 38 0A encoding >> utf-8. >> 00010 73 75 72 76 ? 65 79 20 73 ? 6F 75 6E 64 ? 72 69 76 65 survey >> soundrive >> 00020 72 0A 20 0A ? 20 20 6D 61 ? 70 20 65 6C ? 65 76 61 74 r. . map >> elevat >> 00030 6F 72 20 2D ? 74 69 74 6C ? 65 20 22 54 ? 65 72 69 6B or -title >> "Terik >> 00040 61 6E 3A 20 ? 45 6C 65 76 ? 61 74 6F 72 ? 20 45 6E 74 an: Elevator >> Ent >> 00050 72 61 6E 63 ? 65 22 0A 20 ? 20 20 20 66 ? 61 72 73 69 rance". >> farsi >> 00060 64 65 40 72 ? 69 76 65 72 ? 0A 20 20 20 ? 20 66 61 72 de@river. >> far >> 00070 73 69 64 65 ? 32 40 72 69 ? 76 65 72 0A ? 20 20 65 6E side2@river. >> en >> 00080 64 6D 61 70 ? 20 20 0A 0A ? 20 0A 20 20 ? 23 63 6F 6E dmap .. . >> #con >> 00090 6E 65 63 74 ? 69 6F 6E 73 ? 0A 20 20 0A ? 20 20 6A 6F nections. . >> jo >> 000A0 69 6E 20 66 ? 61 72 73 69 ? 64 65 77 65 ? 73 74 31 40 in >> farsidewest1@ Not in quite such a helpful format but: wookey@knossos:~$ hexdump soundriver.th | more 0000000 6e65 6f63 6964 676e 2020 7475 2d66 0a38 0000010 7573 7672 7965 7320 756f 646e 6972 6576 0000020 0a72 0a20 2020 616d 2070 6c65 7665 7461 0000030 726f 2d20 6974 6c74 2065 5422 7265 6b69 0000040 6e61 203a 6c45 7665 7461 726f 4520 746e 0000050 6172 636e 2265 200a 2020 6620 7261 6973 0000060 6564 7240 7669 7265 200a 2020 6620 7261 0000070 6973 6564 4032 6972 6576 0a72 2020 6e65 0000080 6d64 7061 2020 200a 2020 0a20 0a20 2020 0000090 6323 6e6f 656e 7463 6f69 736e 200a 0a20 00000a0 2023 6a20 696f 206e 6166 7372 6469 4065 >> 2. It is more serious error - but then it would be great, if you can >> compile debug version of therion (make config-debug; make). Then run this >> debug version with your data and send us the exact error message (there >> will be source position also included). Because there is no error in your >> input file => error must be in therion. OK, I'll give that a go. 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/ Subject: Re: problem with 0.3.1 From: Wookey Date: Tue, 1 Jun 2004 18:00:50 +0100 To: therion@speleo.sk +++ Stacho Mudrak [04-05-26 09:22 +0200]: >> At 18:49 25. 5. 2004, you wrote: > >>> >I've upgraded to 0.3.0/0.3.1 and it does indeed fix the 'extra newline >>> >problem' which is great but it won't compile my dataset that was working OK >>> >with 0.2.19. > >> >> I've checked this (running 0.3.1 with your dataset), and on my machine >> (Mandrake 9.2, and WinXP) it did not generated this error. In any case, >> there is no error in the input data, so we have to search for error >> somewhere else. I can imagine following errors: >> >> 2. It is more serious error - but then it would be great, if you can >> compile debug version of therion (make config-debug; make). Then run this >> debug version with your data and send us the exact error message (there >> will be source position also included). Because there is no error in your >> input file => error must be in therion. OK - I did this and got the following: (hope this helps track it down) therion 0.3.1 initialization file: /etc/therion.ini reading open file -- /etc/therion.ini close file -- /etc/therion.ini configuration file: thconfig reading open file -- thconfig close file -- thconfig reading input -- soundriver.th open file -- soundriver.th therion (therion.cxx:332): error -- (thdatareader.cxx:213): soundriver.th [6] -- (thdatabase.cxx:161): invalid command context 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/ Subject: new user .... From: Eric Madelaine Date: Fri, 11 Jun 2004 18:41:15 +0200 To: therion@speleo.sk, eric.madelaine@sophia.inria.fr Hi, I'm Eric Madelaine, caver from the Nice area, in france. I have been fiddling with survey softwares for a while (25 years? ), even building one myself years ago (never get outside my club, but this was in the glorious years of Multics and PL1... distribution was not like it is now (;-)) I have been experimenting with therion for a couple weeks now, and i am really pleased with the results I already have. The concept of morphing vectorial drawings on the survey is of course the best we can imagine today, and the way that therion authors have integrated that in a specific survey tool in such a short time is impressive. A lot left to do yet in terms of 3D modelling, and certainly for getting the software accessible for non-computer people of course (;-) I have a number of questions, starting with things I ran into during my first tries( therion version 0.3.1 on Windows XP), for which I have not found the answer neither in the therin book, nor in wookey's tutorial paper. - How do you get a map (simple plan) with only the centerline, when you have not yet drawn, or scanned, the scraps ? - I have not been able to generate a correct extended elevation, it comes completely distorted. Is it supposed to work? (i've not found any example of elevation maps with the distribution) - I'd like to get a series of cross sections drawn on the side of a map page (or an atlas page), with only the cross-section lines drawn on the principal plan or elevation. Is there a simple way to do that ? It's rather difficult to attach those section points to a given scrap, that could be very far on the map... For more long term things: - Is there any plan, or any contact taken, for a french translation? If not, and if you think that internationalisation could be easy enough in the current version of the code, I could find the time to help you for that... - I have no clue on how the 3D models are generated, but I'm impressed of what you get from a single plan. I understand how you can guess proportionnal heights from the plan. I also have played with passage-heigth point specs (with correct results for tube-like passages, but much less success for rooms...) Do you have any plans/ideas to use cross-section information when available? to use both plan and elevation information when you have both ? or may be to use just LRUD data if you have nothing else ? Eric. Subject: Re: [therion] new user .... From: "Martin Budaj" Date: Mon, 14 Jun 2004 13:12:49 +0200 (CEST) To: therion@speleo.sk Hello, >> - How do you get a map (simple plan) with only the centerline, when you >> have not yet drawn, or scanned, the scraps ? Currently it's possible only to export centreline data as 3d model and print it in Aven or Compass. We want to extend the map command such that it could contain both scraps and surveys. When survey would be included in the map, all centreline data contained in the given survey would be displayed in the map. This would allow to mix (finished) scraps and centreline in one map. >> - I have not been able to generate a correct extended elevation, it >> comes completely distorted. Is it supposed to work? (i've not found any >> example of elevation maps with the distribution) We have neither used nor tested this extensively, but it worked on some simple examples. We'll add an example on the page. >> - I'd like to get a series of cross sections drawn on the side of a map >> page (or an atlas page), with only the cross-section lines drawn on the >> principal plan or elevation. Is there a simple way to do that ? What a great idea! But will take some time to implement. >> - Is there any plan, or any contact taken, for a french translation? If >> not, and if you think that internationalisation could be easy enough in >> the current version of the code, I could find the time to help you for >> that... Well, there were more requests to translate therion to other languages. This can be done on more levels (which one do you mean?): - map output - console messages from therion - xtherion's user interface - input language (commands) - documentation The first is fully supported and we have already Czech and Slovak translations. Contributions are welcome. The last requires more effort while the documentation is changing and growing rapidly. IMHO all other three fields (messages, UI, input language) are deeply wedded together -- I see no great advance in translating messages if xtherion's interface remains English, and only confusion if the UI gets translated but the user has to fill english options for commands (E.g. you see translated label 'options' in your language but have to fill '-subtype ...' in English) On the other side, translation of the input language could create a total mess. What about Punkt 0 0 Wurzel -Sichtbarkeit ein -abschneiden aus or bod 0 0 kore? -vidite?nos? áno -oreza? nie The only real solution I see is to make the GUI in such a way that therion and its language would be completely hidden. see http://labyrinth.speleo.sk >> Do you have any plans/ideas to use cross-section information when >> available? to use both plan and elevation information when you have both >> ? or may be to use just LRUD data if you have nothing else ? The short answer is yes, yes, yes. But these are longer-term wishes. Regards, Martin Subject: Re: new user .... From: Stacho Mudrak Date: Mon, 14 Jun 2004 13:53:52 +0200 To: therion@speleo.sk Hi, thanks a lot for your feedback and compliments. It's great to have another "computer" user :) Sorry for the late answers, we've been a little bit underground over the weekend. I would like to add something only to the last topic - 3D modelling: > - I have no clue on how the 3D models are generated, but I'm impressed > of what you get from a single plan. > I understand how you can guess proportionnal heights from the plan. I > also have played with passage-heigth point specs (with correct results > for tube-like passages, but much less success for rooms...) > Do you have any plans/ideas to use cross-section information when > available? to use both plan and elevation information when you have both > ? or may be to use just LRUD data if you have nothing else ? We have been thinking a lot how to generate "good" 3D models, because LRUD approach (eve if very very extended - various profiles, sections outside stations etc... was not good). So we have tried to generate models from a plan, but there was no idea how to do it - we have seen no software that is doing it (for caves), and we had no idea, how to specify the input format. So we have decided to have no 3D input, to avoid wrong input specification. The problem is, that specific data needed to generate 3D model depends on algorithm, we will use. Until now, we have implemented only one of them, that has some disadvantages - the rooms are one of big disadvantages of this algorithm. Now we are designing second version, that should be better - but until it will not work, I have no idea whether it will be... Things you have described (to use cross sections, plan & elevation data when available, also usage of LRUD if specified) are currently only our dreams (if I'm thinking about results) or nightmares (if I'm thinking about concrete algorithms). Our TODO in 3D is following: 1. replace the algorithm, that is adding 3rd dimension to the map - this is completely wrong and lot of distortions have origin here and add 3D modelling for vertical passages from elevation or extended projection scraps. 2. add special map symbol (not drawn on the map) that will specify up/down dimensions of the scrap. When this will be done, it will be easy also to use elevation data to generate correct ceiling/floor heights, and also LRUD data when available. 3. change the way of triangulation - refine where necessary (rooms) and roughen where it is too fine (straight tunnel passages). When this step will be done, we can start thinking about applying cross-secion shapes to 3D model and modelling the rooms. Last special point are existing LRUD data. We are thinking also about this (usually people have only these data when migrating to therion), and it is painful for them (as it is also for us) to not have 3D model for passages, where there are at least some 3D data. I'm just lazy to do it, because doing 3D reconstruction from maps is much more interesting. But I agree, it should be done, because it's not so complicated to create simple tubes where no other 3D data exists. I'll think about it. S. Subject: Re: [therion] new user .... From: Stacho Mudrak Date: Mon, 14 Jun 2004 13:58:34 +0200 To: therion@speleo.sk > > - I'd like to get a series of cross sections drawn on the side of a map > > page (or an atlas page), with only the cross-section lines drawn on the > > principal plan or elevation. Is there a simple way to do that ? > > What a great idea! But will take some time to implement. In any case - we will introduce in the next release probably special projection type for cross sections "-projection section", because using "-projection none" is quite misleading. Also we will definitely need connection between section-line in the map and section scrap. It will be needed to generate automatical cross-section labels (is there any standard used in france?) and also for 3D in the future. S. Subject: Re: [therion] new user .... From: Eric Madelaine Date: Mon, 14 Jun 2004 23:05:31 +0200 To: therion@speleo.sk Thanks Martin and Stacho, even if the first answers were... wait and see (;-) I will try to run simple examples for producing extended elevation maps, and I'll keep you informed of my progress... > Translations > - map output > The first is fully supported and we have already Czech and Slovak > translations. Contributions are welcome. Ok, this one is easy, I volunteer gladly for a french translatin. > - documentation > The last requires more effort while the documentation is changing and > growing rapidly. Well, yes... Ok, I will not promissed any large amount of work just now. But I'll think about what I can do, and I will certainly do some introduction paper in french, in the same spirit than wookey's paper in Compass Point. > - console messages from therion > - xtherion's user interface > - input language (commands) Console messages and UI are going together (just as they go in survex and the survex-related tools, for which I do contribute my own set of french sentences from time to time...). But this is why I wrote "if the code already supports internationalisation...". So I undertsand that it is not yet the case, and I will not push it anymore (:-( Input language is a separate topic, I agree. But then, I'm not sure why you would not be able to change the lexer without changing the rest of the parser, and get variants for the language... (Again, I'm not suggesting that you should do it) By the way, from which part of Slovakia are your exactly? I'm going to Prague for a european project meeting during the first week of july, so I was wondering whether we could just meet and talk about it while tasting some of your local beers... (I know, Prague is not in Slovakia !) Eric. Subject: Re: [therion] new user .... From: Martin Sluka Date: Tue, 15 Jun 2004 07:47:33 +0200 To: therion@speleo.sk At 23:05 +0200 14.6.2004, Eric Madelaine wrote: ******************************************* > By the way, from which part of Slovakia are your exactly? > I'm going to Prague for a european project meeting during the first week of july, so I was wondering whether we could just meet and talk about it while tasting some of your local beers... (I know, Prague is not in Slovakia !) > > Eric. Eric, Martin, Stacho - no problem, we may make a "therion camp" not far from Prague (30 km) - in small village Hriby. I have a small house there. What about Lada Blazek? Martin -- Subject: Re: [therion] new user .... From: "Ladislav Blazek" Date: Tue, 15 Jun 2004 08:44:12 +0200 (CEST) To: therion@speleo.sk Martin Sluka napsal(a): >> At 23:05 +0200 14.6.2004, Eric Madelaine wrote: >> ******************************************* >> >> Eric, Martin, Stacho - no problem, we may make a "therion camp" not >> far from Prague (30 km) - in small village Hriby. I have a small >> house there. What about Lada Blazek? Hi all, yes it's a good idea. What term you mean exactly? Lada Subject: Re: [therion] new user .... From: "Ladislav Blazek" Date: Tue, 15 Jun 2004 09:12:51 +0200 (CEST) To: therion@speleo.sk Eric Madelaine napsal(a): >> I will try to run simple examples for producing extended elevation maps, >> and I'll keep you informed of my progress... Hi Eric, I have at home some simple extended elevation maps generated from Therion... >From my point of view it's very simple. 1. you need scanned sketch of extended elevation map :-) 2. set projection of the scrap -> extended 3. set options of every point station -> name 11@sifon1 -extend left (or right) Lada Subject: Re: new user .... From: Stacho Mudrak Date: Tue, 15 Jun 2004 10:08:21 +0200 To: therion@speleo.sk > even if the first answers were... wait and see (;-) Not exactly :) - there is new example on the Web page - Rabbit cave (download/sample data) also with extended elevation. Martin just forgot to anounce it yesterday... The 3D is much more difficult think - there you can just wait or help us coding and design algorithms. But I'm afraid, the algorithm design can not be done without sitting with a good beer. > Ok, this one is easy, I volunteer gladly for a french translatin. OK, I'll have a look at the code and then I'll write you what exactly to do (I do not remember now :) . >> - documentation >> The last requires more effort while the documentation is changing and >> growing rapidly. > > > Well, yes... Ok, I will not promissed any large amount of work just now. But I'll think about what I can do, and I will certainly do some introduction paper in french, in the same spirit than wookey's paper in Compass Point. I'm afraid, there is no comprehensive documentation to translate. ThBook is just a reference guide - I think, it will not help people, even if it will be translated. > Console messages and UI are going together (just as they go in survex and the survex-related tools, for which I do contribute my own set of french sentences from time to time...). But this is why I wrote "if the code already supports internationalisation...". So I undertsand that it is not yet the case, and I will not push it anymore (:-( Not exactly :) The internationalization code works in therion. Adding translation for 50 messages that therion generates is a work for 30 minutes. Also translating things in xtherion wouldn't be much work (I guess one evening) within the same framework. > Input language is a separate topic, I agree. But then, I'm not sure > why you would not be able to change the lexer without changing the rest of the parser, and get variants for the language... (Again, I'm not suggesting that you should do it) This is again very easy - to add alternatives to parsing tables. In fact, they are already there to cover UK/US variants :))) pit/pitch, center/centre etc... We are just afraid of a mess, that can happen... I'm almost sure, that if I would write bod 0 0 -typ brèko nobody in the world with exception of CK/CZ would understand this code... In any case, internationalization is a topic for discussion. Last week we have realized, that at least, we should allow also real numbers with comma (e.g. 3,5), because otherwise people must allways switch to english keyboard. > By the way, from which part of Slovakia are your exactly? > I'm going to Prague for a european project meeting during the first week of july, so I was wondering whether we could just meet and talk about it while tasting some of your local beers... (I know, Prague is not in Slovakia !) We come from central Slovakia (Banska Bystrica), but we live in Bratislava. During this week, we (me and my wife) wanted to travel across central europe, so we can add Prague to our itinéraire - no problem. I'm looking forward to meet you and discuss these topics. All good ideas implemented in therion come from such a discussions (with a good beer) :))) Regards, S. Subject: Re: [therion] new user .... From: Olly Betts Date: Tue, 15 Jun 2004 16:22:15 +0100 To: therion@speleo.sk On Mon, Jun 14, 2004 at 11:05:31PM +0200, Eric Madelaine wrote: >> Input language is a separate topic, I agree. But then, I'm not sure >> why you would not be able to change the lexer without changing the rest >> of the parser, and get variants for the language... (Again, I'm not >> suggesting that you should do it) It's possible, but it's not a sane route to go down. The problem comes when users using different i18ns want to exchange files (for example, CUCC shares survey data with the German cavers who work in the same area of Austria). Worse, what if I want to change a survey data file sent to me in German? I'm forced to try to understand the German version of the file format, and either I have to make my changes in German, or the parser will need to understand every keyword from every language at once! A real world example - Microsoft translated keywords in the macro language for either Word or Excel (maybe both!) so a coworker had a fun time translating some macro scripts we shipped to clients by installing both versions and comparing the two manuals...) And of course each time the macros changed, he had to dig out the manuals, and retest everything on the translated version. A better approach would be to translate the keywords from english (or some canonical form) and back to the canonical form on save. That way I can edit a data file from a German surveyor in English, and the language used in the file format becomes just an implementation detail, Cheers, Olly Subject: Re: new user .... From: Wookey Date: Mon, 21 Jun 2004 12:16:11 +0100 To: therion@speleo.sk +++ Eric Madelaine [04-06-14 23:05 +0200]: >>> >- documentation >>> >The last requires more effort while the documentation is changing and >>> >growing rapidly. > >> >> Well, yes... Ok, I will not promissed any large amount of work just >> now. But I'll think about what I can do, and I will certainly do some >> introduction paper in french, in the same spirit than wookey's paper in >> Compass Point. I'll be sending the original to MartinB soon (when I have collected the right image files). I'll send it to you too, or maybe just stick it on my website for people to read/download/translate. It was GPLed to enable this sort of thing. It's going to need rewriting soon for all the 3D stuff :-) I expect to do a new version for September (UK caving conference) 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/ Subject: Re: Visit in Prague From: Eric Madelaine Date: Tue, 15 Jun 2004 10:31:33 +0200 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr I've been looking in more details to my agenda. And I need to book my flight very soon now... So I'm in Charles university in Prague all day on wednesday 7th and thursday 8th. I will arrive in Prague tuesday 6th in the afternoon, and leaving either friday or saterday. It's the first time I go to this area of europe, so I will take some time to visit the city, of course. So I have mainly two options: if I book my return plane friday afternoon (there is one convenient at 5pm), I will have the first evening available (tuesday), plus a part of friday. If some of you are available (for whatever you plan, computer session, caving, or just eating and drinking), and willing to speak french for a while (;-), I can book my plane on saterday, but you'll have to host me for the night, and to drive me back to the airport... wrote: >> Eric, Martin, Stacho - no problem, we may make a "therion camp" not >> far from Prague (30 km) - in small village Hriby. I have a small >> house there. What about Lada Blazek? Cheers, Eric. Subject: [therion] Re: Visit in Prague From: Martin Sluka Date: Tue, 15 Jun 2004 11:10:13 +0200 To: therion@speleo.sk At 10:31 +0200 15.6.2004, Eric Madelaine wrote: ******************************************* > So I have mainly two options: if I book my return plane friday afternoon (there > is one convenient at 5pm), I will have the first evening available (tuesday), > plus a part of friday. > If some of you are available (for whatever you plan, computer session, caving, > or just eating and drinking), and willing to speak french for a while (;-), I > can book my plane on saterday, but you'll have to host me for the night, and to > drive me back to the airport... After phone with Stacho - they (Stacho, his wife, Martin) may come on Friday July 9th at morning - visit a bit old Prague with you and afternoon we may drive to Hriby to barbecue a therion, drink beer, ... On Saturday we may continue and afternoon drive you to aiport. Anybody else? Martin -- Subject: Re: [therion] Re: Visit in Prague From: Eric Madelaine Date: Tue, 15 Jun 2004 16:37:33 +0200 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr martinsluka@mac.com said: >> After phone with Stacho - they (Stacho, his wife, Martin) may come on >> Friday July 9th at morning - visit a bit old Prague with you and >> afternoon we may drive to Hriby to barbecue a therion, drink beer, >> ... On Saturday we may continue and afternoon drive you to aiport. Well thanks all of you! So my plane is reserved now (pretty cheap on KLM), and I'll have to have it emitted confirmed on tomorrow (non modifiable, these companies are hard on us...). Eric. Subject: Re: [therion] Re: Visit in Prague From: Eric Madelaine Date: Fri, 02 Jul 2004 13:17:10 +0200 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr Hello Martin, I'm preparing my travel now (I will fly on tuesday 6th morning), and I have a couple of last minute questions for you all: - Is it still ok for hosting me in Hriby on friday evening ? - should I bring a sleeping bag ? - Can you give me a phone number where I will be able to contact you or somebody of your group? My cell phone should be operationnal in Prague, but you never know... my number is +33 6 87 47 99 80 (and international cell calls are expensive both for the caller and the callee...) - I guess one convenient rendez-vous point for friday could be my hotel, but if you prefer some other rdv, just tell me. I will be in Hotel Abri ( Jana Masaryka 36, 120 00 Praha 2) Eric. martinsluka@mac.com said: >> After phone with Stacho - they (Stacho, his wife, Martin) may come on >> Friday July 9th at morning - visit a bit old Prague with you and >> afternoon we may drive to Hriby to barbecue a therion, drink beer, >> ... On Saturday we may continue and afternoon drive you to aiport. Subject: Re: [therion] Re: Visit in Prague From: Martin Sluka Date: Fri, 2 Jul 2004 13:24:56 +0200 To: therion@speleo.sk At 13:17 +0200 2.7.2004, Eric Madelaine wrote: ******************************************* > Hello Martin, > > I'm preparing my travel now (I will fly on tuesday 6th morning), and I have a > couple of last minute questions for you all: > > - Is it still ok for hosting me in Hriby on friday evening ? OK > - should I bring a sleeping bag ? Not necesary > - Can you give me a phone number where I will be able to contact you or > somebody of your group? My cell phone should be operationnal in Prague, but you > never know... my number is +33 6 87 47 99 80 (and international cell calls are > expensive both for the caller and the callee...) +420-603 513 640 - my cell phone number > - I guess one convenient rendez-vous point for friday could be my hotel, but > if you prefer some other rdv, just tell me. > > I will be in Hotel Abri > ( Jana Masaryka 36, 120 00 Praha 2) No problem, I'll find it. Looking forward to meet you. Martin > > Eric. > > > martinsluka@mac.com said: > >> After phone with Stacho - they (Stacho, his wife, Martin) may come on >> Friday July 9th at morning - visit a bit old Prague with you and >> afternoon we may drive to Hriby to barbecue a therion, drink beer, > > > ... On Saturday we may continue and afternoon drive you to aiport. -- Subject: Wook's persistent Therion bug From: Wookey Date: Sun, 20 Jun 2004 13:14:33 +0100 To: Therion List I spent some hours last week (whilst in a cottage in wales), trying to track down the problem I have with Therion not liking my data any more. Here is what I discovered, which I hope will give you a clue, or suggest some more tests for me to do because I am out of ideas. In summary the problem exists in 0.2.19 and 0.3.1 so it's not a feature of the new version as I first thought. And as 0.2.19 _used_ to work then ewither it's a bug in underlying libraries or my data/environment has changed in some way. All the gdb testing has been done in 0.3.1. There are two bugs: 'invalid command context' on the first 'end*' command and a segfault if I use 'end centreline' instead of 'endcentreline'. I have found the function the segfault occurs in but no more. And the 'invalid command context' thing has been tracked down to the 'wrong' context value (NONE, SURVEY, SCRAP) being set when the endcommand happens, but I don't understand what this context is or enough about C++ to know how it might go wrong. The reading of the data seems to be OK so far as I can tell from using GDB. Here are my notes giving the details of what I did: debugging therion soundriver problem 2004.06.17 soundriver.th gives 'invalid command context' with v0.2.19 and 0.3.1 at first 'end' command (endmap, endcenterline). If I change endcenterline to 'end centerline' then I get a segfault instead. The top of the file looks like: encoding utf-8 # map elevator -title "Terikan River Cave: Elevator Entrance" # farside@river # farside2@river # endmap #connections # join farside@river farside2@river join farsidewest1@river farsidewest2@river join fsceil1@river:0 farsidewest3@river:7 centerline equate 17@evening 53@river equate 24@evening 1@river #*equate 4@river2 6@evening ; was it stn 6 cairn? closure suggests not equate 1@rifticious 2@evening equate 5@rifticious 12@evening equate 1@pooh 50@river equate 22@rifticious 1@rifticious2 equate 10@penthouse 27@river end centerline Backtracing with gdb produces: reading input -- soundriver.th open file -- soundriver.th Program received signal SIGSEGV, Segmentation fault. 0x0806fe92 in thsurvey::get_decdef (this=0x0) at thsurvey.h:239 239 bool get_decdef() { return this->decdef; } the backtrace looks like this: (gdb) bt #0 0x0806fe92 in thsurvey::get_decdef (this=0x0) at thsurvey.h:239 #1 0x0806f5a2 in thdata::set_survey_declination (this=0x819da20) at thdata.cxx:1996 #2 0x0806c605 in thdata::insert_data_leg (this=0x819da20, nargs=2, args=0x8195798) at thdata.cxx:1370 #3 0x080676d6 in thdata::set (this=0x819da20, cod={id = 0, nargs = 1}, args=0xbffffa60, argenc=6, indataline=1) at thdata.cxx:223 #4 0x08063c16 in thdatareader::read (this=0x818b420, ifname=0x8197b70 "soundriver.th", spath=0x819b6a0 "/home/wookey/.therion:/usr/share/therion:/usr/local/share/therion", dbptr=0x818b200) at thdatareader.cxx:119 #5 0x0810c1ef in main (argc=1, argv=0xbffffb34) at therion.cxx:254 (gdb) Now I changed the file to this: encoding utf-8 map elevator -title "Terikan River Cave: Elevator Entrance" farside@river farside2@river endmap #connections # join farside@river farside2@river join farsidewest1@river farsidewest2@river join fsceil1@river:0 farsidewest3@river:7 centerline equate 17@evening 53@river equate 24@evening 1@river #*equate 4@river2 6@evening ; was it stn 6 cairn? closure suggests not equate 1@rifticious 2@evening equate 5@rifticious 12@evening equate 1@pooh 50@river equate 22@rifticious 1@rifticious2 equate 10@penthouse 27@river endcenterline stepping through to find out why 'invalid command context occurs on 'endmap' we find that 'endmap' matches at thdatareader::read line 87 and then barf happens at line 91 dbptr->insert(objptr); because in thdatabase::insert, line 159 if ((optr->get_context() & this->ccontext) == 0) (gdb) print optr->get_context() $2 = 2 -i.e THCTX_SURVEY (gdb) print this->ccontext $3 = 1 i.e THCTX_NONE (gdb) print (optr->get_context() & this->ccontext) $4 = 0 so we get "invalid command context". I don't really understand what this context stuff is about but maybe this will be a clue. 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/ Subject: Re: [therion] Wook's persistent Therion bug From: Stacho Mudrak Date: Tue, 22 Jun 2004 10:12:44 +0200 To: therion@speleo.sk After reading your file several time, it seems to be very simple error. You are missing survey command in the beginning of your file :))) Change your file to following: encoding utf-8 survey soundriver [current file contents] endsurvey soundriver # if this command already does not exists at the end of your file I'm sending you your source files separately (they work on my computer). You can diff them and see, where is the difference. > soundriver.th gives 'invalid command context' with v0.2.19 and 0.3.1 at > first 'end' command (endmap, endcenterline). If I change endcenterline to > 'end centerline' then I get a segfault instead. This is OK. Multiline command (like map or centerline) is inserted into database when endmap(endcenterline) is readed. Note, that you must type "endcenterline" not "end centerline". The segfault is real therion bug - I'll fix in the next version. > I don't really understand what this context stuff is about but maybe this > will be a clue. It's very simple - in fact all therion commands must be placed between survey - endsurvey commands (survey context). And all 2D commands (point, line, area) must be placed between scrap - endscrap commands (scrap context). I'll send you your data files (once you have sent them to us) that work correctly. You can diff with your files to see the difference. Thanks for your feedback, I hope it will work now (at least the files I will send you). Regards, S. Subject: Re: Wook's persistent Therion bug From: Wookey Date: Mon, 28 Jun 2004 14:57:23 +0100 To: therion@speleo.sk +++ Stacho Mudrak [04-06-22 10:12 +0200]: >> After reading your file several time, it seems to be very simple error. You >> are missing survey command in the beginning of your file :))) Change your >> file to following: >> >> encoding utf-8 >> survey soundriver >> >> [current file contents] OK, you're right. That line must have got deleted at some point. So, it was a silly error, but given that this has taken some 6 weeks to solve with some fairly computer-savvy users, it suggests that the error messages could be rather more helpful. If it had said: "'survey' command missing before 'map' command", or "data must be enclosed in 'survey' at line blah", then we might have worked it out a bit quicker than 'invalid command context' which didn't help either of us, and so we started suspecting something complicated and looking through hex-dumps of the file! (this wasn't helped by my mistaken belief that it worked OK with 0.2.19 - sorry about that - "bloody users!"). >> It's very simple - in fact all therion commands must be placed between >> survey - endsurvey commands (survey context). And all 2D commands (point, >> line, area) must be placed between scrap - endscrap commands (scrap >> context). I'll send you your data files (once you have sent them to us) >> that work correctly. You can diff with your files to see the difference. OK - so it shouldn't be too hard to generate a much more user-helpful message when this doesn't happen. >> Thanks for your feedback, I hope it will work now (at least the files I >> will send you). Yep - I'm back in business. I'll upload therion 0.3.1 today and try and get some drawing done soon... 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/ Subject: Re: [therion] Re: Wook's persistent Therion bug From: "Martin Budaj" Date: Tue, 29 Jun 2004 07:45:53 +0200 (CEST) To: therion@speleo.sk >> So, it was a silly error, but given that this has taken some 6 weeks to >> solve with some fairly computer-savvy users, it suggests that the error >> messages could be rather more helpful. In fact your original message with the bug report from May 25 contained the survey command :)) The message from June 20 didn't -- this explains why it took 6 weeks to discover it... M. --------------------- I get: "Invalid command context" at line 6 in this file: 1 encoding utf-8 2 survey soundriver 3 4 map elevator -title "Terikan: Elevator Entrance" 5 farside@river 6 farside2@river 7 endmap 8 ........ --------------------- Subject: Re: Wook's persistent Therion bug From: Wookey Date: Tue, 29 Jun 2004 10:24:38 +0100 To: therion@speleo.sk +++ Martin Budaj [04-06-29 07:45 +0200]: >>> > So, it was a silly error, but given that this has taken some 6 weeks to >>> > solve with some fairly computer-savvy users, it suggests that the error >>> > messages could be rather more helpful. > >> >> In fact your original message with the bug report from May 25 contained >> the survey command :)) The message from June 20 didn't -- this explains >> why it took 6 weeks to discover it... Yes, - I have no explanation for how that happened. So far as I can see there was only ever one copy of this file. But yes, it did greatly confuse the issue. The 'line 6' error suggests that in fact the 'endmap' command was on line 6, so in fact line 2 must have been missing, but then where did I copy this version from to send to you? It's a mystery. Nevertheless - if the error had been 'missing survey command before 'map', then we would probably have got to the answer faster. >> M. >> >> --------------------- >> I get: >> "Invalid command context" at line 6 in this file: >> >> 1 encoding utf-8 >> 2 survey soundriver >> 3 >> 4 map elevator -title "Terikan: Elevator Entrance" >> 5 farside@river >> 6 farside2@river >> 7 endmap >> 8 >> ........ >> --------------------- >> >> >> 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/ Subject: Re: [therion] Re: Wook's persistent Therion bug From: Stacho Mudrak Date: Tue, 29 Jun 2004 13:57:12 +0200 To: therion@speleo.sk > Nevertheless - if the error had been 'missing survey command before 'map', > then we would probably have got to the answer faster. Yes, you are right. I'll try to change this. Regards, S. Subject: Re: french translation (fwd) From: Eric Madelaine Date: Tue, 29 Jun 2004 15:42:24 +0200 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr Soory I send this message only to Stacho yesterday, I think it's better on the list. And I have corrected some of my translation, so this version is slightly better. Eric. ========================== Subject: Re: french translation (fwd) From: madelain@nerim.net Date: Mon, 28 Jun 2004 18:58:10 +0200 (CEST) So there is a first try... I hope that the 8-bit accentuated chars will be ok, if you need another encoding, please tell me. There were 2 or 3 words on which I was not sure, depending on the context in which they are used (raft, flute, or scallop...). Anyway they are outside the proper UIS list (;-) We can dicuss them next week may be. I haven't recompiled, I would have to do it on my linux machine at work, and I'm too busy now for that. Anyway I'm not in a hurry, it can wait till next version. Cheers, Eric. >> Adding another (french) language to therion is very simple, it's already >> written in thbook/appendix/Adding new translations. If you do not wish to >> recompile, just add lines starting with "fr:" and corresponding french >> translation to thlang/texts.txt file (you need therion sources and utf-8 >> text editor for it) and send us this file. We will compile it to the next >> release. >> >> Thanks, S. therion: point station:temporary cz: měřičský bod (nestabilizovaný) en: temporary survey, station sk: meračský bod (nestabilizovaný) fr: station topo temporaire therion: point station:painted cz: měřičský bod (zabarvený) en: painted survey station sk: meračský bod (zafarbený) fr: station topo, peinte therion: point station:natural cz: měřičský bod (přírodní) en: natural survey station sk: meračský bod (prírodný) fr: station topo, naturelle therion: point station:fixed cz: měřičský bod (stabilizovaný) en: fixed survey station sk: meračský bod (stabilizovaný) fr: station topo, fixe therion: line survey cz: polygonový tah en: survey lines sk: polygónový Å¥ah fr: visée topo therion: point station-name cz: číslo měřičského bodu en: survey station name sk: číslo meračského bodu fr: station topo, nom therion: point entrance cz: vchod en: entrance sk: vchod fr: entrée therion: line arrow cz: pomocná Å¡ipka en: arrow sk: pomocná šípka fr: flèche therion: line wall:bedrock cz: stÄ›na en: wall sk: stena fr: mur therion: line wall:underlying cz: stÄ›na nižší úrovnÄ› en: underlying wall sk: stena nižšej úrovne fr: mur sousjacent therion: line wall:unsurveyed cz: nezaměřená stÄ›na en: unsurveyed wall sk: nezameraná stena fr: mur non topographié therion: line wall:presumed cz: pÅ™edpokládaná stÄ›na en: presumed wall sk: predpokladaná stena fr: mur supposé therion: line wall:blocks cz: zával en: breakdown sk: stena tvorená závalom fr: effrondrement therion: line wall:debris cz: Å¡tÄ›rk en: debris sk: stena tvorená Å¡trkom fr: débris de roche therion: line wall:pebbles cz: valouny en: pebbles sk: stena tvorená okruhliakmi fr: cailloux therion: line wall:sand cz: písek en: sand sk: stena tvorená pieskom fr: sable therion: line wall:clay cz: jíl en: clay sk: stena tvorená bahnom fr: argile therion: line wall:ice cz: led en: ice sk: stena tvorená ľadom fr: glace therion: point wall-altitude cz: nadmoÅ™ská výška bodu na stÄ›nÄ› en: altitude sk: nadmorská výška bodu na stene fr: altitude therion: point altitude cz: nadmoÅ™ská výška bodu v chodbÄ› en: altitude sk: nadmorská výška bodu v chodbe fr: altitude therion: line section cz: příčný Å™ez en: cross-section sk: priečny rez fr: section therion: point passage-height:unsigned cz: výška chodby en: passage height sk: výška chodby fr: hauteur du passage therion: point passage-height:positive cz: výška chodby nad hladinou en: height above water level sk: výška nad hladinou fr: hauteur au-dessus de l'eau therion: point passage-height:negative cz: výška chodby pod hladinou en: depth below water level sk: hĺbka pod hladinou fr: hauteur en dessous de l'eau therion: point passage-height:both cz: výška nad i pod hladinou en: height above and depth below water level sk: výška nad a hĺbka pod hladinou fr: hauteur au dessous et au dessus de l'eau therion: point air-draught cz: průvan en: air draught sk: prievan fr: courant d'air therion: point date cz: datum pozorování en: date of observation sk: dátum pozorovania fr: date therion: point continuation cz: možné pokračování en: possible continuation sk: možné pokračovanie fr: suite possible therion: point narrow-end cz: neprůlezné zúžení en: passage narrow end sk: neprielezné zúženie fr: passage impénétrable therion: point low-end cz: neprůlezné snížení en: passage low end sk: neprielezné zníženie fr: passage bas therion: point flowstone-choke cz: zasintrovaný konec en: flowstone choke sk: zasintrený koniec fr: trémie calcifiée therion: point breakdown-choke cz: zavalený konec en: breakdown choke sk: zavalený koniec fr: trémie therion: line floor-step cz: stupeň en: floor step sk: stupeň fr: marche therion: line overhang cz: pÅ™evis en: overhang sk: previs fr: surplomb therion: line pit cz: propast en_UK: pitch en_US: pit sk: priepasÅ¥ fr: puits therion: line ceiling-step cz: zmÄ›na výšky stropu en: step on the ceiling sk: zmena výšky stropu fr: marche de plafond therion: line chimney cz: komín en: chimney sk: komín fr: cheminée therion: line gradient cz: sklon chodby en: passage gradient sk: sklon chodby fr: pente therion: point gradient cz: sklon chodby en: passage gradient sk: sklon chodby fr: pente therion: point height:unsigned cz: výška stupnÄ› en: the height of floor step sk: výška stupňa fr: hauteur d'une marche therion: point height:positive cz: výška komínu en: chimney height sk: výška komínu fr: hauteur d'une cheminée therion: point height:negative cz: hloubka propasti en: pit depth sk: hĺbka priepasti fr: profondeur therion: line contour cz: vrstevnice en: contour sk: vrstevnica fr: contour therion: line slope cz: svah en: slope sk: Å¡ikmá plocha fr: pente therion: line rock-border cz: kameny en: rock border sk: ohraničenie kameňov fr: bord d'un rocher therion: line rock-edge cz: hrany kamenů en: rock edges sk: hrany kameňov fr: arête d'un rocher therion: point bedrock cz: pevná skála en: bedrock sk: pevná skala fr: roche therion: point blocks cz: kamenné bloky en: blocks, breakdown sk: kamenné bloky fr: blocs therion: point debris cz: Å¡tÄ›rk en: debris sk: Å¡trk fr: débris therion: point sand cz: písek en: sand sk: piesok fr: sable therion: point clay cz: jíl en: clay sk: blato fr: argile therion: point water cz: voda en: water sk: voda fr: eau therion: point ice cz: led en: ice sk: ľad fr: glace therion: point pebbles cz: valouny en: pebbles sk: okruhliaky fr: galets therion: point raft cz: náplav en: raft sk: náplav fr: calcite flottante therion: point guano cz: guano en: guano sk: guáno fr: guano therion: line border:visible cz: ohraničení en: border sk: ohraničenie fr: bord therion: line border:temporary cz: nestálé ohraničení en: temporary border sk: nestále ohraničenie fr: bord, temporaire therion: area water cz: vodní plocha en: water sk: vodná plocha fr: eau therion: area sump cz: sifon en: sump sk: zatopená plocha (sifón) fr: siphon therion: area debris cz: Å¡tÄ›rk en: debris sk: Å¡trk fr: débris therion: area sand cz: písek en: sand sk: piesok fr: sable therion: point waterflow:permanent cz: vodní tok en: waterflow sk: vodný tok therion: point waterflow:intermittent cz: občasný vodní tok en: intermittent waterflow sk: občasný vodný tok fr: rivière, intermittente therion: point waterflow:paleo cz: paleoÅ™ečiÅ¡tÄ› en: paleo waterflow sk: paleoriečisko fr: rivière fossile therion: line waterflow:permanent cz: vodní tok en: waterflow sk: vodný tok fr: rivière, permanente therion: line waterflow:intermittent cz: občasný vodní tok en: intermittent waterflow sk: občasný vodný tok fr: rivière, intermittente therion: line waterflow:conjectural cz: pÅ™edpokládaný vodní tok en: conjectural waterflow sk: predpokladaný vodný tok fr: rivière, conjoncturelle therion: point spring cz: vývÄ›r en: spring sk: výver fr: source therion: point sink cz: ponor en: sink sk: ponor fr: perte therion: point flowstone cz: sintr en: flowstone sk: sinter fr: concrétions therion: line flowstone cz: sintrové náteky en: flowstone sk: sintrové náteky fr: concrétion therion: point moonmilk cz: nickamínek en: moonmilk sk: mäkký sinter fr: mondmilch therion: point stalactite cz: stalaktit en: stalactite sk: stalaktit fr: stalactite therion: point stalagmite cz: stalagmit en: stalagmite sk: stalagmit fr: stalagmite therion: point pillar cz: stalagnát en: pillar sk: stalagnát fr: pillier therion: point curtain cz: sintrové záclony en: curtain sk: sintrové záclony fr: rideau therion: point soda-straw cz: brčka en: soda straw sk: brčká fr: fistuleuse therion: point popcorn cz: pizolity en: popcorn sk: pizolity fr: choux-fleur therion: point cave-pearl cz: jeskynní perly en: cave pearl sk: jaskynné perly fr: perle des cavernes therion: point disk cz: disk en: disk sk: disk fr: disque therion: point helictite cz: heliktit en: helictite sk: helektit fr: excentrique/hélictite therion: point aragonite cz: aragonit en: aragonite sk: aragonit fr: aragonite therion: point crystal cz: krystal en: crystal sk: kryÅ¡tál fr: cristaux therion: point wall-calcite cz: vápencový povlak en: wall calcite sk: vápencový povlak fr: mur, calcite therion: point gypsum cz: sádrovec en: gypsum sk: sádrovec fr: gypse therion: point gypsum-flower cz: sádrovcový kvÄ›t en: gypsum flower sk: sádrovcový kvet fr: fleur de gypse therion: point rimstone-dam cz: sintrová hrázka en: rimstone dam sk: sintrová hrádza fr: gours therion: point rimstone-pool cz: sintrové jezírko en: rimstone pool sk: sintrové jazierko fr: gour therion: point anastomosis cz: anastomóza en: anastomosis sk: anastomóza fr: anastomose therion: point karren cz: Å¡krapy en: karren sk: Å¡krapy fr: lapiez therion: point scallop cz: erozní útvary en: scallop sk: erózne útvary fr: vagues d'érosion (coups de gouge) therion: point flute cz: píšťaly en: flute sk: píšťaly fr: flute (?) therion: point raft-cone cz: náplavový kužel en: raft cone sk: náplavový kužeľ fr: cone therion: point archeo-material cz: archeologické nálezy en: archeo material sk: archeologické nálezy fr: matériel archéo therion: point paleo-material cz: paleontologické nálezy en: paleo material sk: paleontologické nálezy fr: matériel paléo therion: point vegetable-debris cz: zbytky rostlin en: vegetable debris sk: zvyÅ¡ky rastlín fr: débris végétaux therion: point root cz: koÅ™eny en: root sk: korene fr: racine therion: point no-equipment cz: nevystrojené místo en: place without equipement sk: nevystrojené miesto fr: pas d'équipement therion: point anchor cz: kotvení en: anchor sk: kotvenie fr: ancrage therion: point rope cz: lano en: rope sk: lano fr: corde therion: point rope-ladder cz: lanový žebřík en: rope ladder sk: lanový rebrík fr: échelle de corde therion: point fixed-ladder cz: pevný žebřík en: fixed ladder sk: fixný rebrík fr: échelle fixe therion: point steps cz: schody en: steps sk: schody fr: marches therion: point traverse cz: traverz en: traverse sk: traverz fr: traversée therion: point bridge cz: most en: bridge sk: most fr: pont therion: point camp cz: bivak en: camp sk: bivak fr: camp therion: title legend cz: Legenda en: Legend sk: Legenda fr: Légende therion: title cave length cz: Délka en: Length sk: Dĺžka fr: Longueur therion: units m cz: m en: m sk: m fr: m therion: title cave depth cz: PÅ™evýšení en: Depth sk: Prevýšenie fr: Profondeur therion: title explo (plural) cz: Objevili en: Explored by sk: Objavili fr: Explorateurs therion: title explo cz: Objevil en: Explored by sk: Objavil fr: Explorateur therion: title topo (plural) cz: Měřili en: Surveyed by sk: Zamerali fr: Topographes therion: title topo cz: Měřil en: Surveyed by sk: Zameral fr: Topographe therion: title carto (plural) cz: Kreslili en: Drawn by sk: Kreslili fr: Dessinateurs therion: title carto cz: Kreslil en: Drawn by sk: Kreslil fr: Dessinateur therion: title preview above cz: [Náhled horních vrstev] en: [Preview above] sk: [Náhľad horných vrstiev] fr: [Prévisualisation au-dessus] therion: title preview below cz: [Náhled dolních vrstev] en: [Preview below] sk: [Náhľad spodných vrstiev] fr: [Prévisualisation au-dessous] Subject: Re: [therion] Report on Therion Visit in Prague From: Eric Madelaine Date: Sun, 11 Jul 2004 16:04:26 +0200 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr Thanks a lot, first, to Martin (Sluka), Stacho, and Erica for their kindness, for taking me in charge in Praha and Hriby, and for everything they have arranged for this nice session. We were able to have quite an efficient session, and plenty of interesting duscussion on therion present and future, on caving in general, on caves in the check ans slovak republics, in france or elsewhere, on environment, on cave management, on Prague history, on Europe, ....etc. yesterday before leaving, I promissed to make a short report from my notes, so there it is, presented as a list of topics/questions, and when possible a sketch of answers... - Therion not running properly on my W2000 Pro laptop (message "cannot read file data.log"...). => this was in fact a conflict with another installation of latex on the machine, that had set a bunch of latex variables. solution: unset all latex variables before running therion. May be this could be done in the therion script... => should go to the FAQ - Extended elevation not working properly on the Pinée example. => Stacho suggested that this was a problem with the order of the station points in the map file. Indeed this order is significant. But it is not the only problem: Back home I have set the correct order, and the result is still not correct. Stacho, I will send you the files when I have a moment (too bad I had not them on my machine in Hriby); And I will try other (smaller) examples... - A lot of problems with the definition of OUTLINES in the Pinée plan maps. I understand better the outline notion now, and I will spend some time correcting the Pinée exemple. I will definitely try to write some tutorial-like section about this topic. - Split Line bug: when you split an existing line in the map editor, save the file and reload it, one half of the line disappears... => Stacho will have a look... - Cross sections. various discusions, several questions: arrows (or marks) are not displayed by default; have to use e.g. "-direction begin" cross-section lines and scraps must be refered by a common id (or "name"). This will be useful to set references when the section scrap is far from the position of its reference line on the map. The labels naming the sections would be left to be user-defined (but maybe with a specific type, so that one can "hide" them together with the section lines/scraps). - Possibility of translating a part of a map (a scrap?) for avoiding overlapping drawings in some cases. This I originaly asked for extended elevation, where it is most useful, but the mechanism would be the same for other sorts of projections. One difficulty is that one would want to specify where to draw connection lines between the two parts. This is NOT a map object, but rather something similar to "joins". - Transparency for overlapping passages. This is currently handled using transparency and opacity at the PDF level. If one would want to draw the lower level wall using interupted lines (as in the UIS standard), it would have to be computed directly in therion, that would be too much work. => Abandonned. - Tricks and Tips: How do you know which side of a line is the interior (e.g. for a pit...)? Stacho showed me that on the first point of the line there is a small (red ?) arrow, that I would not have seen without my glasses (;-). This is a new feature, not in the Book; very useful. - Production of plans at very large scale (e.g. for inclusion in a topographic map). We need: (1) filling of the passage with colors, (2) specify a large scale bar and (3) a large north direction arrow. => (1) and (2) are feasible, e.g.: symbol-hide group all color map-fg [100 0 0] scale-bar 100 m Having several colors on the same plan (different for galeries and sumps, e.g.) does not seem possible. Having a bigger North arrow (for geo-referencing of the resulting map) should be done in Latex... - Printing of grids on the plan: currently not available. - New symbols: Ropes (for elevations) Meander in ceiling, in floor - Drawing of centerlines, even when you don't have the corresponding scrap. I would find it very useful for a quick evening printing when you do not have enough time for more. Martin Sluka disagrees, because he always draws on scale in the cave (different habits...); but still you have to scan the scraps and edit the map... Long discussions on 3D modelling that I will not try to summary (:-( Cheers, and thanks again, Eric. Subject: Re: [therion] Report on Therion Visit in Prague From: Michael Lake Date: Mon, 12 Jul 2004 11:49:05 +1000 To: therion@speleo.sk Eric Madelaine wrote: > - Production of plans at very large scale (e.g. for inclusion in a > topographic map). We need: (1) filling of the passage with > colors, (2) specify a large scale bar and (3) a large north > direction arrow. > => (1) and (2) are feasible, e.g.: > symbol-hide group all > color map-fg [100 0 0] > scale-bar 100 m I have written a scalebar package for LaTeX, perhaps the code will come in useful for those writing one for Therion. Its at http://www.ctan.org and search for 'scalebar'. or read about it directly here: http://www.ctan.org/tex-archive/help/Catalogue/entries/scalebar.html?action=/tools/cataloguesearch&catstring=scalebar There is an example file there also called scalebar_examples.pdf Rather than downloadingfrom CTAN you can access the PDF of examples directly and have a look at it from my home pages: http://www.speleonics.com.au/mikes/latex.html Might save you some time in implementing a scalebar. Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. Subject: Extended Elevation, and other questions. From: Eric Madelaine Date: Wed, 14 Jul 2004 12:13:53 +0200 To: therion@speleo.sk Hi Stacho, Here is the data off the embut de la Pinee, including whatever cause this wrong extended elevation map. I have not included any scan images (except for the ext. elevatin itself) as it would have be over 4 Mo large... I have corrected some (not all) the "scrap intersects itself" bugs in my maps (its a bit tedious, I cannot do it directly in the map editor, because of the splitline bug...). I also tried, after our discussion, to produced a large-scale "filled galeries" map, on which I wanted to have only the scal and north arrow, but no other headers... I have the feeling that I need redefine some tex-level macros for that, but th ebook is not very useful, it only specifies layout changes for the atlas. I have browsed through the tex sources, but I have nor been able to identify the layout macro (or the header macro) for Maps. I tried something like: layout shadow500 scale 1 500 legend off map-header 100 100 w symbol-hide group all symbol-show point entrance scale-bar 100 m color map-bg 100 color map-fg 0 endlayout export map -o ombre.pdf -layout shadow500 It works, but I'd like: - to remove all header texts (or eventually keep just a title) - add something like "show area water", may be in a different color... Cheers, Eric. Subject: Re: [therion] Extended Elevation, and other questions. From: "Martin Budaj" Date: Wed, 14 Jul 2004 13:52:30 +0200 (CEST) To: therion@speleo.sk >> I'd like: >> - to remove all header texts (or eventually keep just a title) Add following code inside your layout command: code tex-map \def\maplayout{ \legendbox{0}{100}{NW}{\northarrow\scalebar} \legendbox{100}{100}{NW}{\scalebar} } it produces two headers for one map (one in the upper-left, second in the upper-right corner) -- one arrow and two scale-bars -- just for an illustration. You may use any number of \legendbox'es inside of \maplayout definition. All macros and predefined boxes (like \scalebar) are described in the `Page layout in the map mode' chapter of the recent thbook. >> - add something like "show area water", may be in a different color... Again, add in layout: color map-fg 50 symbol-hide group all symbol-show area water code metapost def a_water (expr p) = T:=identity; thfill p withcolor (0.1, 0.2, 0.8); enddef; hope it helps. Martin Subject: Re: [therion] Extended Elevation, and other questions. From: Stacho Mudrak Date: Wed, 14 Jul 2004 17:39:50 +0200 To: therion@speleo.sk Eric Madelaine wrote: > Here is the data off the embut de la Pinee, including whatever cause this wrong extended elevation map. > I have not included any scan images (except for the ext. elevatin itself) as it would have be over 4 Mo large... Well, I had a look at your code, and there are several errors in the exteded elevation stations specification. point 152.0 1010.0 station -name k1@pinee8 -extend left -extend should be right, because you extend the stations to the right (k2 is on the right side of k1). Therion is not able to mirror scrap (currently). point 890.0 619.0 station -name k11@pinee8 point 890.0 619.0 station -name k11@pinee8 I'm not sure, but station k11 should be there only once, but may be, this is not an error. Main source of distortion are these lines: point 1070.0 468.0 station -name k15@pinee8 point 1224.0 338.0 station -name k16@pinee8 station k15 is on the right of station k14, therefore there should be -extend right and station k16 is on the left of k13, therefore there should be -extend [left prev k13@pinee8]. I know, in therion book this is written not very understandable way :( So the right code should be point 1070.0 468.0 station -name k15@pinee8 -extend left point 1224.0 338.0 station -name k16@pinee8 -extend [right prev k13@pinee8] After redefinition of anchor symbol, replacing the "point blocks" symbols on the floor with "wall -subtype blocks" and reparing the scrap outline, the extended elevation looks little bit better. > I also tried, after our discussion, to produced a large-scale "filled galeries" map, on which I wanted to have only the scal and north arrow, but no other headers... I have the feeling that I need redefine some tex-level macros for that, but th ebook is not very useful, it only specifies layout changes for the atlas. I have browsed through the tex sources, but I have nor been able to identify the layout macro (or the header macro) for Maps. In the configuration file, there is also simple-map layout, where also scale-bar is redefined (it is a 50 m line in both directions). Using it, you should be able to align the cave on the topo-map (the coordinate grid will be present in some future version of therion). Using your files, I have found some another serious bugs in therion, I'll try to repair them as soon as possible. I have attached the files I have modified. Regards, S. Subject: Re: [therion] Extended Elevation, and other questions. From: Eric Madelaine Date: Wed, 14 Jul 2004 22:12:52 +0200 To: therion@speleo.sk > In the configuration file, there is also simple-map layout, where also scale-bar is redefined (it is a 50 m line in both directions). Using it, you should be able to align the cave on the topo-map (the coordinate grid will be present in some future version of therion). It looks great ! > > Using your files, I have found some another serious bugs in therion, I'll try to repair them as soon as possible. I have attached the files I have modified. Thanks a lot for your help, both of you, I'm sincerily impressed. My first -extend error seems really stupid... I suppose I would not have found the "-extend [right prev k13@pinee8]" alone (;-) By the way, as Martin mentionned today a reference to the "changing the layout in maps" section, I first though I had an older version of the book, and then discovered that I just had missed page 50 when looking exactly for that! Sorry. Anyway, your simple map layout is perfect, Stacho. I will not be able to work much more on therion for the next month, I'm quiting for family holidays on saterday, then beginning of august on our summer camp (massif du Marguareis), and back home only around the &(th of august. Cheers, Eric Madelaine. Subject: Re: [therion] Extended Elevation, and other questions. From: "Martin Budaj" Date: Thu, 15 Jul 2004 08:10:07 +0200 (CEST) To: therion@speleo.sk >> Again, add in layout: >> >> color map-fg 50 >> symbol-hide group all >> symbol-show area water >> >> code metapost >> def a_water (expr p) = >> T:=identity; >> thfill p withcolor (0.1, 0.2, 0.8); >> enddef; It would be more correct do define own symbol set than to redefine the default symbol (it has the same result, but redefining the default doesn't allow to switch among various symbol sets). So the correct solution is: ----------------------------- color map-fg 50 symbol-hide group all symbol-show area water symbol-assign area water MY code metapost def a_water_MY (expr p) = T:=identity; thfill p withcolor (0.1, 0.2, 0.8); enddef; initsymbol("a_water_MY"); ----------------------------- Now you may use the symbol-assign command to switch among all predefined symbol sets and the new set MY. Regards, Martin Subject: Therion 0.3.2 From: "Martin Budaj" Date: Thu, 22 Jul 2004 15:23:20 +0200 (CEST) To: therion@speleo.sk Hi all, new version of Therion is available. Changes include: therion: * configuration file changes: - layout command: scale 1 50 upto 1 100000 allowed and supported * Therion constructs accented characters if the character is not present in the font. It used to omit the accent and display the base character only * error message `invalid command context' changed to `missing xxx command before yyy command' * French translation added xtherion: * line split bug fixed * automatically checks for updates * 3D viewer: reload (Ctrl+R) * 3D viewer: bounding box computation fixed Best regards, Martin Subject: Re: Left-right-up data From: Stacho Mudrak Date: Thu, 05 Aug 2004 17:12:39 +0200 To: Ilker Tunay CC: therion@speleo.sk > I am new to Therion, and I am very impressed with what you guys have > done. This is the most complete cave surveying software I have seen so > far. Thanks for the compliment and feedback :) > What is the purpose of the "left right up" items in data? (These are not > included in the Survex manual.) When I enter numbers into these fields, > nothing happens. Well, you are right :( . In the current version, these numbers are not used anywhere. In fact, we have added them after Wookey's requests and we want to implement them into 3D modelling in the future. The problem is, that everybody interprets these numbers in a different way or better to say in a different direction. Somebody uses LR dimensions ortogonal to the previous shot, sombody in the axis of previous and next shot. The same with UD data - sometimes it is vertical, sometimes ortogonal to the shot (steep and vertical passages). So we need to add also some flags, that will identify which cross-section orientation should be used for particular station. But these flags are nowhere standardised, so we have to introduce our own and this may take some time. In fact, we have a holiday season right now, so therion developement is very problematic, but after holidays, we will definitely continue with 3D modelling and LRUD data will be also included into 3D model (you are not the only one who is asking for that). > If these are for specifying LRUD distances to the walls, ceiling and > floor, then how can I see the corresponding distances in the Map Editor? > This would be very useful for drawing the walls. Do you draw maps in xtherion without bacground images??? We thought, that everybody will use some hand-drawn scatches as a background, where passages are drawn and xtherion is only some kind of vectorization program. Well, if it is not true - I can imagine, that it is really very hard to draw something reasonable. In the current approach, I'm afraid it is not possible to add something like that (may be in the therion with new user interface, it will be possible, but this is currently only our long-term dream :(). So if you would like to draw passages like that, I can see the only way how to do it. Use some other software (even we still use some of them :)), print centerline with LRUD dimensions. Scan this drawing and put as a background image into xtherion. OK, it is very dirty but it should work :) But now I have another idea - in the near future, we want to implement inserting only centerline to the map. Now I see, that it would be probably very good to insert also passage dimensions, if they will be specified. This should enable drawing not vectorized parts of the existing caves where LRUD data exists. > Are these data fields used in the 3D model? Not now :( OK, tomorrow I'm leaving for the holiday, but I believe, we will do some progress in September. Best regards, S. > Thanks for your help! > > Ilker > Subject: Re: [therion] Re: Left-right-up data From: Julian Todd Date: Tue, 10 Aug 2004 18:01:12 +0100 To: therion@speleo.sk Stacho Mudrak wrote: > > Well, you are right :( . In the current version, these numbers are not used anywhere. In fact, we have added them after Wookey's requests and we want to implement them into 3D modelling in the future. > > The problem is, that everybody interprets these numbers in a different way or better to say in a different direction. Somebody uses LR dimensions ortogonal to the previous shot, sombody in the axis of previous and next shot. The same with UD data - sometimes it is vertical, sometimes ortogonal to the shot (steep and vertical passages). > > So we need to add also some flags, that will identify which cross-section orientation should be used for particular station. But these flags are nowhere standardised, so we have to introduce our own and this may take some time. > > In fact, we have a holiday season right now, so therion developement is very problematic, but after holidays, we will definitely continue with 3D modelling and LRUD data will be also included into 3D model (you are not the only one who is asking for that). > Before you proceed along these lines, look at: http://www.goatchurch.org.uk/Tunnel/xsecto.html This pretty much defines a normal form within which all the styles of cave cross-section location and orientation that I've come across can be encoded. Please consider this before you opt for a system that uses lots of complicated flags and modes. Julian T. Subject: how to connect scraps From: Simeon Warner Date: Mon, 9 Aug 2004 14:54:11 -0400 (EDT) To: therion@speleo.sk I've been using xtherion to trace passage detail from my survey notes and now have a collection of scraps, each one corresponding to a page of my survey notebook. I have been unable to work out or find documented how I can connect up the lines for walls and such on adjacent scraps. At present I get a set of nearly-joined-up map segments when I compile the map from the set of scraps. Any help would be appreciated. Thanks, Simeon Subject: Re: [therion] how to connect scraps From: Martin Sluka Date: Mon, 9 Aug 2004 23:02:33 +0200 To: therion@speleo.sk Martin Budaj or Stacho will answer you more detailed, but very shortly: use command "join" for example: join fajc_obch@FAJCIAR_OBCHADZKA fajciar@FAJCIAR where names in small letters are names of scraps and names in capitals are names of surveys. Martin At 14:54 -0400 9.8.2004, Simeon Warner wrote: ******************************************* > I've been using xtherion to trace passage detail from my survey notes and > now have a collection of scraps, each one corresponding to a page of my > survey notebook. I have been unable to work out or find documented how I > can connect up the lines for walls and such on adjacent scraps. At present > I get a set of nearly-joined-up map segments when I compile the map from > the set of scraps. Any help would be appreciated. > > Thanks, > Simeon -- Subject: Re: [therion] how to connect scraps From: Stacho Mudrak Date: Tue, 10 Aug 2004 09:08:48 +0200 To: therion@speleo.sk If your scraps are connected on 2 or more places, you may use option -count N with join command, where N is number of connections, therion should look for (join scrap1 scrap2 -count 2). Sometimes it doesn't work. E.g. when outline or connection place is not correctly determined or more than 2 scraps connect at one place. If it is your case, you need to use join to connect only lines or specific line points. Regards, S. Simeon Warner wrote: > I've been using xtherion to trace passage detail from my survey notes and > now have a collection of scraps, each one corresponding to a page of my > survey notebook. I have been unable to work out or find documented how I > can connect up the lines for walls and such on adjacent scraps. At present > I get a set of nearly-joined-up map segments when I compile the map from > the set of scraps. Any help would be appreciated. > > Thanks, > Simeon > > Subject: demo-rabbit doesn't process From: Olly Betts Date: Sun, 5 Sep 2004 16:47:29 +0100 To: therion@speleo.sk Using the therion 0.3.1 debian packages, I unpacked demo-rabbit from the tar.gz file, ran xtherion, File->Open thconfig from the demo-rabbit directory, and then File->Compile. This stops with an error - the full output cut and pasted from the lower frame is: therion 0.3.1 initialization file: /etc/therion.ini reading open file -- /etc/therion.ini close file -- /etc/therion.ini configuration file: thconfig reading open file -- thconfig close file -- thconfig reading input -- rabbit.th open file -- rabbit.th open file -- rabbit.th2 therion (therion.cxx:332): error -- (thdatareader.cxx:213): rabbit.th2 [708] -- (thline.cxx:370): invalid number -- horizontal Line 708 of rabbit.th2 says "adjust horizontal". If I remove this, I get an error for a later line which says "adjust vertical". Searching the manual for "adjust", "horizontal", or "vertical" doesn't turn up anything useful. Cheers, Olly Subject: Re: [therion] demo-rabbit doesn't process From: "Martin Budaj" Date: Mon, 6 Sep 2004 07:52:01 +0200 (CEST) To: therion@speleo.sk >> Line 708 of rabbit.th2 says "adjust horizontal". If I remove this, I >> get an error for a later line which says "adjust vertical". Searching >> the manual for "adjust", "horizontal", or "vertical" doesn't turn up >> anything useful. I'm really sorry for this. Adjust horizontal/vertical is a feature of 0.3.3 version which hasn't been released yet (it allows to produce exactly horizontal/vertical lines in the elevation or section even after the scrap distortion). Stacho was too happy to implement it that he updated the example to use this feature. None of us noticed that the corresponding therion is not available yet :( Until the 0.3.3 version comes, there will be old rabbit cave demo on the web page. Regards, Martin Subject: Re: [therion] demo-rabbit doesn't process From: Olly Betts Date: Thu, 9 Sep 2004 23:06:18 +0100 To: therion@speleo.sk On Mon, Sep 06, 2004 at 07:52:01AM +0200, Martin Budaj wrote: >> Until the 0.3.3 version comes, there will be old rabbit cave demo on the >> web page. Thankyou - it now processes for me. One question I have though - why is the elevation in the map editor drawn rotated 90 degrees? That would seem to make is much harder to draw unless there's some "view rotated" option, which I can't see to find. Cheers, Olly Subject: Re: [therion] demo-rabbit doesn't process From: Stacho Mudrak Date: Fri, 10 Sep 2004 09:14:24 +0200 To: therion@speleo.sk Olly Betts wrote: > One question I have though - why is the elevation in the map editor > drawn rotated 90 degrees? The reason is very simple. In the original scan - it was drawn on the border of the paper rotated 90degrees to the plan. The plan was drawn beside. And I was too lazy to split this scan into two separate bitmaps and rotate one of them 90 degrees. Now it looks very strange, I agree :( May be if original scan will be included, it can help. > That would seem to make is much harder to > draw unless there's some "view rotated" option, which I can't see to > find. There is no such an option. If you have such a problem (image rotation, scaling, color adjustments), it is very easy to do these bitmap transformations in some picture editor (e.g. gimp or photoshop) and load it into xtherion already prepared. Than you can draw it natural way. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] demo-rabbit doesn't process From: Olly Betts Date: Fri, 10 Sep 2004 15:05:02 +0100 To: therion@speleo.sk On Fri, Sep 10, 2004 at 09:14:24AM +0200, Stacho Mudrak wrote: >> The reason is very simple. In the original scan - it was drawn on the >> border of the paper rotated 90degrees to the plan. The plan was drawn >> beside. And I was too lazy to split this scan into two separate bitmaps >> and rotate one of them 90 degrees. Now it looks very strange, I agree :( Ah, I see. >> May be if original scan will be included, it can help. Probably - it's hard to know why it's like that otherwise. Incidentally why is the "load without images" menu option called "Open XP"? It's not at all self-documenting, and even having looked up the function in the manual, the name isn't obvious to me. My best guess is it's short for "Open eXcluding Pictures". I realise you want to avoid turning a menu entry into an essay, but something like "Open without pictures" or "Open (no pics)" would still be reasonably short while making the function obvious. >>> >That would seem to make is much harder to >>> >draw unless there's some "view rotated" option, which I can't see to >>> >find. > >> >> There is no such an option. If you have such a problem (image rotation, >> scaling, color adjustments), it is very easy to do these bitmap >> transformations in some picture editor (e.g. gimp or photoshop) and load >> it into xtherion already prepared. Than you can draw it natural way. Sure. I only went looking for it because I didn't think someone would have drawn the elevation sideways! Cheers, Olly Subject: Re: [therion] demo-rabbit doesn't process From: Stacho Mudrak Date: Fri, 10 Sep 2004 16:07:28 +0200 To: therion@speleo.sk >> Incidentally why is the "load without images" menu option called >> "Open XP"? It's not at all self-documenting, and even having looked up >> the function in the manual, the name isn't obvious to me. My best guess >> is it's short for "Open eXcluding Pictures". I realise you want to Your guess is correct :) >> avoid turning a menu entry into an essay, but something like "Open without >> pictures" or "Open (no pics)" would still be reasonably short while >> making the function obvious. "Open (no pics)" sounds much better, I agree. Will be changed in next version. Thanks, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Therion 0.3.3 announce From: "Martin Budaj" Date: Fri, 10 Sep 2004 13:09:11 +0200 (CEST) To: therion@speleo.sk Hello everybody, therion 0.3.3 is available. The most important changes are * support for surface map (2D) and surface grid (3D) * it's possible do display centreline in 2D map without drawing the scrap (it's enough to include survey in the map command) See the file CHANGES for details. The web page contains screenshots illustrating new features. Best wishes, Martin Subject: Havranik From: Martin Sluka Date: Fri, 10 Sep 2004 13:38:00 +0200 To: therion@speleo.sk CC: Martin Budaj , Peter Holubek Tak je to presne tak, ako som si myslel :) M. -- Subject: Re: [therion] Havranik From: Martin Sluka Date: Fri, 10 Sep 2004 15:24:43 +0200 To: therion@speleo.sk I apologize myself, I sent the original mail to therion conference instead of private one. The graph is measurement of waterflow of one permanent karst spring under Muran plateau at East Slovakia. We found the second spring, periodical one, not far from it. As you may see, there are missed peaks of the individual curves of permanent spring - the missed water flows from periodical one. Sorry, nothing connected with therion till now. Maybe somebody will dig through the temporary spring and... Martin -- Subject: How to change settings for just a few readings? From: Olly Betts Date: Mon, 27 Sep 2004 20:53:44 +0100 To: therion@speleo.sk I'm looking at how to convert from .svx format to .th format. Mostly working, except I can't see how to handle this cleanly (the situation modelled here is that the tape is too short, and for one leg is was measured from a different point - in the example this was distilled from because 2-3 was a plumb and we needed more tape to tie a crab on): *begin test *calibrate tape 1 1 2 10 0 0 *begin *calibrate tape 2 2 3 10 0 0 *end ; *calibrate 1 is now be back in effect 3 4 10 0 0 *end test The nearest I can get is: encoding iso8859-1 survey test -title "test" centreline calibrate tape 1 1 2 10 0 0 endcentreline centreline calibrate tape 2 2 3 10 0 0 endcentreline centreline 3 4 10 0 0 endcentreline endsurvey However this doesn't restore the "calibrate tape 1" of course (the survey length is 27m). I can't omit the survey name for a survey command, or pass an empty name. And I can't nest centreline commands. The only solution I can see is to track which settings are in effect and reset them all after the *end. That's just about OK for automated conversion if nobody's going to want to edit the result, but it must be a right headache for anyone who has tried to hand convert a dataset so I'm wondering if there's some way to express this situation. Cheers, Olly Subject: Re: [therion] How to change settings for just a few readings? From: Stacho Mudrak Date: Tue, 28 Sep 2004 12:29:51 +0200 To: therion@speleo.sk Olly Betts wrote: > The only solution I can see is to track which settings are in effect and > reset them all after the *end. That's just about OK for automated > conversion if nobody's going to want to edit the result, but it must be > a right headache for anyone who has tried to hand convert a dataset so > I'm wondering if there's some way to express this situation. No, there is no such possibility. You have to repeat calibration every time it changes. I would rewrite your example this way: encoding iso8859-1 survey test -title "test" centreline calibrate tape 1 1 2 10 0 0 calibrate tape 2 2 3 10 0 0 calibrate tape 1 3 4 10 0 0 endcentreline endsurvey I'm just wondering, whether these situations are so common... S. Subject: Re: [therion] How to change settings for just a few readings? From: Olly Betts Date: Tue, 28 Sep 2004 11:45:42 +0100 To: therion@speleo.sk On Tue, Sep 28, 2004 at 12:29:51PM +0200, Stacho Mudrak wrote: >> Olly Betts wrote: >> > >>> >The only solution I can see is to track which settings are in effect and >>> >reset them all after the *end. That's just about OK for automated >>> >conversion if nobody's going to want to edit the result, but it must be >>> >a right headache for anyone who has tried to hand convert a dataset so >>> >I'm wondering if there's some way to express this situation. > >> >> No, there is no such possibility. You have to repeat calibration every >> time it changes. I would rewrite your example this way: >> >> encoding iso8859-1 >> survey test -title "test" >> centreline >> calibrate tape 1 >> 1 2 10 0 0 >> calibrate tape 2 >> 2 3 10 0 0 >> calibrate tape 1 >> 3 4 10 0 0 >> endcentreline >> endsurvey Ick. >> I'm just wondering, whether these situations are so common... It happens 8 times in CUCC's Austria dataset. Cheers, Olly Subject: Re: [therion] How to change settings for just a few readings? From: John Pybus Date: Tue, 28 Sep 2004 12:21:16 +0100 To: therion@speleo.sk Stacho Mudrak wrote: > No, there is no such possibility. You have to repeat calibration every time it changes. I would rewrite your example this way: > > encoding iso8859-1 > survey test -title "test" > centreline > calibrate tape 1 > 1 2 10 0 0 > calibrate tape 2 > 2 3 10 0 0 > calibrate tape 1 > 3 4 10 0 0 > endcentreline > endsurvey > > I'm just wondering, whether these situations are so common... I'd say common enough on fairly large survey projects, especially those under exploration/expedition conditions where the surveying is done in a hurry and the chances of going back and correcting iffy readings are low. I quite often make use of changing the SD for particular legs where it's known that the survey wasn't done to the general standard. In general the SD is defined in a separate file which I *include in the survex data. Having to undo that separation when using therion, and repeat the definition of the SD, is a shame, and makes converting data harder (as I first attempt I've usually just ignored changes in SD and put a comment in the .th file). Yours, John Subject: Re: [therion] How to change settings for just a few readings? From: Stacho Mudrak Date: Tue, 28 Sep 2004 14:44:20 +0200 To: therion@speleo.sk There is no problem to add somethig like group-endgroup pair inside centerline, if it will really help you (or I can use just begin-end pair if you wish). Then it could be rewritten this way: centreline calibrate tape 1 1 2 10 0 0 group calibrate tape 2 2 3 10 0 0 endgroup 3 4 10 0 0 endcentreline Or do you see some other trivial solution of this problem? Regards, S. John Pybus wrote: > Stacho Mudrak wrote: > >> No, there is no such possibility. You have to repeat calibration every time it changes. I would rewrite your example this way: >> >> encoding iso8859-1 >> survey test -title "test" >> centreline >> calibrate tape 1 >> 1 2 10 0 0 >> calibrate tape 2 >> 2 3 10 0 0 >> calibrate tape 1 >> 3 4 10 0 0 >> endcentreline >> endsurvey >> >> I'm just wondering, whether these situations are so common... > > > > I'd say common enough on fairly large survey projects, especially those under exploration/expedition conditions where the surveying is done in a hurry and the chances of going back and correcting iffy readings are low. > > I quite often make use of changing the SD for particular legs where it's known that the survey wasn't done to the general standard. In general the SD is defined in a separate file which I *include in the survex data. Having to undo that separation when using therion, and repeat the definition of the SD, is a shame, and makes converting data harder (as I first attempt I've usually just ignored changes in SD and put a comment in the .th file). > > Yours, > > John > > Subject: Re: [therion] How to change settings for just a few readings? From: John Pybus Date: Tue, 28 Sep 2004 13:53:08 +0100 To: therion@speleo.sk Stacho Mudrak wrote: > There is no problem to add somethig like group-endgroup pair inside centerline, if it will really help you (or I can use just begin-end pair if you wish). > > Then it could be rewritten this way: > > centreline > calibrate tape 1 > 1 2 10 0 0 > group > calibrate tape 2 > 2 3 10 0 0 > endgroup > 3 4 10 0 0 > endcentreline > > Or do you see some other trivial solution of this problem? That seems like the most natural solution; it directly mirrors an unlabeled begin-end pair in survex data. I see no need for the syntax to actually be begin/end, and group/endgroup sounds ideal. Thanks, it would tidy up one of the few edge cases in mapping survex data to therion centrelines. John Subject: Re: [therion] How to change settings for just a few readings? From: Stacho Mudrak Date: Tue, 28 Sep 2004 14:56:33 +0200 To: therion@speleo.sk OK, I'll put it on the top of TODO list - at least now it seems to be like a very simple thing to implement. Regards, S. John Pybus wrote: > Stacho Mudrak wrote: > >> There is no problem to add somethig like group-endgroup pair inside centerline, if it will really help you (or I can use just begin-end pair if you wish). >> >> Then it could be rewritten this way: >> >> centreline >> calibrate tape 1 >> 1 2 10 0 0 >> group >> calibrate tape 2 >> 2 3 10 0 0 >> endgroup >> 3 4 10 0 0 >> endcentreline >> >> Or do you see some other trivial solution of this problem? > > > > That seems like the most natural solution; it directly mirrors an unlabeled begin-end pair in survex data. I see no need for the syntax to actually be begin/end, and group/endgroup sounds ideal. Thanks, it would tidy up one of the few edge cases in mapping survex data to therion centrelines. > > John > > Subject: Re: [therion] How to change settings for just a few readings? From: Stacho Mudrak Date: Wed, 29 Sep 2004 09:23:19 +0200 To: therion@speleo.sk The attached patch should enable group-endgroup inside centerline command. I have not tested it extensively, but you should be able to change everything (data order, calibration, sd, units etc.) inside. Regards, S. John Pybus wrote: > Stacho Mudrak wrote: > >> There is no problem to add somethig like group-endgroup pair inside centerline, if it will really help you (or I can use just begin-end pair if you wish). >> >> Then it could be rewritten this way: >> >> centreline >> calibrate tape 1 >> 1 2 10 0 0 >> group >> calibrate tape 2 >> 2 3 10 0 0 >> endgroup >> 3 4 10 0 0 >> endcentreline >> >> Or do you see some other trivial solution of this problem? > > > > That seems like the most natural solution; it directly mirrors an unlabeled begin-end pair in survex data. I see no need for the syntax to actually be begin/end, and group/endgroup sounds ideal. Thanks, it would tidy up one of the few edge cases in mapping survex data to therion centrelines. > > John > > Subject: snow and ice From: Olly Betts Date: Thu, 30 Sep 2004 15:21:41 +0100 To: therion@speleo.sk There doesn't seem to be a way to make an area "snow and ice" (the UIS symbol for either is stars). Does this entail writing some metapost? Has anyone already done it? Cheers, Olly Subject: Re: [therion] snow and ice From: Stacho Mudrak Date: Thu, 30 Sep 2004 16:58:24 +0200 To: therion@speleo.sk > There doesn't seem to be a way to make an area "snow and ice" (the UIS > symbol for either is stars). > > Does this entail writing some metapost? Has anyone already done it? Yes, and nobody did it until now. Until now, we have only ice point symbol. So we need new type (for point and for area). I suggest to add point snow area snow area ice Or any does your symbol set make a difference between snow, snow-and-ice and ice? Coding of these symbols is not so complicated. Regards, S. Subject: Re: [therion] snow and ice From: Olly Betts Date: Thu, 30 Sep 2004 16:49:06 +0100 To: therion@speleo.sk On Thu, Sep 30, 2004 at 04:58:24PM +0200, Stacho Mudrak wrote: >>> >There doesn't seem to be a way to make an area "snow and ice" (the UIS >>> >symbol for either is stars). >>> > >>> >Does this entail writing some metapost? Has anyone already done it? > >> >> Yes, and nobody did it until now. Until now, we have only ice point >> symbol. So we need new type (for point and for area). I suggest to add >> >> point snow >> area snow >> area ice >> >> Or any does your symbol set make a difference between snow, snow-and-ice >> and ice? Coding of these symbols is not so complicated. The UIS set doesn't distinguish - it's all just stars. I'm not sure about other symbol sets. In reality, the difference is often arbitrary and whether a particular area is best described as ice or snow or a combination varies with time. It looks like mpost/thArea.mp is the file for it, and I can see the definition of p_ice_UIS in mpost/thPoint.mp, which presumably is a single star. But how do I fill an area with that tesselated? Cheers, Olly Subject: Re: [therion] snow and ice From: Stacho Mudrak Date: Thu, 30 Sep 2004 17:52:06 +0200 To: therion@speleo.sk > It looks like mpost/thArea.mp is the file for it, and I can see the > definition of p_ice_UIS in mpost/thPoint.mp, which presumably is a > single star. But how do I fill an area with that tesselated? Firstly, therion must support the snow area type. How to write exact macro, I do not know :( , Martin will probably write us tomorrow. Regards, S. Subject: Example models? From: Wookey Date: Thu, 30 Sep 2004 15:55:28 +0100 To: Therion List I'm giving a talk about Therion at the BCRA conference this weekend. Are there any examples of real 3D models and how to create them beyond the piccy on the website? Is this functionality actually in therion 0.3.3? Can it do colour in surveys yet? If so how? Is morphing restricted to within a scrap? e.g. say I have two parallel passages, the data for one changes so it morphs. If they are drawn on the same scrap then the walls of both passages will move. If they are on separate scrpas then only the one that changes moves - correct? i..e morphing is done on a 'distance from station, within a scrap' basis? Can someone explain what the numbers and arrows and things in the bottom of the atlas view are for? I've pressed a lot of buttons and the view changes but I have not managed to understand exactly what is going on in terms of levels, names, links and grid positions. (I am looking at the cvs cave_a.pdf example) I'm leaving in about 1hr so any quick answers ytou have would be good :-) 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/ Subject: Re: [therion] Example models? From: Stacho Mudrak Date: Thu, 30 Sep 2004 17:10:12 +0200 To: therion@speleo.sk > I'm giving a talk about Therion at the BCRA conference this weekend. > Are there any examples of real 3D models and how to create them beyond the > piccy on the website? I will send you some at about 15 minutes. They are created just by: source input.th export model Where input is only 2D map. Nothing else. > Is this functionality actually in therion 0.3.3? Yes, it is generated by 0.3.3. > Can it do colour in surveys yet? If so how? No. It can do nothing. Just view and rotate. The 3D stuff is still in the stage of design and those models are only preliminary. > Is morphing restricted to within a scrap? e.g. say I have two parallel > passages, the data for one changes so it morphs. If they are drawn on the > same scrap then the walls of both passages will move. If they are on > separate scrpas then only the one that changes moves - correct? i..e > morphing is done on a 'distance from station, within a scrap' basis? Yes, but if two scraps lie on the same loop, error will be distributed between stations in both scraps so both passages will be morphed. Regards, S. Subject: Re: [therion] Example models? From: Stacho Mudrak Date: Thu, 30 Sep 2004 17:34:50 +0200 To: therion@speleo.sk > Can someone explain what the numbers and arrows and things in the bottom of > the atlas view are for? I've pressed a lot of buttons and the view changes > but I have not managed to understand exactly what is going on in terms of > levels, names, links and grid positions. (I am looking at the cvs cave_a.pdf > example) Hope this image helps. S. Subject: Re: Example models? From: Wookey Date: Thu, 30 Sep 2004 16:43:31 +0100 To: therion@speleo.sk +++ Stacho Mudrak [04-09-30 17:10 +0200]: >>> >I'm giving a talk about Therion at the BCRA conference this weekend. >>> >Are there any examples of real 3D models and how to create them beyond the >>> >piccy on the website? > >> >> I will send you some at about 15 minutes. Thanx - I just noticed that one of the website examples claims to have a 3D model... The older example data I have mostly doesn't work with 0.3.3 :-( >> They are created just by: >> >> source input.th >> export model >> >> Where input is only 2D map. Nothing else. Doesn't it need height symbols adding? Or does it guess if none are entered? >>> >Can it do colour in surveys yet? If so how? > >> >> No. It can do nothing. Just view and rotate. The 3D stuff is still in >> the stage of design and those models are only preliminary. Sorry I meant does the 2D stuff support passage colouring at all? or only greyscale/Black&White? >>> >Is morphing restricted to within a scrap? e.g. say I have two parallel >>> >passages, the data for one changes so it morphs. If they are drawn on the >>> >same scrap then the walls of both passages will move. If they are on >>> >separate scrpas then only the one that changes moves - correct? i..e >>> >morphing is done on a 'distance from station, within a scrap' basis? > >> >> Yes, but if two scraps lie on the same loop, error will be distributed >> between stations in both scraps so both passages will be morphed. THanx very much for the quick response. 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/ Subject: Re: [therion] Re: Example models? From: Stacho Mudrak Date: Thu, 30 Sep 2004 17:46:59 +0200 To: therion@speleo.sk >> Where input is only 2D map. Nothing else. > > > > Doesn't it need height symbols adding? Or does it guess if none are entered? Height symbol helps. Otherwise a guess is used. > Sorry I meant does the 2D stuff support passage colouring at all? or only > greyscale/Black&White? You may define colors of symbols in metapost (see lakes in rabbit cave), but things like passage color by survey/depth are not supported yet. S. Subject: Unhelpful metapost error From: Olly Betts Date: Thu, 30 Sep 2004 18:38:52 +0100 To: therion@speleo.sk My, I'm all questions today... When I try to process my survey to produce a PDF plan, metapost appears to not like something, but there's no error message, so I've no idea where to look. I've attached the log, I can send other stuff if that's helpful. This is therion 0.3.3 on Linux, with THUSESVX defined. Cheers, Olly therion 0.3.3 initialization file: /etc/therion.ini reading ... done configuration file: thconfig reading ... done reading source files ... done preprocessing database ... done processing survey data ... ####################### cavern log file ######################## 1> Survex 1.0.31 2> Copyright (C) 1990-2004 Olly Betts 3> Survey has no fixed points. Therefore I've fixed 1 at (0,0,0) 4> 5> Survey contains 275 survey stations, joined by 274 legs. 6> There are 0 loops. 7> Total length of survey legs = 1180.04m (1180.04m adjusted) 8> Total plan length of survey legs = 868.99m 9> Total vertical length of survey legs = 522.64m 10> Vertical range = 189.70m (from 21 at 2.59m to 185 at -187.11m) 11> North-South range = 139.82m (from 261 at 16.42m to 242 at -123.40m) 12> East-West range = 145.01m (from 196 at 34.11m to 231 at -110.90m) 13> 32 1-nodes. 14> 219 2-nodes. 15> 19 3-nodes. 16> 4 4-nodes. 17> 1 5-node. 18> ######################### transcription ######################## 3> 1 : 2@entrance.76 5> 275 : 15@boiling.76 -- 274 : 14@boiling.76 10> 21 : 1@bent.76 -- 185 : 11@keg.76 11> 261 : 1@boiling.76 -- 242 : 12@noways.76 12> 196 : 3@tap.76 -- 231 : 1@noways.76 13> 32 : 5@brave.76 14> 219 : 5@rift.76 15> 19 : 8@bent.76 16> 4 : 4@entrance.76 17> 1 : 2@entrance.76 #################### end of cavern log file #################### done calculating basic statistics ... done processing references ... done selecting export objects ... done scanning centreline tree ... done processing projection plan ... done average distortion: 2.77% writing 76_plan.pdf ... ####################### metapost log file ######################## Survex 1.0.31 Copyright (C) 1990-2004 Olly Betts Survey has no fixed points. Therefore I've fixed 1 at (0,0,0) Survey contains 275 survey stations, joined by 274 legs. There are 0 loops. Total length of survey legs = 1180.04m (1180.04m adjusted) Total plan length of survey legs = 868.99m Total vertical length of survey legs = 522.64m Vertical range = 189.70m (from 21 at 2.59m to 185 at -187.11m) North-South range = 139.82m (from 261 at 16.42m to 242 at -123.40m) East-West range = 145.01m (from 196 at 34.11m to 231 at -110.90m) 32 1-nodes. 219 2-nodes. 19 3-nodes. 4 4-nodes. 1 5-node. #################### end of metapost log file #################### therion: error -- metapost exit code -- 256 Subject: Re: [therion] Unhelpful metapost error From: Olly Betts Date: Thu, 30 Sep 2004 19:56:45 +0100 To: therion@speleo.sk On Thu, Sep 30, 2004 at 06:38:52PM +0100, Olly Betts wrote: >> When I try to process my survey to produce a PDF plan, metapost appears >> to not like something, but there's no error message, so I've no idea >> where to look. >> >> I've attached the log, I can send other stuff if that's helpful. >> >> This is therion 0.3.3 on Linux, with THUSESVX defined. Hmm, well by rearranging what stuff was in which file I seem to have stopped metapost complaining. But the pdf file seems to ignore all the scraps and I just get a lot of station markers with "arms". I've not tried to join any scraps together yet, but it seems odd that I don't get an error message if that's the problem. I also tried without THUSESVX defined, but that doesn't make the scraps appear. Cheers, Olly P.S. I'll keep the dataset which made metapost around for a while in case you want to investigate that. Subject: Re: [therion] Unhelpful metapost error From: Olly Betts Date: Thu, 30 Sep 2004 20:15:21 +0100 To: therion@speleo.sk On Thu, Sep 30, 2004 at 07:56:45PM +0100, Olly Betts wrote: >> Hmm, well by rearranging what stuff was in which file I seem to have >> stopped metapost complaining. But the pdf file seems to ignore all >> the scraps and I just get a lot of station markers with "arms". >> >> I've not tried to join any scraps together yet, but it seems odd that >> I don't get an error message if that's the problem. Ah, I didn't have a map ... endmap section for my plan. It might be better if that produced at least a warning... Cheers, Olly Subject: Re: [therion] Unhelpful metapost error From: Stacho Mudrak Date: Fri, 01 Oct 2004 09:15:47 +0200 To: therion@speleo.sk Olly Betts wrote: > Ah, I didn't have a map ... endmap section for my plan. It might be > better if that produced at least a warning... Thanks a lot. This is a very common problem (even it happens to me sometimes). I will fix it. Therion should generate warning, when there will be no map defined. And I will try, that it will produce map also in this case. Ragards, S. Subject: Re: [therion] Unhelpful metapost error From: Stacho Mudrak Date: Fri, 01 Oct 2004 09:20:11 +0200 To: therion@speleo.sk > therion: error -- metapost exit code -- 256 This is strange, usually metapost writes something to log file. Do you remember your wrong data arrangement? If you would like to see (in the future), where the problem is, you can run therion with -d option. Than all temporary files will not be deleted and in the {$TEMP}/thTMPDIR you will find therion metapost file data.mp. Running "mpost data.mp" should definitely be more verbose. Regards, S. Subject: Re: [therion] Unhelpful metapost error From: Olly Betts Date: Fri, 1 Oct 2004 11:16:31 +0100 To: therion@speleo.sk On Fri, Oct 01, 2004 at 09:20:11AM +0200, Stacho Mudrak wrote: >>> >therion: error -- metapost exit code -- 256 > >> >> This is strange, usually metapost writes something to log file. Do you >> remember your wrong data arrangement? It appears to be a problem with the version of one of the required software packages on one of my machines. The latest version of the survey compiles fine on one box, but gives this error on the other. So it was probably actually switching machines which fixed the problem. I'll double check next week but it looks like this probably isn't actually a therion problem. Cheers, Olly Subject: thbook typo corrections From: Olly Betts Date: Thu, 30 Sep 2004 18:43:11 +0100 To: therion@speleo.sk Just to prove I have actually read the manual... Cheers, Olly diff -ru therion-0.3.3-orig/thbook/ch01.tex therion-0.3.3/thbook/ch01.tex --- therion-0.3.3-orig/thbook/ch01.tex 2004-04-23 08:10:16.000000000 +0100 +++ therion-0.3.3/thbook/ch01.tex 2004-09-30 18:36:54.000000000 +0100 @@ -56,7 +56,7 @@ \subchapter Features. -Therion is a command-line application. It processess input files, which +Therion is a command-line application. It processes input files, which are---including 2D maps---in text format, and creates files with 2D maps or 3D model as the output. @@ -148,7 +148,7 @@ \subsubchapter Setting-up environment. -Therion reads settigs from the initialization file. Default settings should +Therion reads settings from the initialization file. Default settings should work fine for users using only ASCII (non-accented latin) characters, standard \TeX\ and \MP. @@ -182,7 +182,7 @@ * green---input files created by the user and output files created by Therion \endlist -Therion itself does the main task. It reads the input files, interpretes them, +Therion itself does the main task. It reads the input files, interprets them, finds closed loops and distributes errors. Next it transforms all other data (e.g.~2D maps) according to new stations position. Therion exports data for 2D maps in \MP\ format. \MP\ gives diff -ru therion-0.3.3-orig/thbook/ch02.tex therion-0.3.3/thbook/ch02.tex --- therion-0.3.3-orig/thbook/ch02.tex 2004-09-10 06:36:29.000000000 +0100 +++ therion-0.3.3/thbook/ch02.tex 2004-09-30 18:35:43.000000000 +0100 @@ -148,7 +148,7 @@ \description inserts the contents of a file in place of - the command. Default extension is `.th' and may be ommited. For greatest + the command. Default extension is `.th' and may be omitted. For greatest portability use relative paths and Unix slashes `|/|', not Windows backslashes `|\|', as directory separators. @@ -274,7 +274,7 @@ \options * |id | = id of the object - * |author | = author of the data and it's creation date + * |author | = author of the data and its creation date * |copyright | = copyright date and name * |title | = description of the object \endoptions @@ -368,11 +368,11 @@ separately by \MP; scraps which are too large may exceed \MP's memory and cause errors. - Scrap consits of point, line and area map symbols. See chapter {\it How + Scrap consists of point, line and area map symbols. See chapter {\it How the map is put together} for explanation how and in which order are they displayed. - Scrap border consits of lines with the |-outline out| or |-outline in| + Scrap border consists of lines with the |-outline out| or |-outline in| options (passage walls have |-outline out| by default). These line shouldn't intersect---otherwise Therion (\MP) can't detemine the interior of the scrap and \MP\ issues a warning message ``|scrap outline intersects itself|''. @@ -462,7 +462,7 @@ * |3d | = specify if the scrap should be used in 3D model reconstruction - * |author | = author of the data and it's creation date + * |author | = author of the data and its creation date * |copyright | = copyright date and name * |title | = description of the object \endoptions diff -ru therion-0.3.3-orig/thbook/ch03.tex therion-0.3.3/thbook/ch03.tex --- therion-0.3.3-orig/thbook/ch03.tex 2004-09-10 08:36:25.000000000 +0100 +++ therion-0.3.3/thbook/ch03.tex 2004-09-30 18:37:33.000000000 +0100 @@ -220,7 +220,7 @@ * |exclude-pages | = exclude specified pages from cave atlas. The list may contain page numbers separated by a comma or dash (for intervals) e.g.~|2,4-7,9,23| means, that pages 2, 4, 5, 6, 7, 9 and 23 - should be omited. Only the map pages should be counted. (Set |own-pages 0| + should be omitted. Only the map pages should be counted. (Set |own-pages 0| and |title-pages off| to get the correct page numbers to be excluded.) Changes of |own-pages| or |title-pages| options don't affect page excluding. (A) diff -ru therion-0.3.3-orig/thbook/ch04.tex therion-0.3.3/thbook/ch04.tex --- therion-0.3.3-orig/thbook/ch04.tex 2004-07-12 17:21:53.000000000 +0100 +++ therion-0.3.3/thbook/ch04.tex 2004-09-30 18:39:07.000000000 +0100 @@ -64,7 +64,7 @@ (select SURVEY_ID from CENTRELINE where TOPO_DATE between '1998-01-01' and '1998-12-31');| -{\it How long are pasages lying between 1500 and 1550 m a.s.l.?} +{\it How long are passages lying between 1500 and 1550 m a.s.l.?} |select sum(LENGTH) from SHOT, STATION S1, STATION S2 where (S1.Z+S2.Z)/2 between 1500 and 1550 and Subject: Fixed station symbols From: Date: Sat, 02 Oct 2004 16:49:10 +0200 To: therion@speleo.sk Hi, I´m new to therion and cannot solve this problem: when I try to mark station points as fixed (mark fixed) no special symbols are shown in the map or in legend (still there is the symbol for "temporary station"). Can anyone mail me an example file how it should work? Thanks Wolfgang Zillig Subject: [therion] Fixed station symbols From: Date: Sun, 03 Oct 2004 12:52:12 +0200 To: therion@speleo.sk Hi, I already solfed my problem! Thanks Wolfgang Zillig Subject: Re: Models. From: Wookey Date: Mon, 4 Oct 2004 10:54:17 +0100 To: Stacho Mudrak CC: Therion List +++ Stacho Mudrak [04-10-01 08:50 +0200]: >> Wookey wrote: > >>> >OK - thanx - just one thing - what do I view a .thm file with? I don't >>> >recognise the data in it. > >> >> XTherion model viewer (F4). I don't know whether you are running it on >> Linux, but on Win32 it works from standard installation. Ah- My build of therion is missing that menu item, which would explain why I was confused. Looks like the Debian build of therion does not have this facility, no doubt due to missing libraries etc. I hadn't realised the model viewer was internal to xtherion. I'll fix that soon. The Therion demo went reasonably well, although it's fair to say that at the moment Tunnel is easier to use. The comparison was very useful to people I think. I had a lot of trouble with therion 'path not connected' type messages when trying to create the demo. We need to work out some much more reliable way of getting error information to users. Currently if you do something wrong with area paths or joins that don't work you effective get an error of 'something is wrong somewhere' which is hopeless if you have just drawn a big chunk of cave. Even when there is a simple error, the error gives the line number; whilst the xtherion viewer shows 'item number' next to each entry - there is no way to relate these. As the whole thing is integrated it could easily show you the offending line - or even put you there in one of the windows. 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/ therion Digest of: get.201_300 Topics (messages 201 through 300): Re: Fixed station symbols 201 by: Wookey 202 by: Wolfgang Zillig 204 by: Stacho Mudrak 205 by: Wolfgang Zillig 206 by: Stacho Mudrak Re: Models. 203 by: Stacho Mudrak 2 Therion Questions 207 by: Jenny Black 208 by: Stacho Mudrak 209 by: Tomas Bohanes 210 by: Jenny Black 211 by: Stacho Mudrak scale / base-scale question 212 by: Jenny Black 213 by: Stacho Mudrak 214 by: Stacho Mudrak 215 by: Jenny Black 216 by: Stacho Mudrak Re: Unhelpful metapost error 217 by: Olly Betts 218 by: Wookey therion workshop 219 by: Martin Sluka 220 by: Ladislav Blazek 222 by: Wolfgang Zillig 223 by: Martin Sluka 225 by: Martin Sluka Therion 0.3.4 221 by: Martin Budaj Font sizes for labels 224 by: Jenny Black 226 by: Stacho Mudrak problem with 0.2.17 in 0.3.4 227 by: Simeon Warner 228 by: Stacho Mudrak 229 by: Simeon Warner Re: therion] 230 by: Stacho Mudrak Mud and sand 231 by: Andrew Atkinson 232 by: Wookey 236 by: Stacho Mudrak 238 by: Wookey 239 by: Martin Sluka 240 by: Eric Madelaine 241 by: Andrew Atkinson 243 by: Stacho Mudrak 245 by: M.J. Green 246 by: Michael Lake Tom library and scrap connections 233 by: Wookey 234 by: Olly Betts 235 by: Wookey 237 by: Stacho Mudrak Therion hangs occaisionally 242 by: Wookey 244 by: Stacho Mudrak 247 by: Wookey 248 by: Stacho Mudrak 249 by: Martin Sluka 250 by: Stacho Mudrak arranging files and surveys 251 by: Wookey 253 by: Martin Budaj 257 by: Wookey No x-size for pillar? 252 by: Wookey 254 by: Martin Budaj 256 by: Stacho Mudrak Therion Wiki pages 255 by: Martin Budaj Help - my cave is inside-out 258 by: Wookey 259 by: Martin Budaj 260 by: Wookey 261 by: Wookey 262 by: Wookey 263 by: Martin Budaj 264 by: Stacho Mudrak 265 by: Stacho Mudrak 266 by: Stacho Mudrak 267 by: Martin Budaj 268 by: Wookey 269 by: Martin Budaj 272 by: Ing. Jirí Novotný 290 by: Wookey 291 by: Wookey 295 by: Martin Budaj 298 by: Wookey 299 by: Wookey 300 by: Wookey Importing surveys with no data 270 by: Wookey 279 by: Stacho Mudrak 284 by: Wookey 285 by: Martin Sluka 286 by: Martin Sluka 287 by: Stacho Mudrak 288 by: Stacho Mudrak 289 by: Wookey debug mode 271 by: Wookey 273 by: Olly Betts 274 by: Jenny Black 275 by: Wookey 276 by: Wookey 277 by: Olly Betts 278 by: Gary Ritchie 280 by: Stacho Mudrak 281 by: Stacho Mudrak 282 by: Wookey 283 by: Ladislav Blazek General note and suggestions 292 by: Wookey 294 by: Martin Sluka 296 by: Wookey 297 by: Martin Sluka rock-border cannot be presumed 293 by: Wookey Subject: Re: Fixed station symbols From: Wookey Date: Mon, 4 Oct 2004 11:44:20 +0100 To: therion@speleo.sk +++ zillig@hoki.ibp.fhg.de [04-10-03 12:52 +0200]: >> Hi, >> >> I already solfed my problem! Thanks Perhaps tell the rest of us, so we won't make it? 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/ Subject: Re: Fixed station symbols From: Wolfgang Zillig Date: Mon, 04 Oct 2004 13:10:06 +0200 To: therion@speleo.sk Hi all, here a loger description of my problem und the solution: First I tried to add "mark fixed" within the centreline command as mentioned in the Handbook on page 13 and 14. But this did not result in different Symbols in the map. Afterwards I found out that it is possibile to mark the stations within the point command (in map editor). But when I tried this first I added a non complete command at another point symbol and so I always got error messages and I thought its a therion problem. It needed some time until I realised that the error message links to an other line number. Then I realised my mistakes. in short: point x y station -mark fixed/painted -> this works But I have another question: are there other (known) therion users from Germany? Best regards Wolfgang Zillig Subject: Re: Fixed station symbols From: Stacho Mudrak Date: Mon, 04 Oct 2004 14:52:22 +0200 To: therion@speleo.sk Wolfgang Zillig wrote: > First I tried to add "mark fixed" within the centreline command as mentioned in the Handbook on page 13 and 14. But this did not result in different Symbols in the map. Afterwards I found out that it is possibile to mark the stations within the point command (in map editor). You are right, this is not natural arrangement. It would be better, if station subtypes would be determined from centerline, if -subtype is not exactly specified in point command. This should not be a big problem to implement. > But I have another question: are there other (known) therion users from Germany? There are none in the mailing list. Regards, S. Subject: Re: [therion] Re: Fixed station symbols From: Wolfgang Zillig Date: Mon, 04 Oct 2004 15:31:42 +0200 To: therion@speleo.sk Stacho Mudrak wrote: > Wolfgang Zillig wrote: > >> First I tried to add "mark fixed" within the centreline command as mentioned in the Handbook on page 13 and 14. But this did not result in different Symbols in the map. Afterwards I found out that it is possibile to mark the stations within the point command (in map editor). > > > > You are right, this is not natural arrangement. It would be better, if station subtypes would be determined from centerline, if -subtype is not exactly specified in point command. This should not be a big problem to implement. > I think it´s not a big problem to mark each station within the map editor. I was worried about why this command is within centreline and why output did not change. But I don´t know how it should be possibile to mark each station in centreline when there are different types of stations ond to keep it readable. Wolfgang Zillig Subject: Re: [therion] Re: Fixed station symbols From: Stacho Mudrak Date: Mon, 04 Oct 2004 16:03:13 +0200 To: therion@speleo.sk > I think it´s not a big problem to mark each station within the map editor. I was worried about why this command is within centreline and why output did not change. Well, it is not correctly written in thbook. We will fix it. > But I don´t know how it should be possibile to mark each station in centreline when there are different types of stations ond to keep it readable. Oooops, you are right. Now I see, that it is not possible to mark stations in one centerline different ways. I will think about it a little bit... Regards, S. Subject: Re: Models. From: Stacho Mudrak Date: Mon, 04 Oct 2004 14:41:47 +0200 To: therion@speleo.sk Wookey wrote: > Ah- My build of therion is missing that menu item, which would explain why I > was confused. Looks like the Debian build of therion does not have this > facility, no doubt due to missing libraries etc. Yes. We are using modified version of one French OpenGL TclTk parser. Therefore it's included in therion distribution. In any case, I'm already working on a new version of therion 3D viewer written in wxWidgets, but it's going very slowly (I have to learn a lot of new things). > I had a lot of trouble with therion 'path not connected' type messages when trying > to create the demo. We need to work out some much more reliable way of > getting error information to users. Currently if you do something wrong with > area paths or joins that don't work you effective get an error of 'something > is wrong somewhere' which is hopeless if you have just drawn a big chunk of > cave. You are right. We did not face such problems very often, therefore we did not make error detection effective. If error is generated by metapost, it is very difficult to fix. It would probably help, if metapost will also report source position of errors. > Even when there is a simple error, the error gives the line number; whilst > the xtherion viewer shows 'item number' next to each entry - there is no way > to relate these. As the whole thing is integrated it could easily show you > the offending line - or even put you there in one of the windows. Yes, I wanted to do this several times, but it is not so simple (to connect line number and xtherion's item number). But it is possible, so I will put this on the TODO list. Thanx for your suggestions, S. Subject: 2 Therion Questions From: Jenny Black Date: Tue, 05 Oct 2004 11:40:02 +0100 To: therion@speleo.sk Hi, I have just started using Therion to draw up some cave found this summer. And I have a couple of things that I wondered if it would be possible to change. I apologise if they are things that I will get used to as I become more familiar with using Therion. When you draw lines there is the little yellow tick mark at the first line-point telling you which side is inside the wall, or down the pit, or whatever. Would it be possible to make the tick mark larger (maybe twice the size?), so it was easier to see? I managed to draw up quite a lot before realising it was there! Also, when you "insert scrap" in the map editor, it places the "scrap" "end scrap" lines wherever you currently are, which will probably be in the middle of the previous scrap you worked on. I don't know if it would be possible for it to check whether this was in the middle of scrap, and if so, automatically insert the new scrap after the current scrap, or above the "end of file" line? Thanks, Jenny Subject: Re: [therion] 2 Therion Questions From: Stacho Mudrak Date: Tue, 05 Oct 2004 13:18:21 +0200 To: therion@speleo.sk >> When you draw lines there is the little yellow tick mark at the first >> line-point telling you which side is inside the wall, or down the pit, or >> whatever. Would it be possible to make the tick mark larger (maybe twice >> the size?), so it was easier to see? I managed to draw up quite a lot >> before realising it was there! Yes. Uncomment the last two lines of xtherion.ini file and changed them as desired. Example: # size of start line tick set xth(gui,me,line,ticksize) 50 # width of start line tick set xth(gui,me,line,tickwidth) 10 You may modify whatever you want. If you are running therion on Linux, the best way is to create .therion directory in $HOME and put xtherion.ini file there. If you are running it on Win32, you may change in therion installation directory, but the best way is to create your own directory with therion settings (therion.ini and xtherion.ini) and set environment variable THERION to this directory. If there are any other wishes, what else should be in xtherion.ini file, just let me know. >> Also, when you "insert scrap" in the map editor, it places the "scrap" "end >> scrap" lines wherever you currently are, which will probably be in the >> middle of the previous scrap you worked on. I don't know if it would be >> possible for it to check whether this was in the middle of scrap, and if >> so, automatically insert the new scrap after the current scrap, or above >> the "end of file" line? It is a very good idea - I will try to do it until next release. Thanks, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] 2 Therion Questions From: "Tomas Bohanes" Date: Thu, 7 Oct 2004 09:31:50 +0200 To: therion@speleo.sk >>> > Also, when you "insert scrap" in the map editor, it places the "scrap" "end >>> > scrap" lines wherever you currently are, which will probably be in the >>> > middle of the previous scrap you worked on. I don't know if it would be >>> > possible for it to check whether this was in the middle of scrap, and if >>> > so, automatically insert the new scrap after the current scrap, or above >>> > the "end of file" line? > >> >> It is a very good idea - I will try to do it until next release. It is not the only problem of the map editor. I have observed several times that after adding some object to the map (boulder, area etc.) the editor put referrence to the new object under the end of the current scrap. Compilation naturally generates an error, however it is very easy to repair it when I know what is the problem now. It would be good to check this problem for the next release, too. Regards Tomas Bohanes Subject: Re: [therion] 2 Therion Questions From: Jenny Black Date: Mon, 11 Oct 2004 15:25:52 +0100 To: therion@speleo.sk Thanks Stacho, for answering my other questions so quickly. I've got another question now, that maybe you or someone else can answer... How do I make underlying passage look paler than the main passage? I can see that it is possible as you have successfully done it in two of the examples, demo and demo-padavka. But I don't seem to be able to get the effect with our own data. Thanks, Jenny Subject: Re: [therion] 2 Therion Questions From: Stacho Mudrak Date: Mon, 11 Oct 2004 16:46:53 +0200 To: therion@speleo.sk Jenny Black wrote: > How do I make underlying passage look paler than the main passage? It is very simple: 1. These passages must be in different scraps (let's call them above-scrap and below-scrap). Now you need to put these scraps in two different levels. If they exist within one map (this is probably your case), use break command to separate map levels: map two-passages above-scrap break below-scrap endmap In other case (if each of them is in the different map), it should work automatically. 2. In your layout, transparency must be enabled, using "transparency on" switch (or "-layout-transparency on" option directly in export command.) But this is defalut - so you probably do not need to modify this. You may also need to redefine opacity to some other value, especially if you want to print or you are using LCD screen. 3. You need a PDF browser, that supports transparencies (e.g. Acrobat 5.0 or newest version of Ghostscript) Hope it helps, S. Subject: scale / base-scale question From: Jenny Black Date: Tue, 12 Oct 2004 14:10:04 +0100 To: therion@speleo.sk Hi, >> How do I make underlying passage look paler than the main passage? > > > It is very simple: Adding in the "break"s within the maps worked well, thank you! Now I have another question to do with scaling... I want to print out the final survey at 1:500 (to be consistent with other caves in the area). However most of the cave passages are between 1 and 2m wide. I have noticed that you use 1:200 for drawing up passages of a similar width, and have therefore the symbol sizes have been designed accordingly. I tried several different combinations of scale and base-scale options, with the following results: 1) scale 1 500 * symbols (water and air flow arrows especially) are disproportionately large for the passage, the arrow heads of the water-flows are often larger than the passages they are in * wall lines seem very thick, and overshadow the smaller passages 2) scale 1 500 base-scale 1 200 * labels are small (but I can change that easily enough with the "fonts_setup" thing described in The Therionbook) * water-flow arrowheads are all wiggly rather than triangular * air-flow arrows and other symbols are great 3) scale 1 200 * symbols look good * but at 1:200, not 1:500, perhaps I could scale it in a graphics package before printing, though this seems like cheating! Any suggestions for how to create the best output? Thanks, Jenny Subject: Re: [therion] scale / base-scale question From: Stacho Mudrak Date: Tue, 12 Oct 2004 15:33:10 +0200 To: therion@speleo.sk Jenny Black wrote: > 1) scale 1 500 > * symbols (water and air flow arrows especially) are disproportionately large for the passage, the arrow heads of the water-flows are often larger than the passages they are in > * wall lines seem very thick, and overshadow the smaller passages Well, the symbol sizes can be redefined via metapost code directly in the layout. The problem is, I have only a feeling, how this works and Martin (he is doing this stuff) is on holidays this week :( > 2) scale 1 500 > base-scale 1 200 > * labels are small (but I can change that easily enough with the "fonts_setup" thing described in The Therionbook) > * water-flow arrowheads are all wiggly rather than triangular > * air-flow arrows and other symbols are great This should be the correct solution, but ... + there is a bug in water-flow symbol - it have to be fixed. + setting font sizes is possible also without font-setup - but again, I have no idea at the moment how to do it. But both things are possible to change from layout. I will have a look at it later today and I will let you know, how to solve this problem. Regards, S. Subject: Re: [therion] scale / base-scale question From: Stacho Mudrak Date: Tue, 12 Oct 2004 16:06:09 +0200 To: therion@speleo.sk Font sizes setup is very simple, just add to layout following lines: code metapost fonts_setup(14,16,20,28,40); Some remarks: Default is fonts_setup(7,8,10,14,20) for 1:200, so the above command will double font sizes. Sizes 7,8,10,14,20 are the font sizes for xs,s,m,l,xl fonts. In the output map, these sizes are mupltiplied by optical scale (1/2.5 in this case). So if you want medium font to be 10 point size, it needs to be set to 10 * 2.5 = 25 pt :) OK, it sounds complicated, but it is very simple. To fix the waterflow arrow bug, add following metapost code to your layout. code metapost def p_waterflow_permanent (expr pos,theta,sc,al)= U:=(.15u,.5u); T:=identity aligned al rotated theta scaled sc shifted pos; pickup PenC; p:=(0,.5u){down}..(.12u,.3u)..(-.15u,.15u)..(.13u,0).. (-.08u,-.2u)..{down}(0,-.5u); p:=p rotated 180; thdraw p; oldahlength:=ahlength; ahlength:=2.5pt * optical_zoom; thdraw arrowhead p; thfill arrowhead p; ahlength:=oldahlength; enddef; It is still "cheating", but it should help you. If not or you are using other waterflow symbols, please let me know. In the next release, these problems should be fixed. Regards, S. Subject: Re: [therion] scale / base-scale question From: Jenny Black Date: Tue, 12 Oct 2004 20:54:12 +0100 (BST) To: therion@speleo.sk Hello again, Thanks for replying so quickly again. I tried adding this to my layout and I'm afraid it didn't make any difference, the water-flow arrow heads are still all wiggly. Do you have any other ideas? Thanks agian, Jenny >>To fix the water-flow arrow bug, add following metapost code to your layout. >> >> code metapost >> def p_waterflow_permanent (expr pos,theta,sc,al)= >> U:=(.15u,.5u); >> T:=identity aligned al rotated theta scaled sc shifted pos; >> pickup PenC; >> p:=(0,.5u){down}..(.12u,.3u)..(-.15u,.15u)..(.13u,0).. >> (-.08u,-.2u)..{down}(0,-.5u); >> p:=p rotated 180; >> thdraw p; >> oldahlength:=ahlength; ahlength:=2.5pt * optical_zoom; >> thdraw arrowhead p; >> thfill arrowhead p; >> ahlength:=oldahlength; >> enddef; Subject: Re: [therion] scale / base-scale question From: Stacho Mudrak Date: Wed, 13 Oct 2004 10:35:30 +0200 To: therion@speleo.sk No problem. It means - you are using "line water-flow" symbols, I did not expect this. Please copy metapost code from layout "water-bug-fix" in the attached project to your layout. This should solve your problem - see attached PDF files. Regards, S. Jenny Black wrote: > Hello again, > > Thanks for replying so quickly again. I tried adding this to my layout > and I'm afraid it didn't make any difference, the water-flow arrow heads > are still all wiggly. Do you have any other ideas? > > Thanks agian, > Jenny > > >> To fix the water-flow arrow bug, add following metapost code to your layout. >> >> code metapost >> def p_waterflow_permanent (expr pos,theta,sc,al)= >> U:=(.15u,.5u); >> T:=identity aligned al rotated theta scaled sc shifted pos; >> pickup PenC; >> p:=(0,.5u){down}..(.12u,.3u)..(-.15u,.15u)..(.13u,0).. >> (-.08u,-.2u)..{down}(0,-.5u); >> p:=p rotated 180; >> thdraw p; >> oldahlength:=ahlength; ahlength:=2.5pt * optical_zoom; >> thdraw arrowhead p; >> thfill arrowhead p; >> ahlength:=oldahlength; >> enddef; > > > > Subject: Re: [therion] Unhelpful metapost error From: Olly Betts Date: Thu, 14 Oct 2004 04:27:51 +0100 To: therion@speleo.sk CC: Wookey On Fri, Oct 01, 2004 at 09:20:11AM +0200, Stacho Mudrak wrote: >>> >therion: error -- metapost exit code -- 256 > >> >> This is strange, usually metapost writes something to log file. Do you >> remember your wrong data arrangement? >> >> If you would like to see (in the future), where the problem is, you can >> run therion with -d option. Than all temporary files will not be deleted >> and in the {$TEMP}/thTMPDIR you will find therion metapost file data.mp. OK, this problem hasn't gone away (we've just been using the box it works on). But looking at it again, if I run therion -d the output from metapost is: This is MetaPost, Version 0.641 (Web2C 7.4.5) kpathsea: Running mktexfmt mpost.mem fmtutil: format `mpost' not available. I can't find the mem file `mpost.mem'! therion: error -- metapost exit code -- 256 It turns out that the problem box is missing /var/lib/texmf/web2c/mpost.mem while the other box has it. Both boxes are running debian "unstable", but that file isn't owned by any package (so I presume it is generated by installing one of the tetex packages or something list that). Digging deeper, the "good" box has tetex-extra installed, but the "bad" box doesn't, and after installing this package, everything works. But the debian therion package depends on tetex-bin but not tetex-extra so it's not automatically installed. Wookey: I've not filed a Debian bug for this - let me know if you want me to... Cheers, Olly Subject: Re: Unhelpful metapost error From: Wookey Date: Thu, 14 Oct 2004 22:48:09 +0100 To: therion@speleo.sk +++ Olly Betts [04-10-14 04:27 +0100]: >> On Fri, Oct 01, 2004 at 09:20:11AM +0200, Stacho Mudrak wrote: > >>>> > >therion: error -- metapost exit code -- 256 >> >>> > >>> > This is strange, usually metapost writes something to log file. Do you >>> > remember your wrong data arrangement? >>> > >>> > If you would like to see (in the future), where the problem is, you can >>> > run therion with -d option. Than all temporary files will not be deleted >>> > and in the {$TEMP}/thTMPDIR you will find therion metapost file data.mp. > >> >> OK, this problem hasn't gone away (we've just been using the box it >> works on). But looking at it again, if I run therion -d the output from >> metapost is: >> >> This is MetaPost, Version 0.641 (Web2C 7.4.5) >> kpathsea: Running mktexfmt mpost.mem >> fmtutil: format `mpost' not available. >> I can't find the mem file `mpost.mem'! >> therion: error -- metapost exit code -- 256 >> >> It turns out that the problem box is missing /var/lib/texmf/web2c/mpost.mem >> while the other box has it. Both boxes are running debian "unstable", >> but that file isn't owned by any package (so I presume it is generated >> by installing one of the tetex packages or something list that). >> >> Digging deeper, the "good" box has tetex-extra installed, but the "bad" >> box doesn't, and after installing this package, everything works. But >> the debian therion package depends on tetex-bin but not tetex-extra so >> it's not automatically installed. >> >> Wookey: I've not filed a Debian bug for this - let me know if you want >> me to... Nope - I'll fix that - I need to do an update anyway to have Debian therion include the model viewer.... That's another 10MB on the therion footprint, which is a problem for 'embedded' use, but otherwise simple enough. Well spotted. 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/ Subject: therion workshop From: Martin Sluka Date: Fri, 15 Oct 2004 12:38:34 +0200 To: therion@speleo.sk CC: heller@geo.unizh.ch, France Sustersic Hi, we are preparing the Therion workshop. Date: last weekend of November - 27th and 28t'h. Place: Czech Republic - Moravian Karst - near Brno or Czech Karst - near Prague. Program: Main goal is - each participant should be able to create individualy cave map and other outputs in Therion. For participants: please bring your own computer if possible. To work with therion without one is not very practical. Cave program - it depends on interest. For details contact me, Stacho or Lada Blazek - blazek (att) speleo (ddott) cz Best regards Martin Sluka -- Subject: Re: [therion] therion workshop From: "Ladislav Blazek" Date: Fri, 15 Oct 2004 12:54:51 +0200 (CEST) To: therion@speleo.sk Martin Sluka napsal(a): >> For details contact me, Stacho or Lada Blazek - blazek (att) speleo >> (ddott) cz My e-mail address is lblazek (at) speleo (dot) cz -- Ladislav Blazek Subject: Re: [therion] therion workshop From: Wolfgang Zillig Date: Tue, 26 Oct 2004 20:07:05 +0200 To: therion@speleo.sk Hi, I would like to join the workshop. I think I will come by car from munich. Is there anybody out there whom I shoud give a lift? Wolfgang Zillig Martin Sluka wrote: > Hi, > > we are preparing the Therion workshop. > > Date: last weekend of November - 27th and 28t'h. > > Place: Czech Republic - Moravian Karst - near Brno or Czech Karst - near Prague. > > Program: Main goal is - each participant should be able to create individualy cave map and other outputs in Therion. > > For participants: please bring your own computer if possible. To work with therion without one is not very practical. > > Cave program - it depends on interest. > > For details contact me, Stacho or Lada Blazek - blazek (att) speleo (ddott) cz > > Best regards > > Martin Sluka Subject: Re: [therion] therion workshop From: Martin Sluka Date: Tue, 26 Oct 2004 21:25:58 +0200 To: therion@speleo.sk The workshop will be at Moravian Karst - at Macocha hotel near Macocha abyss. The accomodation is booked from 26. November. Feel free to call me - +420-603513640. If possible come with your computer. Martin At 20:07 +0200 26.10.2004, Wolfgang Zillig wrote: ******************************************* > Hi, > > I would like to join the workshop. I think I will come by car from munich. Is there anybody out there whom I shoud give a lift? > > Wolfgang Zillig > > Martin Sluka wrote: > >> Hi, >> >> we are preparing the Therion workshop. >> >> Date: last weekend of November - 27th and 28t'h. >> >> Place: Czech Republic - Moravian Karst - near Brno or Czech Karst - near Prague. >> >> Program: Main goal is - each participant should be able to create individualy cave map and other outputs in Therion. >> >> For participants: please bring your own computer if possible. To work with therion without one is not very practical. >> >> Cave program - it depends on interest. >> >> For details contact me, Stacho or Lada Blazek - blazek (att) speleo (ddott) cz >> >> Best regards >> >> Martin Sluka -- Subject: Re: [therion] therion workshop From: Martin Sluka Date: Tue, 26 Oct 2004 22:45:43 +0200 To: therion@speleo.sk Atached is a map how to reach the workshop place. Martin -- Subject: Therion 0.3.4 From: "Martin Budaj" Date: Fri, 22 Oct 2004 10:30:01 +0200 (CEST) To: therion@speleo.sk Hello everybody, Therion 0.3.4 is available for download. The most important improvements are: - Error messages in Compiler window in XTherion are hyperlinked to data source files - group/endgroup inside centreline command - Windows installation: TeX/MetaPost works even if there is other TeX installation present in the system (it used not to run if there was TeXLive installed) Therion team Subject: Font sizes for labels From: Jenny Black Date: Tue, 26 Oct 2004 20:30:31 +0100 (BST) To: Therion List Thanks for helping with all my other questions, heres another one... I would like to use two different font sizes for labeling passages, ideally in the same font-type. Is it possible to do this in therion? I have tried a few things... I have been using the "label" point symbol for these labels. The thbook suggests that the size of point symbols can be altered with "-scale s" however this doesn't seem to do anything to labels, so presumably it only works for certain point symbols? I tried using the line symbol for labels, but I would like to make the labels horizontal, and even if the line appears horizontal in the Map Editor, it doesnt end up horizontal in the final map (presumably it gets morphed with the passage?). I then tried to use the "remark" point symbol, and this successfully produces a small font size, however, whislt I figured out how to stop it being italic (-text "Passage Name") it seems to be in a different font type to the other labels produced by the "label" point symbol. Any ideas please? Thanks! Jenny Subject: Re: Font sizes for labels From: Stacho Mudrak Date: Wed, 27 Oct 2004 09:17:59 +0200 To: therion@speleo.sk Jenny Black wrote: > I have been using the "label" point symbol for these labels. The thbook > suggests that the size of point symbols can be altered with "-scale s" > however this doesn't seem to do anything to labels, so presumably it > only works for certain point symbols? Well - it does work in the case of line label, but it does not in the case of point label. Thanks for pointing out - it is a bug. > I then tried to use the "remark" point symbol, and this successfully > produces a small font size, however, whislt I figured out how to stop it > being italic (-text "Passage Name") it seems to be in a different > font type to the other labels produced by the "label" point symbol. You should use instead ( means sans serif). means roman - it is a serif font. This should solve your problem for a while. We will try to fix it in the next release. Regards, S. Subject: problem with 0.2.17 in 0.3.4 From: Simeon Warner Date: Wed, 3 Nov 2004 23:20:28 -0500 (EST) To: therion@speleo.sk I recently picked up a project I started working on with therion 0.2.17 and installed 0.3.4. When I try to compile I get lots of errors of the form shown below. Can anyone suggest where I should look to fix this? Cheers, Simeon simeon@localhost mcfails>therion mcfails.thconfig therion 0.3.4 configuration file: mcfails.thconfig reading ... done reading source files ... done preprocessing database ... done scanning centreline tree ... done searching for centerline loops ... done calculating station coordinates ... done calculating basic statistics ... done processing references ... done selecting export objects ... done processing projection plan ... done average distortion: 5.01% writing mcfails_beyond_asia_dome.pdf ... This is MetaPost, Version 0.641 (Web2C 7.3.1) (data.mp [4001] [4002] [4003] [4004] [4005] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] ! Inconsistent equation (off by -96.8626). ; ...z1,zz2])>0.1pt):zz5=whatever[zz1,zz2]; (zz3-zz5)=whatever*(zz1-zz... l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor ;for.pnt=(TEXT1):if.pnt=-1... l.3238 ),) ; ! Inconsistent equation (off by -18.38467). ; ...(zz3-zz5)=whatever*(zz1-zz2)rotated90; draw.zz1--zz5;zz6=whatever... l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor ;for.pnt=(TEXT1):if.pnt=-1... l.3238 ),) ; .... ! Inconsistent equation (off by 24.34366). ; ...zz4-zz6)=whatever*(zz1-zz2)rotated90; draw.zz2--zz6;else:draw.zz... l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor ;for.pnt=(TEXT1):if.pnt=-1... l.3238 ),) ; [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [Warning: scrap outline intersects itself in scrap_asia1@mcfails] [35] [36] [37] [38] ) (see the transcript file for additional information) 43 output files written: data.1 .. data.4005 Transcript written on data.log. /home/simeon/bin/therion/therion: error -- metapost exit code -- 256 (yhe error doesn't go away if I remove the scrap reported as intersecting itself) Subject: Re: problem with 0.2.17 in 0.3.4 From: Stacho Mudrak Date: Thu, 04 Nov 2004 08:59:02 +0100 To: therion@speleo.sk We are sorry - it is a bug in the therion. It is caused by "line section" symbol, probably there is some pathology there (zero length line?), which is not handled properly. But we are not able to fix it without seeing the therion code, that generates this error. It would be great, if you could send us that part of the code. Thanks, S. Simeon Warner wrote: > I recently picked up a project I started working on with therion 0.2.17 > and installed 0.3.4. When I try to compile I get lots of errors of the > form shown below. Can anyone suggest where I should look to fix this? > > Cheers, > Simeon > > > simeon@localhost mcfails>therion mcfails.thconfig > therion 0.3.4 > configuration file: mcfails.thconfig > reading ... done > reading source files ... done > preprocessing database ... done > scanning centreline tree ... done > searching for centerline loops ... done > calculating station coordinates ... done > calculating basic statistics ... done > processing references ... done > selecting export objects ... done > processing projection plan ... done > average distortion: 5.01% > writing mcfails_beyond_asia_dome.pdf ... > This is MetaPost, Version 0.641 (Web2C 7.3.1) > (data.mp [4001] [4002] [4003] [4004] [4005] > [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] > ! Inconsistent equation (off by -96.8626). > > ; > ...z1,zz2])>0.1pt):zz5=whatever[zz1,zz2]; > > (zz3-zz5)=whatever*(zz1-zz... > > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor > > ;for.pnt=(TEXT1):if.pnt=-1... > l.3238 ),) > ; > ! Inconsistent equation (off by -18.38467). > > ; > ...(zz3-zz5)=whatever*(zz1-zz2)rotated90; > > draw.zz1--zz5;zz6=whatever... > > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor > > ;for.pnt=(TEXT1):if.pnt=-1... > l.3238 ),) > ; > > .... > > ! Inconsistent equation (off by 24.34366). > > ; > ...zz4-zz6)=whatever*(zz1-zz2)rotated90; > > draw.zz2--zz6;else:draw.zz... > > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor > > ;for.pnt=(TEXT1):if.pnt=-1... > l.3238 ),) > ; > [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] > [27] [28] [29] [30] [31] [32] [33] [34] > [Warning: scrap outline intersects itself in scrap_asia1@mcfails] [35] > [36] > [37] [38] ) > (see the transcript file for additional information) > 43 output files written: data.1 .. data.4005 > Transcript written on data.log. > /home/simeon/bin/therion/therion: error -- metapost exit code -- 256 > > (yhe error doesn't go away if I remove the scrap reported as intersecting > itself) > > Subject: Re: [therion] Re: problem with 0.2.17 in 0.3.4 From: Simeon Warner Date: Thu, 4 Nov 2004 08:25:48 -0500 (EST) To: therion@speleo.sk On Thu, 4 Nov 2004, Stacho Mudrak wrote: >> We are sorry - it is a bug in the therion. It is caused by "line >> section" symbol, probably there is some pathology there (zero length >> line?), which is not handled properly. But we are not able to fix it >> without seeing the therion code, that generates this error. Thanks, I found the problem by inserting scraps one at a time and then commenting blocks within the one bad scrap. >> It would be great, if you could send us that part of the code. For you debugging pleasure... the bad 'line section' was: line section -close on 344.0 798.0 348.0 803.0 373.0 817.0 373.0 817.0 smooth off 373.0 817.0 378.0 823.0 393.0 823.0 408.0 823.0 424.0 820.0 424.0 820.0 smooth off 449.0 798.0 480.0 779.0 510.0 773.0 510.0 773.0 542.0 771.0 553.0 770.0 564.0 769.0 601.0 765.0 601.0 765.0 smooth off 601.0 765.0 623.0 765.0 627.0 766.0 631.0 767.0 682.0 750.0 682.0 750.0 smooth off 619.0 755.0 512.0 757.0 440.0 761.0 424.0 765.0 399.0 763.0 367.0 749.0 337.0 733.0 355.0 752.0 376.0 781.0 377.0 792.0 364.0 801.0 364.0 801.0 340.0 793.0 344.0 798.0 endline Thanks again, Simeon >> Thanks, S. >> >> Simeon Warner wrote: > >>> > I recently picked up a project I started working on with therion 0.2.17 >>> > and installed 0.3.4. When I try to compile I get lots of errors of the >>> > form shown below. Can anyone suggest where I should look to fix this? >>> > >>> > Cheers, >>> > Simeon >>> > >>> > >>> > simeon@localhost mcfails>therion mcfails.thconfig >>> > therion 0.3.4 >>> > configuration file: mcfails.thconfig >>> > reading ... done >>> > reading source files ... done >>> > preprocessing database ... done >>> > scanning centreline tree ... done >>> > searching for centerline loops ... done >>> > calculating station coordinates ... done >>> > calculating basic statistics ... done >>> > processing references ... done >>> > selecting export objects ... done >>> > processing projection plan ... done >>> > average distortion: 5.01% >>> > writing mcfails_beyond_asia_dome.pdf ... >>> > This is MetaPost, Version 0.641 (Web2C 7.3.1) >>> > (data.mp [4001] [4002] [4003] [4004] [4005] >>> > [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] >>> > ! Inconsistent equation (off by -96.8626). >>> > >>> > ; >>> > ...z1,zz2])>0.1pt):zz5=whatever[zz1,zz2]; >>> > >>> > (zz3-zz5)=whatever*(zz1-zz... >>> > >>> > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor >>> > >>> > ;for.pnt=(TEXT1):if.pnt=-1... >>> > l.3238 ),) >>> > ; >>> > ! Inconsistent equation (off by -18.38467). >>> > >>> > ; >>> > ...(zz3-zz5)=whatever*(zz1-zz2)rotated90; >>> > >>> > draw.zz1--zz5;zz6=whatever... >>> > >>> > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor >>> > >>> > ;for.pnt=(TEXT1):if.pnt=-1... >>> > l.3238 ),) >>> > ; >>> > >>> > .... >>> > >>> > ! Inconsistent equation (off by 24.34366). >>> > >>> > ; >>> > ...zz4-zz6)=whatever*(zz1-zz2)rotated90; >>> > >>> > draw.zz2--zz6;else:draw.zz... >>> > >>> > l_section->...z2--zz6;else:draw.zz1--zz2;fi;endfor >>> > >>> > ;for.pnt=(TEXT1):if.pnt=-1... >>> > l.3238 ),) >>> > ; >>> > [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] >>> > [27] [28] [29] [30] [31] [32] [33] [34] >>> > [Warning: scrap outline intersects itself in scrap_asia1@mcfails] [35] >>> > [36] >>> > [37] [38] ) >>> > (see the transcript file for additional information) >>> > 43 output files written: data.1 .. data.4005 >>> > Transcript written on data.log. >>> > /home/simeon/bin/therion/therion: error -- metapost exit code -- 256 >>> > >>> > (yhe error doesn't go away if I remove the scrap reported as intersecting >>> > itself) >>> > >>> > > >> >> Subject: Re: [Fwd: RE: therion] From: Stacho Mudrak Date: Tue, 14 Dec 2004 08:44:04 +0100 To: Andrew Atkinson CC: therion@speleo.sk Andrew Atkinson wrote: >> Well, most of the people find it too difficult :) > > > It does make my head hurt. Therion in the beginning was only experiment and we wanted just to draw a simple map of our complicated 19km cave system. There are a lot of things, that could be designed simplier, but it is too late... :( > PS Any chance of some more fills or control of the density, you can hardly > see the sand and debris fill. (on the attached pdf you can only see the sand > when you zoom in) This is a serious BUG, we have discovered 2 weeks ago. It will be certainly fixed in next release. > Also would it be possible to fill passages with small rocks and medium > rocks. Mud would be useful too. With area we have one problem, that is still not solved. Metapost is not able to tell us, whether specific point lies inside or outside a clipping region. When drawing rocks, it will look terrible, if a rock would be clipped by invisible border in the middle. In any case, soon I will probably add those missing area symbols - blocks, snow, ice and mud, but I am afraid, blocks will not look nice. One question, what is the difference between mud and clay? clay = mud without water? Should it mean the same, or not? > My ideal solution would be to pick an area an then use an option like > -medium_rock 30 -small_rock 50 > and this would mix the 2 fills in these percentages leaving the other 20 > percent (in this case) empty. > While I am on the thought process, I would really like to be able to define > a graded change from say rocks to sand, possibly by putting a straight line > though an area labelling on end -small_rocks 100 and the other end -sand 100 > and the fill would slowly grade. :) Even it looks crazy, this can be a solution. If a rocks, debris, sand or other clastic sediments (mud) would be randomly drawn around a line (like it is done in tunnel). There would be no problem with clipping and it is possible to do also gradient changes (probably...) > Terrible isn't it you spend all your time writing a wonderful program and > all I do is ask for more. All I can say is thanks again, one day I may see > you to buy you a drink. Until now, we were not using areas et all. Our primary target was to have a map, which will be allways up-to-date and there will be all information. For passage fills, we used only point symbols - because those rocks are usually drawn randomly also in the survey notes. Therefore if passage is full of rocks or there is one symbol, that means that passage is full of rocks, it is the same information. The second approach is more easier to implement and read in a map, the first looks nicer (sometimes :) . Fills around the line could solve this problem, but it will definitely need some time. It will not be trivial to implement, and I am currently more focused on 3D modelling, which I am missing much more... Regards, S. P.S. I Cc-ed this message to therion conference, may be some other users will write some useful remarks... Subject: Mud and sand From: "Andrew Atkinson" Date: Tue, 14 Dec 2004 20:10:29 -0800 To: "Stacho Mudrak" CC: Stacho Mudrak wrote >> >> In any case, soon I will probably add those missing area symbols - >> blocks, snow, ice and mud, but I am afraid, blocks will not look nice. >> But it has to be better than drawing them by hand >> One question, what is the difference between mud and clay? clay = mud >> without water? Should it mean the same, or not? I am not a sedimentologist, but I think that clay is a type of mud, usually of a finer grain. Mud possibly covers silt and sand as well. As a cave surveyor I do not think that I can tell a difference, so would would not particularly want different symbols, but I suspect there are lot of people out there who do. I have tended to use minus signs for mud and dots for sand. But I most probably should be using dots for all of it Andrew Atkinson Subject: Re: Mud and sand From: Wookey Date: Wed, 15 Dec 2004 16:01:42 +0000 To: therion@speleo.sk CC: Stacho Mudrak +++ Andrew Atkinson [04-12-14 20:10 -0800]: >> Stacho Mudrak wrote > >>> > >>> > In any case, soon I will probably add those missing area symbols - >>> > blocks, snow, ice and mud, but I am afraid, blocks will not look nice. >>> > > >> But it has to be better than drawing them by hand It's easier :-) , but it will look worse :-( We do need to solve this problem somehow. Current rock-drawing is super-slow, but I want my finished rocks to look realistic as well (i.e. not sticking through the walls). >>> > One question, what is the difference between mud and clay? clay = mud >>> > without water? Should it mean the same, or not? > >> >> I am not a sedimentologist, but I think that clay is a type of mud, usually >> of a finer grain. Mud possibly covers silt and sand as well. As a cave >> surveyor I do not think that I can tell a difference, so would would not >> particularly want different symbols, but I suspect there are lot of people >> out there who do. I have tended to use minus signs for mud and dots for >> sand. But I most probably should be using dots for all of it Do the UIS have different symbols for this? clay is indeed sediment with very fine particles. I think of there being 'dry sediment' (sand symbol) and 'wet sediment' (mud symbol). I think that's plenty for my purposes, but Therion just needs to provide whatever the various symbol sets provide. 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/ Subject: Re: [therion] Re: Mud and sand From: Stacho Mudrak Date: Thu, 16 Dec 2004 10:07:01 +0100 To: therion@speleo.sk > It's easier :-) , but it will look worse :-( > > We do need to solve this problem somehow. Current rock-drawing is > super-slow, but I want my finished rocks to look realistic as well (i.e. not > sticking through the walls). MartinS has found a dirty trick how to solve this problem, so now it is just a question of implementation. :) In any case, we would welcome a good example (or even an algorithm), how those random blocks should look like... > Do the UIS have different symbols for this? clay is indeed sediment with > very fine particles. I think of there being 'dry sediment' (sand symbol) and > 'wet sediment' (mud symbol). UIS is using dots symbol for "Sand-Silt-Clay-Humus". So I suggest to let exist clay symbol and add mud symbol. Then we will have three symbols: mud for wet sediment, clay and sand for dry sediment. In UIS symbol set, it will be the same symbol. > I think that's plenty for my purposes, but > Therion just needs to provide whatever the various symbol sets provide. We have a problem with that - in one symbol set used in Lechuguilla cave (I am not able to locate it on the WEB now), we have found a RAFT and RAFT CONE symbols. We still do not know, for what we should use them... Therefore we would like to remove them (I guess, nobody used them until now). And we would also like to add three new point symbols we are missing: stalactites stalagmites stalactites-and-stalagmites They will mark places, where these speleothems occur in bigger amounts. Regards, S. Subject: Re: Mud and sand From: Wookey Date: Thu, 16 Dec 2004 11:53:32 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-16 10:07 +0100]: >>> >It's easier :-) , but it will look worse :-( >>> > >>> >We do need to solve this problem somehow. Current rock-drawing is >>> >super-slow, but I want my finished rocks to look realistic as well (i.e. >>> >not >>> >sticking through the walls). > >> >> MartinS has found a dirty trick how to solve this problem, so now it is >> just a question of implementation. :) In any case, we would welcome a >> good example (or even an algorithm), how those random blocks should look >> like... Take a look at the tunnel code. That is a nice implementation. I think there have actually been two. The original one let you draw a 'gradient line' across an area which indicated that rocks should get smaller in the direction of the line, and there were several sizes of rocks. Then rocks were drawn so that small rocks would stay on top of large rocks if they fitted on top. Something like that anyway. One problem with this was that is was very slow to render, so I think current tunnel has a slightly different scheme - anyone on this list moreuptodate than me? I see from Martin Sluka's example that therion already does neat clipping of rocks on top of each other which is good (I have carefully been drawing them non-overlapping, as I hadnt realised this would work.) The important thing is to be able to get quite a 'natural' look, with randomised sizes, but still the ability to say at least 'theserocks are mostly big/medium/small'. >> We have a problem with that - in one symbol set used in Lechuguilla cave >> (I am not able to locate it on the WEB now), we have found a RAFT and >> RAFT CONE symbols. We still do not know, for what we should use them... >> Therefore we would like to remove them (I guess, nobody used them until >> now). I think these are a type of speleothem - calcite raft floating on water. I'mnot sure about a raft cone, but presumably it is some variation. These are certainly quite rare formations.... 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/ Subject: [therion] Re: Mud and sand From: Martin Sluka Date: Thu, 16 Dec 2004 14:22:36 +0100 To: therion@speleo.sk At 11:53 +0000 16.12.2004, Wookey wrote: ******************************************* > I think these are a type of speleothem - calcite raft floating on water. > I'mnot sure about a raft cone, but presumably it is some variation. These > are certainly quite rare formations.... Typical for Lechuguia cave and simillar karst I think. There is an important difference od mud/clay and sand in sense of sedimentation - the sand sedimented in flowing water but mud/clay in static water, so there should be two different symbols probably. Martin (S) -- Subject: Re: [therion] Re: Mud and sand From: Eric Madelaine Date: Thu, 16 Dec 2004 17:08:56 +0100 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr martinsluka@mac.com said: >> There is an important difference od mud/clay and sand in sense of >> sedimentation - the sand sedimented in flowing water but mud/clay in >> static water, so there should be two different symbols probably. I think there are indeed two different symbols for sand and clay in most symbol sets. We usually use dots for sands (as in UIS), and dashes for clay. Eric. -- -- ^v^ ^v^ ^v^ ------------------------------------------------------------------- Eric Madelaine tel: (+33) 4 92387807 (secr: 7556, fax: 7765) INRIA Sophia-Antipolis email: Eric.Madelaine@sophia.inria.fr BP 93 06902 Sophia-Antipolis CEDEX FRANCE ------------------------------------------------------------------- SIS (Section INRIA Speleo): http://www.inria.fr/agos-sophia/sis SophiTaupes (Section Speleo du COV): http://www-sop.inria.fr/agos-sophia/sis/COV/ST.html CDS 06: http://www.ffspeleo.fr/cds/06/ Subject: RE: [therion] Re: Mud and sand From: "Andrew Atkinson" Date: Thu, 16 Sep 2004 18:48:42 -0700 To: >> > >>> > We have a problem with that - in one symbol set used in > >> Lechuguilla cave > >>> > (I am not able to locate it on the WEB now), we have found a RAFT and >>> > RAFT CONE symbols. We still do not know, for what we should use them... >>> > Therefore we would like to remove them (I guess, nobody used them until >>> > now). > >> >> I think these are a type of speleothem - calcite raft floating on water. >> I'mnot sure about a raft cone, but presumably it is some variation. These >> are certainly quite rare formations.... >> I am guessing but are raft cones where a 'raft' has calcited around a stal? Andrew Atkinson Subject: Re: [therion] Re: Mud and sand From: Stacho Mudrak Date: Fri, 17 Dec 2004 08:45:42 +0100 To: therion@speleo.sk > I am guessing but are raft cones where a 'raft' has calcited around a stal? No idea. But I think it's better to remove them, before somebody will use this symbol for something wrong. It will be no problem to add later, when it will be clear what they mean. Regards, S. Subject: Re: [therion] Re: Mud and sand From: "M.J. Green" Date: 17 Dec 2004 10:58:29 +0000 To: therion@speleo.sk On Dec 16 2004, Wookey wrote: > +++ Stacho Mudrak [04-12-16 10:07 +0100]: > > >It's easier :-) , but it will look worse :-( > > > > > > We do need to solve this problem somehow. Current rock-drawing is > > super-slow, but I want my finished rocks to look realistic as well > > (i.e. not sticking through the walls). > > > MartinS has found a dirty trick how to solve this problem, so now it > is just a question of implementation. :) In any case, we would welcome > a good example (or even an algorithm), how those random blocks should > look like... > > Take a look at the tunnel code. That is a nice implementation. I think there have actually been two. The original one let you draw a 'gradient line' across an area which indicated that rocks should get smaller in the direction of the line, and there were several sizes of rocks. Then rocks were drawn so that small rocks would stay on top of large rocks if they fitted on top. Something like that anyway. One problem with this was that is was very slow to render, so I think current tunnel has a slightly different scheme - anyone on this list moreuptodate than me? I have been using tunnel to draw up caves. The rock and sand symbols will be recoded again in a little while. I believe the current implimentation, randomly puts down symbols, and checks if they are in the area and if they overlap any other symbol already there. The symbols themselves have clear outlines around them. As these outlines can not overlap, the symbols will not get too close to each other. User options tell tunnel wheather to allow bolders to randomly rotate the bolders, and by how much to randomly scale them. Ordering is important, although not well implimented, so that more important symbols such as slopes are put down before bolders. I believe futher optimisation is planned by creating a bitmap that records free areas. So to choose where to put down the sybol, it can be checked against a bitmap to see if it will fit there, before clipping the different shapes together, which is more computationaly expensive. To get nice looking bolders, it is worth drawing a few different shapes, so typically I use a quadraleral bolder and a triangular bolder. Ideally which bolder is placed should be done randomly. But at the moment all the quadralerals are placed first, and then the triangles are placed. Tunnel can be found at http://www.goatchurch.org.uk/tunnelx/ I suspect that the executable provided is out of date, so you are better of downloading the source from cvs and compiling it yourself. Examples of output are at: http://cucc.survex.com/expo/smkridge/204/surveys/plan2004.png I believe Wookey may also be refering to a pull back feature, where by somehow sybmols can be pulled back to a line. I do not use this, but understand it iis to do with trying to make walls of boulders, or sticking stals into ceilings. Cheers, Martin Subject: Re: [therion] Re: Mud and sand From: Michael Lake Date: Fri, 17 Dec 2004 22:18:47 +1100 To: therion@speleo.sk Andrew Atkinson wrote: >> I think these are a type of speleothem - calcite raft floating on water. >> I'mnot sure about a raft cone, but presumably it is some variation. These >> are certainly quite rare formations.... > > > I am guessing but are raft cones where a 'raft' has calcited around a stal? A raft is as you thought, calcite rafts floating on water. When these are disturbed the calcite rafts sink and can build up on the bottom of the pool as 'conical' shaped piles. The pool can dry up and the raft cones will be left. Thus they are different to rafts and so have a different symbol. Yes they are not common but they are not rare. Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. Subject: Tom library and scrap connections From: Wookey Date: Wed, 15 Dec 2004 16:19:55 +0000 To: Therion List I've got back to Therion after a long period of working all the time. I have a _lot_ of cave to draw up... Current Debian Status: You may recall that I discovered in October that the 0.3.3 version of therion I was building should have had the TOM/OPenGL stuff in it, but didn't. So I've started packaging the Tom library for Debian so that Therion can use it. This is not a trivial job to do properly, and I haven't yet succeeded in building a Debian Therion with 3D support, but expect to in the next couple of weeks. This probably won't quite make it into the imminend debian stable release (but the existing therion 0.3.3-1 is). Connecting scraps: My biggest problem at the moment with Therion is how to split up scraps and connect them nicely. I am drawing over previously-drawn-to-scale scans. given that I want to join scraps at convenient (low detail/logical) places and not the edges of scans, how can I best do this so they match up? I can keep adding background drawings into one file and draw all the scraps that way but I will end up with a huge file that is very slow to load and manipulate, even if I turn off some images which I am not longer directly using. As soon as I start a new file with new background images then I can't see where the old scrap ends so I don't know where to start the new scrap. How do others deal with this problem? How well does therion deal with the lines significantly overlapping, or not reaching each other? Do you always add in the adjoining scan so that you can see what it looked like? This still doesn't really help with remembering how far you drew up to on the last scrap. I feel I am missing something obvious here, as the existing system doesn't seem to work. How is everyone else managing it? How can we make it easier to use? Bugs: I found a couple of bugs, one serious. (using therion 0.3.3-1 on x86) 1) If I have an image (PNM) of size 1672x2333 then only about half of it is visible in the map editor. This makes it impossible to draw round. Is this expected? Should images be limited to some size before they can be importad as background? If so what is that size? 2) if keys used to change mode (F2, F1 etc) then menu top bar disappears.('normalize' window size fixes it). Can anyone else reproduce 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/ Subject: Re: [therion] Tom library and scrap connections From: Olly Betts Date: Wed, 15 Dec 2004 17:18:30 +0000 To: Therion List On Wed, Dec 15, 2004 at 04:19:55PM +0000, Wookey wrote: >> 2) if keys used to change mode (F2, F1 etc) then menu top bar >> disappears.('normalize' window size fixes it). Can anyone else >> reproduce this I believe I've seen that happen a couple of times, but couldn't work out how to reproduce it on demand... Cheers, Olly Subject: Re: Tom library and scrap connections From: Wookey Date: Wed, 15 Dec 2004 17:31:52 +0000 To: therion@speleo.sk +++ Olly Betts [04-12-15 17:18 +0000]: >> On Wed, Dec 15, 2004 at 04:19:55PM +0000, Wookey wrote: > >>> > 2) if keys used to change mode (F2, F1 etc) then menu top bar >>> > disappears.('normalize' window size fixes it). Can anyone else >>> > reproduce this > >> >> I believe I've seen that happen a couple of times, but couldn't work out >> how to reproduce it on demand... I fogot to say that there needs to be no file loaded in the window you change to. 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/ Subject: Re: [therion] Tom library and scrap connections From: Stacho Mudrak Date: Thu, 16 Dec 2004 10:31:31 +0100 To: therion@speleo.sk Wookey wrote: > succeeded in building a Debian Therion with 3D support, but expect to in the > next couple of weeks. This probably won't quite make it into the imminend > debian stable release (but the existing therion 0.3.3-1 is). Do you need some support for this? In any case, I stopped developement of therion 3D viewer. I came to conclusion, that TclTk is too slow for that... I have started new project, but it will take some time again, there are a lot of problems. I have one question. Would it be possible to enter to survex .3d format an arbitrary triangulated surface, not just LRUD data? > where the old scrap ends so I don't know where to start the new scrap. How > do others deal with this problem? How well does therion deal with the lines > significantly overlapping, or not reaching each other? When we were doing this, we marked scrap ends by red lines on the scan images. In fact, we usually prepare bitmats, that we are using as background. We have original scans at 300dpi, but for backgroud, we subsample them to 150dpi, adjust contrast and brightness, draw scrap ends with red line etc. If some detail is not clear, then we have a look at original scan. > 1) If I have an image (PNM) of size 1672x2333 then only about half of it is > visible in the map editor. This makes it impossible to draw round. Is this > expected? Should images be limited to some size before they can be importad > as background? If so what is that size? Try "Auto adjust" button in drawing area toolbar :) The scrollable are is defined by user, when you insert picture, it is not automatically adjusted (probably should be). > 2) if keys used to change mode (F2, F1 etc) then menu top bar > disappears.('normalize' window size fixes it). Can anyone else reproduce this It is a bug somewhere deep in Tcl/Tk (it happens only from time to time on Linux, each time after longer compilation on Win32). I have no idea how to solve it (I have tried reduced it a lot, but it still happens). Regards, S. Subject: Therion hangs occaisionally From: Wookey Date: Fri, 17 Dec 2004 03:03:10 +0000 To: Therion List I've had therion 0.3.3 hang on me twice this evening. It's very annoying if you have just drawn a load of cave... The second time I was editing a line. I tried sending it (wish) a HUP but that just closed it. Not sure what can be done about this apart from saving often, but thought I should report it. 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/ Subject: Re: [therion] Therion hangs occaisionally From: Stacho Mudrak Date: Fri, 17 Dec 2004 08:52:44 +0100 To: therion@speleo.sk > Not sure what can be done about this apart from saving often, but thought I > should report it. No idea why this happens - from time to time it happened to me also, but it was very rare. In any case, I will probably add "Auto save" feature to xtherion. Regards, S. Subject: Re: Therion hangs occaisionally From: Wookey Date: Fri, 17 Dec 2004 13:21:56 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-17 08:52 +0100]: >>> >Not sure what can be done about this apart from saving often, but thought I >>> >should report it. > >> >> No idea why this happens - from time to time it happened to me also, but >> it was very rare. In any case, I will probably add "Auto save" feature >> to xtherion. It did it again after I sent that mail - just as I was re-drawing the scrap that it had lost! That's far too often. I have 20km of cave to draw - I am going to get very annoyed if I keep losing chucks... Difficult to track this sort of think down I know. I'll see if I can work out what is going on. Are there any 'escape' mechanisms in wish/tcl that might let me regain control? or debug mechanisms that might tell us where it got stuck? The CPU use is not excessive, but the app is unresponsive - so it is presumably blocking waiting for something. I could run it under strace I suppose... 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/ Subject: Re: [therion] Re: Therion hangs occaisionally From: Stacho Mudrak Date: Fri, 17 Dec 2004 15:09:17 +0100 To: therion@speleo.sk We have never had such problems, and we have already drawn more then 20km of cave passages. I have never used any TclTk debugger or any debug mechanism. But Google has found at least several of them (claiming thery are able to connect to already running TclTk program), so you may try... May be also TclTk upgrade would help, no idea. Unless I am not able to reproduce it, I am not able to help you :( Regards, S. Wookey wrote: > +++ Stacho Mudrak [04-12-17 08:52 +0100]: > >>> Not sure what can be done about this apart from saving often, but thought I >>> should report it. >> >> >> No idea why this happens - from time to time it happened to me also, but it was very rare. In any case, I will probably add "Auto save" feature to xtherion. > > > > It did it again after I sent that mail - just as I was re-drawing the scrap > that it had lost! That's far too often. I have 20km of cave to draw - I am > going to get very annoyed if I keep losing chucks... > > Difficult to track this sort of think down I know. I'll see if I can work > out what is going on. Are there any 'escape' mechanisms in wish/tcl that > might let me regain control? or debug mechanisms that might tell us where it > got stuck? The CPU use is not excessive, but the app is unresponsive - so it > is presumably blocking waiting for something. > > I could run it under strace I suppose... > > Wookey Subject: [therion] Re: Therion hangs occaisionally From: Martin Sluka Date: Fri, 17 Dec 2004 15:17:31 +0100 To: therion@speleo.sk There are the same things rarely under MacOS X, but it is definitely in TCL. And it mainly if I try to do several steps very fast - click, move with mouse, choose menu item and so on. MS. At 13:21 +0000 17.12.2004, Wookey wrote: ******************************************* > +++ Stacho Mudrak [04-12-17 08:52 +0100]: > >> >Not sure what can be done about this apart from saving often, but thought I >> >should report it. >> >> No idea why this happens - from time to time it happened to me also, but >> it was very rare. In any case, I will probably add "Auto save" feature >> to xtherion. > > > It did it again after I sent that mail - just as I was re-drawing the scrap > that it had lost! That's far too often. I have 20km of cave to draw - I am > going to get very annoyed if I keep losing chucks... > > Difficult to track this sort of think down I know. I'll see if I can work > out what is going on. Are there any 'escape' mechanisms in wish/tcl that > might let me regain control? or debug mechanisms that might tell us where it > got stuck? The CPU use is not excessive, but the app is unresponsive - so it > is presumably blocking waiting for something. > > I could run it under strace I suppose... > > 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/ -- Subject: Re: [therion] Re: Therion hangs occaisionally From: Stacho Mudrak Date: Fri, 17 Dec 2004 15:39:10 +0100 To: therion@speleo.sk May be it has something to do with multi-threading. If two events are processed in parallel, something like this may happen. Then a version of Tcl/Tk build with "-diable-threads" option should solve the problem. Regards, S. Martin Sluka wrote: > There are the same things rarely under MacOS X, but it is definitely in TCL. And it mainly if I try to do several steps very fast - click, move with mouse, choose menu item and so on. > > MS. > > At 13:21 +0000 17.12.2004, Wookey wrote: > ******************************************* > >> +++ Stacho Mudrak [04-12-17 08:52 +0100]: >> >>> >Not sure what can be done about this apart from saving often, but thought I >>> >should report it. >>> >>> No idea why this happens - from time to time it happened to me also, but >>> it was very rare. In any case, I will probably add "Auto save" feature >>> to xtherion. >> >> >> >> It did it again after I sent that mail - just as I was re-drawing the scrap >> that it had lost! That's far too often. I have 20km of cave to draw - I am >> going to get very annoyed if I keep losing chucks... >> >> Difficult to track this sort of think down I know. I'll see if I can work >> out what is going on. Are there any 'escape' mechanisms in wish/tcl that >> might let me regain control? or debug mechanisms that might tell us where it >> got stuck? The CPU use is not excessive, but the app is unresponsive - so it >> is presumably blocking waiting for something. >> >> I could run it under strace I suppose... >> >> 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/ > > > > Subject: arranging files and surveys From: Wookey Date: Mon, 20 Dec 2004 02:16:53 +0000 To: Therion List I'm a bit lost about how files scraps and surveys should relate. Therion encourages drawing s complex junction chamber as one scrap, but that tends to mean that one scrap now has stations fromseveral surveys in it. How shold these be labelled and where in the hierarchy should the files be 'input'? In general scrapsdon't match to surveys very well at all, but if you don't incldue a .th2 file in the .th file within a survey/endsurvey pair then presumably the station labels need full names not just numbers? I'm not sure when I start drawing whether it will all be one survey so I can just use numbers or if it will be several surveys and I'll need to use full names - and it's a paid to go back afterwards and change them. What is the recommended way to deal with scrap/survey mismatches? Do you have a file for each scrap, put all scraps inthe samesurvye in one file? etc. I've got a huge cave and I'm going to get in a mess over this if I don't have a sensible structure. Suggestions welcome. And I see therion now gives scraps names automatically, based on the item-number, so you get scraps 1, 36, 90, 109 in your file. I think it would be better if it named the scraps 1, 2, 3, 4 - I'd find that less confusing. 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/ Subject: Re: [therion] arranging files and surveys From: "Martin Budaj" Date: Mon, 20 Dec 2004 08:33:59 +0100 (CET) To: therion@speleo.sk >> Therion encourages drawing s complex junction chamber as one scrap, but >> that >> tends to mean that one scrap now has stations fromseveral surveys in it. >> How >> shold these be labelled and where in the hierarchy should the files be >> 'input'? The chapter Thinking in Therion/How to draw maps in thbooks gives some explanation. It is perhaps written very condensed, but all basic ideas are given. >> In general scrapsdon't match to surveys very well at all, but if you don't >> incldue a .th2 file in the .th file within a survey/endsurvey pair then >> presumably the station labels need full names not just numbers? I'm not Exactly, you need full names. >> sure >> when I start drawing whether it will all be one survey so I can just use >> numbers or if it will be several surveys and I'll need to use full names - >> and it's a paid to go back afterwards and change them. Only solution is a Slovak proverb "Think twice, cut once" :)) At the beginning of therion development I suggested to have variable namespaces, e.g. to give all stations in the scrap references like 1@VAR 2@VAR etc. and than define centrally in one place that VAR is actually chamber1.entrance survey. It would be than easy to redefine it. But it seemed to be too much work to implement it. >> What is the recommended way to deal with scrap/survey mismatches? Do you >> have a file for each scrap, put all scraps inthe samesurvye in one file? See the above mentioned chapter. >> And I see therion now gives scraps names automatically, based on the >> item-number, so you get scraps 1, 36, 90, 109 in your file. I think it >> would >> be better if it named the scraps 1, 2, 3, 4 - I'd find that less >> confusing. It always used to. I rename all scraps after creation. Martin Subject: Re: arranging files and surveys From: Wookey Date: Mon, 20 Dec 2004 23:11:53 +0000 To: therion@speleo.sk +++ Martin Budaj [04-12-20 08:33 +0100]: >> The chapter Thinking in Therion/How to draw maps in thbooks gives some >> explanation. It is perhaps written very condensed, but all basic ideas are >> given. That is indeed a very useful addition to the therion book. I should have read it first, as it does basically answer the above questions. Good work Martin :-) And the english is good too. >>> > And I see therion now gives scraps names automatically, based on the >>> > item-number, so you get scraps 1, 36, 90, 109 in your file. I think it >>> > would >>> > be better if it named the scraps 1, 2, 3, 4 - I'd find that less >>> > confusing. > >> >> It always used to. I rename all scraps after creation. This suggests that perhaps you agree it would be nice if therion defaulted to giving scrpanumbers 1,2,3,4 and perhaps scrapnames in the suggested format _s1, _s2 etc. This would help everyone unless they wanted to do something odd. 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/ Subject: No x-size for pillar? From: Wookey Date: Mon, 20 Dec 2004 03:14:57 +0000 To: Therion List I just got the error -x-size not valid with type pillar I have a passage with a load of pillars in it here - of varying size and width. I don't want 27 identical pillars - so orientation, and X and Y sizes are important to make it look realistic (some are huge) and not computer-drawn. Can we update therion to draw an ellipse for the pillar according to the x, y and orientation values, or at least accept them quietly for the time being? 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/ Subject: Re: [therion] No x-size for pillar? From: "Martin Budaj" Date: Mon, 20 Dec 2004 08:39:46 +0100 (CET) To: therion@speleo.sk >> I just got the error >> -x-size not valid with type pillar >> >> I have a passage with a load of pillars in it here - of varying size and >> width. I don't want 27 identical pillars - so orientation, and X and Y >> sizes >> are important to make it look realistic (some are huge) and not >> computer-drawn. Use -scale xs/s/m/l/xl in the options box. This will scale most of the point symbols. Separate specification of x/y-size would lead to non-proportional scaling. Martin Subject: Re: [therion] No x-size for pillar? From: Stacho Mudrak Date: Mon, 20 Dec 2004 12:58:17 +0100 To: therion@speleo.sk Wookey wrote: > I have a passage with a load of pillars in it here - of varying size and > width. I don't want 27 identical pillars - so orientation, and X and Y sizes > are important to make it look realistic (some are huge) and not > computer-drawn. Point symbol pillar is only a symbol and symbols are not stretched on maps. Symbol will never look realistic, even x/y-sized. For drawing realistic pillars (or stalactites or stalagmites), we are using line border in point:pillar (stalactite|stalagmite) context (usually in sections or elevations) or line flowstone (usually in plans). Regards, S. Subject: Therion Wiki pages From: "Martin Budaj" Date: Mon, 20 Dec 2004 12:02:26 +0100 (CET) To: therion@speleo.sk Hello all, with the help of Lada Blazek we added Wiki pages to Therion homepage (therion.speleo.sk/wiki.php). You may edit them, ask questions, answer them, contribute examples, translate the documentation or whatever is missing on the official pages. Cheers, Martin Subject: Help - my cave is inside-out From: Wookey Date: Sun, 26 Dec 2004 00:15:29 +0000 To: Therion List Hi guys, Lots of notes here on things I found and suggestions for improvements, but the important one first: I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far. One bit of wall wasn't shown. By adding a map-fg colour I could see that therion is very confused about what is the inside and what is the outside of the scrap. Here is the set of files needed to process this example: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.tgz including the offending background image. You can see from the included pdf (also here: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.pdf what the problem is. I;ve tried reversing some lines and reading the thbook, but I don;t know how to fix this. Does it in fact need to be split up into smaller, simpler scraps? why? I am hesitant to use smaller scraps on this drawing because none of the joins work when I just do join scrap1 scrap2 - it joins lines to the wrong places. I have to use explicit line ID's, which is really tedious - add line in map editor then add then to join command in text editor. Being able to graphically describe joins (at letsfor joins within one .th2 file) would be a really useful improvement. I'll send a separate mail for my other notes. 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/ Subject: Re: [therion] Help - my cave is inside-out From: "Martin Budaj" Date: Sun, 26 Dec 2004 13:06:28 +0100 (CET) To: therion@speleo.sk >> I'm getting the hang of this and have drawn up some cave. It went OK until >> I >> got to a complicated section, with an underlying streamway adn overlying >> passages. The streamway needs to be a separate scrap. But I haven't got >> that >> far. One bit of wall wasn't shown. By adding a map-fg colour I could see >> that therion is very confused about what is the inside and what is the >> outside of the scrap. Only minor improvements were required -- mostly to correct line types (the hidden wall was actually a border, the inner pillar should have -outline in option...). All my changes are marked red in the enclosed picture. The correct line types make correct scrap joins possible. Simple join s1 s2 worked fine with one exception, where the scrap ends are too far. There is perhaps a blunder in your data. Martin Subject: Re: Help - my cave is inside-out From: Wookey Date: Mon, 27 Dec 2004 19:20:00 +0000 To: therion@speleo.sk +++ Martin Budaj [04-12-26 13:06 +0100]: >>> > I'm getting the hang of this and have drawn up some cave. It went OK until >>> > I >>> > got to a complicated section, with an underlying streamway adn overlying >>> > passages. The streamway needs to be a separate scrap. But I haven't got >>> > that >>> > far. One bit of wall wasn't shown. By adding a map-fg colour I could see >>> > that therion is very confused about what is the inside and what is the >>> > outside of the scrap. > >> >> Only minor improvements were required -- mostly to correct line types (the >> hidden wall was actually a border, the inner pillar should have -outline >> in option...). All my changes are marked red in the enclosed picture. Thanx for that, martin - that's great :-) I thin we need a better understanding of what makes a 'pillar'. I thought a pillar was a closed loop within a passage, but that is not a closed loop (a passage goes off underneath from the gap - see the scan to get the full idea). So when does therion need to be told that an outline is 'in'? >> The correct line types make correct scrap joins possible. Simple join s1 >> s2 worked fine with one exception, where the scrap ends are too far. There >> is perhaps a blunder in your data. OK. so there is some threshold of closeness that prevents a join happening automatically (to the right place). I think some form of feedback is needed that allows me to work out that the join has gone wrong due to excessive distortion. How did you work out what was wrong? Also a couple of new points - I added some areas and used 'Insert ID' in the area control. I assumed this just gave an ID to the area, but now having added 'bankatjoin' I get the error: object does not exist -- bankatjoin I'm a bit confused about this - does this area ID have some special significance and isn't just any old string I give to the area? Also what happens if an area crosses a scrap join? Presumably I have to draw an invisible borderline across the join in order to make a closed area (in both scraps)? Or is there some special way to indicate that it is one area? 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/ Subject: Re: Help - my cave is inside-out From: Wookey Date: Mon, 27 Dec 2004 23:59:27 +0000 To: therion@speleo.sk +++ Martin Budaj [04-12-26 13:06 +0100]: >>> > I'm getting the hang of this and have drawn up some cave. It went OK until >>> > I got to a complicated section, with an underlying streamway adn overlying >>> > passages. The streamway needs to be a separate scrap. But I haven't got >>> > that far. Sorry to keep asking the group questions but I'm stuck again. I've updated the files online. I've added the scrap containing the underlying streamway. As soon as I add the underlying scrap and process I get : therion: error -- metapost exit code -- 256 This appears to be due to "! Paths 4 and 3 don't intersect." But I have 5 aras in this scrap - how on earth do I work out which one is at fault? The area 'show' button doesn't seem to work - is that a clue? The odd thing is that that scrap did appearonce but I had a mislabelled station in it so it was tiny and in one corner. After I fixed that it seemed broken. Also I'm extrememly annoyed because I drew a load of another scrap but lost it somehow. It's the oldproblem of having files open in therion and another editor. But So far as I can tell I need to open it in another editor in order to edit the names of scraps. (as you say - calling them _sn is a good idea.) Having a .th2 file open in both the text and map editors seems to work OK, but I can't find any info on how to search in the text editor? So I use an editor i can search in. I tried to make sure I always closed a file in the map editor before editing it extrenally but something went wrong and a whole scrap disappeared :-( Given how long they take to draw in therion, we need to make sure this is not possible to do accidentally by checking timestamps. The 'command preview' window looks like it ought to let you edit commands, but it doesn't. It this worked and/or there was a 'search' option in the text editor then external editing would not be necessary. Ah - maybe I need to use the 'scrap control' section. On the good side I've discovered the 'move to' button which is brilliant. And the red entriesin the error window which takes you to the offending item in the mapeditor is really useful, although it doesn't work for metapost 'don't intersect' errors. where '(mptextmp.mp) [5]' is highlighted in red but clicking on it just gives an error saying it can't load it. I'm making a list of things I think we need to add shortcuts for. I'll post that soon. 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/ Subject: Re: Help - my cave is inside-out From: Wookey Date: Tue, 28 Dec 2004 03:26:18 +0000 To: therion@speleo.sk +++ Wookey [04-12-27 23:59 +0000]: >> +++ Martin Budaj [04-12-26 13:06 +0100]: > >>>> > > I'm getting the hang of this and have drawn up some cave. It went OK until >>>> > > I got to a complicated section, with an underlying streamway adn overlying >>>> > > passages. The streamway needs to be a separate scrap. But I haven't got >>>> > > that far. > >> >> Sorry to keep asking the group questions but I'm stuck again. >> >> I've updated the files online. I've added the scrap containing the >> underlying streamway. As soon as I add the underlying scrap and process I >> get : >> therion: error -- metapost exit code -- 256 >> This appears to be due to "! Paths 4 and 3 don't intersect." >> But I have 5 aras in this scrap - how on earth do I work out which one is at >> fault? The area 'show' button doesn't seem to work - is that a clue? OK- I fixed this by comenting out areas until things worked again, but there does need to be a better way. That example (scrap bmb2_s3) has a streamway with sandbanks. Having got the large water area to work, I find that some of the sandbanks are sandy, but some are covered in water. What determines when an area follows the outer wall, or the sandbank border? IS the only way to be sure to get the right thing to split the wall at the sandbank? This gets back to the problem that making changes to line which surround areas is problematic - if you split a line that is part of an area then both lines losetheir IDs and the area breaks. This is a tricky problem, but what you really want is for the areas and lines to get re-written so they all still work. 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/ Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Tue, 28 Dec 2004 08:37:01 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> I thin we need a better understanding of what makes a 'pillar'. I thought >> a >> pillar was a closed loop within a passage, but that is not a closed loop >> (a >> passage goes off underneath from the gap - see the scan to get the full >> idea). So when does therion need to be told that an outline is 'in'? I agree that in the cave would nobody calls the massif between two passages 'pillar', but therion sees things purely geometrically -- doesn't matter if a closed loop within a passage is small or large, formed by a fallen block or two passages. So everything surrounded by a scrap border and not belonging to the scrap is a 'pillar' and need to have "-outline in" option specified. >> OK. so there is some threshold of closeness that prevents a join happening >> automatically (to the right place). I think some form of feedback is >> needed >> that allows me to work out that the join has gone wrong due to excessive >> distortion. How did you work out what was wrong? Yes, there should be a warning that therion couldn't find a join. >> Also what happens if an area crosses a scrap join? Presumably I have to >> draw >> an invisible borderline across the join in order to make a closed area (in >> both scraps)? Or is there some special way to indicate that it is one >> area? It would work, but areas (the pattern) wouldn't join smoothly :(( There is unfortunately no better solution now. Martin Subject: Re: [therion] Re: Help - my cave is inside-out From: Stacho Mudrak Date: Tue, 28 Dec 2004 08:44:47 +0100 To: therion@speleo.sk > Yes, there should be a warning that therion couldn't find a join. Therion always joins something - there is no treshold for not joining. If join is not correct, usually scrap distortion is too big. If you will turn on debug mode in layout, you should see those distortions very easily. >> Also what happens if an area crosses a scrap join? Presumably I have to >> draw >> an invisible borderline across the join in order to make a closed area (in >> both scraps)? Or is there some special way to indicate that it is one >> area? > > > It would work, but areas (the pattern) wouldn't join smoothly :(( There is > unfortunately no better solution now. At the scrap joins, you should try to avoid any symbols. If there are some, usually -clip off helps (if you do not need to clip them by scrap border). But in the case of area that exists between walls, it would probably not help. Regards, S. Subject: Re: [therion] Re: Help - my cave is inside-out From: Stacho Mudrak Date: Tue, 28 Dec 2004 08:52:15 +0100 To: therion@speleo.sk Wookey wrote: > That example (scrap bmb2_s3) has a streamway with sandbanks. Having got the > large water area to work, I find that some of the sandbanks are sandy, but > some are covered in water. What determines when an area follows the outer > wall, or the sandbank border? IS the only way to be sure to get the right > thing to split the wall at the sandbank? When I have to draw something like this, I draw one border curve that goes behind the wall on those places, where wall is areas active border. In the output, such border and area are clipped by walls. > This gets back to the problem that making changes to line which surround > areas is problematic - if you split a line that is part of an area then both > lines losetheir IDs and the area breaks. This is a tricky problem, but what > you really want is for the areas and lines to get re-written so they all > still work. May be in the future it will be neccessary, but again - every time I draw area that should be surrounded by walls also, I just let it overlap walls and in the output this are will be clipped correctly. Regards, S. Subject: Re: [therion] Re: Help - my cave is inside-out From: Stacho Mudrak Date: Tue, 28 Dec 2004 08:58:27 +0100 To: therion@speleo.sk > This appears to be due to "! Paths 4 and 3 don't intersect." > But I have 5 aras in this scrap - how on earth do I work out which one is at > fault? The area 'show' button doesn't seem to work - is that a clue? ??? It should work, I will have a look at it. In any case, we should add source position to error report at least to areas. > Also I'm extrememly annoyed because I drew a load of another scrap but lost > it somehow. It's the oldproblem of having files open in therion and another > editor. But So far as I can tell I need to open it in another editor in order > to edit the names of scraps. (as you say - calling them _sn is a > good idea.) Having a .th2 file open in both the text and map editors seems > to work OK, but I can't find any info on how to search in the text editor? There is Search & Replace command bar, may be it is just hidden. But in any case - having file open both in map and text editor is not a good idea right now. Checking timestamps is in the TODO list, I can put it higher priority. > The 'command preview' window looks like it ought to let you edit commands, > but it doesn't. It this worked and/or there was a 'search' option in the > text editor then external editing would not be necessary. Preview is just preview. It would be too difficult to edit command directly there. But there is Search & Select also in map editor, why don't you use it? Regards, S. Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Tue, 28 Dec 2004 09:47:52 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> But So far as I can tell I need to open it in another editor in >> order >> to edit the names of scraps. (as you say - calling them _sn is a >> good idea.) You may edit scrap names directly in the map editor -- select the line with the scrap name in the 'File commands' menu and you may change the name in the 'Scrap control' menu. Martin Subject: Re: Help - my cave is inside-out From: Wookey Date: Tue, 28 Dec 2004 12:45:25 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-28 08:44 +0100]: >>> >Yes, there should be a warning that therion couldn't find a join. > >> >> Therion always joins something - there is no treshold for not joining. >> If join is not correct, usually scrap distortion is too big. If you will >> turn on debug mode in layout, you should see those distortions very easily. OK - yes, I noticed that in the thbook. I must try it. >>>> >>Also what happens if an area crosses a scrap join? Presumably I have to >>>> >>draw an invisible borderline across the join in order to make a closed area (in >>>> >>both scraps)? Or is there some special way to indicate that it is one >>>> >>area? >> >>> > >>> >It would work, but areas (the pattern) wouldn't join smoothly :(( There is >>> >unfortunately no better solution now. > >> >> At the scrap joins, you should try to avoid any symbols. If there are >> some, usually -clip off helps (if you do not need to clip them by scrap >> border). But in the case of area that exists between walls, it would >> probably not help. OK - this is a real problem for a cave containing a long streamway. There is a very long continuous 'water' area. This connot always be drawn as one scrap. As you say the pattern rather obviously doesn't match up at the join. I think we need to have some mechanism for making such smooth area joins in the medium term. 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/ Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Tue, 28 Dec 2004 15:57:02 +0100 (CET) To: therion@speleo.sk >>>>> >It would work, but areas (the pattern) wouldn't join smoothly :(( There >> >>>> is >> >>>>> >unfortunately no better solution now. >> >>>> >>>> At the scrap joins, you should try to avoid any symbols. If there are >>>> some, usually -clip off helps (if you do not need to clip them by scrap >>>> border). But in the case of area that exists between walls, it would >>>> probably not help. > >> >> OK - this is a real problem for a cave containing a long streamway. There >> is >> a very long continuous 'water' area. This connot always be drawn as one >> scrap. As you say the pattern rather obviously doesn't match up at the >> join. >> I think we need to have some mechanism for making such smooth area joins >> in >> the medium term. I have tried this now and it works :-) It seemes that PDF viewers optimize filling of adjacent areas and join patterns smoothly. Martin Subject: Re: [therion] Re: Help - my cave is inside-out From: Ing. Jirí Novotný Date: Wed, 29 Dec 2004 01:45:43 +0100 To: Ahoj! Kdyz jsme na Macose prohlizeli 3D pohled (.thm), orezavalo nam to nekdy predni a zadni rovinou. Ted jsem zjistil, ze se mi to objevuje pouze tehdy, kdyz je v exportu -disable cave-centreline. Kdyz to tam neni, tak to alespon u mne neorezava. A jeste mam jeden dotaz: mam zatim jen holy polygon, ve 3D se mi v internim prohlizeci zobrazi, ale kdyz ho vyexportuji do .wrl, tak tam nic neni (jen cerna plocha). Mam neco spatne nastaveno, nebo ten prohlizec .wrl neumi zobrazit cary? Diky za odpoved Ik S pranim ZARE SVETLA Ing. Jiri Novotny - JINOLI Tynska 7, 110 00 Praha 1 tel: 777 677 988, fax: 777 476 960 ICO: 48064149, DIC: CZ5404242239 e-mail: jinoli@centrum.cz http://jinoli.zde.cz - vse pro nezavisle sviceni a nejen to Subject: Re: Help - my cave is inside-out From: Wookey Date: Sun, 2 Jan 2005 21:11:00 +0000 To: therion@speleo.sk +++ Martin Budaj [04-12-28 15:57 +0100]: >>>> >> >>>> >> At the scrap joins, you should try to avoid any symbols. If there are >>>> >> some, usually -clip off helps (if you do not need to clip them by scrap >>>> >> border). But in the case of area that exists between walls, it would >>>> >> probably not help. >> >>> > >>> > OK - this is a real problem for a cave containing a long streamway. There >>> > is a very long continuous 'water' area. This connot always be drawn as >>> > one scrap. As you say the pattern rather obviously doesn't match up at >>> > the join. >>> > I think we need to have some mechanism for making such smooth area joins >>> > in the medium term. > >> >> I have tried this now and it works :-) It seemes that PDF viewers optimize >> filling of adjacent areas and join patterns smoothly. xpdf doesn't do this unfortunately. gpdf can't render my pdf file at all anymore :-( 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/ Subject: Re: Help - my cave is inside-out From: Wookey Date: Sun, 2 Jan 2005 21:48:51 +0000 To: therion@speleo.sk +++ Martin Budaj [04-12-26 13:06 +0100]: >>> > I'm getting the hang of this and have drawn up some cave. It went OK until >>> > I got to a complicated section, with an underlying streamway adn overlying >>> > passages. The streamway needs to be a separate scrap. But I haven't got >>> > that far. One bit of wall wasn't shown. By adding a map-fg colour I could >>> > see that therion is very confused about what is the inside and what is the >>> > outside of the scrap. > >> >> Only minor improvements were required -- mostly to correct line types (the >> hidden wall was actually a border, the inner pillar should have -outline >> in option...). All my changes are marked red in the enclosed picture. Now that I've drawn about 8km of survey the last scrap (top right hand corner - scrap bmb3_s3) has had 'pillar failure' again. There are 3 pillars which do not work (the insides are filled). They are all walls with -outline in and I've tried reversing them, but it seems to stay broken. What's going on? The files are are: Big version with the scans in (16Mb): http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon1.tgz Small version without the scans: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.tgz 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/ Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Mon, 3 Jan 2005 12:59:13 +0100 (CET) To: therion@speleo.sk >> Now that I've drawn about 8km of survey the last scrap (top right hand >> corner - scrap bmb3_s3) has had 'pillar failure' again. >> >> There are 3 pillars which do not work (the insides are filled). They are >> all >> walls with -outline in and I've tried reversing them, but it seems to stay >> broken. What's going on? There is another problem. Even if scrap boundary has correctly specified all -outline out/in/none options, there may be problem to determine which area is inside of the scrap if the outline crosses itself (like figure 8). In such a case you get a MetaPost warning Warning: scrap outline intersects itself in bmb3_s3@fake and it is than random if MetaPost determines the interior of scrap correctly. The solution is to 1) find where the loop occured -- this may be tricky, but start with the endpoints where scraps should join. The loop may be very small, even unnoticable. Even worse, it may not be visible at all, because it happens anly after the joining of scraps -- which is the case of your example :( 2) correct the position of the control points (see the second picture) I hope the enclosed pictures make it more clear. Regards Martin Subject: Re: Help - my cave is inside-out From: Wookey Date: Wed, 5 Jan 2005 02:14:36 +0000 To: therion@speleo.sk message re-sent as it seems to have got lost (same with the other two I sent just now). +++ Martin Budaj [05-01-03 12:59 +0100]: >>> > Now that I've drawn about 8km of survey the last scrap (top right hand >>> > corner - scrap bmb3_s3) has had 'pillar failure' again. >>> > >>> > There are 3 pillars which do not work (the insides are filled). They are >>> > all walls with -outline in and I've tried reversing them, but it seems >>> > to stay broken. What's going on? > >> >> There is another problem. Even if scrap boundary has correctly specified >> all -outline out/in/none options, there may be problem to determine which >> area is inside of the scrap if the outline crosses itself (like figure 8). >> In such a case you get a MetaPost warning >> >> Warning: scrap outline intersects itself in bmb3_s3@fake I have this warning in a few scrpas in that survey - I wondered how serious it was, and what I should do about it. But without more details of _where_ it intersects itself (and why this is a problem), I could not do anything but ignore it. >> and it is than random if MetaPost determines the interior of scrap >> correctly. The solution is to >> 1) find where the loop occured -- this may be tricky, but start with the >> endpoints where scraps should join. The loop may be very small, even >> unnoticable. Even worse, it may not be visible at all, because it happens >> anly after the joining of scraps -- which is the case of your example :( >> 2) correct the position of the control points (see the second picture) >> >> I hope the enclosed pictures make it more clear. It does - thanks very much for taking the time to look at it. I have several more scraps which I cannot include in the overall survey at the moment because if I do I get cryptic metapost errors. We have to work out a way of getting better feedback to the user about _where_ the problem lies as it is currently extremely difficult to fix as you don't know which of many lines is at fault. How did you find the above problem. If I understood the process you used to find this it might help me next time. I'll add this answer to the FAQ too. 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/ Subject: Re: Help - my cave is inside-out From: Wookey Date: Wed, 5 Jan 2005 02:12:47 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-03 12:59 +0100]: >> Warning: scrap outline intersects itself in bmb3_s3@fake >> >> and it is than random if MetaPost determines the interior of scrap >> correctly. The solution is to >> 2) correct the position of the control points (see the second picture) I have a bit of a problem with your example fix. Now the wall does not follow the wall on my survey - I have had to distort it a little to solve this problem. This seems to me to be the wrong answer - the original version is a correct drawing of the cave, therion needs to be able to join (and distort if necessary) that drawing without telling me it it 'wrong' and I have to draw the cave a slightly different shape in order for it to be accepted. I realise this may not be easy, but I don't really think that telling the user their correct drawing causes an error is good enough. Perhaps when the outline intersection happens on a line that is a scrap end line (i.e one that therion invented, not one the user drew) then that should not be an error - and therion could adjust its own line to compensate? Is that practical? 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/ Subject: Re: Help - my cave is inside-out From: Wookey Date: Wed, 5 Jan 2005 02:11:08 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-03 12:59 +0100]: >> There is another problem. Even if scrap boundary has correctly specified >> all -outline out/in/none options, there may be problem to determine which >> area is inside of the scrap if the outline crosses itself (like figure 8). >> In such a case you get a MetaPost warning >> >> Warning: scrap outline intersects itself in bmb3_s3@fake OK. I have another big section of cave that is currently broken due to mysterious therion metapost errors. I've tried to track it down but I don't understand well enough to do it. I am getting this error: ! angle(0,0) is taken as zero. l_arrow->...d(angle(direction.infinity.of(EXPR0))- 90)shifted(point.infinity....l.5565 ),2); The angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. I assume this means that I have two points on top of each other - but I don't know in which scrap, or which line, so it is not practical to find it. The offending files are at: http://trilogy-gw.aleph1.co.uk/~wookey/files/soundriver.tgz http://trilogy-gw.aleph1.co.uk/~wookey/files/soundriverpic.tgz (includes scans) It seems that if I include any of soundriver2_s1 soundriver3_s1 or soundrivercrab_s1 then it breaks. soundriver2_s1 is particularly perplexing as it is a straight bit of passage with no areas in it, 3 stations, and not much detail - seems to me there is very little to go wrong. I did have soundriver3_s1 working last night I thought, but not now... I am afraid I am going to keep sending you these until we work out some better debugging system :-( or I get a lot smarter. 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/ Subject: Importing surveys with no data From: Wookey Date: Tue, 28 Dec 2004 21:00:12 +0000 To: Therion List We have a number of pre-1990 surveys in mulu for which all the centreline data has been lost but we still have the drawn up surveys. We have regenerated centreline data by inventing survey stations and legs and working out XYZ coordinates for them (very laboriously)2, but now I am putting these surveys into Therion. At the moment I am using the XYZ base survey data and putting in stations for these on the plan. However the positions of these stations on the drawing are very aproximate (I don't actually have the original plot showing exactly where the made-up stations are - one can just just guess from the look of the survey). But this introduces errors of approx the width of the passage, which can be several meters, and is adding distortion to the drawings I am putting in. I am wondering if there is a better way - so I put the drawings in and say 'these are all we have - you work it out', rather than using ill-defined stations which were only made up by taking off this very same drawing in the first place but now they have been through numerous innacuracies and distortions. Can therion do this? And how would I work out the scaling? Can I use a scale bar or something and just copy the scale into each scrap? 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/ Subject: Re: [therion] Importing surveys with no data