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 From: Stacho Mudrak Date: Wed, 29 Dec 2004 09:44:37 +0100 To: therion@speleo.sk > 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. There two possibilities how to solve this: 1. To position each scrap - in principle you need only two stations for each scrap. You do not need to enter a lot of stations. Then in output you can hide those virtual stations using symbol-hide group centerline. 2. You can use projection none for that - but then you will need to calibrate each scrap at real coordinates (if you have some grid on your paper, this should not be a big problem). 3. We can change the behaviour of therion and allow calibration of scraps using only -scale option also in other projections (currently it is allowed only in the "none" projection) But in any case, you will need to specify -scale for each scrap. > 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? In the scrap -scale option, you can specify coordinates of two real and corresponding two image points. There is no scalebar or something like that. Copying can be done in text editor (very carefully :) Regards, S. Subject: Re: Importing surveys with no data From: Wookey Date: Wed, 29 Dec 2004 20:45:31 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-29 09:44 +0100]: >>> >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. > >> >> There two possibilities how to solve this: >> >> 1. To position each scrap - in principle you need only two stations for >> each scrap. You do not need to enter a lot of stations. Then in output >> you can hide those virtual stations using symbol-hide group centerline. Yes I've been doing this - and since discovering debug mode I've been correcting the stations which were badly placed. Nevertheless there seem to be some errors in our original 're-generation' of the fake data which means there is some stretching of of the image. It would be better to use the image itself as the reference, with the only stations involved being ones where real surveys connect. I tried adding one passage (for which we didn't even have 'fake' data) as 'projection none', but this just produced an error (something like 'incompatible projection'). Is it possible to mix projection none and plan in a map (and have joins between them)? If not how would you add a load of old 'lost data' survey to some new data (which is what I need to do). >> 2. You can use projection none for that - but then you will need to >> calibrate each scrap at real coordinates (if you have some grid on your >> paper, this should not be a big problem). I don't have a grid on the paper. There is nothing but a scale bar in one corner. What exactly am I trying to do here? There are 8 number to be given - 4 picture scale points and 4 real scale points. Let us say I have a scrap on a sheet of paper and I know nothing but the distance that corresponds to 50m. How might I go about making up some numbers for the scrap? And would I then just copy those numbers to all the other scraps? I suspect we need a little how-to for importing such 'lost data' surveys to therion, and how to best combine them with new survey data. >> 3. We can change the behaviour of therion and allow calibration of >> scraps using only -scale option also in other projections (currently it >> is allowed only in the "none" projection) But in any case, you will need >> to specify -scale for each scrap. Would this solve the 'incompatible projection' problem when connecting to plan projection scraps? >> In the scrap -scale option, you can specify coordinates of two real and >> corresponding two image points. There is no scalebar or something like >> that. Copying can be done in text editor (very carefully :) OK - but as above I have no idea how to give these numbers. Which way do they increase? are both sets of numbers entirely arbtrary and only the ratio matters? Are there overflow limits I should worry about? and so on... What a lot of questions! 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: Importing surveys with no data From: Martin Sluka Date: Thu, 30 Dec 2004 08:07:26 +0100 To: therion@speleo.sk At 20:45 +0000 29.12.2004, Wookey wrote: ******************************************* > I don't have a grid on the paper. There is nothing but a scale bar in one > corner. What exactly am I trying to do here? There are 8 number to be given > - 4 picture scale points and 4 real scale points. Let us say I have a scrap > on a sheet of paper and I know nothing but the distance that corresponds to > 50m. How might I go about making up some numbers for the scrap? You may make a grid in Gimp, Illustrator, ... on top of your scan and generate a "scan with grid" My 0.02 EUR M. -- Subject: [therion] Re: Importing surveys with no data From: Martin Sluka Date: Thu, 30 Dec 2004 08:49:11 +0100 To: therion@speleo.sk At 20:45 +0000 29.12.2004, Wookey wrote: ******************************************* > I tried adding one passage (for which we didn't even have 'fake' data) as > 'projection none', but this just produced an error (something like > 'incompatible projection'). Wookey, I hope you may use minimaly one reference point - from passage where this "fake" passage is connected to. Martin -- Subject: Re: Importing surveys with no data From: Stacho Mudrak Date: Fri, 31 Dec 2004 09:19:09 +0100 To: therion@speleo.sk > 'incompatible projection'). Is it possible to mix projection none and plan > in a map (and have joins between them)? No it is not. In the map - all scraps have to be from same projection. > If not how would you add a load of > old 'lost data' survey to some new data (which is what I need to do). Well, If I should do this, I would probably do it following way: 1. For each paper define one virtual station, that will position this paper in real world coordinates. 2. For all scraps on this paper, I would insert into each of them only this single station (and I would give it -visibility off option, that it will not be visible in the map). 3. Scaling and rotation of scrap would be done using -scale option. If you have a horizontal 50 m scalebar on the paper, and paper is facing north, than I would use 0 0 50 0 as real scale coordinates for edges of scalebar. See attached picture. Real coordinates are not important, only their difference (vector) is. Scrap will be positioned according to stations specified in it. > - 4 picture scale points and 4 real scale points. Let us say I have a scrap > on a sheet of paper and I know nothing but the distance that corresponds to > 50m. How might I go about making up some numbers for the scrap? As above. All you need to do is to specify paper and real vector. From these two vectors rotation and scaling are determined. > And would I then just copy those numbers to all the other scraps? Yes, for all scraps lying on the same paper, these numbers would be same. > OK - but as above I have no idea how to give these numbers. Which way do > they increase? are both sets of numbers entirely arbtrary and only the ratio > matters? Are there overflow limits I should worry about? and so on... Both paper and real coordinates are standard cartesian. X = east, Y = north. Yes, numbers are arbitrary, important are only relative positions. There are no overflow limits - you can probably use any numbers you like. 4. When scraps will be drawn, I would then adjust positions of those virtual paper stations, that scraps will be as close as possible. When scraps will be close to each other - then I would join them. And that's all. You will need only so as many stations, as many papers you have. Mixing projections, or calibrating scraps only using scale option I do not consider as a good idea. Once you may decide to use other coordinets (e.g. GPS), and you will need to shift all papers somewhere else. If real coordinats will be in form: fix paper1 10 20 30 fix paper2 20 30 40 it will be very simple, because it will be in one table. If scaling points would be in scrap headers, it would be very hard. Another point - this way (one station per scrap or paper) each scrap also receives some vertical information. If you would like to color scraps according to altitudes (it should be possible in the next release), it will be also possible. When scaling scraps only using -scale option, there is no vertical information. I am not sure, whether I wrote it understandable way, but I hope you understand what I wanted to say. Happy new year to everybody, S. Subject: Re: Importing surveys with no data From: Stacho Mudrak Date: Fri, 31 Dec 2004 09:20:04 +0100 To: therion@speleo.sk And the scaling picture :) Subject: Re: Importing surveys with no data From: Wookey Date: Fri, 31 Dec 2004 11:56:58 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-31 09:19 +0100]: >>> >'incompatible projection'). Is it possible to mix projection none and plan >>> >in a map (and have joins between them)? > >> >> No it is not. In the map - all scraps have to be from same projection. >> > >>> >If not how would you add a load of >>> >old 'lost data' survey to some new data (which is what I need to do). > >> >> Well, If I should do this, I would probably do it following way: >> I am not sure, whether I wrote it understandable way, but I hope you >> understand what I wanted to say. Thanx Stacho - that's exactly what I needed to know, carefully explained, and yes, I think it all made sense. I'll give it a go and get back to you if I have any problems. Another excellent answer for the FAQ :-) 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: debug mode From: Wookey Date: Wed, 29 Dec 2004 00:36:15 +0000 To: Therion List OK - I turned 'debug on' in layout and now I get pretty images like this: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.pdf I can see that the black linesare the final result and the red lines are the initial positions of the scrap walls, but what do the yellow lines/triangles indicate. It looks like distortions or distortions at joins? As you can see something has gone badly wrong in the upper centre of this image - I'm just trying to work out what... Also - as you can see on that pdf I am not getting any transparency on overlaying passages (despite having 'transparency on', 'opacity 50'). How do I fix that? or is it just that my viewer (xpdf) can't do it and it is just output into the PDF? 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] debug mode From: Olly Betts Date: Wed, 29 Dec 2004 01:14:34 +0000 To: Therion List On Wed, Dec 29, 2004 at 12:36:15AM +0000, Wookey wrote: >> Also - as you can see on that pdf I am not getting any transparency on >> overlaying passages (despite having 'transparency on', 'opacity 50'). How do >> I fix that? or is it just that my viewer (xpdf) can't do it and it is just >> output into the PDF? Jenny found xpdf wasn't showing the transparency just before the BCRA conference (latest xpdf from debian unstable at the time). It worked at uni using a fairly recent version of the Adobe viewer on Windows 2000. A quick poke round the web seems to confirm this as a limitation of xpdf. It seems PDF may be rather entangled by patent problems (boo hiss): http://www.ghostscript.com/pipermail/gs-devel/2002-February/001203.html It's a shame Adobe's support for Unix and Linux is so rubbish. Cheers, Olly Subject: Re: [therion] debug mode From: Jenny Black Date: Wed, 29 Dec 2004 01:18:04 +0000 (GMT) To: Therion List >>I can see that the black lines are the final result and the red lines are the >>initial positions of the scrap walls, but what do the yellow lines/triangles >>indicate. It looks like distortions or distortions at joins? I think the yellow blobs are the points that have been moved the most and the yellow lines are where they are being moved to (with one for each scrap?). Is this what is referred to as "orange" in the thbook? For me these were often a station that i had carelessly miss-labelled when drawing the scrap. Bye, Jenny Subject: Re: debug mode From: Wookey Date: Wed, 29 Dec 2004 01:55:51 +0000 To: therion@speleo.sk +++ Olly Betts [04-12-29 01:14 +0000]: >> On Wed, Dec 29, 2004 at 12:36:15AM +0000, Wookey wrote: > >>> > Also - as you can see on that pdf I am not getting any transparency on >>> > overlaying passages (despite having 'transparency on', 'opacity 50'). How do >>> > I fix that? or is it just that my viewer (xpdf) can't do it and it is just >>> > output into the PDF? > >> >> Jenny found xpdf wasn't showing the transparency just before the BCRA >> conference (latest xpdf from debian unstable at the time). It worked >> at uni using a fairly recent version of the Adobe viewer on Windows >> 2000. >> >> A quick poke round the web seems to confirm this as a limitation of >> xpdf. So it is - if I use gpdf then I get transparency. xpdf is realy handy though because you can leave a window open and do 'R' to reload the file each time you run a therion update (which is _really_often_ so that you can tell when you last broke it and so that I don't lose much when it hangs), gpdf doesn't have this very handy 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: Re: debug mode From: Wookey Date: Wed, 29 Dec 2004 02:05:58 +0000 To: therion@speleo.sk +++ Jenny Black [04-12-29 01:18 +0000]: >>> >I can see that the black lines are the final result and the red lines are the >>> >initial positions of the scrap walls, but what do the yellow lines/triangles >>> >indicate. It looks like distortions or distortions at joins? > >> >> I think the yellow blobs are the points that have been moved >> the most and the yellow lines are where they are being moved to (with >> one for each scrap?). Is this what is referred to as "orange" in the >> thbook? presumably. And I notice that in fact I sometimes have 3 version of a scrap - red, blue and black/grey. >> For me these were often a station that i had carelessly >> miss-labelled when drawing the scrap. yes - rogue stations were the problem in that example. The most common problems are a) getting two stations with the same -name b) having a spurious station somwhere (which is also usually a duplicate) The interface means you have to actiuviely work to avoid these. When you add a new station it defaults to the same -name as the last one. This can be a useful speedup (edit the existing number) - but there should be something to tell you if you have entered two stations with the same -name. (this can be valid when the same station appears in two scraps, but two stations with the same name in one scrap is always wrong I think). Also because xtherion stays in 'insert point mode' until you cancel it, it is very easy to accidentaly put in a point somewhere random whilst moving the canvas, or to get two on top of each other. I'm not quite sure what to do about this, but maybe more actions should cancel 'insert point mode' than just 'escape'. Suggestions? Debug mode is very helpful in working out what has gone wrong though. 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: debug mode From: Olly Betts Date: Wed, 29 Dec 2004 02:29:12 +0000 To: therion@speleo.sk On Wed, Dec 29, 2004 at 01:55:51AM +0000, Wookey wrote: >> +++ Olly Betts [04-12-29 01:14 +0000]: > >>> > A quick poke round the web seems to confirm [lack of transparency >>> > support] as a limitation of xpdf. > >> >> So it is - if I use gpdf then I get transparency. That's interesting, since gpdf is based on xpdf. >> xpdf is realy handy though because you can leave a window open and do 'R' to >> reload the file each time you run a therion update (which is _really_often_ >> so that you can tell when you last broke it and so that I don't lose much when >> it hangs), gpdf doesn't have this very handy feature. Post an "enhancement" bug on the GNOME bugzilla? Cheers, Olly Subject: Re: [therion] debug mode From: Gary Ritchie Date: Tue, 28 Dec 2004 22:14:45 -0500 To: therion@speleo.sk please unsubscribe me! On Dec 28, 2004, at 7:36 PM, Wookey wrote: OK - I turned 'debug on' in layout and now I get pretty images like this: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.pdf I can see that the black linesare the final result and the red lines are the initial positions of the scrap walls, but what do the yellow lines/triangles indicate. It looks like distortions or distortions at joins? As you can see something has gone badly wrong in the upper centre of this image - I'm just trying to work out what... Also - as you can see on that pdf I am not getting any transparency on overlaying passages (despite having 'transparency on', 'opacity 50'). How do I fix that? or is it just that my viewer (xpdf) can't do it and it is just output into the PDF? 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/ Gary Ritchie, Designer + Digital Artist Pittsburgh, USA http://garyritchie.com T: 412 371 9152 AIM: secundarx Alt email: g.ritchie4@verizon.net Subject: Re: [therion] debug mode From: Stacho Mudrak Date: Wed, 29 Dec 2004 10:01:50 +0100 To: therion@speleo.sk > I can see that the black linesare the final result and the red lines are the > initial positions of the scrap walls, but what do the yellow lines/triangles > indicate. It looks like distortions or distortions at joins? red-lines - original scraps just rotated and scaled blue-lines - scraps adjusted to survey stations (before processing joins) red points - original positions of survey stations yellow points connected by yellow line - original position of two points in scrap with maximal distortion black points connected by black line - final position of two points in scrap with maximal distortion yellow lines connecting black and yellow points indicate how these pointe were shifted. If there is only one black point -> two stations with different names at one place. Easiest way how to trace stations is to put -name in the search field. Then click "Find first" and then "Find next" and trace station after station, whether it has correct position. Regards, S. Subject: Re: [therion] Re: debug mode From: Stacho Mudrak Date: Wed, 29 Dec 2004 10:06:47 +0100 To: therion@speleo.sk > The interface means you have to actiuviely work to avoid these. When you add > a new station it defaults to the same -name as the last one. This can be a > useful speedup (edit the existing number) - but there should be something to > tell you if you have entered two stations with the same -name. This is already in the TODO list. It will be reported as therion error (in the plan and elevation projections). > Also because xtherion stays in 'insert point mode' until you cancel it, it > is very easy to accidentaly put in a point somewhere random whilst moving > the canvas, or to get two on top of each other. This is already changed (will be in next release). If you will enter second point with the same type on the same place, it will not insert it, but it will cancel insert mode. Regards, S. Subject: Re: debug mode From: Wookey Date: Wed, 29 Dec 2004 10:53:55 +0000 To: therion@speleo.sk +++ Stacho Mudrak [04-12-29 10:01 +0100]: >> red-lines - original scraps just rotated and scaled >> blue-lines - scraps adjusted to survey stations (before processing joins) >> >> red points - original positions of survey stations >> yellow points connected by yellow line - original position of two points >> in scrap with maximal distortion >> black points connected by black line - final position of two points in >> scrap with maximal distortion >> yellow lines connecting black and yellow points indicate how these >> pointe were shifted. >> >> If there is only one black point -> two stations with different names at >> one place. >> >> Easiest way how to trace stations is to put -name in the search field. >> Then click "Find first" and then "Find next" and trace station after >> station, whether it has correct position. I put this in the wiki. Although possibly not in the best place... I'll put somemore info of these questions/answers in the wiki as we go along. 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: debug mode From: "Ladislav Blazek" Date: Wed, 29 Dec 2004 12:20:28 +0100 (CET) To: therion@speleo.sk Wookey napsal(a): >> I put this in the wiki. Although possibly not in the best place... I think FAQ is better place for it. L. Subject: General note and suggestions From: Wookey Date: Mon, 3 Jan 2005 03:00:59 +0000 To: Therion List After the last week or so I have come up with qiute a few small problems and interface improvements. Here they all are for discussiona and consideration. This is part of my reaction to Stacho asking about year ago for a suggested list of extra keystrokes. A couple of these have been mentioned before, but here is the whole list anyway. Whilst loading a new file in map editor it says 'noname0x.th2' in a slightly confusing manner. It should show nothin or the name of the files that is being loaded. Can't create a point if it happens to be where the yellow direction tick is (or the control handle of previous point). Makes it difficult to do small stuff like rocks. I think this is a bug. You can't move two points together (e.g if you have ended two lines at the same point but want to adjust them, you have to do them both separately). Not sure how the interface should work for this, but it would be an improvement. 'water-flow conjectural' does not show up in plans. I want to show this. It is very hard to tell that you have loaded the wrong thconfig file. Some sensibe error like 'cannot find foo' would help. e.g: My data is in subdir 'bluemoon' load thconfig from dir above (soundriver) load bmb1.th2 from bluemoon dir hit compile - gives 'error' but doesn't show what error. run 'therion' in the bluemoon dir and things are fine (of course). There used to be an entry: "It would be really useful if there was something showing the name of the current scrap", but after using it for best part of two weeks I noticed this was in the title bar! Should be in the tips/FAQ I think so people notice faster. It would be _really_ useful to be able to do graphical joins: click on something and say 'join this to foo'. Difficult to do between two .th2 files, but at least for joins within a .th2 file being able to do them graphically like areas would help a lot (especially if you have to name lines - same automatic naming as areas would help enormously). inserting line points happens _after_ the current point inserting file entries happens _before_ the current line inserting scrap happens at the start of the file this is confusing. inserting after the current position always would be good (then things appear in the file in the order you draw them, not reverse order Difficult to add several points to the end of a line (i.e. carry on a line I accidentally stopped). First new point happens at end but then next point happens one back from end, which is never what I want. Check to tell you you are entering line outside a scrap would be good. Splitting lines that are part of areas is tricky. Does label get removed from both halves of line? Need to be able to find areas and lines better (especially after splitting a line). e.g if I click on an item it is highlyighted, but if it is currently off-screen then there is no clue where it is. maybe double-clicking would move the selected item on-screen? Docs need explanation of 'scrap distortion' numbers. What do they mean? Mine are around 70% - is that as bad as it sounds? Debris rocks look daft on 1:1000 plans. Thye look OK on some of the 1:200 maps martinS showed me. This may be rectifiable by using the base-scale as well as scale options, but I haven't yet got both the rocks and the legend to look sensible. When you insert an area it is always 'water' not the last area you inserted. The line type gets defaulted to whatever you set the area to last time. When you start a line or area and don't add anything to it you end up with an empty entry in the file. It would be smart to tidy these up. What is difference between floor-step and pit? Button for 'invisible', indeed a list of available subtypes in general would be useful. I've found it very easy to mis-spell '-subtype invisible', and having a list would save you needing to know which ones were available. Why do newscraps go in at the top of the file, not bottom of file? This results in scraps being in reverse order in the file. I'd naturaly expect it to be the other way round. After creating the first scrap the cursor is left at a position such that if you enter any lines/points they end up outside a scrap. 0.3.3 keys needed: scroll up/down in side panel (pageup/down?) scroll up/down in file commands window (shift pageup/down?) Shortcut for insert area is needed _very badly_. having to switch between the 'insert area' and 'insert scrap' action is just not good enough as an interface. insert area ctrl-A insert scrap ctrl-S Shortcuts needed to select common types: wall rock-border rock-edge pit floor-step A very useful thing to be able to do would be right-clicking on an item on the map and selecting a point or line type. Making the point type selector taller so that you don't need to page up _twice_ to get from 'wall' to 'border'. some way to select a whole load of lines and move them to a new scrap. bugs: (present since at least 0.3.1 - still in 0.3.5) If entering a line then use ctrl-D to abandon it, one char disappears from current text field (eg pillar becomes illar, contour becomes ontour or cntour (depending on cursor position) prone to crashing - still present in 0.3.5. Need to test with tcltk recompiled without thread support. 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] General note and suggestions From: Martin Sluka Date: Mon, 3 Jan 2005 11:49:00 +0100 To: therion@speleo.sk At 03:00 +0000 3.1.2005, Wookey wrote: ******************************************* > It is very hard to tell that you have loaded the wrong thconfig file. > Some sensibe error like 'cannot find foo' would help. > My data is in subdir 'bluemoon' > load thconfig from dir above (soundriver) > load bmb1.th2 from bluemoon dir > hit compile - gives 'error' but doesn't show what error. > run 'therion' in the bluemoon dir and things are fine (of course). You may give them different names - bluemoon.thconfig, soundriver.thconfig, etc. and press F3 (Compiler window) first and F9 after. It is not so clever, but ... Martin -- Subject: Re: General note and suggestions From: Wookey Date: Mon, 3 Jan 2005 16:14:50 +0000 To: therion@speleo.sk +++ Martin Sluka [05-01-03 11:49 +0100]: >> At 03:00 +0000 3.1.2005, Wookey wrote: >> ******************************************* >> > >>> >It is very hard to tell that you have loaded the wrong thconfig file. >>> >Some sensibe error like 'cannot find foo' would help. >>> >My data is in subdir 'bluemoon' >>> >load thconfig from dir above (soundriver) >>> >load bmb1.th2 from bluemoon dir >>> >hit compile - gives 'error' but doesn't show what error. >>> >run 'therion' in the bluemoon dir and things are fine (of course). > >> >> You may give them different names - bluemoon.thconfig, >> soundriver.thconfig, etc. and press F3 (Compiler window) first and F9 >> after. It is not so clever, but ... Yes that is a work-around, but then I could not just run theroin in the directory and have it automatically pick up the config file - I would have to give an option. The real reason for pointing it out is that Therion does not give a useful error when you do this. It should say something like "Current dir cannot open ' ", so that you could work out that you opened the wrong 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: [therion] Re: General note and suggestions From: Martin Sluka Date: Mon, 3 Jan 2005 18:45:28 +0100 To: therion@speleo.sk At 16:14 +0000 3.1.2005, Wookey wrote: ******************************************* > Yes that is a work-around, but then I could not just run theroin in the > directory and have it automatically pick up the config file - I would have > to give an option. You are right, but it is only problem of first run. If the correct config file is loaded already, F9 works. BTW - in this way you may have several xxxx.thconfig files in one directory with different parameters and switch easy among them. Martin -- Subject: rock-border cannot be presumed From: Wookey Date: Mon, 3 Jan 2005 03:37:44 +0000 To: Therion List I have a rock-border that is presumed, but this is not a permitted subtype. How should should a thing be drawn in therion? 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.301_400 Topics (messages 301 through 400): Re: General note and suggestions 301 by: Martin Sluka 322 by: Stacho Mudrak 327 by: Wookey 330 by: Stacho Mudrak 331 by: Wookey Re: Help - my cave is inside-out 302 by: Martin Budaj 303 by: Martin Budaj 304 by: Martin Budaj 305 by: Wookey 306 by: Wookey 307 by: Martin Budaj 309 by: Wookey 316 by: Martin Budaj piles of rocks 308 by: Wookey 313 by: Martin Sluka 317 by: Martin Budaj arranging files for big systems 310 by: Wookey 315 by: Martin Budaj 319 by: Wookey 320 by: Stacho Mudrak 333 by: Martin Sluka 337 by: Wookey 348 by: Wookey 349 by: Martin Budaj 350 by: Stacho Mudrak 351 by: Stacho Mudrak 352 by: Wookey 353 by: Wookey 354 by: Stacho Mudrak 355 by: John Pybus 359 by: Martin Budaj problem with staggered data format 311 by: Wookey 312 by: Olly Betts 314 by: Martin Budaj 318 by: Wookey Compilation Problems... 321 by: Thierry GONON 323 by: Stacho Mudrak 325 by: Thierry GONON 326 by: Stacho Mudrak 335 by: Martin Sluka Re: rock-border cannot be presumed 324 by: Stacho Mudrak 328 by: Wookey 329 by: Stacho Mudrak 332 by: Wookey change to flags and subtypes (was Re: rock-border cannot be presumed) 334 by: Andrew Atkinson 336 by: Wookey Segfault when including survey data in plan 338 by: Wookey 339 by: Stacho Mudrak survex to therion conversion script 340 by: Wookey 341 by: Olly Betts 342 by: Stacho Mudrak 343 by: Wookey 344 by: Simeon Warner 345 by: John Pybus 346 by: Stacho Mudrak 347 by: Olly Betts another set of inside-out pillars 356 by: Wookey 357 by: Martin Sluka 358 by: Stacho Mudrak 360 by: Wookey 361 by: Wookey 365 by: Martin Budaj problem compiling on debian woody 362 by: Roman Muñoz 363 by: Olly Betts 364 by: Roman Muñoz model viewer? 366 by: Roman Muñoz 367 by: Stacho Mudrak 373 by: Roman Muñoz 374 by: Wookey 375 by: Olly Betts 376 by: Roman Muñoz 377 by: Roman Muñoz 378 by: Wookey 379 by: Roman Muñoz 380 by: Martin Budaj 381 by: Roman Muñoz 382 by: Olly Betts Adding sections error 368 by: Andrew Atkinson 370 by: Martin Budaj 371 by: Andrew Atkinson 372 by: Martin Budaj Section problem 369 by: Andrew Atkinson translating... 383 by: Roman Muñoz 384 by: Martin Budaj 385 by: Roman Muñoz 386 by: Stacho Mudrak 387 by: Martin Sluka 388 by: Roman Muñoz 389 by: Martin Budaj 390 by: Stacho Mudrak 391 by: Martin Sluka 392 by: Martin Sluka 393 by: Stacho Mudrak 394 by: Ladislav Blazek 395 by: Wookey 396 by: Stacho Mudrak 397 by: Olly Betts 398 by: Stacho Mudrak 399 by: Martin Budaj texts_es.tx 400 by: Roman Muñoz Subject: Re: [therion] General note and suggestions From: Martin Sluka Date: Wed, 5 Jan 2005 12:17:52 +0100 To: therion@speleo.sk Wookey, if the file thconfig isn't in actual directory and you press F9 first time (no any config file in F3 window), xtherion will ask you for correct file. So you may check what you are doing. MartinS At 03:00 +0000 3.1.2005, Wookey wrote: ******************************************* > It is very hard to tell that you have loaded the wrong thconfig file. > Some sensibe error like 'cannot find foo' would help. > My data is in subdir 'bluemoon' > load thconfig from dir above (soundriver) > load bmb1.th2 from bluemoon dir > hit compile - gives 'error' but doesn't show what error. > run 'therion' in the bluemoon dir and things are fine (of course). You may give them different names - bluemoon.thconfig, soundriver.thconfig, etc. and press F3 (Compiler window) first and F9 after. It is not so clever, but ... Martin -- Subject: Re: [therion] General note and suggestions From: Stacho Mudrak Date: Mon, 10 Jan 2005 09:28:34 +0100 To: therion@speleo.sk > Whilst loading a new file in map editor it says 'noname0x.th2' in a slightly > confusing manner. It should show nothin or the name of the files that is > being loaded. No problem. > Can't create a point if it happens to be where the yellow direction tick is > (or the control handle of previous point). Makes it difficult to do small > stuff like rocks. I think this is a bug. Yes, it is a bug. > You can't move two points together (e.g if you have ended two lines at the same > point but want to adjust them, you have to do them both separately). Not > sure how the interface should work for this, but it would be an improvement. It would be nice (I am having also such problems), but I have no idea how to do it. > 'water-flow conjectural' does not show up in plans. I want to show this. I have to check this. > It is very hard to tell that you have loaded the wrong thconfig file. Some sensibe error like 'cannot find foo' would help. e.g: > My data is in subdir 'bluemoon' > load thconfig from dir above (soundriver) > load bmb1.th2 from bluemoon dir > hit compile - gives 'error' but doesn't show what error. > run 'therion' in the bluemoon dir and things are fine (of course). This sounds strange. Therion is allways started from dir, at which current thconfig file is located. You may not compile, unless some config-file is loaded (or you can? I have to check). In any case, the compilation process needs to be changed. I am preparing new arrangement, but it will take some time. > It would be _really_ useful to be able to do graphical joins: click on > something and say 'join this to foo'. Difficult to do between two .th2 > files, but at least for joins within a .th2 file being able to do them > graphically like areas would help a lot (especially if you have to name > lines - same automatic naming as areas would help enormously). OK, I will put it in the TODO. If you have to join scraps manually (line by line), it is real pain - I agree. > inserting line points happens _after_ the current point > inserting file entries happens _before_ the current line This I think is natural. If you draw something, it should overlap things that were drawn previously. Example: firstly you draw rock-border and than rock-edge. > inserting scrap happens at the start of the file > this is confusing. OK, I can change it that new scraps will be inserted before current scrap. > inserting after the current position always would be good (then things appear in the file in the order you draw them, not reverse order That's true, but then you should draw rock-borders/edges in reversed order. > Difficult to add several points to the end of a line (i.e. carry on a line I > accidentally stopped). First new point happens at end but then next point > happens one back from end, which is never what I want. Well, you just need to click manually on the "end of line" item in the line point list (or just hit Escape to jump there :) . Than you can continue inserting the line. > Check to tell you you are entering line outside a scrap would be good. OK, but I hate error windows, I have to click OK every time. Would a beep be enought? > Splitting lines that are part of areas is tricky. Does label get removed from both halves of line? Yes. You need to copy the label and paste it into part of line you wish to. > Need to be able to find areas and lines better (especially after splitting a > line). e.g if I click on an item it is highlyighted, but if it is currently > off-screen then there is no clue where it is. maybe double-clicking would > move the selected item on-screen? This is only the problem of lines. OK - if line will be selected, last point of line will be highlighted and centered on the screen. You are right. > Docs need explanation of 'scrap distortion' numbers. What do they mean? Mine > are around 70% - is that as bad as it sounds? OK, we should probably add something like relative distortion. This is absolute distortion. It means, that there exists two points in a scrap, which distance was changed by 70% in adjustment process. It may be bad, but it must not be bad. We have to find some different measure of distortion, but no idea about it. > Debris rocks look daft on 1:1000 plans. Thye look OK on some of the 1:200 > maps martinS showed me. This may be rectifiable by using the base-scale as > well as scale options, but I haven't yet got both the rocks and the legend > to look sensible. This is a problem of map symbol metapost definition. It will certainly be improved. > When you insert an area it is always 'water' not the last area you inserted. The line type gets defaulted to whatever you set the area to last time. This is a bug. > When you start a line or area and don't add anything to it you end up with an empty entry in the file. It would be smart to tidy these up. OK, I can do it when saving the file. > What is difference between floor-step and pit? I think, that pit is big floor-step, which can not be passed without equipement (rope, ladder). > Button for 'invisible', indeed a list of available subtypes in general would > be useful. I've found it very easy to mis-spell '-subtype invisible', and > having a list would save you needing to know which ones were available. OK, but again - it will take some time. > Why do newscraps go in at the top of the file, not bottom of file? This > results in scraps being in reverse order in the file. I'd naturaly expect it > to be the other way round. No problem. No idea, why is it so. > After creating the first scrap the cursor is left at a position such that if you enter any lines/points they end up outside a scrap. This should not be true in the newest version :) But I will check it. > 0.3.3 > > keys needed: > scroll up/down in side panel (pageup/down?) > scroll up/down in file commands window (shift pageup/down?) OK > Shortcut for insert area is needed _very badly_. having to switch between > the 'insert area' and 'insert scrap' action is just not good enough as an > interface. > insert area ctrl-A > insert scrap ctrl-S I usually use Edit->Insert->Area/Scrap. Alt-E+I+A on Windows. But I will add some shortcats. > Shortcuts needed to select common types: > wall > rock-border > rock-edge > pit > floor-step That's true. > A very useful thing to be able to do would be right-clicking on an item on the map and > selecting a point or line type. > > Making the point type selector taller so that you don't need to page up > _twice_ to get from 'wall' to 'border'. No problem. > some way to select a whole load of lines and move them to a new scrap. This would need some interface. I will think about it. > (present since at least 0.3.1 - still in 0.3.5) > If entering a line then use ctrl-D to abandon it, one char disappears from > current text field (eg pillar becomes illar, contour becomes ontour or > cntour (depending on cursor position) This doeas not happen on Win/Mac. I have to check on my Linux. It seems, that text control has mapped "Ctrl+D" to backspace. I can try to remove it. > prone to crashing - still present in 0.3.5. Need to test with tcltk > recompiled without thread support. OK, it is a lot of things, but some of them are easy to implement. I will update TODO list and we will see. Thanks for your feedback, S. Subject: Re: General note and suggestions From: Wookey Date: Mon, 10 Jan 2005 11:46:11 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-10 09:28 +0100]: >>> >It is very hard to tell that you have loaded the wrong thconfig file. >>> >Some sensibe error like 'cannot find foo' would help. >>> >e.g: >>> >My data is in subdir 'bluemoon' >>> >load thconfig from dir above (soundriver) >>> >load bmb1.th2 from bluemoon dir >>> >hit compile - gives 'error' but doesn't show what error. >>> >run 'therion' in the bluemoon dir and things are fine (of course). > >> >> This sounds strange. Therion is allways started from dir, at which >> current thconfig file is located. You may not compile, unless some >> config-file is loaded (or you can? I have to check). Ah, OK. So I thought the problem was that it couldn't find file, but what you are saying is that the .th2 files loaded is irrelevant, and doing 'compile' just runs wahtever the thconfig file says? Yes, at that time the soundriver thconfig file probably did not build. OK, so it works, and I revise my bug report to say we need to make clear that 'compile' does whatever the thconfig file does, and _does_not_ compile the file loaded in the map-editor (if it is not mentioned). This is a bit of a problem if you loaded the wrong thconfig file (as I did above), but I'm not sure what should be done about it. Maybe a warning about 'unused file in map editor - is that what you wanted?'? >> In any case, the compilation process needs to be changed. I am preparing >> new arrangement, but it will take some time. It does? I don't have a particular problem with it at the moment. >>> >inserting line points happens _after_ the current point >>> >inserting file entries happens _before_ the current line > >> >> This I think is natural. If you draw something, it should overlap things >> that were drawn previously. Example: firstly you draw rock-border and >> than rock-edge. I hadn't realised this was necessary. I agree it is natural to draw things so that the last-drawn things covers those drawn before. I think it would also be natural that the last thing in the file was drawn last, but it seems that part is the other way round, so we write the file 'backwards' too. :-) It seems to me that this is exposing therion internals in the interface more than is necessary. Presumably it could be done so that each new item went on the end of the list and the items were rendered so that the last one ended up 'on top'? However this is perhaps a very large change in the internals with only a small gain for users. I can live with it, but I do think it adds to the things that make therion confusing to use. But if we just explain about the ordering (especially for rocks - what else does it affect?), that will be enough to let people use it. >>> >inserting scrap happens at the start of the file >>> >this is confusing. > >> >> OK, I can change it that new scraps will be inserted before current scrap. after :-) >>> >Check to tell you you are entering line outside a scrap would be good. > >> >> OK, but I hate error windows, I have to click OK every time. Would a >> beep be enought? A beep and a message in the status area (where it says 'select object', 'drawing line', etc). >>> >Splitting lines that are part of areas is tricky. Does label get removed > >> >from both halves of line? >> >> Yes. You need to copy the label and paste it into part of line you wish to. In the long term I think therion should try to keep the label on the 'correct' half of the line - it should be able to determine that most of the time, but I can see that this is tricky. >>> >What is difference between floor-step and pit? > >> >> I think, that pit is big floor-step, which can not be passed without >> equipement (rope, ladder). OK - but they look exactly the same in the UIS symbol set. I actually want to use the 'border' type line for floor-step. I will have to try to fine-tune my output,one thing I have not yet messed with. >>> >After creating the first scrap the cursor is left at a position such that >>> >if you enter any lines/points they end up outside a scrap. > >> >> This should not be true in the newest version :) But I will check it. I think you are right and this is fixed in 0.3.5 >> I usually use Edit->Insert->Area/Scrap. Alt-E+I+A on Windows. But I will >> add some shortcats. I had not noticed that - I got used to esing entirely the right-hand pane interface. That is easier. >> OK, it is a lot of things, but some of them are easy to implement. I >> will update TODO list and we will see. Of course I am not expecting most of these to happen immediately :-) But it is important to record the things that annoy me, before I get used to them and forget that they are a problem when starting out. I'm very happy to provide feedback. Despite all my complaining, I think therion is very good, or at least will be good one day when it is a bit more finished. :-) The biggest problem at the moment is error feedback from metafont-level problems, as disucussed with martinB. That is what keeps getting me stuck so I have to ask for help. 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: General note and suggestions From: Stacho Mudrak Date: Mon, 10 Jan 2005 14:21:59 +0100 To: therion@speleo.sk Wookey wrote: > Ah, OK. So I thought the problem was that it couldn't find file, but what > you are saying is that the .th2 files loaded is irrelevant, and doing > 'compile' just runs wahtever the thconfig file says? Exactly. > the file loaded in the map-editor (if it is not mentioned). This is a bit of > a problem if you loaded the wrong thconfig file (as I did above), but I'm > not sure what should be done about it. Maybe a warning about 'unused file in > map editor - is that what you wanted?'? May be. In any case, if you know what happens, than it is not so bad error. >> In any case, the compilation process needs to be changed. I am preparing new arrangement, but it will take some time. > > > It does? I don't have a particular problem with it at the moment. OK, I would like to have editor of configuration files in the therion text editor (I think this is more correct). I have also added checking of time-stamps in text and map editor (to avoid problems of using external editors), but I was not able to do it in compiler (this text editor is not standard). But I am only thinking about it, I am working on different things. >>> inserting line points happens _after_ the current point >>> inserting file entries happens _before_ the current line > > > However this is perhaps a very large change in the internals with only a > small gain for users. I can live with it, but I do think it adds to the > things that make therion confusing to use. OK, in the 0.3.5 version, symbols should never be inserted outside of scrap just by mistake. With all symbols with exception of rock-border and edges (and stations in extended-elevation), you do not need to take care of their order. So probably users will not have huge problems in the future. > But if we just explain about the ordering (especially for rocks - what else > does it affect?), that will be enough to let people use it. I think also. Somebody should write it down to tips and tricks :) >> OK, I can change it that new scraps will be inserted before current scrap. > > > after :-) OK after or if it will be too difficult, at the end of file. >>> Check to tell you you are entering line outside a scrap would be good. >> >> >> OK, but I hate error windows, I have to click OK every time. Would a beep be enought? > > > > A beep and a message in the status area (where it says 'select object', > 'drawing line', etc). OK > OK - but they look exactly the same in the UIS symbol set. I actually want > to use the 'border' type line for floor-step. I will have to try to > fine-tune my output,one thing I have not yet messed with. try following two lines in your layout: code metapost let l_floorstep = l_border_visible_SKBB; > But it is important to record the things that annoy me, before I get used to > them and forget that they are a problem when starting out. Yes. I will translate TODO.S file into english a little bit :) . > I'm very happy to provide feedback. Despite all my complaining, I think > therion is very good, or at least will be good one day when it is a bit more > finished. :-) Thanks, S. Subject: Re: General note and suggestions From: Wookey Date: Mon, 10 Jan 2005 14:53:38 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-10 14:21 +0100]: >> Wookey wrote: >> >> May be. In any case, if you know what happens, than it is not so bad error. This is true of a number of things in Therion :-) >>>> >>In any case, the compilation process needs to be changed. I am preparing >>>> >>new arrangement, but it will take some time. >> >>> > >>> >It does? I don't have a particular problem with it at the moment. > >> >> OK, I would like to have editor of configuration files in the therion >> text editor (I think this is more correct). OK, yes I see. I agree. >> I have also added checking >> of time-stamps in text and map editor (to avoid problems of using >> external editors), great (I have been careful recently and have not accidentally wasted hours of work for a while :-) >>>> >>OK, I can change it that new scraps will be inserted before current scrap. >> >>> > >>> >after :-) > >> >> OK after or if it will be too difficult, at the end of file. Oh I see. I thought you had just made a typo above, but you were thinking of adding a new scrap immediately before the current scrap. That is more-or less what currently happens, although I agree, not exactly the same. My thought was that each one should go at the end of the file, as the 'natural way of doing things'. Although you could argue that if each linegoes in at the beginning of the list, then each scrap should also go in at the beginning of the list, for consistency? (I'd like them both to go on the end of the list, ecause that is how 'most things' normally work.) >>> >OK - but they look exactly the same in the UIS symbol set. I actually want >>> >to use the 'border' type line for floor-step. I will have to try to >>> >fine-tune my output,one thing I have not yet messed with. > >> >> try following two lines in your layout: >> >> code metapost >> let l_floorstep = l_border_visible_SKBB; aha - thanx. 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: Wed, 5 Jan 2005 22:31:44 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> 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'll start with easier problems. The problem in soundriver3_s1 was really tricky. Step by step description: *** uncommented soundrivercrab_s1: I got an MetaPost error "! Paths 6 and 5 don't intersect." It's always related to areas so I used "search & select" in the map area to find all areas. There was only one area (line 6 in File commands). I looked to Command preview window to see the definition and tried to locate all area border lines in the scrap. There was one line too much (l26-1164-70), which I deleted in Area control. *** uncommented soundriver2_s1: I got an error: ----- l_flowstone->...as>dlzka+(mojkrok/3);t1:=t2;endfor ; l.5074 )) ; The `angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. ----- The first error line gives the name of symbol in which the error ocured (l_flowstone) with a piece of its definition (which is not interesting now) and the second line gives a line number in the metapost file (created from all scraps) where the error ocurred and the text on that line. I knew that problem was in some line flowstone symbol so I used "search & select" to find all "line flowstone" occurences, and checked the definition in the "Command preview". Fortunately already the first flowstone line had duplicated point 703.0 793.0 703.0 793.0 I deleted it in Line control->Edit line->Delete point *** uncommented soundriver3_s1: Similar error ----- l_arrow->...d(angle(direction.infinity.of(EXPR0))- 90)shifted(point.infinity.... l.5728 ),2) ; The `angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. ----- As before I searched for the given symbol (line arrow): search & select line arrow (Find first, Find next, ...) and watched the Command preview window to see the definition. I suspected that problematic is line 24 in the File commands window: 363.0 573.5 363.0 573.5 317.0 604.5 295.0 642.5 with the control point of bezier line equal to previous point. After playing a bit with control points and even deleting the line the problem remained. I couldn't imagine which arrow casues problems so I had to identify it acoording to the line number given in MP error. I run therion in debugging mode (-d argument), opened the file data.mp in the $TEMP/thTMPDIR directory and jumped to line 5728. The problem with the file data.mp is that it doesn't contain original coordinates from th2 files so I couldn't identify the arrow using coordinates. I counted how many arrows are in the scrap containing line 5728 before the arrow ending on line 5728. Our arrow was the second in this scrap. Metapost file has reverse order of symbols (in order to display first object in the th2 file on top) so the final result is that problematic arrow is last-but-one in the file, i.e. line 23 in the File commands window. There is actually nothing wrong with that arrow -- that is the reason why it took so long to find it :) It has the last control point identical with the last point, which is perfectly acceptable in metapost. Unfortunately there is some bug in the arrow definition, which doesn't allow this. I hope it will be possible to fix it. In the meantime you may change the line either to a straight segment (no control points) or add a control point different from the endpoint. Martin Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Wed, 5 Jan 2005 22:44:40 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> 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. There is a problem that therion does some calculations itself and some lets to MetaPost. When the scraps are joined, therion has no idea if the border is intersecting itself. When MetaPost examines the border, it's too late for changing the scrap distortion -- it may only give a warning. >> 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 It can't be just ignored, because metapost needs non-intersecting outline to determine the interior of scrap correctly. >> and therion could adjust its own line to compensate? Is that practical? It can't right now -- the intersection is detected only in metapost. We would have to implement the algorithm in therion, which would be not trivial. Martin Subject: Re: [therion] Re: Help - my cave is inside-out From: "Martin Budaj" Date: Wed, 5 Jan 2005 23:42:08 +0100 (CET) To: therion@speleo.sk Wookey wrote: >>>> 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. The only information we can give here is the scrap name. There is no way how to find out in MetaPost where exactly the closed path intersects itself :-(( >> 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. I think it's doable to give a line number in th2 file where the error occures. It would be perhaps possible to also identify area border lines which don't intersect. >> How did you find the above problem. If I understood the process you used >> to >> find this it might help me next time. I got this error (uncorrectly determined interior of the scrap) long time ago in Dead Bats Cave map. There was some strange clipping by the scrap border, which I could't explain. In that time there was no MP warning, no map colouring. I don't remember exactly but it took quite long till i identified that the problem is in the border and than what is wrong with the border. After reading thoroughly the apprpriate chapter of the Metafont book I knew that problem is in the loop -- but even than I couldn't find any -- so small it was, in fact very similar to yours. I added the MP warning to point to this problem. When I see it now, I first check scrap ends if something could cause the problem. The biggest problem is if the loop is introduced only after morphing the scrap ends before joining scraps. I can only recommend to move control point in the last bezier arc of wall just before the scrap end, run therion, undo the change by pressing Ctrl+Z and repeat with other walls until the problem remains. The loop may occur also in the middle of the wall, but it should be visible, at least in 400% zoom. I'm sorry that there is no cleverer algorithm to find the loop :( Martin Subject: Re: Help - my cave is inside-out From: Wookey Date: Thu, 6 Jan 2005 00:06:31 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-05 23:42 +0100]: >> Wookey wrote: > >>>> >> Warning: scrap outline intersects itself in bmb3_s3@fake >> >>> > 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. > >> >> I think it's doable to give a line number in th2 file where the error >> occures. It would be perhaps possible to also identify area border lines >> which don't intersect. That would be a great improvement I think, although if it sometimes ends up suggesting the wrong line then that will cause some extra confusion. >> I got this error (uncorrectly determined interior of the scrap) long time >> ago in Dead Bats Cave map. >> I added the MP warning to point to this problem. When I see it now, I >> first check scrap ends if something could cause the problem. OK. Having the metafont error suggest possible causes might be good (and probably removing some of the slovakian variable-names stuff which doesn't help anyone except maybe you), so that the error makes more sense to a normal user. >> I'm sorry that there is no cleverer algorithm to find the loop :( OK, well for now the best hing is to use these examples I have (unfortunately) produced to demonstrate likely problems and solution, and diagnostics. Your reply explaining how you found my errors is exactly what people need in order to learn therion-fu, so thanx very much for that. More for someone to put in the FAQ. MartinS can you do that again (with the pictures and everything) and I'll tidy it up? I'll get round to it eventually but I have survey-drawing and work deadlines this month _and_ my engine blew up on christmas day so I have to spend a lot of time under the car this month too, so time is limited. 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: Thu, 6 Jan 2005 02:50:12 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-05 22:31 +0100]: >> I'll start with easier problems. The problem in soundriver3_s1 was really >> tricky. Step by step description: >> >> *** uncommented soundrivercrab_s1: >> >> I got an MetaPost error "! Paths 6 and 5 don't intersect." >> >> It's always related to areas so I used "search & select" in the map area >> to find all areas. There was only one area (line 6 in File commands). OK- at this point if I select the area then 3 of the lines surrounding the area are highlighted, but not the others? Why is this? Is it a clue to the problem or is the area highlighting just broken? Being able to click on the lines in the area control and have them highlighted would make it much quicker to check an area. (at the oment you have to search for their names, and after the first 3 you need to keep scrolling the preview window). Someone add this to the wishlist :-) >> I >> looked to Command preview window to see the definition and tried to locate >> all area border lines in the scrap. There was one line too much >> (l26-1164-70), which I deleted in Area control. OK - fixed :-) BTW when I view therion-produced pdf files in xpdf I get this a lot: Error (181503): Name token too long Error (181523): Dictionary key must be a name object The rendering looks OK so far as I can see, but maybe some element is missing. Is this an xpdf problem or something that should be fixed in therion? Do you need an example file? (this was the soundriver.pdf I sent with the above fix in) >> *** uncommented soundriver2_s1: >> >> I got an error: >> >> ----- >> l_flowstone->...as>dlzka+(mojkrok/3);t1:=t2;endfor >> The first error line gives the name of symbol aha - that's useful to know. fixed. >> *** uncommented soundriver3_s1: >> >> Similar error >> >> ----- >> l_arrow->...d(angle(direction.infinity.of(EXPR0))- >> 90)shifted(point.infinity.... >> l.5728 ),2) >> ; >> The `angle' between two identical points is undefined. >> I'm zeroing this one. Proceed, with fingers crossed. >> ----- >> >> As before I searched for the given symbol (line arrow): search & select >> line arrow (Find first, Find next, ...) and watched the Command preview >> window to see the definition. I suspected that problematic is line 24 in >> the File commands window: >> 363.0 573.5 >> 363.0 573.5 317.0 604.5 295.0 642.5 >> with the control point of bezier line equal to previous point. After >> playing a bit with control points and even deleting the line the problem >> remained. OK - in fact this line should be a contour not an arrow. >> I couldn't imagine which arrow casues problems so I had to >> identify it acoording to the line number given in MP error. >> >> Unfortunately >> there is some bug in the arrow definition, which doesn't allow this. I >> hope it will be possible to fix it. In the meantime you may change the >> line either to a straight segment (no control points) or add a control >> point different from the endpoint. OK thanx - I don't think I'd have worked that out myself in a month! So I've fixed all that and added some joins between the segments, and that all works reasonably well, but I have a few small problems remaining: Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. There is an 'outline crosses itself' error in soundriver_pooh which I thought might be affecting it, but removing that scrap makes no difference, and neither does reversing the line. Why is this pillar broken? Also there are a couple of places where there are 'gaps' in the grey background. The most obvious example is the large chamber in the middle is soundriver2_s2 (with lots of boulders). The main chamber has a RH wall which is in the 'middle' of 3 walls. The rightmost wall is the RH wall of a lower passage, formed by the large pile of rocks in the middle separating the upper and lower parts for 30m or so. What is the 'therion way' to draw something like this? Just use a border for the central line? Or split the lower portion into a very small scrap, I suppose? And there is a similar problem on the other side of the chamber (where a steep ramp goes up on the left) BTW - I hope you looked at the scale bar and were impressed with the size of the passage we found :-) All that was found on two pretty amazing trips! 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: Thu, 6 Jan 2005 11:19:37 +0100 (CET) To: therion@speleo.sk Wookey wrote: >>>> It's always related to areas so I used "search & select" in the map area >>>> to find all areas. There was only one area (line 6 in File commands). > >> >> OK- at this point if I select the area then 3 of the lines surrounding the >> area are highlighted, but not the others? Why is this? Is it a clue to the >> problem or is the area highlighting just broken? It's perhaps broken -- but that is a question for Stacho, who is on holidays now. >> Being able to click on the lines in the area control and have them >> highlighted would make it much quicker to check an area. (at the oment you >> have to search for their names, and after the first 3 you need to keep >> scrolling the preview window). Someone add this to the wishlist :-) Agree. >> BTW when I view therion-produced pdf files in xpdf I get this a lot: >> Error (181503): Name token too long >> Error (181523): Dictionary key must be a name object >> >> The rendering looks OK so far as I can see, but maybe some element is >> missing. >> >> Is this an xpdf problem or something that should be fixed in therion? Do >> you need an example file? (this was the soundriver.pdf I sent with the >> above >> fix in) I'll look at this. Recently we have had problems with Acrobat reader 7.0, which doesn't open files created on other platform (e.g. linux files on windows) and complains that file is dameged. There is no problem with 6.0 and older versions. >> So I've fixed all that and added some joins between the segments, and that >> all works reasonably well, but I have a few small problems remaining: >> >> >> Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. >> There >> is an 'outline crosses itself' error in soundriver_pooh which I thought >> might be affecting it, but removing that scrap makes no difference, and >> neither does reversing the line. Why is this pillar broken? In my file is line 81 only a segment of the wall - I can't imagine where the pillar should be... >> Also there are a couple of places where there are 'gaps' in the grey >> background. The most obvious example is the large chamber in the middle is >> soundriver2_s2 (with lots of boulders). The main chamber has a RH wall >> which >> is in the 'middle' of 3 walls. The rightmost wall is the RH wall of a >> lower >> passage, formed by the large pile of rocks in the middle separating the >> upper >> and lower parts for 30m or so. What is the 'therion way' to draw something >> like this? Just use a border for the central line? Or split the lower >> portion into a very small scrap, I suppose? And there is a similar problem >> on the other side of the chamber (where a steep ramp goes up on the left) The separate scrap is the best solution. The other is to split the inner wall and set the 'outline in' option as displayed in the attached picture. The exact rule is that each line forming the outer border of the scrap has to have 'outline out' option (walls have this by default), each line forming inner pillars 'outline in' option, and all other lines (even walls lying inside of scrap) 'outline none' option. For all walls which shouldn't form the scrap border you have to set 'outline none' option. See the second attachment to see how to specify this. >> BTW - I hope you looked at the scale bar and were impressed with the size >> of >> the passage we found :-) All that was found on two pretty amazing trips! Of course we did :) it's really great. Martin Subject: Re: Help - my cave is inside-out From: Wookey Date: Sat, 8 Jan 2005 00:53:51 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-06 11:19 +0100]: [I wrote this a day or two ago and forgot to send it.] >> Wookey wrote: > >>> > Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. >>> > There >>> > is an 'outline crosses itself' error in soundriver_pooh which I thought >>> > might be affecting it, but removing that scrap makes no difference, and >>> > neither does reversing the line. Why is this pillar broken? > >> >> In my file is line 81 only a segment of the wall - I can't imagine where >> the pillar should be... Sorry I don't mean line 81 I mean command list no 81 in map editor. >>> > Also there are a couple of places where there are 'gaps' in the grey >>> > background. The most obvious example is the large chamber in the middle is >>> > soundriver2_s2 (with lots of boulders). >> The separate scrap is the best solution. The other is to split the inner >> wall and set the 'outline in' option as displayed in the attached picture. >> >> The exact rule is that each line forming the outer border of the scrap has >> to have 'outline out' option (walls have this by default), each line >> forming inner pillars 'outline in' option, and all other lines (even walls >> lying inside of scrap) 'outline none' option. For all walls which >> shouldn't form the scrap border you have to set 'outline none' option. See >> the second attachment to see how to specify this. OK - another useful answer - that one might count as a 'tip and trick'. (we could write a lot of tips and tricks about scraps - where to split them, how big to make them, to do a check build after adding an area, not to make control points too close to the end lines and so on). 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: Sat, 8 Jan 2005 14:55:37 +0100 (CET) To: therion@speleo.sk Wookey wrote: >>>>> > Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. >>>>> > There >>>>> > is an 'outline crosses itself' error in soundriver_pooh which I >> >>>> thought >> >>>>> > might be affecting it, but removing that scrap makes no difference, >> >>>> and >> >>>>> > neither does reversing the line. Why is this pillar broken? >> >>>> >>>> In my file is line 81 only a segment of the wall - I can't imagine where >>>> the pillar should be... > >> >> Sorry I don't mean line 81 I mean command list no 81 in map editor. I meant also line 81 in the command list of the map editor... Is the file the same? Martin Subject: piles of rocks From: Wookey Date: Fri, 7 Jan 2005 23:50:05 +0000 To: Therion List I need to understand how to draw largepiles of boulders. This pic: http://trilogy-gw.aleph1.co.uk/~wookey/files/1.png shows a chamber which has a 20m-high pile of boulders in it, highest in the middle. I saw in one of Martin Sluka's pics that therion can draw rocks which will obscure rocks lying below - ie they arefilled objects, not just lines. This is good - and more realistic, but it means that the order things are drawn matters. However in the example shown above, the overlying,overlapping rock,does not obscure the one below. So - how do I get the effect Martin S had - what are the rules? * Which order do rocks need to be drawn in? hiest first,or lowest first? * How do I make them obscure lower rocks - just make a rock-bordre that is a closed loop? or something cleverer? thanx 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] piles of rocks From: Martin Sluka Date: Sat, 8 Jan 2005 10:55:37 +0100 To: therion@speleo.sk At 23:50 +0000 7.1.2005, Wookey wrote: ******************************************* > However in the example shown above, the overlying,overlapping rock,does > not obscure the one below. So - how do I get the effect Martin S had - what > are the rules? There is no rule for it - I just drew blocks and checked if the small yellow tick is outside of block. This tick indicates allways the "free space" - inside the passage, inside of chimney or pit, higher part of overhang or ceiling step, lower part of floor step or conture, outside of block. > * Which order do rocks need to be drawn in? hiest first,or lowest first? Normal, from bottom to top. Martin -- Subject: Re: [therion] piles of rocks From: "Martin Budaj" Date: Sat, 8 Jan 2005 14:59:25 +0100 (CET) To: therion@speleo.sk Martin Sluka wrote: >> At 23:50 +0000 7.1.2005, Wookey wrote: >> ******************************************* >> > >>>>However in the example shown above, the overlying,overlapping rock,does >>>>not obscure the one below. So - how do I get the effect Martin S had - >>>> what >>>>are the rules? > >> >> There is no rule for it - I just drew blocks and checked if the small >> yellow tick is outside of block. This tick indicates allways the >> "free space" - inside the passage, inside of chimney or pit, higher >> part of overhang or ceiling step, lower part of floor step or >> conture, outside of block. In this case line orientation doesn't matter -- iff the line is closed, the rock is filled and hides everything below. Martin Subject: arranging files for big systems From: Wookey Date: Sat, 8 Jan 2005 01:13:02 +0000 To: Therion List OK - now that I have a few non-trivial chunks of therion data to bring together I have re-arranged everything in a big-cave way. This has of course caused some problems. I am documenting them here. What I want to be able to do is produce a whole area map as well as smaller maps of each cave in the area, and maybe parts of a cave, and keep related data together,but only have it appear in one place. I know how to do this in survex, using a directory for each major cave or area. That contains an 'overview file' that is something like: *survey terikan *equate elevator.pt3.18b evening.25 *include elevator.svx *equate river.40 goon.0 *inculde goon.svx ... *end terikan so connections between surveys are here, but not connections within surveys (they are inside each .svx sub-file), and also connections (equates) are grouped together with the relevant files. So, I have an overall file for terikan in therion form but if I try to use the above structure - i.e like this: survey terikan map endmap input elevator.th2 input goon.th2 ... join centreline equate 0@goon 40@river input goon.th equate 25@evening 18b@pt3.elevator input elevator.th endcentreline endsurvey terikan then I get an error: therion: error -- terikan/terikan.th [72] -- not enough data readings at the first line that is an 'input .th' The only way I can get it to work is by moving all the equates into one block, wrapped in a centreline/endcentreline command But for a big system this gives you a huge list of equates in one place and ahuge list of inputs below - it'smuch nicer to have the equates in the file next to the relevant inputs IMHO. So questions: 1) is my preferred arrangement possible/permitted in therion? How do would one do it? 2) Why do I get the error 'not enough data readings'? That seems to have very little to do with the actual problem - it took me some time to work out how to make it go away. I have more questions about arranging scraps and submaps too, but those can wait till another mail. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: [therion] arranging files for big systems From: "Martin Budaj" Date: Sat, 8 Jan 2005 14:49:06 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> So, I have an overall file for terikan in therion form but if I try to use >> the above structure - i.e like this: >> >> survey terikan >> map >> >> endmap >> >> input elevator.th2 >> input goon.th2 >> ... >> >> join >> >> centreline >> equate 0@goon 40@river >> input goon.th >> >> equate 25@evening 18b@pt3.elevator >> input elevator.th >> >> endcentreline >> endsurvey terikan >> >> then I get an error: >> therion: error -- terikan/terikan.th [72] -- not enough data readings >> at the first line that is an 'input .th' You should input files outside of the centreline command. You got the error message because therion considered 'input foo.th' be the station names without instrument readings. >> The only way I can get it to work is by moving all the equates into one >> block, wrapped in a centreline/endcentreline command You could also use centreline equate 0@goon 40@river endcentreline input goon.th centreline equate 25@evening 18b@pt3.elevator endcentreline input elevator.th which is not particularly nice :( We considered to allow the equate command outside of centerline, which would simplify the syntax to equate 0@goon 40@river input goon.th equate 25@evening 18b@pt3.elevator input elevator.th It may be perhaps introduced in the future. Martin Subject: Re: arranging files for big systems From: Wookey Date: Mon, 10 Jan 2005 03:07:40 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-08 14:49 +0100]: >> Wookey wrote: > >>> > So, I have an overall file for terikan in therion form >> You should input files outside of the centreline command. >> You could also use >> >> centreline >> equate 0@goon 40@river >> endcentreline >> input goon.th Right. As you say, the syntax is a bit ugly. OK, so with the 'break' option I now have all my data arranged and read in in a big structure ready ford rawing the restof the cave. I should now have the same set-up as before, but within a larger structure - notjust the soundriver/elevator section. However with the same scraps and joins as before, just more centreline data and the new context,trying to process gives: ------------------ >>>> (0,0) ! Division by zero. endgroup ) mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) ; ...ime.cas.of(path);mark_((path),t,0.2u) ;cas:=cas+mojkrok;exitif.c... l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor ;pickup.PenC;thdraw(EXPR0); l.4670 )) ; You're trying to divide the quantity shown above the error message by zero. I'm going to divide it by one instead. ------------------ Any clues as to what's wrong there? Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- 38 which seems very odd asit looks perfectly valid to me.... The tarball is at http://trilogy-gw.aleph1.co.uk/~wookey/files/terikan.tgz right. bedtime Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: arranging files for big systems From: Stacho Mudrak Date: Mon, 10 Jan 2005 08:47:45 +0100 To: therion@speleo.sk Wookey wrote: >> centreline >> equate 0@goon 40@river >> endcentreline >> input goon.th > > > > Right. As you say, the syntax is a bit ugly. Some time ago, we wanted to enhance JOIN command to work also for survey stations (like it works for drawn scraps, lines or points). This way centreline equate 0@goon 40@river endcentreline would be replaced by join 0@goon 40@river Another possibility is to add separate equate command. I am not sure, which way is more correct. S. Subject: [therion] Re: arranging files for big systems From: Martin Sluka Date: Mon, 10 Jan 2005 19:32:28 +0100 To: therion@speleo.sk krok = step, interval cas = time dlzka = length mojkrok b= my step, my interval :) MS. -- Subject: Re: arranging files for big systems From: Wookey Date: Tue, 11 Jan 2005 01:06:54 +0000 To: therion@speleo.sk +++ Wookey [05-01-10 03:07 +0000]: >> +++ Martin Budaj [05-01-08 14:49 +0100]: > >>> > Wookey wrote: >> >>>> > > So, I have an overall file for terikan in therion form > >> >> However with the same scraps and joins as before, just more centreline data >> and the new context,trying to process gives: >> >> ------------------ > >>>> >> (0,0) > >> ! Division by zero. >> >> endgroup >> >> ) >> mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) >> ; >> ...ime.cas.of(path);mark_((path),t,0.2u) >> ;cas:=cas+mojkrok;exitif.c... >> >> l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor >> ;pickup.PenC;thdraw(EXPR0); >> l.4670 )) >> ; >> You're trying to divide the quantity shown above the error >> message by zero. I'm going to divide it by one instead. >> ------------------ >> >> Any clues as to what's wrong there? OK -I took bits in and out until I worked which bit is causing the problem: If I comment out this join then it works OK. join soundrivercrab_s1 soundriver2_s1 What is odd was that this join was OK when the centreline dataset was smaller. Nothing should have changed in this area. The map still looks OK. I am a bit perplexed. Still,now it is compiling again I can get on with drawing some more and comeback to this. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: arranging files for big systems From: Wookey Date: Fri, 14 Jan 2005 03:51:35 +0000 To: therion@speleo.sk Has anyone (that probably means you martinB) got any idea what the problem below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't. And I still have no idea about this either: Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- 38 +++ Wookey [05-01-11 01:06 +0000]: >> +++ Wookey [05-01-10 03:07 +0000]: > >>> > +++ Martin Budaj [05-01-08 14:49 +0100]: >> >>>> > > Wookey wrote: >>> >>>>> > > > So, I have an overall file for terikan in therion form >> >>> > >>> > However with the same scraps and joins as before, just more centreline data >>> > and the new context,trying to process gives: >>> > >>> > ------------------ >> >>>>> > >> (0,0) >> >>> > ! Division by zero. >>> > >>> > endgroup >>> > >>> > ) >>> > mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) >>> > ; >>> > ...ime.cas.of(path);mark_((path),t,0.2u) >>> > ;cas:=cas+mojkrok;exitif.c... >>> > >>> > l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor >>> > ;pickup.PenC;thdraw(EXPR0); >>> > l.4670 )) >>> > ; >>> > You're trying to divide the quantity shown above the error >>> > message by zero. I'm going to divide it by one instead. >>> > ------------------ >>> > >>> > Any clues as to what's wrong there? > >> >> OK -I took bits in and out until I worked which bit is causing the problem: >> If I comment out this join then it works OK. >> join soundrivercrab_s1 soundriver2_s1 >> >> What is odd was that this join was OK when the centreline dataset was >> smaller. Nothing should have changed in this area. The map still looks OK. >> >> I am a bit perplexed. Still,now it is compiling again I can get on with >> drawing some more and comeback to this. >> >> Wookey >> -- >> Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 >> work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: [therion] Re: arranging files for big systems From: "Martin Budaj" Date: Fri, 14 Jan 2005 08:13:33 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> Has anyone (that probably means you martinB) got any idea what the problem >> below is? Look back up the thread for the URL of the tarball. This join >> used to work, but now it doesn't. The file index.th specified in the thconfig file as the main data source is missing in the archive. Could you supply it? Martin Subject: Re: [therion] Re: arranging files for big systems From: Stacho Mudrak Date: Fri, 14 Jan 2005 08:17:42 +0100 To: therion@speleo.sk Wookey wrote: > Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- > 38 It is BUG in therion :) I will fix it. S. Subject: Re: arranging files for big systems From: Stacho Mudrak Date: Fri, 14 Jan 2005 08:23:01 +0100 To: therion@speleo.sk A question - my developement version reports errors when reading your LRUD data. What doeas 0+8 means? And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 at from-station and 5 at to-station? Regards, S. Wookey wrote: > Has anyone (that probably means you martinB) got any idea what the problem > below is? Look back up the thread for the URL of the tarball. This join used to work, but now it doesn't. > > And I still have no idea about this either: > > Also if I include the file 'grumble.th', then I get: therion: error -- terikan/grumble.th [19] -- bearing reading out of range -- > 38 > > > +++ Wookey [05-01-11 01:06 +0000]: > >> +++ Wookey [05-01-10 03:07 +0000]: >> >>> +++ Martin Budaj [05-01-08 14:49 +0100]: >>> >>>> Wookey wrote: >>>> >>>>> So, I have an overall file for terikan in therion form >>> >>> >>> However with the same scraps and joins as before, just more centreline data >>> and the new context,trying to process gives: >>> >>> ------------------ >>> >>>>> (0,0) >>> >>> >>> ! Division by zero. >>> endgroup >>> ) >>> mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) >>> ; >>> ...ime.cas.of(path);mark_((path),t,0.2u) >>> ;cas:=cas+mojkrok;exitif.c... >>> >>> l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor >>> ;pickup.PenC;thdraw(EXPR0); >>> l.4670 )) >>> ; >>> You're trying to divide the quantity shown above the error >>> message by zero. I'm going to divide it by one instead. >>> ------------------ >>> >>> Any clues as to what's wrong there? >> >> >> OK -I took bits in and out until I worked which bit is causing the problem: >> If I comment out this join then it works OK. >> join soundrivercrab_s1 soundriver2_s1 >> >> What is odd was that this join was OK when the centreline dataset was >> smaller. Nothing should have changed in this area. The map still looks OK. >> >> I am a bit perplexed. Still,now it is compiling again I can get on with >> drawing some more and comeback to this. >> >> Wookey >> -- >> Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 >> work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ > > > Wookey Subject: Re: arranging files for big systems From: Wookey Date: Fri, 14 Jan 2005 12:57:33 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-14 08:13 +0100]: >> Wookey wrote: > >>> > Has anyone (that probably means you martinB) got any idea what the problem >>> > below is? Look back up the thread for the URL of the tarball. This join >>> > used to work, but now it doesn't. > >> >> The file index.th specified in the thconfig file as the main data source >> is missing in the archive. Could you supply it? Sorry, it's currently fairly pointless :-) -------------- #overview file for terikan system input terikan/terikan.th #input bluemoon/bluemoon.th --------------- Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: arranging files for big systems From: Wookey Date: Fri, 14 Jan 2005 13:03:54 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-14 08:23 +0100]: >> A question - my developement version reports errors when reading your >> LRUD data. What doeas 0+8 means? >> >> And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 >> at from-station and 5 at to-station? Ah - I think both of those are notations for when there are two plausible/significant possible readings. e.g 0+8 could mean the point is on the wall, but there is 8m of bedding plane going off beyond, or keyhole passage where the point is on the wall of the canyon but the upper passage goes off 8m to the left. 1/5 could be two things: Either is has the same meaning but a different notation or it is means 1.5 and not been transliterated on data entry. Recording 'both' values like this is very useful when drawing up but of course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing centrelines that would be handy. Which file was it in? I'd have to check against the notes to be sure what the meaning was. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ Subject: Re: [therion] Re: arranging files for big systems From: Stacho Mudrak Date: Fri, 14 Jan 2005 14:29:31 +0100 To: therion@speleo.sk soundriver.th [281] I was just asking, because in the 0.3.6, specification of from/to dimension is allowed in non-interleaved data, but currently you have to insert two numbers in [] instead of one. E.g. data from to bearing clino tape up down left right 10 11 123 -10 20 4 5 [8 6] [2 4] where [8 6] means, that left wall is 8 meters from station 10 and 6 metres from station 11. There is possibility to add different separator than space (e.g. /), therefore I was asking. Regards, S. Wookey wrote: > +++ Stacho Mudrak [05-01-14 08:23 +0100]: > >> A question - my developement version reports errors when reading your LRUD data. What doeas 0+8 means? >> >> And I see, that in grumble.th, there are also fields 1/5. Does it mean 1 at from-station and 5 at to-station? > > > > Ah - I think both of those are notations for when there are two > plausible/significant possible readings. e.g 0+8 could mean the point is on > the wall, but there is 8m of bedding plane going off beyond, or keyhole > passage where the point is on the wall of the canyon but the upper passage > goes off 8m to the left. > > 1/5 could be two things: Either is has the same meaning but a > different notation or it is means 1.5 and not been transliterated on data > entry. > > Recording 'both' values like this is very useful when drawing up but of > course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing > centrelines that would be handy. > > Which file was it in? I'd have to check against the notes to be sure what > the meaning was. > > Wookey Subject: Re: [therion] Re: arranging files for big systems From: John Pybus Date: Fri, 14 Jan 2005 13:31:50 +0000 To: therion@speleo.sk Wookey wrote: > > Ah - I think both of those are notations for when there are two > plausible/significant possible readings. e.g 0+8 could mean the point is on > the wall, but there is 8m of bedding plane going off beyond, or keyhole > passage where the point is on the wall of the canyon but the upper passage > goes off 8m to the left. > > 1/5 could be two things: Either is has the same meaning but a > different notation or it is means 1.5 and not been transliterated on data > entry. > > Recording 'both' values like this is very useful when drawing up but of > course it is not a standard notation, and the software should probably take the 'bigger' number, although if it marked both when drawing > centrelines that would be handy. If therion (and/or survex) is going to support this useful concept[0] then we need to decide on a consistent syntax. I'd strongly recommend against using '/' as it's so commonly used as a more robust decimal point by surveyors, and would lead to a lot of the sort of confusion that Wookey's already in. The usual ',' and ';' sequencing operators are respectively the common european decimal point, and the survex comment, so are out too. I'd suggest one of '+', '&', ':' or '|', with a slight preference for '|'. For the record I currently record this type of thing as comments so is never interpreted by software, and I use no consistent syntax. John [0] Even if this is only to parse it then take the larger value, it still allows the data file to represent what was actually recorded in the cave without resorting to comments. Subject: Re: [therion] Re: arranging files for big systems From: "Martin Budaj" Date: Mon, 17 Jan 2005 09:30:35 +0100 (CET) To: therion@speleo.sk Wookey wrote: >>>>> > However with the same scraps and joins as before, just more centreline >> >>>> data >> >>>>> > and the new context,trying to process gives: >>>>> > >>>>> > ------------------ >>> >>>>>>> > >> (0,0) >>> >>>>> > ! Division by zero. >>>>> > >>>>> > endgroup >>>>> > >>>>> > ) >>>>> > mark_->...vector(thdir((EXPR0),(EXPR1))rotated90)) >>>>> > ; >>>>> > ...ime.cas.of(path);mark_((path),t,0.2u) >>>>> > ;cas:=cas+mojkrok;exitif.c... >>>>> > >>>>> > l_pit->...krok;exitif.cas>dlzka+(mojkrok/3);endfor >>>>> > ;pickup.PenC;thdraw(EXPR0); >>>>> > l.4670 )) >>>>> > ; >>>>> > You're trying to divide the quantity shown above the error >>>>> > message by zero. I'm going to divide it by one instead. >>>>> > ------------------ >>>>> > >>>>> > Any clues as to what's wrong there? >> >>>> >>>> OK -I took bits in and out until I worked which bit is causing the >>>> problem: >>>> If I comment out this join then it works OK. >>>> join soundrivercrab_s1 soundriver2_s1 >>>> >>>> What is odd was that this join was OK when the centreline dataset was >>>> smaller. Nothing should have changed in this area. The map still looks >>>> OK. The problem is the pit (line 72 in file commands) in scrap soundrivercrab_s1, which has duplicated last point (781.00 -53.00). I wonder how it could happen -- XTherion finishes the line when you click twice on the same point and doesn't insert the point twice. I have no idea why it is related to joining scraps. The problematic line is too far from the join to be influenced. This is perhaps question for Stacho. Anyway if you delete last duplicated point scrap join works fine. Martin. Subject: problem with staggered data format From: Wookey Date: Sat, 8 Jan 2005 02:53:30 +0000 To: Therion List I've got a file with data in like this: data normal station ignore ignore ignore ignore newline tape compass clino 1 6 6 20 1 12.6 179 -39 2 4 8 25 2 20.5 266 +04 3 4 4 3 2 # cairn 2 - - - - 22.6 114 -01 4 2 7+ 15 2 16.4 158 0.5 5 4 6 12 2 #cairn 18.3 230 -08 This goes wrong at the line 2 - - - - with the error: therion: error -- terikan/elevator.th [56] -- invalid gradient reading -- - Does the data need reformating to make therion understand or does therion just need fixing? 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] problem with staggered data format From: Olly Betts Date: Sat, 8 Jan 2005 03:23:41 +0000 To: Therion List On Sat, Jan 08, 2005 at 02:53:30AM +0000, Wookey wrote: >> I've got a file with data in like this: >> >> data normal station ignore ignore ignore ignore newline tape compass clino >> >> 1 6 6 20 1 >> 12.6 179 -39 >> 2 4 8 25 2 >> 20.5 266 +04 >> 3 4 4 3 2 # cairn >> >> 2 - - - - >> 22.6 114 -01 >> 4 2 7+ 15 2 >> 16.4 158 0.5 >> 5 4 6 12 2 #cairn >> 18.3 230 -08 >> >> This goes wrong at the line >> 2 - - - - >> with the error: >> therion: error -- terikan/elevator.th [56] -- invalid gradient reading -- - Perhaps it doesn't understand you've started a new "string" of readings? Although I'd probably expect "invalid compass reading" if it was trying to parse "2 - - - -" as "tape compass clino". Or something like "too many readings". Cheers, Olly Subject: Re: [therion] problem with staggered data format From: "Martin Budaj" Date: Sat, 8 Jan 2005 14:38:19 +0100 (CET) To: therion@speleo.sk Olly Betts wrote: >> On Sat, Jan 08, 2005 at 02:53:30AM +0000, Wookey wrote: > >>>> I've got a file with data in like this: >>>> >>>> data normal station ignore ignore ignore ignore newline tape compass >>>> clino >>>> >>>> 1 6 6 20 1 >>>> 12.6 179 -39 >>>> 2 4 8 25 2 >>>> 20.5 266 +04 >>>> 3 4 4 3 2 # cairn >>>> >>>> 2 - - - - >>>> 22.6 114 -01 ... >> Perhaps it doesn't understand you've started a new "string" of readings? Yes, you have to separate new branch using 'break' keyword. >> Although I'd probably expect "invalid compass reading" if it was trying >> to parse "2 - - - -" as "tape compass clino". Or something like "too >> many readings". A dash is valid compass reading for clino values ± 90 deg, so it was parsed as unspecified compass reading. Martin Subject: Re: problem with staggered data format From: Wookey Date: Mon, 10 Jan 2005 02:31:32 +0000 To: therion@speleo.sk +++ Martin Budaj [05-01-08 14:38 +0100]: >> Olly Betts wrote: > >>> > On Sat, Jan 08, 2005 at 02:53:30AM +0000, Wookey wrote: >> >>>> >> I've got a file with data in like this: >>>> >> >>>> >> data normal station ignore ignore ignore ignore newline tape compass >>>> >> clino >>>> >> >>>> >> 1 6 6 20 1 >>>> >> 12.6 179 -39 >>>> >> 2 4 8 25 2 >>>> >> 20.5 266 +04 >>>> >> 3 4 4 3 2 # cairn >>>> >> >>>> >> 2 - - - - >>>> >> 22.6 114 -01 > >> ... > >>> > Perhaps it doesn't understand you've started a new "string" of readings? > >> >> Yes, you have to separate new branch using 'break' keyword. aha - that's the clue I needed. Thanx. Ol - I'm collecting info on the conversion script so we can improve the various things that go wrong. It mostly works quite well apart from 'overview' files which include a lot of others - I'll mail you my notes 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: Compilation Problems... From: Thierry GONON Date: Mon, 10 Jan 2005 10:17:18 +0200 To: therion@speleo.sk Hello, I'm working on Mac OSX (previously working with Toporobot and intended to find another software, to compare...) and I've found Therion this week... So I've downloaded the sources to compile them, but during the make install procedure, the Terminal answered : I don't know what are the two --symbolic : file or directory?? Do I have to create them, as I do for the Therion and Xtherion directories?? Thank you very much, and enjoy caving!! Thierry GONON 2 Place de l'Eglise 01150 LAGNIEU FRANCE Subject: Re: [therion] Compilation Problems... From: Stacho Mudrak Date: Mon, 10 Jan 2005 09:41:32 +0100 To: therion@speleo.sk Installation is still a problem on MacOSX :( It depends a lot on the system version and version of Tcl/Tk. But installation is simple. All you need to do to install therion is to copy therion executable (file named therion in compilation directory) to the /usr/bin directory (you do not need to create symbolic link for it). When therion is copied, you can run xtherion following way. 1. Go to the therion compilation directory. 2. cd xtherion 3. wish ./xtherion This works on all systems. You can try to copy also xtherion to /usr/bin and run xtherion from anywhere, but on most systems it gives error. Hope this helps. If not, we will find other way :) Regrads, S. Thierry GONON wrote: > Hello, > > I'm working on Mac OSX (previously working with Toporobot and intended to find another software, to compare...) and I've found Therion this week... > So I've downloaded the sources to compile them, but during the /make install/ procedure, the Terminal answered : > > I don't know what are the two /--symbolic/ : file or directory?? Do I have to create them, as I do for the /Therion /and/ Xtherion/ directories?? > > Thank you very much, and enjoy caving!! > > Thierry GONON > 2 Place de l'Eglise > 01150 LAGNIEU > FRANCE > Subject: Re: [therion] Compilation Problems... From: Thierry GONON Date: Mon, 10 Jan 2005 11:51:54 +0200 To: therion@speleo.sk Thank you for your answer... But it still don't work!! My system is OSX 10.3.7 (last update) and I'm running Tcl/Tk8.4 I've copied the file as indicated, but when I run xtherion, here's the answer of the terminal : Application initialization failed: no display name and no $DISPLAY environment variable Error in startup script: invalid command name "frame" while executing "frame .def" (file "./xtherion" line 232) When I try trough X11, the result is : Error in startup script: can't find package BWidget while executing "package require BWidget" (file "./xtherion" line 672) I've successfully installed BWidget (in the /Library/Tcl folder, the global one and in my personnal Tcl folder)... Best regards Le 10 janv. 05, à 10:41, Stacho Mudrak a écrit : Installation is still a problem on MacOSX :( It depends a lot on the system version and version of Tcl/Tk. But installation is simple. All you need to do to install therion is to copy therion executable (file named therion in compilation directory) to the /usr/bin directory (you do not need to create symbolic link for it). When therion is copied, you can run xtherion following way. 1. Go to the therion compilation directory. 2. cd xtherion 3. wish ./xtherion This works on all systems. You can try to copy also xtherion to /usr/bin and run xtherion from anywhere, but on most systems it gives error. Hope this helps. If not, we will find other way :) Regrads, S. Thierry GONON wrote: Hello, I'm working on Mac OSX (previously working with Toporobot and intended to find another software, to compare...) and I've found Therion this week... So I've downloaded the sources to compile them, but during the /make install/ procedure, the Terminal answered : I don't know what are the two /--symbolic/ : file or directory?? Do I have to create them, as I do for the /Therion /and/ Xtherion/ directories?? Thank you very much, and enjoy caving!! Thierry GONON 2 Place de l'Eglise 01150 LAGNIEU FRANCE Subject: Re: [therion] Compilation Problems... From: Stacho Mudrak Date: Mon, 10 Jan 2005 11:03:58 +0100 To: therion@speleo.sk Thierry GONON wrote: > I've copied the file as indicated, but when I run /xtherion/, here's the answer of the terminal : > */Application initialization failed: no display name and no $DISPLAY environment variable > Error in startup script: invalid command name "frame" > while executing > "frame .def" > (file "./xtherion" line 232) This sounds strange. It looks like wish is not correctly installed. Did you use Apple's distribution of Tcl/Tk (batteries included)? As far as I know, with this distribution it works without any problems. May be Martin Sluka will give you some hints, he is running therion on various versions of Tcl/Tk and MacOSX - but he is probably busy right now (not answering my e-mails). > /*When I try trough X11, the result is : > */Error in startup script: can't find package BWidget > while executing > "package require BWidget" > (file "./xtherion" line 672) > /* I've successfully installed BWidget (in the /Library/Tcl folder, the global one and in my personnal Tcl folder)... ??? No idea. Try running only wish and type following commnad to the console: puts $tcl_library It should print directory, at which it is searching for BWidget package directory. Regards, S. Subject: Re: [therion] Compilation Problems... From: Martin Sluka Date: Mon, 10 Jan 2005 19:44:34 +0100 To: therion@speleo.sk Hi Thierry, I use Therion on MacOSX long time. There are same strange things, but it normaly works OK. Known problems: version of Tcl - I have try the AlphaTk editor and this one uses the higher version of Tcl. So I had to uninstall AlphaTk, repair permissions, reinstall the Aqua Tcl/Tk including batteries and recompile Therion. Sometimes the Tcl lost the connection to itself and frozes. But after killing of Tcl (Ctrl+C in terminal) it is able to work again. My directory for Therion is inside of my home directory in forder Caves. There are folders for other caves too. If I run xtherion: - I open the terminal - change the directory to that with my data - write xtherion and press return It normaly works. Martin S. At 11:51 +0200 10.1.2005, Thierry GONON wrote: ******************************************* > Thank you for your answer... But it still don't work!! My system is OSX 10.3.7 (last update) and I'm running Tcl/Tk8.4 > > I've copied the file as indicated, but when I run xtherion, here's the answer of the terminal : > Application initialization failed: no display name and no $DISPLAY environment variable > Error in startup script: invalid command name "frame" > while executing > "frame .def" > (file "./xtherion" line 232) > > When I try trough X11, the result is : > Error in startup script: can't find package BWidget > while executing > "package require BWidget" > (file "./xtherion" line 672) > I've successfully installed BWidget (in the /Library/Tcl folder, the global one and in my personnal Tcl folder)... > > Best regards > > > Le 10 janv. 05, ą 10:41, Stacho Mudrak a écrit : > >> Installation is still a problem on MacOSX :( It depends a lot on the system version and version of Tcl/Tk. >> >> But installation is simple. All you need to do to install therion is to copy therion executable (file named therion in compilation directory) to the /usr/bin directory (you do not need to create symbolic link for it). >> >> When therion is copied, you can run xtherion following way. >> >> 1. Go to the therion compilation directory. >> 2. cd xtherion >> 3. wish ./xtherion >> >> This works on all systems. You can try to copy also xtherion to /usr/bin and run xtherion from anywhere, but on most systems it gives error. >> >> Hope this helps. If not, we will find other way :) >> >> Regrads, S. >> >> Thierry GONON wrote: >> >>> Hello, >>> I'm working on Mac OSX (previously working with Toporobot and intended to find another software, to compare...) and I've found Therion this week... >>> So I've downloaded the sources to compile them, but during the /make install/ procedure, the Terminal answered : >>> I don't know what are the two /--symbolic/ : file or directory?? Do I have to create them, as I do for the /Therion /and/ Xtherion/ directories?? >>> Thank you very much, and enjoy caving!! >>> Thierry GONON >>> 2 Place de l'Eglise >>> 01150 LAGNIEU >>> FRANCE >> >> > > content-type: application/pgp-signature; x-mac-type=70674453; > name=PGP.sig > content-description: Ceci est une signature électronique PGP > content-disposition: inline; filename=PGP.sig > content-transfer-encoding: 7bit > > Attachment converted: Leveler:PGP.sig 1 (pgDS/----) (00007DA3) -- Subject: Re: [therion] rock-border cannot be presumed From: Stacho Mudrak Date: Mon, 10 Jan 2005 09:46:09 +0100 To: therion@speleo.sk Do you use different map symbol for this (dashed/dotted line)? If yes, we need to add another sumbols for that. Regards, S. Wookey wrote: > I have a rock-border that is presumed, but this is not a permitted subtype. > How should should a thing be drawn in therion? > > > > Wookey Subject: Re: rock-border cannot be presumed From: Wookey Date: Mon, 10 Jan 2005 11:47:58 +0000 To: therion@speleo.sk >> Wookey wrote: +++ Stacho Mudrak [05-01-10 09:46 +0100]: >>> >I have a rock-border that is presumed, but this is not a permitted subtype. >>> >How should should a thing be drawn in therion? >> Do you use different map symbol for this (dashed/dotted line)? If yes, >> we need to add another sumbols for that. yes - it should be dashed, like a presumed wall. (or a presumed block wall, or a presumed border, or presumed anything) 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: rock-border cannot be presumed From: Stacho Mudrak Date: Mon, 10 Jan 2005 14:03:40 +0100 To: therion@speleo.sk >> Do you use different map symbol for this (dashed/dotted line)? If yes, we need to add another sumbols for that. > > > yes - it should be dashed, like a presumed wall. (or a presumed block wall, > or a presumed border, or presumed anything) OK, but having everything presumed or not brings another dimension to symbols - it can complicate things a lot. Adding one presumed symbol is OK, adding presumed versions of all symbols is not possible. Having types and subtypes was an error in the therion concept in the beginning. Having only types and flags would be probably much better, but it is too late to change this. Another example is visibility. We have visible flag for each symbol (on/off) but also we have wall -subtype invisible symbol. Both are doing the same :(( OK - changing therion this way would be easy - but converting existing data is difficult. I would be very happy if I could remove subtypes, but it would be quite substantial change... Regards, S. Subject: Re: rock-border cannot be presumed From: Wookey Date: Mon, 10 Jan 2005 15:00:26 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-10 14:03 +0100]: >>>> >>Do you use different map symbol for this (dashed/dotted line)? If yes, >>>> >>we need to add another sumbols for that. >> >>> > >>> >yes - it should be dashed, like a presumed wall. (or a presumed block wall, >>> >or a presumed border, or presumed anything) I will send a separatemessage about this little drawing problem as it is an odd one which can perhaps be dealt with a different way,but it needs a diagram to explain. >> OK, but having everything presumed or not brings another dimension to >> symbols - it can complicate things a lot. Adding one presumed symbol is >> OK, adding presumed versions of all symbols is not possible. As you say, it should be a flag, not an additional type. >> Having types and subtypes was an error in the therion concept in the >> beginning. Having only types and flags would be probably much better, >> but it is too late to change this. >> >> Another example is visibility. We have visible flag for each symbol >> (on/off) but also we have wall -subtype invisible symbol. Both are doing >> the same :(( >> >> OK - changing therion this way would be easy - but converting existing >> data is difficult. I would be very happy if I could remove subtypes, but >> it would be quite substantial change... It it really that difficult to write some perl conversion that would usually do the right thing? I think you are right that this was a design error and we should fix it if at all possible. There are not that many datasets now - in the future it will only get harder... I think we should say that this will change in 0.4 or something. If we can add the new functionality now/soon so that people can create new data in the new style, then that will make it easier to convert (because there will be a version that can cope with old and new data for people to use until they have converted). I don't want to break my dataset any more than necessary, but if changes are necessary for long-term growth, and we can design a reasonable transition, then it is probably worth doing. 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: change to flags and subtypes (was Re: rock-border cannot be presumed) From: "Andrew Atkinson" Date: Mon, 10 Jan 2005 18:43:52 -0000 To: Wookey wrote >>> > >>> > OK - changing therion this way would be easy - but converting existing >>> > data is difficult. I would be very happy if I could remove > >> subtypes, but > >>> > it would be quite substantial change... > >> >> It it really that difficult to write some perl conversion that >> would usually >> do the right thing? >> >> I think you are right that this was a design error and we should fix it if >> at all possible. There are not that many datasets now - in the >> future it will >> only get harder... >> >> I think we should say that this will change in 0.4 or something. If we can >> add the new functionality now/soon so that people can create new >> data in the >> new style, then that will make it easier to convert (because >> there will be a >> version that can cope with old and new data for people to use until they >> have converted). >> >> I don't want to break my dataset any more than necessary, but if >> changes are >> necessary for long-term growth, and we can design a reasonable transition, >> then it is probably worth doing. >> The difference and different ways to get the same thing confused me, I think that although it would break my data, it would be better to change it now so that the program can be developed coherently in the future. Andrew PS On a related topic, how does Therion now fit with survex, I have to say that I am finding data set conversion a little tedious, and I have not tried to for a big cave yet. Subject: Re: change to flags and subtypes (was Re: rock-border cannot be presumed) From: Wookey Date: Tue, 11 Jan 2005 00:01:15 +0000 To: therion@speleo.sk +++ Andrew Atkinson [05-01-10 18:43 -0000]: >> Wookey wrote > >>>> > > > >> PS On a related topic, how does Therion now fit with survex, Therion no longer uses survex directly. As you know the format is 'similar but different' in a rather tiresome way. >> I have to say >> that I am finding data set conversion a little tedious, and I have not tried >> to for a big cave yet. Have you got ol's svx2th script? It's not perfect, but it does a very good base job which just needs a little fettling sometimes. This will get updated and integrated at some point. 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: Segfault when including survey data in plan From: Wookey Date: Tue, 11 Jan 2005 01:21:03 +0000 To: Therion List I noted the bit in the map defiition which says I can can include names of surveys in the map command so that the centrelines are drawn. I tried this with the terikan survey and therion just says 'error' in the compiler and doesn't say what. Running Therion standalone shows that it is segfaulting. You should be able to demonstrate this with the dataset I uploaded last night. Comment out the join soundrivercrab_s1 soundriver2_s1 line so it runs,then add the name of a survey (I tried 'river' and 'goon') to theend of the scrap list. Now it crashes. I noticed the bit about -projection being required 'if the map contains survey', but adding "-projection plan" to the map command didn't help. This looks like a bug. And is there some subtlty about adding surveys (centrelines) to maps? 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] Segfault when including survey data in plan From: Stacho Mudrak Date: Tue, 11 Jan 2005 10:08:49 +0100 To: therion@speleo.sk Wookey wrote: > This looks like a bug. And is there some subtlty about adding surveys > (centrelines) to maps? Yes, it is a bug. I have downloaded your data, made your changes and it really fails - no idea why, but I will fix it. If you would like to have map with centerline also, create a separate map with centerline only - it should work with it (at least on my machine it worked - see attached picture). Regards, S. Subject: survex to therion conversion script From: Wookey Date: Wed, 12 Jan 2005 02:54:53 +0000 To: Therion List CC: Olly Betts A couple of people asked about this, so here it is under a sensible title so people can find it in the archives. Below is a perl script which does a reasonable job of converting .svx files to .th files. Written by Olly. I have noticed a few problems, which I might as well document here as as good a place as any: (I was going to tidy them up and send them to Ol as I was given said script for 'testing'). *calibrate declination comes out wrong. It should be: *calibrate declination n -> declination n degrees therion doesn't understand 'ignoreall' - needs commenting out Doesn't try to deal with different 'team' syntax - but could be fixed to get most of them right ((lower case them all), 'pics'->'pictures', 'disto'->'length #disto' etc) Only significant problem was with 'overview' files which include a number of others. * All the equates need enclosing in 'centreline'/'endcentreline' * The converter reads in any 'included' files and inserts them. It stopped after doing two of these and truncated the file. It should probably just convert '*include foo' to 'input foo.th' It once inserted a top-level 'dummy' survey where one wasn't needed. This is a feature of converting files individually rather than as a coherent dataset, I suspect. It could probably do a better job if it 'spidered' the dataset from a top-level overview file, but that's a lot more work :-) I found one case where the ';' remained for the comment char instead of it getting converted to '#'. I need to look at that or send ol the offending file. Then you can do this to convert a whole directory: for FILE in ls *.svx; do FILE=echo $FILE | sed "s/.svx//"; echo "Converting $FILE.svx"; svx2th $FILE.svx > $FILE.th; done #!/usr/bin/perl -w use strict; # svx2th v0.1 # Copyright (C) Olly Betts 2004 sub convert_file($); my $in_survey = 0; my $had_fix = 0; print "encoding iso8859-1\n"; for my $filename (@ARGV) { convert_file($filename); } if ($in_survey) { print "endsurvey dummy\n"; } sub convert_file($) { my $filename = shift; open F, "<", $filename or die "$filename: $!\n"; my @lines = ; close F; my $in_centre_line = 0; my $lineno = 0; my $dummy_survey = -1; foreach $_ (@lines) { ++$lineno; # Replace ; with # as comment separator. # FIXME won't cope with ; in a filename or *title s/;/#/; # Comment out "*export" and "*entrance" as there seems to be no # equivalent of either. if (/^\s*\*\s*(?:export|entrance)\b/i) { print "#$_"; next; } if ($in_centre_line) { if (/^\s*\*/ && !/^\s*\*\s*(?:date|calibrate|fix|equate|data|instrument|units|sd|infer|flags|team)\b/i) { print "endcentreline\n"; $in_centre_line = 0; } } else { if (/^\s*[^\s*#]/ || /^\s*\*\s*(?:date|calibrate|fix|equate|data|instrument|units|sd|infer|flags|team)\b/) { if (!$in_survey) { # Therion can't handle these outside a centreline which # must be inside a survey, so we have to add a dummy # top-level survey. print "survey dummy -title \"Therion is crap\"\n"; ++$in_survey; } print "centreline\n"; $in_centre_line = 1; } } # *begin -> survey if (s/^(\s*)\*(\s*)begin\b(\s*)(\S+)/$1$2survey$3$4 -title "$4" /i) { ++$in_survey; print $_; next; } # *begin -> # The *begin will cause an endcentreline / centreline pair to be # output which hopefully prevents settings from escaping. However # this doesn't restore the old settings, just undoes any new ones. # FIXME: Need to address this somehow... if (/^(\s*)\*(\s*)begin\b[ \t]*$/i) { ++$in_survey; if ($dummy_survey != 0) { # FIXME: doesn't coped with nested *begin with no arguments... die "This convertor doesn't currently handle nested *begin with no arguments\n"; } $dummy_survey = $in_survey; print "#$_"; next; } # *end [] -> endsurvey [] if (s/^(\s*)\*(\s*)end\b/$1$2endsurvey/i) { if ($dummy_survey == $in_survey) { $_ = "#$_"; $dummy_survey = -1; } --$in_survey; if ($in_centre_line) { print "endcentreline\n"; $in_centre_line = 0; } print $_; next; } # *title -> # -title <title> # FIXME: just comment out for now - should really convert to -title on # the "survey" line. if (s/^(\s*)\*\s*title\b\s*/$1# -title /i) { print $_; next; } # *team and *instrument format is unspecified in Survex, and they're # just informational so comment them out for now... # NB therion seems to be case sensitive so "Compass" isn't a valid role # ("compass" is)... # NB in *team pics -> pictures if (s/^(\s*)\*(\s*(?:team|instrument))\b/#$1$2/i) { print $_; next; } # *include -> literal text inclusion. # Note that the *include means an implicit *begin, but the output # may not reflect this correctly (since we can't handle *begin # with no survey name anyway...) if (/^\s*\*\s*include\s*"?([^"\s]*)/i) { # Use Unix path separators (/ not \) - Survex understands either on # either platform. my $filename = $1; $filename =~ s!\\!/!g; $filename .= '.svx' unless $filename =~ /\.svx$/i; convert_file($filename); next; } # survey.subsurvey.12 -> 12@subsurvey.survey if (s/^(\s*)\*(\s*equate)\b/$1$2/i) { # Ensure that a comment separator doesn't get eaten by station name. s/(\S)#/$1 #/; s/(\S+)\.(\S+)/"$2\@".join(".",reverse split m!\.!, $1)/ge; print $_; next; } if (/^\s*\*\s*fix\b/i) { $had_fix = 1; } s/^(\s*)\*/$1/; print; } } 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 conversion script From: Olly Betts <olly@survex.com> Date: Wed, 12 Jan 2005 03:44:04 +0000 To: Therion List <therion@speleo.sk> On Wed, Jan 12, 2005 at 02:54:53AM +0000, Wookey wrote: >> It once inserted a top-level 'dummy' survey where one wasn't needed. This is >> a feature of converting files individually rather than as a coherent dataset, >> I suspect. It could probably do a better job if it 'spidered' the dataset >> from a top-level overview file, but that's a lot more work :-) Um, the script is designed to crawl over an included tree of .svx files to produce a single .th file. So this is already done (and in fact more work would be required if you wanted a usable tree of .th files). I probably should have documented that, but to be honest the whole thing is barely more than a proof of concept - mostly it was quicker and a lot less tedious than converting all the data by hand, plus I could just rerun it if we found any typos in the survex dataset. >> Then you can do this to convert a whole directory: >> for FILE in ls *.svx; do FILE=echo $FILE | sed "s/.svx//"; echo "Converting >> $FILE.svx"; svx2th $FILE.svx > $FILE.th; done You seem to have lost some backticks in there: for FILE in *.svx; do FILE=`echo $FILE | sed "s/.svx//"`; echo "Converting $FILE.svx"; svx2th $FILE.svx > $FILE.th; done But the idea is that you just run it using: ./svx2th TOPLEVEL.svx > SINGLEFILE.th But I'm not sure a perl script is really a good approach. At least it stops you having to maintain two parallel versions of your data, but the two formats are sufficiently different that it's not just a matter of stripping out the "*"s and changing the comment characters, as I'd initially hoped. It's also hard to hide this machinery away from the user - for example, there's the danger that you change the generated .th file and lose the changes next time you run the script. I looked at bolting the .svx parsing code into Therion. If that could be done you'd just include a .svx file instead of a .th one and everything would just work. Unfortunately the therion code has a lot of Czech or Slovak variable names and comments and we had a survey to draw up for the BCRA conference, so I took the safer route and hacked up a bit of perl. I also wondered about being able to include a .3d file instead - that would probably actually be easier, as the .3d file reading code is designed as a separate module, whereas the .svx reading code isn't. And it would avoid the annoyance of having to choose at compile time whether you want to use Survex for loop closure or not. As it is the prebuilt Windows and debian packages for therion are useless to anyone who actually cares if their stations are in the same place in Survex and therion, which is rather sad... Cheers, Olly Subject: Re: survex to therion conversion script From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 12 Jan 2005 09:49:24 +0100 To: therion@speleo.sk > I also wondered about being able to include a .3d file instead - that > would probably actually be easier, as the .3d file reading code is > designed as a separate module, whereas the .svx reading code isn't. Great idea, Olly! This is probably ideal solution also for people, that are starting with therion and have their centerline data in different package. If this will be possible, they will not need to convert their dataset to therion format. And reading of .3d file (or any other with processed data, .plt for example) is usually trivial. So I suggest to add new command: input-centreline <filename> It will add survey stations and shots from given (.3d, later may be compass, toporobot, vtopo etc.) file to current survey. This should not be too much work. Any comments? Regards, S. Subject: Re: survex to therion conversion script From: Wookey <wookey@aleph1.co.uk> Date: Wed, 12 Jan 2005 11:31:00 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-12 09:49 +0100]: >> >> So I suggest to add new command: >> >> input-centreline <filename> >> >> It will add survey stations and shots from given (.3d, later may be >> compass, toporobot, vtopo etc.) file to current survey. This should not >> be too much work. >> >> Any comments? _Now_ he tells me :-) 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 conversion script From: Simeon Warner <simeon@cs.cornell.edu> Date: Wed, 12 Jan 2005 08:32:42 -0500 (EST) To: therion@speleo.sk On Wed, 12 Jan 2005, Wookey wrote: >> +++ Stacho Mudrak [05-01-12 09:49 +0100]: > >>> > >>> > So I suggest to add new command: >>> > >>> > input-centreline <filename> >>> > >>> > It will add survey stations and shots from given (.3d, later may be >>> > compass, toporobot, vtopo etc.) file to current survey. This should not >>> > be too much work. >>> > >>> > Any comments? > >> >> _Now_ he tells me :-) This sounds very sensible and would nicely decouple the survex and therion files/data. -- Simeon Subject: Re: [therion] Re: survex to therion conversion script From: John Pybus <john@pybus.org> Date: Wed, 12 Jan 2005 15:24:35 +0000 To: therion@speleo.sk Stacho Mudrak wrote: > > Great idea, Olly! It certainly is. I've been wondering about the problems of keeping two datasets up to date. If the conversion from svx to .th requires any manual editing and is beyond scripting in a Makefile then keeping edits and fixes in sync would become a huge pain. > So I suggest to add new command: > > input-centreline <filename> > > It will add survey stations and shots from given (.3d, later may be compass, toporobot, vtopo etc.) file to current survey. This should not be too much work. > > Any comments? When you say 'current survey' I'm assuming that this would account for putting dotted station names into subsurveys. I'd need to process a whole survey hierarchy at once to benefit from the loop closing in cavern. Cheers, John Subject: Re: survex to therion conversion script From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 12 Jan 2005 16:54:25 +0100 To: therion@speleo.sk John Pybus wrote: > When you say 'current survey' I'm assuming that this would account for > putting dotted station names into subsurveys. I'd need to process a > whole survey hierarchy at once to benefit from the loop closing in cavern. Well, this make sense only in the case, if user will create simmilar (up to some level) survey structure in therion, like it is in survex data he wants to input. So if therion will find station foo.1 and there will be corresponging subsurvey foo in therion data (at survey level, where input-centerline appears), it will put station 1 into this subsurvey. For other cases, we would like to add scrap option called -station-name-prefix/suffix, which will specify what characters to add to station names specified in scrap. It is usefull also for therion data, if scrap is referencing stations from some subsurvey. It will simplyfy entering station names a lot. In fact, survey hierarchy is not necessary, if you are drawing maps. There is a map hierarchy, which is independent on survey hierarchy, so you may define map structure like map floor1 f1scrap1 f1scrap2 endmap map floor2 f2scrap1 endmap map whole-cave floor2 floor1 endmap And select maps using their names in configuration file. In the future, there is also possibility to add some filter options to input-centerline command, that will import only stations with certain prefix (without this prefix) and you will be able to import same file in different survey. But I am not sure whether this is necessary. Regards, S. Subject: Re: [therion] Re: survex to therion conversion script From: Olly Betts <olly@survex.com> Date: Wed, 12 Jan 2005 15:54:39 +0000 To: therion@speleo.sk On Wed, Jan 12, 2005 at 09:49:24AM +0100, Stacho Mudrak wrote: >> This is probably ideal solution also for people, that are starting with >> therion and have their centerline data in different package. If this >> will be possible, they will not need to convert their dataset to therion >> format. And reading of .3d file (or any other with processed data, .plt >> for example) is usually trivial. The hardest part of reading the file formats is pinning them down. Larry Fish was very helpful in resolving minor ambiguities in the Compass file format descriptions, which was very useful when writing the Survex support for Compass formats. Without a precise spec or a lot of sample data from a range of sources, you're likely to end up handling just a subset of the format. But generally it's going to be easier for processed data formats than unprocessed data formats as they're written by machines, so the format-as-defined-by-use has a lot less variation, even if you don't have a formal specification. >> So I suggest to add new command: >> >> input-centreline <filename> >> >> It will add survey stations and shots from given (.3d, later may be >> compass, toporobot, vtopo etc.) file to current survey. This should not >> be too much work. You get compass "for free" with the Survex "img" library - it transparently reads .plt files (and processed CMAP files). Cheers, Olly Subject: another set of inside-out pillars From: Wookey <wookey@aleph1.co.uk> Date: Sun, 16 Jan 2005 04:02:58 +0000 To: Therion List <therion@speleo.sk> I've added another km or so - the go-on series. No real problems except that all the pillars were inside-out. I split it into two scraps instead of one huge one, thereby determining in which half the problem lay, but after much staring at it and checking line types and looking at debug mode and fixing various problems, I still can't see why it's confused. The problem scrap is goon_s2 and it goes wrong on its own as well as when processed as part of the big plan. There are no therion errors about overlapping outlines, although there is one red metapost entry in the list (what do those mean?) The set of files is at http://trilogy-gw.aleph1.co.uk/~wookey/files/terikan.tgz (no pics). As ever, clues welcome. 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] another set of inside-out pillars From: Martin Sluka <martinsluka@mac.com> Date: Sun, 16 Jan 2005 19:07:52 +0100 To: therion@speleo.sk At 04:02 +0000 16.1.2005, Wookey wrote: ******************************************* > I've added another km or so Lucky man - I'm happy to add 50 m in 3 scraps to map of Cachtice cave in one sesion :) MartinS -- Subject: Re: another set of inside-out pillars From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 17 Jan 2005 08:19:37 +0100 To: therion@speleo.sk Wookey wrote: > I've added another km or so - the go-on series. No real problems except that > all the pillars were inside-out. Well, all your pillars are drawn in reverse sense. The yellow tick should allways point to free space! Like it is in pits or chimneys. In your case - it points to the insight of pillar. So in the pillar case - you should draw this line in CW sense. But checking reverse option for line for each line flowstone should help. > I split it into two scraps instead of one > huge one, thereby determining in which half the problem lay, but after much > staring at it and checking line types and looking at debug mode and fixing > various problems, I still can't see why it's confused. You have there one line with two identical points (no idea how this can happen in xtherion - it should not). In any case - new version will not fail in this case. It is just a problem of symbol set. > The problem scrap is goon_s2 and it goes wrong on its own as well as when > processed as part of the big plan. There are no therion errors about > overlapping outlines, although there is one red metapost entry in the list > (what do those mean?) If you mean (mptextmp.mp) [60], it is bug in xtherion :) It should not be highlighted (this bug is also already removed). > The set of files is at > http://trilogy-gw.aleph1.co.uk/~wookey/files/terikan.tgz > (no pics). > > As ever, clues welcome. The best clue for you would be probably new release. Most of the bugs you are still reporting are already removed and a lot of functionality you asked for is added. Unfortunately, it will be finished in about 2 or 3 weeks. But if you are using therion so intensivly, it would be probably better if I sent you current state of 0.3.6 by mail, and you will test it. It should save you some time... Regards, S. Subject: Re: another set of inside-out pillars From: Wookey <wookey@aleph1.co.uk> Date: Mon, 17 Jan 2005 13:34:18 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-17 08:19 +0100]: >> Wookey wrote: > >>> >I've added another km or so - the go-on series. No real problems except >>> >that >>> >all the pillars were inside-out. > >> >> Well, all your pillars are drawn in reverse sense. The yellow tick >> should allways point to free space! Like it is in pits or chimneys. In >> your case - it points to the insight of pillar. doh!! I knew that really. I did have the feeling that I was missing something obvious, but I'm obvioously just becoming stupid in my old age. PArtly comes from drawing at 4am in the morning. >>> >The problem scrap is goon_s2 and it goes wrong on its own as well as when >>> >processed as part of the big plan. There are no therion errors about >>> >overlapping outlines, although there is one red metapost entry in the list >>> >(what do those mean?) > >> >> If you mean (mptextmp.mp) [60], it is bug in xtherion :) It should not >> be highlighted (this bug is also already removed). I did, yes. I had already noticed that clicking on it just produced an error :-) >>> >The set of files is at >>> >http://trilogy-gw.aleph1.co.uk/~wookey/files/terikan.tgz >>> >(no pics). >>> > >>> >As ever, clues welcome. > >> >> The best clue for you would be probably new release. Most of the bugs >> you are still reporting are already removed and a lot of functionality >> you asked for is added. Unfortunately, it will be finished in about 2 or >> 3 weeks. >> >> But if you are using therion so intensivly, it would be probably better >> if I sent you current state of 0.3.6 by mail, and you will test it. It >> should save you some time... OK - no problem. I'm happy to test a new one, and will continue with intensive use fora while yet (maybe not next week as I am in holland for work). I'll start doing cross-sections and text and elevations and things 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: another set of inside-out pillars From: Wookey <wookey@aleph1.co.uk> Date: Mon, 17 Jan 2005 19:11:34 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-17 08:19 +0100]: >> Wookey wrote: > >>> >I've added another km or so - the go-on series. No real problems except >>> >that all the pillars were inside-out. > >> >> Well, all your pillars are drawn in reverse sense. The yellow tick >> should allways point to free space! Like it is in pits or chimneys. In >> your case - it points to the insight of pillar. >> >> So in the pillar case - you should draw this line in CW sense. But >> checking reverse option for line for each line flowstone should help. Hmm. I just checked. I found one in goon_s1 that the wrong way round, but every pillar in goon_s2 (which is the one coming out wrong in the final plot) is correct (tick on the inside). I am talking about walls which make loops because they are surrounded by passage here, not actual calcite pillars/columns. >>> >I split it into two scraps instead of one >>> >huge one, thereby determining in which half the problem lay, but after much >>> >staring at it and checking line types and looking at debug mode and fixing >>> >various problems, I still can't see why it's confused. > >> >> You have there one line with two identical points (no idea how this can >> happen in xtherion - it should not). In any case - new version will not >> fail in this case. It is just a problem of symbol set. OK, that's fixed. thanx. This problem may have ben caused by my persistent 'xtherion hangs' problem. It happened several times drawing that section. I got really mad for a while until I learned to save my work every 5-10 mouse clicks so I never lose much. (at least saving is nice and fast :-) Xtherion ran for several hours hours last night without crashing once - that is the best for a long time! I have no idea why - I didn't do anything different. I have now downloaded the tcl and tk sources and will try building a version with '--disable-threads' to see if it helps. Do you know if this should be in the tk or tcl sources, or both? 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: another set of inside-out pillars From: "Martin Budaj" <m.b@speleo.sk> Date: Tue, 18 Jan 2005 08:36:41 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> Hmm. I just checked. I found one in goon_s1 that the wrong way round, but >> every pillar in goon_s2 (which is the one coming out wrong in the final >> plot) >> is correct (tick on the inside). The line orientation in inner pillars is significant only for displaying of asymetrical walls (blocks, sand, ice), not for determining the inside of the passage. You have actually two crossing scrap borders in one scrap :-) MetaPost didn't notice it, which is really bad. This can't be improved at the level of MetaPost macros, because we use low-level built-in function to determine the line orientation. The enclosed picture shows the problematic connections. M. Subject: problem compiling on debian woody From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 00:45:09 +0100 To: Therion <therion@speleo.sk> Hi, this is my first post I'm trying to compile in debian woody with Tcl/Tk8.4 from www.backports.org. BWidget is 1.3 from woody. Tkimg is compiled from source. This is what I am getting: tatel@ganbo:~/src/therion$ make g++ -c -Wall -DTHLINUX -O2 -o thdate.o thdate.cxx g++ -c -Wall -DTHLINUX -O2 -o thexception.o thexception.cxx g++ -c -Wall -DTHLINUX -O2 -o thbuffer.o thbuffer.cxx g++ -c -Wall -DTHLINUX -O2 -o thmbuffer.o thmbuffer.cxx g++ -c -Wall -DTHLINUX -O2 -o thlogfile.o thlogfile.cxx g++ -c -Wall -DTHLINUX -O2 -o thtmpdir.o thtmpdir.cxx g++ -c -Wall -DTHLINUX -O2 -o thparse.o thparse.cxx thparse.cxx: In function `void thparse_image(char *, double &, double &, double &)': thparse.cxx:756: implicit declaration of function `int round(...)' make: *** [thparse.o] Error 1 What should I do? Thanks, Roman Subject: Re: [therion] problem compiling on debian woody From: Olly Betts <olly@survex.com> Date: Tue, 18 Jan 2005 00:50:42 +0000 To: Roman Muñoz <tatel@infonegocio.com> CC: Therion <therion@speleo.sk> On Tue, Jan 18, 2005 at 12:45:09AM +0100, Roman Mu?oz wrote: >> thparse.cxx:756: implicit declaration of function `int round(...)' >> make: *** [thparse.o] Error 1 round() was added to ISO C in the 1999 revision of the standard, which can make it tricky to call from C++ currently (ISO C++ includes the C89 library functions, but not those added in C99 so these currently live in a strange no man's land). Actually, now I think about it, I'm not sure the compiler in woody supports round() even in C code. Anyway, the simplest solution is probably just to stick your own implementation of round near the top of any file which wants it (looks like thparse.cxx is the only one actually). Adding it just after the #include lines is safest: static inline double round(double x) { if (x >= 0.0) return floor(x + 0.5); return ceil(x - 0.5); } Cheers, Olly Subject: Re: [therion] problem compiling on debian woody From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 02:43:09 +0100 To: therion@speleo.sk Hi again, It worked like a charm Many thanks, Roman On Tue, 18 Jan 2005 00:50:42 +0000 Olly Betts <olly@survex.com> wrote: >> On Tue, Jan 18, 2005 at 12:45:09AM +0100, Roman Mu?oz wrote: > >>> > thparse.cxx:756: implicit declaration of function `int round(...)' >>> > make: *** [thparse.o] Error 1 > >> >> round() was added to ISO C in the 1999 revision of the standard, which >> can make it tricky to call from C++ currently (ISO C++ includes the C89 >> library functions, but not those added in C99 so these currently live in >> a strange no man's land). Actually, now I think about it, I'm not sure >> the compiler in woody supports round() even in C code. >> >> Anyway, the simplest solution is probably just to stick your own >> implementation of round near the top of any file which wants it (looks >> like thparse.cxx is the only one actually). Adding it just after the >> #include lines is safest: >> >> static inline double >> round(double x) { >> if (x >= 0.0) return floor(x + 0.5); >> return ceil(x - 0.5); >> } >> >> Cheers, >> Olly Subject: model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 14:15:23 +0100 To: therion@speleo.sk Hi, I'm missing (in Linux) the model viewer available on windows Is this rigth? If yes, what coul I use to view models? Thanks, Roman Subject: Re: [therion] model viewer? From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 18 Jan 2005 15:25:01 +0100 To: therion@speleo.sk You need a special extension to Tcl to view therion models. It is a modified version of tom package, and it is present at therion/thtom directory. Running cd thtom/linux make should compile this extension, then copying Tom0.2 to /usr/lib/tk8.4 should enable this extension to Tk and model viewer will be automatically activated next time xtherion is started. Regards, S. Roman Muñoz wrote: > Hi, > > I'm missing (in Linux) the model viewer available on windows > > Is this rigth? If yes, what coul I use to view models? > > Thanks, > Roman > > Subject: Re: [therion] model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 16:51:06 +0100 To: therion@speleo.sk Thanks, I missed it on thbook.pdf (oops) But ... tatel@ganbo:~/src/therion/thtom/linux$ make gcc -Wall -s -DGL12 -I/usr/X11R6/include -DIMLIB2 -c -o Tom0.2/tom.o ../src/tom.c In file included from ../src/tom.c:3: ../src/tom.h:4: tcl.h: No such file or directory ../src/tom.h:5: tk.h: No such file or directory ../src/tom.h:13: GL/glx.h: No such file or directory ../src/tom.h:15: GL/gl.h: No such file or directory ../src/tom.h:16: GL/glu.h: No such file or directory make: *** [Tom0.2/tom.o] Error 1 Regards, Roman On Tue, 18 Jan 2005 15:25:01 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> You need a special extension to Tcl to view therion models. It is a >> modified version of tom package, and it is present at therion/thtom >> directory. >> >> Running >> >> cd thtom/linux >> make >> >> should compile this extension, then copying Tom0.2 to /usr/lib/tk8.4 >> should enable this extension to Tk and model viewer will be >> automatically activated next time xtherion is started. >> >> Regards, S. >> >> Roman Muñoz wrote: > >>> > Hi, >>> > >>> > I'm missing (in Linux) the model viewer available on windows >>> > >>> > Is this rigth? If yes, what coul I use to view models? >>> > >>> > Thanks, >>> > Roman >>> > >>> > > >> Subject: Re: model viewer? From: Wookey <wookey@aleph1.co.uk> Date: Tue, 18 Jan 2005 16:36:02 +0000 To: therion@speleo.sk +++ Roman Muñoz [05-01-18 14:15 +0100]: >> Hi, >> >> I'm missing (in Linux) the model viewer available on windows >> >> Is this rigth? If yes, what coul I use to view models? The debian version does not currently build this stuff (and I think you are using that, right?). It needs the tcltom library (which is in the therion sources), but I decided to make it a separate Debian package and haven't finished packaging it yet. If you get the build working do please send me the details so I can do a proper upload. Although Stacho has said that he is changing the approach anyway to export VRML and use a dedicated viewer, I think. 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: model viewer? From: Olly Betts <olly@survex.com> Date: Tue, 18 Jan 2005 17:51:11 +0000 To: therion@speleo.sk On Tue, Jan 18, 2005 at 04:36:02PM +0000, Wookey wrote: >> The debian version does not currently build this stuff (and I think you are >> using that, right?). No, he's built from source on debian (presumably because your packages don't work with woody/stable). Roman: it sounds like you don't have the relevant -dev packages installed for tcl, tk, opengl, etc. Cheers, Olly Subject: Re: [therion] Re: model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 19:36:26 +0100 To: therion@speleo.sk Yes, I do use debian woody. But I'm not sure about what "debian version" means. I'm building from therion-0.3.5.tar.gz So I'm not using any "debian version", right? However, I can't find tcltom in the sources. Where is it? I used to do ./configure --with-tcl-includes=/usr/include/tcl8.4 to get tcl.h but since there were no ./configure I was feeling a little bit lost. I copied tcl.h to thtom source. Don't worked. Now I'm feeling like a monkey at the center of the Sahara ;-) Cheers, Roman Roman On Tue, 18 Jan 2005 16:36:02 +0000 Wookey <wookey@aleph1.co.uk> wrote: >> The debian version does not currently build this stuff (and I think >> you are using that, right?). It needs the tcltom library (which is in >> the therion sources), but I decided to make it a separate Debian >> package and haven't finished packaging it yet. >> >> If you get the build working do please send me the details so I can do >> a proper upload. Although Stacho has said that he is changing the >> approach anyway to export VRML and use a dedicated viewer, I think. >> >> 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: model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 19:49:23 +0100 To: therion@speleo.sk On Tue, 18 Jan 2005 17:51:11 +0000 Olly Betts <olly@survex.com> wrote: >> Roman: it sounds like you don't have the relevant -dev packages >> installed for tcl, tk, opengl, etc. >> >> Cheers, >> Olly I do have tcl8.4-dev and tk8.4-dev installed. I downloaded them from www.backports.org. May be I'll try to compile tcl8.4 myself Regards Roman Subject: Re: model viewer? From: Wookey <wookey@aleph1.co.uk> Date: Tue, 18 Jan 2005 20:18:09 +0000 To: therion@speleo.sk +++ Roman Muñoz [05-01-18 19:36 +0100]: >> >> >> Yes, I do use debian woody. But I'm not sure about what "debian version" >> means. I'm building from therion-0.3.5.tar.gz So I'm not using any >> "debian version", right? No, you are not - I thought you were building form the debian source package. >> However, I can't find tcltom in the sources. >> Where is it? thtom in top-level of source. >> I used to do ./configure --with-tcl-includes=/usr/include/tcl8.4 to get >> tcl.h but since there were no ./configure I was feeling a little bit >> lost. >> >> I copied tcl.h to thtom source. Don't worked. Now I'm feeling like a >> monkey at the center of the Sahara ;-) Ah well - it wouldn't work for me either, and I haven't sat down and worked out why not.. 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: model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 18 Jan 2005 22:30:39 +0100 To: therion@speleo.sk Wookey, Well, after some search, I found an old post about "old debian problem... need to link/usr/include/tcl8.3/tcl.h to /usr/include/tcl.h" So I did: ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tk.h /usr/include/ ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tcl.h /usr/include/ ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tclDecls.h /usr/include/ ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tclPlatDecls.h ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tkDecls.h And it worked... partially: compilation ran with no errors, but I still can't get the model viewer window; trying to see what other thing could I have missed just now. GL messages were efectively about not having installed xlibmesa-dev BTW, on my "regular" woody box with TclTk8.3, there are not soft links and it works fine, so probably there is a difference from the backported package 8.4 and 8.3 stable Hope this helps, Roman Subject: Re: [therion] Re: model viewer? From: "Martin Budaj" <m.b@speleo.sk> Date: Wed, 19 Jan 2005 09:00:21 +0100 (CET) To: therion@speleo.sk >> And it worked... partially: compilation ran with no errors, but I still >> can't get the model viewer window; trying to see what other thing could >> I have missed just now. Did you copy Tom0.2 directory to /usr/lib/tk8.4 after compilation? Regards, Martin Subject: Re: [therion] Re: model viewer? From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 19 Jan 2005 11:04:42 +0100 To: therion@speleo.sk No I did not... at the first moment. Now it is working. I'm quite impressed. Next days I'll try editing of sites and those scrap things. Has somebody experienced this need of soft links to /usr/include/tcl.h et al? Thanks to all who helped me. Best regards, Roman On Wed, 19 Jan 2005 09:00:21 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >>> > And it worked... partially: compilation ran with no errors, but I still >>> > can't get the model viewer window; trying to see what other thing could >>> > I have missed just now. > >> >> Did you copy Tom0.2 directory to /usr/lib/tk8.4 after compilation? >> >> Regards, >> Martin >> Subject: Re: [therion] Re: model viewer? From: Olly Betts <olly@survex.com> Date: Wed, 19 Jan 2005 16:02:52 +0000 To: Roman Muñoz <tatel@infonegocio.com> CC: therion@speleo.sk On Tue, Jan 18, 2005 at 10:30:39PM +0100, Roman Mu?oz wrote: >> ganbo:/home/tatel# ln -s /usr/include/tcl8.4/tk.h /usr/include/ >> [...] Adding -I/usr/include/tcl8.4 to the compiler flags should have much the same effect, but without having to modify your installation. >> BTW, on my "regular" >> woody box with TclTk8.3, there are not soft links and it works fine, so >> probably there is a difference from the backported package 8.4 and >> 8.3 stable It's probably done that way so you can have 8.3 stable and 8.4 backport installed at the same time. Cheers, Olly Subject: Adding sections error From: "Andrew Atkinson" <andrew@wotcc.org.uk> Date: Tue, 18 Jan 2005 14:49:42 -0000 To: <therion@speleo.sk> Just been trying to add sections to my plans, happily doing it until it decided to stop working, I cannot see what difference I have done. Whenever I try to put a point in to display sectB I get an error that starts off like the insert below. sectA, section1, section2, section3 seem to have worked fine, even discovered that you can use the scale points to rotate the sections, however this may not be the best method. START ERROR MESSAGE ! Inconsistent equation (off by 29.83728). <to be read again> ; <for(1)> ...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.3292 ),0,4) ; The equation I just read contradicts what was said before. But don't worry; continue and I'll just ignore it. ! Inconsistent equation (off by -22.96272). <to be read again> END THE ERROR MESSAGE While I am writing this email, I have a few clarification points pit-ent (not in this data set) seems to be displayed as a normal pit, not with the double line round it. The scaling of sections is very tedious, would there be anyway to make the default scale the same as the plan if it was in the same th2 file. The above error arose when adding sections, but I could not identify which one, the only thing I could do was to remove them all and then go back and add them one at a time until I found the mistake. As above is there a better way to rotate the sections if they have not been drawn on the original plan. Andrew Subject: Re: [therion] Adding sections error From: "Martin Budaj" <m.b@speleo.sk> Date: Tue, 18 Jan 2005 16:06:32 +0100 (CET) To: therion@speleo.sk Andrew Atkinson wrote: >> START ERROR MESSAGE >> >> ! Inconsistent equation (off by 29.83728). >> <to be read again> >> ; >> <for(1)> ...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.3292 ),0,4) >> ; >> The equation I just read contradicts what was said before. >> But don't worry; continue and I'll just ignore it. >> >> ! Inconsistent equation (off by -22.96272). >> <to be read again> >> >> END THE ERROR MESSAGE This bug has been corrected in version 0.3.5. Regards, Martin Subject: RE: [therion] Adding sections error From: "Andrew Atkinson" <andrew@wotcc.org.uk> Date: Tue, 18 Jan 2005 15:18:45 -0000 To: <therion@speleo.sk> >> >> >> Andrew Atkinson wrote: >> > >>> > START ERROR MESSAGE >>> > >>> > ! Inconsistent equation (off by 29.83728). >>> > <to be read again> >>> > ; >>> > <for(1)> ...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.3292 ),0,4) >>> > ; >>> > The equation I just read contradicts what was said before. >>> > But don't worry; continue and I'll just ignore it. >>> > >>> > ! Inconsistent equation (off by -22.96272). >>> > <to be read again> >>> > >>> > END THE ERROR MESSAGE > >> >> This bug has been corrected in version 0.3.5. >> >> Regards, >> Martin But I am using version 0.3.5 Andrew Subject: RE: [therion] Adding sections error From: "Martin Budaj" <m.b@speleo.sk> Date: Tue, 18 Jan 2005 16:39:06 +0100 (CET) To: therion@speleo.sk Andrew Atkinson wrote: >>>> This bug has been corrected in version 0.3.5. > >> >> But I am using version 0.3.5 I checked it and 0.3.5 for Windows still contains the bug. The source code distribution is correct. There could be some problems in synchronization of sources for both versions. Will be corrected in 0.3.6 Martin Subject: Section problem From: "Andrew Atkinson" <andrew@wotcc.org.uk> Date: Tue, 18 Jan 2005 14:54:15 -0000 To: <therion@speleo.sk> Sorry Typically, just after I sent the email I found the problem, on sectB I had the line type set to section instead of wall, fixed that and now it worked, although I still think that the error message with different information may have saved me a few hours Andrew Subject: translating... From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 20 Jan 2005 02:12:30 +0100 To: Therion <therion@speleo.sk> Hi After some playing with Therion, I'm quite happy... Now I'm considering to translate it to spanish... Question is: in the texts_es.txt file should I do therion: point station:temporary es: punto estacion:temporal (i e translating all words) or therion: point station:temporary es: point estacion:temporal Cheers Roman Subject: Re: [therion] translating... From: "Martin Budaj" <m.b@speleo.sk> Date: Thu, 20 Jan 2005 07:43:08 +0100 (CET) To: therion@speleo.sk >> After some playing with Therion, I'm quite happy... Now I'm considering to >> translate it to spanish... Question is: in the texts_es.txt file should I >> do >> >> therion: point station:temporary >> es: punto estacion:temporal >> >> (i e translating all words) >> or >> >> therion: point station:temporary >> es: point estacion:temporal The names like "point station:temporary" are internal Therion identifiers which shouldn't be translated literally. The best way is to export also english translation (perl process.pl export en) to see how these identifiers were translated into English, e.g. therion: point station:temporary en: temporary survey station and take the 'en:' lines as the basis for translation. M. Subject: Re: [therion] translating... From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 20 Jan 2005 10:07:21 +0100 To: therion@speleo.sk On Thu, 20 Jan 2005 07:43:08 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >> >> The names like "point station:temporary" are internal Therion identifiers >> which shouldn't be translated literally. The best way is to export also >> english translation (perl process.pl export en) OK, I exported the fr file too. Both helped me, but still there are some doubts. What is ... underlying wall (a hidden wall under i.e. clay?) floor-step (I guess this is a little climb in our way across the cave) ceiling-step (I surrender here because I can't walk on the ceiling) soda-straw (thin hollow stalactite looking like italian food?) flute (the same thin hollow stalactite?) raft (I was guessing this is a rubber boat but fr version doesn't) raft-cone (whooaa!) sump (I think it is a pit with water, but fr calls it siphon) My Oxford Advanced Learner's Dictionaty don't helped me... Regards, Roman Subject: Re: [therion] translating... From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 20 Jan 2005 11:31:31 +0100 To: therion@speleo.sk > underlying wall (a hidden wall under i.e. clay?) In some cases, you > floor-step (I guess this is a little climb in our way across the cave) Yes. You do not need equipement for it. > ceiling-step (I surrender here because I can't walk on the ceiling) Ceiling step is for example something, you are afraid off, if you do not wear helmet. There are two floor and ceiling equivalents: pit/floor-step - chimney/ceiling-step. > soda-straw (thin hollow stalactite looking like italian food?) Yes. Thin, long with hole inside. > flute (the same thin hollow stalactite?) If I am correct, it is a special kind of erosion formation. See UIS cave signatures at http://www.carto.net/cgi-neumann/cave_symbol.pl > raft (I was guessing this is a rubber boat but fr version doesn't) > raft-cone (whooaa!) Mike Lake once wrote: 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. > sump (I think it is a pit with water, but fr calls it siphon) Yes, it is passage completely filled with water (also in Slovakia we call it sifon). Regards, S. Subject: Re: [therion] translating... From: Martin Sluka <martinsluka@mac.com> Date: Thu, 20 Jan 2005 11:46:26 +0100 To: therion@speleo.sk At 11:31 +0100 20.1.2005, Stacho Mudrak wrote: ******************************************* >> ceiling-step (I surrender here because I can't walk on the ceiling) > > > Ceiling step is for example something, you are afraid off, if you do not wear helmet. There are two floor and ceiling equivalents: pit/floor-step - chimney/ceiling-step. The ommiting of ceiling morphology is the most common error you may see on maps of caves. There are plenty of on first look "very nice" cave maps, with detailed morphology of floor, color sediments, blue water, ... , but without any information of ceiling morphology. The cave surveyors are able to discus hours and hours about precision of measurement with particular tools, but such a cave map as I described before, measured with total laser station, is 50 % not true. Because there are not half of informations. My 0.02 EUR Martin -- Subject: Re: [therion] translating... From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 20 Jan 2005 22:23:44 +0100 To: therion@speleo.sk OK, thanks May be you would get the texts_es.txt file? Also, may be I could send a translated thbook_es.pdf (perhaps next month or so). I don't promise but it is now in my TODO list because my caving friends don't worrry too much about learning english... Regards, Roman Subject: Re: [therion] translating... From: "Martin Budaj" <m.b@speleo.sk> Date: Fri, 21 Jan 2005 09:24:42 +0100 (CET) To: therion@speleo.sk >> May be you would get the texts_es.txt file? Of course we'll include it in the main distribution. >> Also, may be I could send a >> translated thbook_es.pdf (perhaps next month or so). I don't promise but >> it is now in my TODO list >> because my caving friends don't worrry too much about learning english... That would be really great! Suggestions for FAQ or tutorial are also welcome. Cheers, Martin Subject: Re: [therion] translating... From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 21 Jan 2005 09:36:56 +0100 To: therion@speleo.sk Just a question. What caving software is commonly used in Spain? I am preparing a list of softaware, that I would like to be supported via new import command. It allows people to draw maps without boring and complicated conversion of centerline data. Regards, S. Roman Muñoz wrote: > > OK, thanks > > May be you would get the texts_es.txt file? Also, may be I could send a > translated thbook_es.pdf (perhaps next month or so). I don't promise but it is now in my TODO list > because my caving friends don't worrry too much about learning english... > > Regards, > Roman > Subject: Re: [therion] translating... From: Martin Sluka <martinsluka@mac.com> Date: Fri, 21 Jan 2005 10:20:46 +0100 To: therion@speleo.sk At 22:23 +0100 20.1.2005, Roman =?ISO-8859-15?Q?Mu=F1oz?= wrote: ******************************************* > OK, thanks > > May be you would get the texts_es.txt file? Also, may be I could send a > translated thbook_es.pdf (perhaps next month or so). I don't promise but it is now in my TODO list > because my caving friends don't worrry too much about learning english... > > Regards, > Roman Maybe there is time to add Spanish section to wiki.speleo.sk/therion, isn't it. MartinS. -- Subject: Re: [therion] translating... From: Martin Sluka <martinsluka@mac.com> Date: Fri, 21 Jan 2005 10:48:44 +0100 To: therion@speleo.sk At 10:20 +0100 21.1.2005, Martin Sluka wrote: ******************************************* > wiki.speleo.sk/therion wiki.speleo.cz/therion . sorry MS. -- Subject: Re: [therion] translating... From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 21 Jan 2005 10:52:32 +0100 To: therion@speleo.sk Sorry, I did not finished this sentence in previous mail :) Stacho Mudrak wrote: >> underlying wall (a hidden wall under i.e. clay?) > > > In some cases, you underlying wall is used, when you do not wish to draw underlying passage in separate scrap. We used it for small passages under large blocks or something like that. Regards, S. Subject: Re: [therion] translating... From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Fri, 21 Jan 2005 11:10:31 +0100 (CET) To: therion@speleo.sk Hi Roman Roman Muńoz napsal(a): >> May be you would get the texts_es.txt file? Also, may be I could send a >> translated thbook_es.pdf (perhaps next month or so). I don't promise but >> it is now in my TODO list >> because my caving friends don't worrry too much about learning english... I created for you Spanish Therion book section on Wiki pages - http://wiki.speleo.cz/therion/doku.php?id=therion:therionbook ... We started on the same place also czechoslovak translation... Lada Blazek Subject: Re: translating... From: Wookey <wookey@aleph1.co.uk> Date: Fri, 21 Jan 2005 11:34:19 +0000 To: therion@speleo.sk +++ Roman Muñoz [05-01-20 02:12 +0100]: >> Hi >> >> After some playing with Therion, I'm quite happy... Now I'm considering to >> translate it to spanish... Question is: in the texts_es.txt file should I do Does therion use simple .txt files for translations? It occurs to me that if we are going to get into translations (and it's obviously a good thing) that it might be better to use the standard .po file mechanism for this. I don't know much about how it works but it seems to be used a lot and I assume it deals sensibly with things like character set problems? And we must get some standard tools to use etc. Just a suggestion. 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: translating... From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 21 Jan 2005 13:05:46 +0100 To: therion@speleo.sk Wookey wrote: > Does therion use simple .txt files for translations? No. Text files are only sources. In the compilation, they comes a part of binary executable. Not efficient, but very simple and reliable. > It occurs to me that if we are going to get into translations (and it's > obviously a good thing) that it might be better to use the standard .po file > mechanism for this. I don't know much about how it works but it seems to be > used a lot and I assume it deals sensibly with things like character set > problems? And we must get some standard tools to use etc. Well - my experience is, it does not a good job. All the programs I have been using in Slovak (including survex), were doing problems. I encountered problems with missing .po files (especially under Windows I had to set up environment variables) and missing or wrongly substituted characters. Well, in the future, we will certainly switch to .po files (we are forced to use them by WX in new model viewer), but now it would only slow down developement of more needed things. S. Subject: Re: [therion] Re: translating... From: Olly Betts <olly@survex.com> Date: Fri, 21 Jan 2005 12:11:34 +0000 To: Stacho Mudrak <s.m@speleo.sk> CC: therion@speleo.sk On Fri, Jan 21, 2005 at 01:05:46PM +0100, Stacho Mudrak wrote: >> Well - my experience is, it does not a good job. All the programs I have >> been using in Slovak (including survex), were doing problems. I >> encountered problems with missing .po files (especially under Windows I >> had to set up environment variables) and missing or wrongly substituted >> characters. Survex doesn't use .po files - it has its own i18n system (it was written before GNU gettext was!) There are a few .po files in the install, but they're from wxWindows. What are these problems with Survex and Slovak? I don't recall anyone reporting them to me... Cheers, Olly Subject: Re: [therion] Re: translating... From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 21 Jan 2005 13:21:06 +0100 To: therion@speleo.sk Olly Betts wrote: > What are these problems with Survex and Slovak? I don't recall anyone > reporting them to me... When I wanted to use cavern without survex installation - missing translation files. And in the old versions of survex, there were missing characters. But in the recent versions, characters are OK, but punctation is missing also for ISO8859-1 characters. But it is only only a cosmetic error, I can live with it. May be on Slovak version of windows, it is OK, but on my english one, it is not. On linux I do not know - I am not able to compile aven with configuration of wx I am using. If you are interested, I can send you log file sometimes. Regards, S. Subject: Re: [therion] Re: translating... From: "Martin Budaj" <m.b@speleo.sk> Date: Fri, 21 Jan 2005 13:24:30 +0100 (CET) To: therion@speleo.sk Olly Betts wrote: >> On Fri, Jan 21, 2005 at 01:05:46PM +0100, Stacho Mudrak wrote: > >>>> Well - my experience is, it does not a good job. All the programs I have >>>> been using in Slovak (including survex), were doing problems. I >>>> encountered problems with missing .po files (especially under Windows I >>>> had to set up environment variables) and missing or wrongly substituted >>>> characters. > >> >> Survex doesn't use .po files - it has its own i18n system (it was >> written before GNU gettext was!) There are a few .po files in the >> install, but they're from wxWindows. >> >> What are these problems with Survex and Slovak? I don't recall anyone >> reporting them to me... I get all Slovak characters unaccented in Aven 1.0.33 on Windows 2000. My experience is that wxWidgets in Unicode build work fine with .mo (compiled .po) files in utf-8 encoding, even for non-latin alphabets. Martin Subject: texts_es.tx From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 21 Jan 2005 13:12:08 +0100 To: therion@speleo.sk Hi, Here is the translated file. I observed there is no spanish translation in UIS symbols site, so I worked with some freedom, i,e on flute's case, which seems to be referred to 3 different things (marmitas (pits worked on rivers by pebbles), cupola (dome on the ceil) and channels For all those things about wiki, etc, please give me some time to get used with therion :) Cheers, Roman therion: point station:temporary es: estación topo temporal therion: point station:painted es: estación topo pintada therion: point station:natural es: estación topo natural therion: point station:fixed es: estación topo fija therion: line survey es: poligonal therion: point station-name es: nombre estacion topo therion: point entrance es: boca therion: line arrow es: flecha therion: line wall:bedrock es: pared therion: line wall:underlying es: pared subyacente therion: line wall:unsurveyed es: pared no topografiada therion: line wall:presumed es: pared supuesta therion: line wall:blocks es: bloques therion: line wall:debris es: derrubios therion: line wall:pebbles es: cantos rodados therion: line wall:sand es: arena therion: line wall:clay es: arcilla therion: line wall:ice es: hielo therion: point wall-altitude es: altura pared therion: point altitude es: altura therion: line section es: sección therion: point passage-height:unsigned es: altura therion: point passage-height:positive es: altura sobre nivel del mar therion: point passage-height:negative es: profundidad bajo nivel del mar therion: point passage-height:both es: altura y profundidad respecto nivel del mar therion: point air-draught es: corriente aire therion: point date es: fecha therion: point continuation es: continuación therion: point narrow-end es: final estrecho therion: point low-end es: final bajo therion: point flowstone-choke es: colmatado por concreción therion: point breakdown-choke es: colmatado por derrumbe therion: line floor-step es: resalte therion: line overhang es: extraplomo therion: line pit es: pozo therion: line ceiling-step es: resalte (techo) therion: line chimney es: chimenea therion: line gradient es: gradiente galería therion: point gradient es: gradiente galería therion: point height:unsigned es: altura resalte therion: point height:positive es: altura chimenea therion: point height:negative es: profundidad pozo therion: line contour es: contorno therion: line slope es: pendiente therion: line rock-border es: límite roca therion: line rock-edge es: arista therion: point bedrock es: roca madre therion: point blocks es: bloques therion: point debris es: derrubios therion: point sand es: arena therion: point clay es: arcilla therion: point water es: agua therion: point ice es: hielo therion: point pebbles es: cantos rodados therion: point raft es: calcita flotante therion: point guano es: guano therion: line border:visible es: límite therion: line border:temporary es: límite temporal therion: area water es: agua therion: area sump es: sifón therion: area debris es: derrubios therion: area sand es: arena therion: point waterflow:permanent es: curso agua therion: point waterflow:intermittent es: curso agua intermitente therion: point waterflow:paleo es: paleocurso agua therion: line waterflow:permanent es: curso agua therion: line waterflow:intermittent es: curso agua intermitente therion: line waterflow:conjectural es: curso agua supuesto therion: point spring es: surgencia therion: point sink es: sumidero therion: point flowstone es: concreción therion: line flowstone es: concreción therion: point moonmilk es: mondmilch therion: point stalactite es: estalactita therion: point stalagmite es: estalagmita therion: point pillar es: pilar therion: point curtain es: cortina therion: point soda-straw es: fistulosa therion: point popcorn es: coliflor therion: point cave-pearl es: perla de caverna therion: point disk es: disco therion: point helictite es: excéntrica therion: point aragonite es: aragonito therion: point crystal es: cristal therion: point wall-calcite es: calcita therion: point gypsum es: yeso therion: point gypsum-flower es: flor yeso therion: point rimstone-dam es: gour-presa therion: point rimstone-pool es: gour-poza therion: point anastomosis es: anastomosis therion: point karren es: lapiaz therion: point scallop es: golpes gubia therion: point flute es: canaleta therion: point raft-cone es: conos therion: point archeo-material es: yacimiento arq therion: point paleo-material es: yacimiento pal therion: point vegetable-debris es: detritus therion: point root es: raíz therion: point no-equipment es: sin equipar therion: point anchor es: anclaje therion: point rope es: cuerda therion: point rope-ladder es: escala therion: point fixed-ladder es: escala fija therion: point steps es: escalones therion: point traverse es: pasamanos therion: point bridge es: puente roca therion: point camp es: campamento therion: title legend es: Leyenda therion: title cave length es: Desarrollo therion: units m es: m therion: title cave depth es: Desnivel therion: title explo (plural) es: Exploración therion: title explo es: Exploración therion: title topo (plural) es: Espeleometría therion: title topo es: Espeleometría therion: title carto (plural) es: Espeleografía therion: title carto es: Espeleografía therion: title preview above es: Vista previa superior therion: title preview below es: Vista previa inferior therion: title surface bitmap es: Mapa superficie therion Digest of: get.401_500 Topics (messages 401 through 500): Re: translating... 401 by: Roman Muñoz 402 by: Olly Betts 403 by: Olly Betts 405 by: Olly Betts 406 by: Martin Budaj string list 404 by: Roman Muñoz 407 by: Martin Budaj 408 by: Roman Muñoz 409 by: Wookey 412 by: Martin Budaj 413 by: Stacho Mudrak 414 by: Martin Sluka 417 by: Eric Madelaine 418 by: Stacho Mudrak 419 by: Roman Muñoz 427 by: Stacho Mudrak SVG output from therion 410 by: John Pybus 411 by: Martin Budaj 415 by: Martin Sluka 416 by: Ladislav Blazek 420 by: Andrew Atkinson 421 by: John Pybus 422 by: John Pybus 423 by: Wookey 424 by: Olly Betts 425 by: Martin Budaj 426 by: Martin Sluka 428 by: Stacho Mudrak Re: Compilation Problems... 429 by: Thierry GONON 430 by: Martin Sluka 431 by: Roman Muñoz Therion 0.3.6 432 by: Martin Budaj 433 by: Ladislav Blazek 436 by: Stacho Mudrak therion protractor 434 by: Carlos Henrique Grohmann 435 by: Martin Budaj New version of therion software 437 by: Martin Sluka 438 by: Martin Sluka Picts of projects made in therion 439 by: Martin Sluka problem importing .3d file 440 by: Wookey 441 by: Martin Sluka 442 by: Stacho Mudrak 443 by: Stacho Mudrak 445 by: Wookey 446 by: Stacho Mudrak 448 by: Wookey 449 by: Stacho Mudrak 450 by: Wookey 451 by: Stacho Mudrak 452 by: Wookey 453 by: Martin Sluka 454 by: Wookey 455 by: Martin Sluka 456 by: Martin Sluka 457 by: Stacho Mudrak translation 444 by: Roman Muñoz translation on therion wiki 447 by: Roman Muñoz flowstone area needed 458 by: Wookey 459 by: Stacho Mudrak 460 by: Wookey translating types 461 by: Roman Muñoz 462 by: Stacho Mudrak 463 by: Roman Muñoz 464 by: Martin Sluka 465 by: Stacho Mudrak 466 by: Martin Sluka 467 by: Roman Muñoz 468 by: Stacho Mudrak 473 by: Roman Muñoz xtherion i18n 469 by: Stacho Mudrak 470 by: Ladislav Blazek 471 by: Stacho Mudrak 472 by: Ladislav Blazek 474 by: Roman Muñoz 477 by: Stacho Mudrak Re: Segfault when including survey data in plan 475 by: Wookey 476 by: Stacho Mudrak 479 by: Stacho Mudrak 480 by: Wookey 481 by: Wookey 482 by: Martin Sluka 483 by: Stacho Mudrak 484 by: Wookey 485 by: Stacho Mudrak Wiki 478 by: Ladislav Blazek windows binary translated 486 by: Roman Muñoz 487 by: Martin Budaj 488 by: Ladislav Blazek 491 by: Roman Muñoz 492 by: Martin Budaj 493 by: Roman Muñoz New snapshot 489 by: Stacho Mudrak 490 by: Stacho Mudrak devel snapshot - translations 494 by: Ladislav Blazek 496 by: Stacho Mudrak 498 by: Ladislav Blazek 499 by: Stacho Mudrak 500 by: Ladislav Blazek New developement snapshot. 495 by: Stacho Mudrak 497 by: Martin Sluka Subject: Re: [therion] translating... From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 21 Jan 2005 13:51:22 +0100 To: therion@speleo.sk I think Visual Topo is, by far, the more widely used one, at least by young people. My friends are using it, and there are caving groups from other regions who have translated Visual Topo's manual, etc. Those people would be very interested in getting their LRUD data in any software to change to. Toporobot was my election, because I was mac-based some years ago. But it wouldn't surprise me if I were the only one in Spain ;-) Really I know about only one caving group using (allegedly) toporobot, but yet I haven't see any toporobot survey not made by me. There are some older people still working with spreadsheets and AutoCAD. Those are not used to take LRUD data. In our group, for high grade surveys, working with total stations is not rare, at least on mines. We have quite a lot of roman mines who are being explored and surveyed. Government is very interested in getting some of them open to public. In this case my friends take a lot of... radiated points? they can't lose. These data goes finally into AutoCAD too. But wide use of survey software is less than 10 years old here (perhaps 5) so 80-90% of surveys are drawn on paper and centreline data is losed... this is one of the reasons making therion so interesting. Best regards, Roman On Fri, 21 Jan 2005 09:36:56 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> Just a question. What caving software is commonly used in Spain? Subject: Re: [therion] Re: translating... From: Olly Betts <olly@survex.com> Date: Fri, 21 Jan 2005 16:26:09 +0000 To: Stacho Mudrak <s.m@speleo.sk> CC: therion@speleo.sk On Fri, Jan 21, 2005 at 01:21:06PM +0100, Stacho Mudrak wrote: >> Olly Betts wrote: > >>> >What are these problems with Survex and Slovak? I don't recall anyone >>> >reporting them to me... > >> >> When I wanted to use cavern without survex installation - missing >> translation files. Normally you just install survex, so it's not something that I've ever seen the need to worry about. In the past it was important not to bloat the code with compiled in English messages and then load (say) Slovak ones in from disk. Back in the DOS 640K days, that could mean you couldn't process your cave system! That's not really such an issue now - 10K of messages is irrelevant when 128M of RAM is low end. But if the code works, why spend time and effort replacing it? It risks introducing bugs into a stable package. So as I've said before, if you want to install cavern alone, you'll need to fiddle a bit - either install the translation files somewhere they can be found using the default search rules in message.c, or modify the sources to look for them where you want, or even to compile the translations in. >> And in the old versions of survex, there were missing >> characters. But in the recent versions, characters are OK, but >> punctation is missing also for ISO8859-1 characters. I take it you mean missing accents? What codepage are you using? 1252 (Microsoft's tweaked version of iso-8859-1) is handled, but 1250 (MS's version of iso-8859-2) isn't (it's just a missing line of code so easy to fix). So if you're using codepage 1250, this'll be fixed in the next release. If not, let me know what you are using, and I'll see what's going wrong. >> On linux I do not know - I am not able to compile aven with >> configuration of wx I am using. If you are interested, I can send you >> log file sometimes. Aven won't build with a unicode build of wxWindows. My feeling is that the changes required are too invasive for Survex 1.0.X, especially since nobody has shown real interest in producing a wide character translation yet. If Aven won't build with a non-unicode of wx, let me know where it fails. Cheers, Olly Subject: Re: [therion] Re: translating... From: Olly Betts <olly@survex.com> Date: Fri, 21 Jan 2005 16:27:09 +0000 To: Martin Budaj <m.b@speleo.sk> CC: therion@speleo.sk On Fri, Jan 21, 2005 at 01:24:30PM +0100, Martin Budaj wrote: >> I get all Slovak characters unaccented in Aven 1.0.33 on Windows 2000. Which codepage? Cheers, Olly Subject: Re: [therion] Re: translating... From: Olly Betts <olly@survex.com> Date: Sat, 22 Jan 2005 02:44:02 +0000 To: therion@speleo.sk On Fri, Jan 21, 2005 at 04:26:09PM +0000, Olly Betts wrote: >> On Fri, Jan 21, 2005 at 01:21:06PM +0100, Stacho Mudrak wrote: > >>> > And in the old versions of survex, there were missing >>> > characters. But in the recent versions, characters are OK, but >>> > punctation is missing also for ISO8859-1 characters. > >> >> So if you're using codepage 1250, this'll be fixed in the next release. OK, Survex 1.0.34 (just released) should fix this, but I'm unable to check it myself. Can you check and confirm (or deny) that it's fixed? Cheers, Olly Subject: Re: [therion] Re: translating... From: "Martin Budaj" <m.b@speleo.sk> Date: Sat, 22 Jan 2005 23:21:57 +0100 (CET) To: therion@speleo.sk Olly Betts wrote: >>>>> > And in the old versions of survex, there were missing >>>>> > characters. But in the recent versions, characters are OK, but >>>>> > punctation is missing also for ISO8859-1 characters. >> >>>> >>>> So if you're using codepage 1250, this'll be fixed in the next release. > >> >> OK, Survex 1.0.34 (just released) should fix this, but I'm unable to >> check it myself. Can you check and confirm (or deny) that it's fixed? Now all characters are displayed correctly with accents. Only few strings remain untranslated (Help, Export as..., Exit), but that's other issue. Cheers, Martin Subject: string list From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 21 Jan 2005 23:59:53 +0100 To: Therion <therion@speleo.sk> Could you give me a list of strings to translate user interface? I started editing files in xtherion directory just for fun; after the first rush, I can see aprox 60% of my user interface in spanish. However, I'm getting some nasty errors about bad index entries because I feared to touch some things not marked label or text. I'm not a coder and this is the first time I see Tcl code. Fixed the first four or five errors, but detected others, and got a beautiful freeze just now. Expended more time debugging than translating. Regards, Roman Subject: Re: [therion] string list From: "Martin Budaj" <m.b@speleo.sk> Date: Sun, 23 Jan 2005 16:17:47 +0100 (CET) To: therion@speleo.sk >> Could you give me a list of strings to translate user interface? >> >> I started editing files in xtherion directory just for fun; after the >> first rush, I can see aprox 60% of my user interface in spanish. >> However, I'm getting some nasty errors about bad index entries because I >> feared to touch some things not marked label or text. I'm not a coder >> and this is the first time I see Tcl code. Fixed the first four or five >> errors, but detected others, and got a beautiful freeze just now. >> Expended more time debugging than translating. I'm afraid that xtherion is not really prepared for translations :-( Few months ago there was a discussion about translating it; I append the substantial parts. M. ---------- Forwarded message ---------- From: "Martin Budaj" <m.b@speleo.sk> To: therion@speleo.sk Date: Mon, 14 Jun 2004 13:12:49 +0200 (CEST) Subject: Re: [therion] new user .... >> - 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 ---------- Forwarded message ---------- From: Eric Madelaine <madelain@nerim.fr> To: therion@speleo.sk Date: Mon, 14 Jun 2004 23:05:31 +0200 Subject: Re: [therion] new user .... >> 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) ---------- Forwarded message ---------- From: Stacho Mudrak <s.m@speleo.sk> To: therion@speleo.sk Date: Tue, 15 Jun 2004 10:08:21 +0200 Subject: Re: new user .... >> 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 bre`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. ---------- Forwarded message ---------- From: Olly Betts <olly@survex.com> To: therion@speleo.sk Date: Tue, 15 Jun 2004 16:22:15 +0100 Subject: Re: [therion] new user .... 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, Subject: Re: [therion] string list From: Roman Muñoz <tatel@infonegocio.com> Date: Sun, 23 Jan 2005 18:52:19 +0100 To: therion@speleo.sk Martin, I understand how translating is a complex work. However, we are considering to organize some survey stages and need good software for it. I think therion is a serious candidate for many reasons. But we need it (mostly) translated because: First: obviously all the people needs get map output in their own languages, I think texts_xx.txt files are just for that. Right? Next, to have an untranslated user interface is one of the most scary things to my friends. If translated, they can play quite easy, and, being therion as good as really is, there is a probability for it to be adopted. But, with untranslated user interface, no chance. Friends will remain with Visual Topo, which is not bad software, and is translated. Third, thbook is very good as reference book, but it is not a starter guide IMHO. There was perhaps a year ago I see therion for the first time, getting a quite pretty headhache and running away with the tail between the legs. No offense intended. This time, I got it, but I'm really missing a starter guide so I could play with my first cave quickly. Input commands: Yes this is a problem. Friends are used to put their data, not to output commands. Language does not matter. Hopefully, to get a centreline for a "normal" cave seems not to need a lot of commands, so I was considering seriously to do some scripting work in order to get spreadsheet data converted to .th files, at least for easy caves. That mentioned (some days ago) import module would be great. But I could always do the stage with only some few commands and .th template files to explain how it works. Not so difficult. Console messages: If all the rest works smoothly, I don't care so much about them. May be am I making a mistake? So, if output map is in spanish thanks to texts_es.txt, next step is to get user interface translated too. I have map editor window fully translated and working now. I made a string list where file, line number and old/new strings are listed. I tested map editor and it seems to work OK. String list is not tested yet. I hope user interface will be fully translated next week. Newer versions of therion will probably change and may be this translation will become useless for them, I understand it. But at very least we will have one translated version to get people introduced to therion. BTW, it *must* to work in windows, this is the nastiest thing... After this, I'll be ready to start writing that starter guide, expect to get quite a lot of questions about therion tips, etc ;-) Only after this I could think about translating thbook reference Cheers, Roman Subject: Re: string list From: Wookey <wookey@aleph1.co.uk> Date: Sun, 23 Jan 2005 23:09:48 +0000 To: therion@speleo.sk +++ Roman Muñoz [05-01-23 18:52 +0100]: >> >> Next, to have an untranslated user interface is one of the most scary >> things to my friends. If translated, they can play quite easy, and, >> being therion as good as really is, there is a probability for it to be >> adopted. But, with untranslated user interface, no chance. Friends will >> remain with Visual Topo, which is not bad software, and is translated. You are quite right that everyone deserves an interface in theri native language, but therion is a trickier case than most software. Because the interface is really just an aid to editing the data files, thier format is exposed a great deal in the interface. I don't think it is practical or sensible for therion to have a different file format for every language, so some english will show through in the UI until someone writes a UI that hides the data format completely, and we are a long way from that now. However I'm sure a significant amount of UI translation is possible, whilst keeping the syntax the same. I assume that is what you are trying to do. It will make things a little more confusing by adding yet another layer of indirection (from the test in the UI to text in the file, which will only match up when the UI is english), but most of the time this will not be too much of a problem. >> Third, thbook is very good as reference book, but it is not a starter >> guide IMHO. There was perhaps a year ago I see therion for the first >> time, getting a quite pretty headhache and running away with the tail >> between the legs. No offense intended. This time, I got it, but I'm >> really missing a starter guide so I could play with my first cave >> quickly. I wrote one a year or so ago for therion 0.2.19. It is now a bit out of date, but I think it is the most useful existing starter guide. You can read it here: http://www.chaos.org.uk/~wookey/CP33.pdf Martin is working on including it in the thbook and.or website I think. I could write an 'intermediate' one now :-) >> After this, I'll be ready to start writing that starter guide, expect to >> get quite a lot of questions about therion tips, etc ;-) Only after this >> I could think about translating thbook reference Feel free to translate my article - it is GPL-licenced. 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: string list From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 24 Jan 2005 08:42:46 +0100 (CET) To: therion@speleo.sk Wookey wrote: >> You can read it here: >> http://www.chaos.org.uk/~wookey/CP33.pdf >> >> Martin is working on including it in the thbook and.or website I think. There were some pictures missing. I'll link your pdf directly from the web page. >> I could write an 'intermediate' one now :-) That would be really helpful ;-) Martin Subject: Re: [therion] string list From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 24 Jan 2005 08:57:56 +0100 To: therion@speleo.sk Roman Muñoz wrote: > First: obviously all the people needs get map output in their own > languages, I think texts_xx.txt files are just for that. Right? Yes, I will put it into 0.3.6. > Next, to have an untranslated user interface is one of the most scary > things to my friends. If translated, they can play quite easy, and, > being therion as good as really is, there is a probability for it to be > adopted. But, with untranslated user interface, no chance. Friends will > remain with Visual Topo, which is not bad software, and is translated. OK, putting all strings from xtherion to separate files should be a question of one evening. May be I should google for some tcl i18n package and it will be even easier. I will have a look, but it will not be in the next release. > caves. That mentioned (some days ago) import module would be > great. But I could always do the stage with only some few commands > and .th template files to explain how it works. Not so difficult. I will have a look at VTOPO once more. It looks to me, that importing it should not be a huge problem. Than, they will be enabled to use VTOPO for centerline processing and therion only for drawing of maps. > Console messages: If all the rest works smoothly, I don't care so much > about them. May be am I making a mistake? Again, if people are interested, putting all strings into translation macro is a question of hour or so. In therion, i18n is already working. Regards, S. Subject: [therion] Re: string list From: Martin Sluka <martinsluka@mac.com> Date: Mon, 24 Jan 2005 09:09:33 +0100 To: therion@speleo.sk At 23:09 +0000 23.1.2005, Wookey wrote: ******************************************* > I wrote one a year or so ago for therion 0.2.19. It is now a bit out of > date, but I think it is the most useful existing starter guide. > > You can read it here: > http://www.chaos.org.uk/~wookey/CP33.pdf Wookey, may you add your starter guide to wiki pages? TIA BR MS. -- Subject: Re: [therion] string list From: Eric Madelaine <Eric.Madelaine@sophia.inria.fr> Date: Mon, 24 Jan 2005 13:03:56 +0100 To: therion@speleo.sk CC: Eric.Madelaine@sophia.inria.fr s.m@speleo.sk said: >> Again, if people are interested, putting all strings into translation >> macro is a question of hour or so. In therion, i18n is already >> working. Well, I've not be very active here since the first french translation (for produced maps), but I guess that I could use this opportunity to come back (;-) s.m@speleo.sk said: >> I will have a look at VTOPO once more. It looks to me, that importing >> it should not be a huge problem. Than, they will be enabled to use >> VTOPO for centerline processing and therion only for drawing of maps. Yes Stacho, this can be a first useful approach. Of course there are many users of Vtopo in france (and more generaly in french) so this could be a large user community. A (not very optimised, but nevertheless useful scenario) scenario could be: - use your Vtopo data to print a centerline + LRUD information, draw and scan the onscale hand drawings (plan and extended elevation) - automaticaly get the therion centerline data - draw the scratches with therion map editor, and use some naming schemas to relate them. The fisrt limit to this approach is that Vtopo has no naming structure, so usually people get huge vtopo files with all surveyx of a given cave inside. At best they use the "merge" feature, when dealing with several caves in a given area (but the merge is based on entrance coordinates, and I've not found a way to twist this feature to deal with surveyx within a given cave, with potential joins inside). So you'll get a single big .th file, possibly with several survey sequence within (with diffrenet instruments settings and declination). No theoritcal problem there, just difficulties whne managing big dat sets. Eric. Subject: Re: [therion] string list From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 24 Jan 2005 14:36:08 +0100 To: therion@speleo.sk Eric Madelaine wrote: > Yes Stacho, this can be a first useful approach. > Of course there are many users of Vtopo in france (and more generaly in french) so this could be a large user community. I have played a little bit with VTopo with following results: 1. VTopo has PLT export :) => even existing developement version is able to to import centerline data in this format. 2. Parsing VTOPO .tro files should not be difficult also - but not in next version. In principle, both approaches are almost equivalent. User will have all stations imported to one survey. > A (not very optimised, but nevertheless useful scenario) scenario could be: - use your Vtopo data to print a centerline + LRUD information, draw and scan the onscale hand drawings (plan and extended elevation) Very soon, we will add support for passage dimensions to be drawn automatically on the background (as a background image). This should enable user to draw maps directly on the screen without printing>hand-drawing>scanning. > The fisrt limit to this approach is that Vtopo has no naming structure, so > usually people get huge vtopo files with all surveyx of a given cave inside. > > At best they use the "merge" feature, when dealing with several caves in a given area (but the merge is based on entrance coordinates, and I've not found a way to twist this feature to deal with surveyx within a given cave, with potential joins inside). > > So you'll get a single big .th file, possibly with several survey sequence within (with diffrenet instruments settings and declination). > No theoritcal problem there, just difficulties whne managing big dat sets. Well, if they do not wish to convert centerline data (they will keep them in original format and therion will be able to import VTopo .tro files), huge files are not necessary. In therion, you can input files without any survey command. And maps have also tree structure independent of surveys. Therefore you can have each piece of map in separate .th2 file and maps structure can be also divided into several .th files. If they would like to convert centerline data to therion -> it would be better for them to create survey structure from the beginning. But I think, that new user will be afraid of converting his dataset to "unknown" and "complicated" software. Especially, if there will be import command and maps can be drawn directly without this conversion. Regards, S. Subject: Re: [therion] string list From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 24 Jan 2005 16:53:29 +0100 To: therion@speleo.sk On Mon, 24 Jan 2005 14:36:08 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> 1. VTopo has PLT export :) => even existing developement version is >> able to to import centerline data in this format. >>(...) >> Very soon, we will add support for passage dimensions to be drawn >> automatically on the background (as a background image). This should >> enable user to draw maps directly on the screen without >> printing>hand-drawing>scanning. Very good news! BTW, I finished translation of user interface. I have a pipe-separated list of strings, with these fields: file|line number|original string|translated string| I can send to you if you think it could be useful. Best regards, Roman Subject: Re: [therion] string list From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 25 Jan 2005 10:05:17 +0100 To: therion@speleo.sk Roman Muñoz wrote: > BTW, I finished translation of user interface. I have a pipe-separated > list of strings, with these fields: > > file|line number|original string|translated string| > > I can send to you if you think it could be useful. I will have a look and let you know. In any case, translation will be a hash of translated strings with original string as key. So it will be probably very easy to use your file, when xtherion will be translated. But now we would like to finish 0.3.6 and release it. Then we can start working on these new things. Regards, S. Subject: SVG output from therion From: John Pybus <john@pybus.org> Date: Mon, 24 Jan 2005 00:31:04 +0000 To: therion@speleo.sk Hi, I've been investigating what it would take to get therion to produce SVG maps. I'm not too interested in replacing pdftex to produce atlases: output in pdf seems fine for that, but I find it hard to successfully convert pdfs with transparency into something I can edit and add into larger posters/publications. I note that tunnelX have recently acquired an SVG output module, but then they have it easy rendering through the Java2D API as they can just plug in Batik. Looking at the 0.3.5 sources I'd originally though that the output of metapost was used by pdftex, but I see that you parse the PS and write your own pdf fragments. Since SVG uses exactly same rendering model as pdf it should be easy enough to adapt this to produce SVG fragments also. With these, replacing pdftex for the job of stitching the fragments together into a map should be feasible. Do the developers have any comments on this? If it seems sensible to you then I'll have a go at an svg version of thconvert.cxx when I get some free time. Also, do you have a CVS/svn repository for the code? If so, would it be possible for that to be exposed read-only? I hate developing against point releases when I know that a project is still undergoing such active development. Cheers, John Subject: Re: [therion] SVG output from therion From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 24 Jan 2005 08:32:06 +0100 (CET) To: therion@speleo.sk >> Looking at the 0.3.5 sources I'd originally though that the output of >> metapost was used by pdftex, but I see that you parse the PS and write >> your own pdf fragments. Since SVG uses exactly same rendering model as >> pdf it should be easy enough to adapt this to produce SVG fragments >> also. With these, replacing pdftex for the job of stitching the >> fragments together into a map should be feasible. Yes, SVG is planned to be implemented in about a month. The PostScript parsing needs to be enhanced a bit (some simplifications were takan because of similarity of PS and PDF). The idea is to get only map in SVG (and other formats), leaving the Atlas for PDF. >> Also, do you have a CVS/svn repository for the code? If so, would it be >> possible for that to be exposed read-only? I hate developing against >> point releases when I know that a project is still undergoing such >> active development. We don't use online CVS repository -- I would have no possibility to access it. We used to put the development tarball on the web page every week or so, but that led only to confusion. M. Subject: Re: [therion] SVG output from therion From: Martin Sluka <martinsluka@mac.com> Date: Mon, 24 Jan 2005 12:34:06 +0100 To: therion@speleo.sk At 00:31 +0000 24.1.2005, John Pybus wrote: ******************************************* > Hi, > > I've been investigating what it would take to get therion to produce SVG maps. I just tested the possibility to read PDF from therion to Illustrator CS and exoport several other formats: CJ.pdf -> Illustrator Illustrator -> CJ.dxf CJ.eps CJ.html (for swf) CJ.svg CJ.swf Without any problem. It is about 16.5 MB, so may I give the samples to wiki? Martin -- Subject: Re: [therion] SVG output from therion From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Mon, 24 Jan 2005 13:02:36 +0100 (CET) To: therion@speleo.sk >> It is about 16.5 MB, so may I give the samples to wiki? Yes, no problem. But there is 2 MB/file upload limit on the server (when you uploading files via PHP). L.B Subject: RE: [therion] SVG output from therion From: "Andrew Atkinson" <andrew@wotcc.org.uk> Date: Mon, 24 Jan 2005 21:17:34 -0000 To: <therion@speleo.sk> >> >> I just tested the possibility to read PDF from therion to Illustrator >> CS and exoport several other formats: >> >> CJ.pdf -> Illustrator >> I have been doing this to purplish surveys, with the plan and elevation aligned. The text has been coming through as dots, but as I am new to illustrator, I was not going to say anything until I had investigated further. However now seems appropriate. While on the subject the grouping seems to be a little random, again not had time to investigate further, but if by some how the groups could be associated by scraps, that may make sense. Eg I rotated a plan to align with an elevation and therefore had to rotate the text and cross sections. The text was grouped together, nice and easy (if it had not been dots) but the cross sections where all over the place. As I said, I have now been using illustrator for a week so may be missing something. Andrew Subject: Re: [therion] SVG output from therion From: John Pybus <john@pybus.org> Date: Tue, 25 Jan 2005 01:19:56 +0000 To: therion@speleo.sk Martin Budaj wrote: >> Looking at the 0.3.5 sources I'd originally though that the output of >> metapost was used by pdftex, but I see that you parse the PS and write >> your own pdf fragments. Since SVG uses exactly same rendering model as >> pdf it should be easy enough to adapt this to produce SVG fragments >> also. With these, replacing pdftex for the job of stitching the >> fragments together into a map should be feasible. > > > Yes, SVG is planned to be implemented in about a month. The PostScript > parsing needs to be enhanced a bit (some simplifications were takan > because of similarity of PS and PDF). The idea is to get only map in SVG > (and other formats), leaving the Atlas for PDF. Sounds good news. Does this mean that it's not worth me trying to do any work on this myself, or that you'd appreciate any start I make before you get round to it? > We don't use online CVS repository -- I would have no possibility to > access it. We used to put the development tarball on the web page every > week or so, but that led only to confusion. Fair enough. Perhaps if it's not on the downloads page but a separate developers page it wouldn't be a cause of confusion. John Subject: Re: [therion] SVG output from therion From: John Pybus <john@pybus.org> Date: Tue, 25 Jan 2005 01:20:00 +0000 To: therion@speleo.sk Martin Sluka wrote: > At 00:31 +0000 24.1.2005, John Pybus wrote: > ******************************************* > >> Hi, >> >> I've been investigating what it would take to get therion to produce SVG maps. > > > I just tested the possibility to read PDF from therion to Illustrator CS and exoport several other formats: > > CJ.pdf -> Illustrator That's all well and good, but I don't have a copy of Illustrator, nor easy access to a computer with an OS which Illustrator is available for. John Subject: Re: SVG output from therion From: Wookey <wookey@aleph1.co.uk> Date: Tue, 25 Jan 2005 02:57:42 +0000 To: therion@speleo.sk +++ John Pybus [05-01-25 01:20 +0000]: >> >> That's all well and good, but I don't have a copy of Illustrator, nor >> easy access to a computer with an OS which Illustrator is available for. Use inkscape. A very fine SVG drawing package. It's quite new so some things are a bit 'not finished' but it's very reliable and good enough for most things and getting very good reviews all over (about time there was a decent vector package for GNU/Linux). 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: SVG output from therion From: Olly Betts <olly@survex.com> Date: Tue, 25 Jan 2005 03:10:34 +0000 To: therion@speleo.sk On Tue, Jan 25, 2005 at 02:57:42AM +0000, Wookey wrote: >> +++ John Pybus [05-01-25 01:20 +0000]: > >>> > That's all well and good, but I don't have a copy of Illustrator, nor >>> > easy access to a computer with an OS which Illustrator is available for. > >> >> Use inkscape. A very fine SVG drawing package. It's quite new so some things >> are a bit 'not finished' but it's very reliable and good enough for most >> things and getting very good reviews all over (about time there was a decent >> vector package for GNU/Linux). Looking at their site, it doesn't (yet) have PDF import, so it's not a good alternative to Illustrator in this situation. Cheers, Olly Subject: Re: [therion] SVG output from therion From: "Martin Budaj" <m.b@speleo.sk> Date: Tue, 25 Jan 2005 09:41:17 +0100 (CET) To: therion@speleo.sk John Pybus wrote: >>>> Yes, SVG is planned to be implemented in about a month. The PostScript >>>> parsing needs to be enhanced a bit (some simplifications were takan >>>> because of similarity of PS and PDF). The idea is to get only map in SVG >>>> (and other formats), leaving the Atlas for PDF. > >> >> Sounds good news. Does this mean that it's not worth me trying to do >> any work on this myself, or that you'd appreciate any start I make >> before you get round to it? I think it would be better not to try to extend current conversion to handle SVG. It's major drawback is line-by-line PS to PDF conversion, which saves memory, but is not usable for SVG or other formats. The conversion itself needs to be rewritten from scratch. Other topic is text handlig -- labels in SVG will probably not be processed by MetaPost, but directly by Therion, which adds more complexity to conversion. Martin Subject: Re: [therion] SVG output from therion From: Martin Sluka <martinsluka@mac.com> Date: Tue, 25 Jan 2005 09:53:24 +0100 To: therion@speleo.sk At 01:20 +0000 25.1.2005, John Pybus wrote: ******************************************* > That's all well and good, but I don't have a copy of Illustrator, nor easy access to a computer with an OS which Illustrator is available for. May you send me your PDFs? I'll send you back SVGs. Martin -- Subject: Re: [therion] SVG output from therion From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 25 Jan 2005 10:07:43 +0100 To: therion@speleo.sk John Pybus wrote: > Fair enough. Perhaps if it's not on the downloads page but a separate developers page it wouldn't be a cause of confusion. We have agreed yesterday, that we will put this link on download page. S. Subject: Re: [therion] Compilation Problems... From: Thierry GONON <thierrygonon@mac.com> Date: Tue, 25 Jan 2005 20:34:31 +0100 To: therion@speleo.sk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I finally find a few time to have a look to my problem with Therion. Thank to Martin's answer, it appears that my problem probably consists in my installation of Tk. I use the distribution that came with Grass 5.7. How could I remove it and install the standard aqua distribution (what do you mean by "batteries included" ?) Thank you very much Le 10 janv. 05, à 19:44, Martin Sluka a écrit : > Hi Thierry, > > I use Therion on MacOSX long time. There are same strange things, but > it normaly works OK. > > Known problems: > > version of Tcl - I have try the AlphaTk editor and this one uses the > higher version of Tcl. So I had to uninstall AlphaTk, repair > permissions, reinstall the Aqua Tcl/Tk including batteries and > recompile Therion. > > Sometimes the Tcl lost the connection to itself and frozes. But after > killing of Tcl (Ctrl+C in terminal) it is able to work again. > > My directory for Therion is inside of my home directory in forder > Caves. There are folders for other caves too. > > If I run xtherion: > > - I open the terminal > - change the directory to that with my data > - write xtherion and press return > > It normaly works. > > Martin S. > > At 11:51 +0200 10.1.2005, Thierry GONON wrote: > ******************************************* > >> Thank you for your answer... But it still don't work!! My system is >> OSX 10.3.7 (last update) and I'm running Tcl/Tk8.4 >> >> I've copied the file as indicated, but when I run xtherion, here's >> the answer of the terminal : >> Application initialization failed: no display name and no $DISPLAY >> environment variable >> Error in startup script: invalid command name "frame" >> while executing >> "frame .def" >> (file "./xtherion" line 232) >> >> When I try trough X11, the result is : >> Error in startup script: can't find package BWidget >> while executing >> "package require BWidget" >> (file "./xtherion" line 672) >> I've successfully installed BWidget (in the /Library/Tcl folder, >> the global one and in my personnal Tcl folder)... >> >> Best regards >> >> >> Le 10 janv. 05, ą 10:41, Stacho Mudrak a écrit : >> >>> Installation is still a problem on MacOSX :( It depends a lot on >>> the system version and version of Tcl/Tk. >>> >>> But installation is simple. All you need to do to install therion >>> is to copy therion executable (file named therion in compilation >>> directory) to the /usr/bin directory (you do not need to create >>> symbolic link for it). >>> >>> When therion is copied, you can run xtherion following way. >>> >>> 1. Go to the therion compilation directory. >>> 2. cd xtherion >>> 3. wish ./xtherion >>> >>> This works on all systems. You can try to copy also xtherion to >>> /usr/bin and run xtherion from anywhere, but on most systems it >>> gives error. >>> >>> Hope this helps. If not, we will find other way :) >>> >>> Regrads, S. >>> >>> Thierry GONON wrote: >>> >>>> Hello, >>>> I'm working on Mac OSX (previously working with Toporobot and >>>> intended to find another software, to compare...) and I've found >>>> Therion this week... >>>> So I've downloaded the sources to compile them, but during the >>>> /make install/ procedure, the Terminal answered : >>>> I don't know what are the two /--symbolic/ : file or directory?? >>>> Do I have to create them, as I do for the /Therion /and/ Xtherion/ >>>> directories?? >>>> Thank you very much, and enjoy caving!! >>>> Thierry GONON >>>> 2 Place de l'Eglise >>>> 01150 LAGNIEU >>>> FRANCE >>> >>> >> >> content-type: application/pgp-signature; x-mac-type=70674453; >> name=PGP.sig >> content-description: Ceci est une signature électronique PGP >> content-disposition: inline; filename=PGP.sig >> content-transfer-encoding: 7bit >> >> Attachment converted: Leveler:PGP.sig 1 (pgDS/----) (00007DA3) > > > > -- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB9p9H1Au96VwreaARAkhhAKC3JX7QKEIvKcXXHaYjcLYuOXtEqQCeNY1l ybkdrjVniRuW5CUm+y0Wq1M= =6Z6r -----END PGP SIGNATURE----- Subject: Re: [therion] Compilation Problems... From: Martin Sluka <martinsluka@mac.com> Date: Wed, 26 Jan 2005 09:25:33 +0100 To: therion@speleo.sk At 20:34 +0100 25.1.2005, Thierry GONON wrote: ******************************************* > Hello, > > I finally find a few time to have a look to my problem with Therion. Thank to Martin's answer, it appears that my problem probably consists in my installation of Tk. I use the distribution that came with Grass 5.7. This could be a problem - I have tried the AlphaTk editor and it uses developer version 5 of Tcl/Tk. > How could I remove it and install the standard aqua distribution I simply removed the AlphaTk application and reinstaled the latest Aqua Tcl again. And repaired permisions by Disk Utility. There should be much more inteligent way how to use both applications together, but I'm not an ..nix guru :( > (what do you mean by "batteries included" ?) As I understood there are two versions of instalator -- one installs only Tcl/Tk and second Tcl/Tk + many other libraries - "bateries". The second one installs the libraries for therion too. MartinS -- Subject: Re: [therion] Compilation Problems... From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 26 Jan 2005 19:52:55 +0100 To: therion@speleo.sk On Wed, 26 Jan 2005 09:25:33 +0100 Martin Sluka <martinsluka@mac.com> wrote: >> I simply removed the AlphaTk application and reinstaled the latest >> Aqua Tcl again. And repaired permisions by Disk Utility. There should >> be much more inteligent way how to use both applications together, >> but I'm not an ..nix guru :( Can you not have both versions installed? If both versions can be installed, it would be a matter of symbolic linking to the right version of TclTk before compiling therion, or (as suggested to me on this list a week ago) passing an -I /path/to/tcltk/ to therions compilation. Hope this helps, Roman Subject: Therion 0.3.6 From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 31 Jan 2005 12:11:09 +0100 (CET) To: therion@speleo.sk Hi all, new Therion is available for download. It includes a lot of improvements and fixes. Cheers, Martin ------------------------------- List of most important changes: therion: * LRUD passage dimensions support * centreline processed in other programs (*.3d, *.plt) may be imported * transparent solid surface in 3D model * map colouring support * map grid support * if station subtype is not specified, Therion reads it from centreline, if it's specified there * MetaPost symbols completed and improved (error handling, division by zero fixed) * scrap filled and clipped correctly even if scrap border intersects itself * centerline, bounding box and surface supported in 3DMF and VRML export * Spanish translation added * input language changes: - centreline command: mark, walls, vtreshold; + new role pics + new data item ignoreall + new data type dimensions (station, up/ceiling, down/floor, left, right) + LRUD dimensions may specified as pair [<from> <to>] - point command: snow - line command: ceiling/floor-meander, border:presumed + line gradient and water-flow not clipped by default - area command: blocks, snow, ice, clay, pebbles - scrap command: -3d changed to -walls option - equate command: may be used outside of centreline - import command added * configuration file changes: - layout command: grid, grid-size, code/endcode, color map-fg <altitude/map>, color-legend xtherion: * new items in xtherion.ini * file timestamps are checked while saving * auto save feature * lot of bugfixes * Map editor: new shortcuts (ctrl-a, ctrl-r, page up/down, shift page up/down) * Map editor: clicking twice on the same point ends the point insertion mode * Map editor: station names are automatically increased (or decreased :) in extended elevation) Subject: Re: [therion] Therion 0.3.6 From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Mon, 31 Jan 2005 12:58:54 +0100 (CET) To: therion@speleo.sk Hi Martin, do you have some example files for testing of new features in version 0.3.6? L. Martin Budaj napsal(a): >> Hi all, >> >> new Therion is available for download. It includes a lot of improvements >> and fixes. >> >> Cheers, >> Martin >> >> ------------------------------- >> List of most important changes: >> >> therion: >> >> * LRUD passage dimensions support >> * centreline processed in other programs (*.3d, *.plt) may be imported >> * transparent solid surface in 3D model >> * map colouring support >> * map grid support >> * if station subtype is not specified, Therion reads it from centreline, >> if it's specified there >> * MetaPost symbols completed and improved (error handling, >> division by zero fixed) >> * scrap filled and clipped correctly even if scrap border intersects >> itself >> * centerline, bounding box and surface supported in 3DMF and VRML export >> * Spanish translation added >> * input language changes: >> - centreline command: mark, walls, vtreshold; >> + new role pics >> + new data item ignoreall >> + new data type dimensions >> (station, up/ceiling, down/floor, left, right) >> + LRUD dimensions may specified as pair [<from> <to>] >> - point command: snow >> - line command: ceiling/floor-meander, border:presumed >> + line gradient and water-flow not clipped by default >> - area command: blocks, snow, ice, clay, pebbles >> - scrap command: -3d changed to -walls option >> - equate command: may be used outside of centreline >> - import command added >> * configuration file changes: >> - layout command: grid, grid-size, code/endcode, color map-fg >> <altitude/map>, >> color-legend >> >> xtherion: >> >> * new items in xtherion.ini >> * file timestamps are checked while saving >> * auto save feature >> * lot of bugfixes >> * Map editor: new shortcuts (ctrl-a, ctrl-r, page up/down, shift page >> up/down) >> * Map editor: clicking twice on the same point ends the point insertion >> mode >> * Map editor: station names are automatically increased (or decreased :) >> in >> extended elevation) >> >> -- Ladislav Blazek Subject: Re: [therion] Therion 0.3.6 From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 01 Feb 2005 16:06:54 +0100 To: therion@speleo.sk The answer is no. I have started to work on a set of therion samples (minimal sample for each feature), but it is still only a concept and currently there is no time for that :( Regards, S. Ladislav Blazek wrote: > Hi Martin, > do you have some example files for testing of new features in version 0.3.6? > > L. Subject: therion protractor From: Carlos Henrique Grohmann <guano@usp.br> Date: Mon, 31 Jan 2005 13:04:53 -0200 To: therion@speleo.sk Hello, I'm a geologist/speleologist in Brazil. I find the Therion Protractor in the www and find it very useful, but here we use more often a 1:400 scale. I have printed the protractor at 50% of the original size, but the results were not so good, so I was thining if you could send me a vetorial version of it (in degrees), either in SVG, CDR,WMF or any other format. thank you so much cheers Carlos Grohmann - Guano -- +----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - guano at usp dot br +----------------------------------------------------------+ Subject: Re: [therion] therion protractor From: "Martin Budaj" <m.b@speleo.sk> Date: Tue, 1 Feb 2005 16:03:09 +0100 (CET) To: therion@speleo.sk >> I'm a geologist/speleologist in Brazil. I find the Therion Protractor in >> the >> www >> and find it very useful, but here we use more often a 1:400 scale. I have >> printed the protractor at 50% of the original size, but the results were >> not so >> good, so I was thining if you could send me a vetorial version of it (in >> degrees), either in SVG, CDR,WMF or any other format. Attached is protractor 1:400 in PDF format in two sizes. One of the next versions of Therion (hopefully 0.3.7) will contain an easy-to-use interface to generate the protractor in any combination of scale/length units/angle units. Cheers, Martin Subject: New version of therion software From: Martin Sluka <martinsluka@mac.com> Date: Wed, 2 Feb 2005 10:49:04 +0100 To: therion@speleo.sk ------------------------------------------------------------------------ -------- Therion 0.3.6 (2005-01-31): therion: * LRUD passage dimensions support * centreline processed in other programs (*.3d, *.plt) may be imported * transparent solid surface in 3D model * map colouring support * map grid support * if station subtype is not specified, Therion reads it from centreline, if it's specified there * MetaPost symbols completed and improved (error handling, division by zero fixed) * scrap filled and clipped correctly even if scrap border intersects itself * centerline, bounding box and surface supported in 3DMF and VRML export * Spanish translation added * input language changes: - centreline command: mark, walls, vtreshold; + new role pics + new data item ignoreall + new data type dimensions (station, up/ceiling, down/floor, left, right) + LRUD dimensions may specified as pair [<from> <to>] - point command: snow - line command: ceiling/floor-meander, border:presumed + line gradient and water-flow not clipped by default - area command: blocks, snow, ice, clay, pebbles - scrap command: -3d changed to -walls option - equate command: may be used outside of centreline - import command added * configuration file changes: - layout command: grid, grid-size, code/endcode, color map-fg <altitude/map>, color-legend xtherion: * new items in xtherion.ini * file timestamps are checked while saving * auto save feature * lot of bugfixes * Map editor: new shortcuts (ctrl-a, ctrl-r, page up/down, shift page up/down) * Map editor: clicking twice on the same point ends the point insertion mode * Map editor: station names are automatically increased (or decreased :) in extended elevation) -- Subject: Re: [therion] New version of therion software From: Martin Sluka <martinsluka@mac.com> Date: Wed, 2 Feb 2005 11:29:26 +0100 To: therion@speleo.sk Sorry, it was private mail. Martin S. -- Subject: Picts of projects made in therion From: Martin Sluka <martinsluka@mac.com> Date: Thu, 3 Feb 2005 12:09:02 +0100 To: therion@speleo.sk Dear friends, we are looking to write an article about therion - main part of article should be the realised surveying projects made with help of therion. May you help us and if possible to send picts (PDFs) - of your maps? Only outlines and headers and a few details -localisation (country, region), part of which project is particular map, length, maybe interesting detail of map. You may use next layout settings for the whole map: scale 1 1000 color map-fg 70 color map-bg 100 symbol-hide group all symbol-show line wall transparency on opacity 70 All maps will be published from bitmaps. TIA Martin Sluka -- Subject: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Mon, 7 Feb 2005 03:17:18 +0000 To: Therion List <therion@speleo.sk> OK - I'm trying to use the new import feature in 0.3.6. I'm not sure how the namespace hierarchy works. I have a survex dataset where everything is under terikan so we have major surveys terikan.goon terikan.eagle terikan.eagle2 terikan.elevator terikan.evening etc The .th file looks like: ------ survey tmp import terikan.3d survey terikan -title "Terikan River Caves" -declination [0.511 degrees] map elevatorplan -title "Terikan River Cave: Elevator entrance" goon_s3 break goon_s1 etc... input goon.th2 input soundriver.th2 etc... -------- This fails with: reading source files ... done preprocessing database ... done therion: error -- terikan/terikan.th [3] -- station doesn't exist -- eagle2.15 This is odd because there is no mention of eagle2 in any of the files in this dir. I'm not sure why it gets mentioned. The error is referencing the "import" line. If I comment out everything apart from the import line then the processing completes without error. Adding an empty file that continas nothing more than survey terikan endsurvey terikan will make it break again (same error). Changing the survey name to survey goon endsurvey goon Processes fine. Changing it to survey goon input goon.th2 endsurvey goon Now gives the error: therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- invalid station reference -- 69@goon (see below) Now going back to the original file and moving the input command inside the 'survey terikan' context: ------ survey terikan -title "Terikan River Caves" -declination [0.511 degrees] import terikan.3d map elevatorplan -title "Terikan River Cave: Elevator entrance" goon_s3 ... ------ I get a different error, having got rather further: 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 ... therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- invalid station reference -- 69@goon This suggests that the correct level to import things is inside a survey of the same name as the top level of the .3d file - correct? terikan.goon.69 is a valid station. It is the fiurst station mentioned in the first .th2 file read in. This suggests that it hasn't been read at the right level? Changing to put another .th2 file first changes the error to refer to the first station in that file instead. I'm confused - how should this feature be used? Is there a bug, or am I just doing it 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: [therion] problem importing .3d file From: Martin Sluka <martinsluka@mac.com> Date: Mon, 7 Feb 2005 07:30:47 +0100 To: therion@speleo.sk At 03:17 +0000 7.2.2005, Wookey wrote: ******************************************* > The .th file looks like: > ------ > survey tmp > import terikan.3d > > survey terikan -title "Terikan River Caves" -declination [0.511 degrees] > > map elevatorplan -title "Terikan River Cave: Elevator entrance" > goon_s3 break > goon_s1 > etc... > input goon.th2 > input soundriver.th2 > etc... > -------- > > This fails with: > reading source files ... done > preprocessing database ... done > therion: error -- terikan/terikan.th [3] -- station doesn't exist -- eagle2.15 Stacho and MartinB will explain this better, but if I try to check the part of cave I should use something as: survey test map elevatorplan -title "Terikan River Cave: Elevator entrance" goon_s3 break goon_s1 etc... endmap survey tmp import terikan.3d survey terikan -title "Terikan River Caves" -declination [0.511 degrees] # map elevatorplan -title "Terikan River Cave: Elevator entrance" # goon_s3 # break # goon_s1 # etc... input goon.th2 input soundriver.th2 etc... -------- endsurvey #tmp endsurvey #test The reference to the stations in map-endmap should be one level DOWN in survey hierarchy - as I understood this. Martin -- Subject: Re: [therion] problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 07 Feb 2005 10:03:24 +0100 To: therion@speleo.sk Wookey wrote: > OK - I'm trying to use the new import feature in 0.3.6. > I'm not sure how the namespace hierarchy works. > > I have a survex dataset where everything is under terikan > so we have major surveys > terikan.goon > terikan.eagle > terikan.eagle2 > terikan.elevator > terikan.evening > etc > > The .th file looks like: > ------ > survey tmp > import terikan.3d > > survey terikan -title "Terikan River Caves" -declination [0.511 degrees] > > map elevatorplan -title "Terikan River Cave: Elevator entrance" > goon_s3 break goon_s1 > etc... > input goon.th2 > input soundriver.th2 > etc... > -------- So far everything looks OK. > This fails with: > reading source files ... done > preprocessing database ... done > therion: error -- terikan/terikan.th [3] -- station doesn't exist -- eagle2.15 ... this is a bug. Import command (terikan/terikan.th [3]) should never throw such an exception. Are you able to send me some files, that generate this sort of error? > This is odd because there is no mention of eagle2 in any of the files in > this dir. I'm not sure why it gets mentioned. The error is referencing the > "import" line. If I comment out everything apart from the import line then > the processing completes without error. Adding an empty file that continas > nothing more than survey terikan > endsurvey terikan > will make it break again (same error). > Changing the survey name to survey goon > endsurvey goon > Processes fine. OK - now I am guessing where the error is - I will try to find and fix it. > Changing it to survey goon > input goon.th2 > endsurvey goon > Now gives the error: > therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- invalid station reference -- 69@goon > (see below) This is OK - you are trying to reference goon survey in goon context (so in upper context it is a survey goon.goon). > Now going back to the original file and moving the input command inside the 'survey terikan' context: > ------ > survey terikan -title "Terikan River Caves" -declination [0.511 degrees] > import terikan.3d > > map elevatorplan -title "Terikan River Cave: Elevator entrance" > goon_s3 ... > ------ > > I get a different error, having got rather further: > 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 ... therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- > invalid station reference -- 69@goon Again the same error. > This suggests that the correct level to import things is inside a survey of > the same name as the top level of the .3d file - correct? The correct is your first try. If you have in your .3d file all stations named terikan.*, then import terikan.3d must be outside terikan survey. > I'm confused - how should this feature be used? > > Is there a bug, or am I just doing it wrong? Yes, there is probably some bug. I will chech it. Regards, S. Subject: Re: [therion] problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 07 Feb 2005 10:29:56 +0100 To: therion@speleo.sk I have tried to reproduce your error - but without success :( On my machine import works fine (see attached minimal sample). To fix this problem - I need some data where it fails. Thanks, S. Wookey wrote: > OK - I'm trying to use the new import feature in 0.3.6. > I'm not sure how the namespace hierarchy works. > > I have a survex dataset where everything is under terikan > so we have major surveys > terikan.goon > terikan.eagle > terikan.eagle2 > terikan.elevator > terikan.evening > etc > > The .th file looks like: > ------ > survey tmp > import terikan.3d > > survey terikan -title "Terikan River Caves" -declination [0.511 degrees] > > map elevatorplan -title "Terikan River Cave: Elevator entrance" > goon_s3 break goon_s1 > etc... > input goon.th2 > input soundriver.th2 > etc... > -------- > > This fails with: > reading source files ... done > preprocessing database ... done > therion: error -- terikan/terikan.th [3] -- station doesn't exist -- eagle2.15 > > This is odd because there is no mention of eagle2 in any of the files in > this dir. I'm not sure why it gets mentioned. The error is referencing the > "import" line. If I comment out everything apart from the import line then > the processing completes without error. Adding an empty file that continas > nothing more than survey terikan > endsurvey terikan > will make it break again (same error). > Changing the survey name to survey goon > endsurvey goon > Processes fine. > > Changing it to survey goon > input goon.th2 > endsurvey goon > Now gives the error: > therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- invalid station reference -- 69@goon > (see below) > > Now going back to the original file and moving the input command inside the 'survey terikan' context: > ------ > survey terikan -title "Terikan River Caves" -declination [0.511 degrees] > import terikan.3d > > map elevatorplan -title "Terikan River Cave: Elevator entrance" > goon_s3 ... > ------ > > I get a different error, having got rather further: > 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 ... therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- > invalid station reference -- 69@goon > > This suggests that the correct level to import things is inside a survey of > the same name as the top level of the .3d file - correct? > > terikan.goon.69 is a valid station. It is the fiurst station mentioned in > the first .th2 file read in. This suggests that it hasn't been read at the > right level? > > Changing to put another .th2 file first changes the error to refer to the > first station in that file instead. > > I'm confused - how should this feature be used? > > Is there a bug, or am I just doing it wrong? > > Wookey Subject: Re: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Mon, 7 Feb 2005 12:08:26 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-07 10:29 +0100]: >> I have tried to reproduce your error - but without success :( >> >> On my machine import works fine (see attached minimal sample). To fix >> this problem - I need some data where it fails. http://wookware.org/terikan20050207.tgz (I'm using the recently-released 0.3.6 BTW) 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: problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 07 Feb 2005 16:19:22 +0100 To: therion@speleo.sk It was dirty bug, but it should be fixed now. I have put new developement snapshot on the downloads page. Your sample seems to works now. Regards, S. Wookey wrote: > +++ Stacho Mudrak [05-02-07 10:29 +0100]: > >> I have tried to reproduce your error - but without success :( >> >> On my machine import works fine (see attached minimal sample). To fix this problem - I need some data where it fails. > > > > http://wookware.org/terikan20050207.tgz > > (I'm using the recently-released 0.3.6 BTW) > > Wookey Subject: Re: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Tue, 8 Feb 2005 03:05:52 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-07 16:19 +0100]: >> It was dirty bug, but it should be fixed now. I have put new >> developement snapshot on the downloads page. Your sample seems to works now. Thanx again for the speedy fixes. Downloaded, built, and tested. Something very odd happenned the first time I ran it. It seemed to run through lots of data, looking like everything was fixed andthen it came up with a 'duplicate survey error - dummy' error. It turned out that this was due to the thconfig file being 'doubled' - it had had a second copy of itself added to the end (thus including index.th twice, hence the duplicate survey error). However having fixed that it now seems to process OK, so I'm not sure if this is a bug or finger trouble on my part, but I'm fairly sure I didn't mess it up. However - whilst it now processes a 'null' set of data as in the example, as soon as I put back any data it goes wrong again: input goon.th2 (inside the terikan survey) and I get: therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- invalid station reference -- 69@goon Now it doesn't seem to matter whether the terikan.3d file is included inside or outside the terikan survey context, or even not included at all - I get the same erro in each case. The .3d file is being read because I get a cave.3d file out that looks fine (i.e. looks just the same as the terikan.3d file). So - any clues? You can test this by just uncommenting line 47 of the 20050207 dataset you have. 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: problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 08 Feb 2005 08:53:43 +0100 To: therion@speleo.sk Wookey wrote: > However - whilst it now processes a 'null' set of data as in the example, as > soon as I put back any data it goes wrong again: > input goon.th2 > (inside the terikan survey) and I get: > therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- > invalid station reference -- 69@goon Well - I expected that you will report this error :) OK - the problem is - when stations are imported, they are inserted into subsurveys _if and only if this subsurvey exists_. In your example - you have no survey goon defined, therefore terikan.goon.69 is interpreted like goon.69@terikan. We came to conclusion, that this arrangement is better, like if subsurveys will be created - because we usually use "." in station names within single survey. If therion would have import command before - you would probably reference stations like goon.69 and you would not create any survey structure. So this problem is probably only in the case - when somebody converted his surveys first and then he tries to use import command instead. You can solve your problem three ways: 1. Define empty surveys at the beginning of the file import terikan.3d survey terikan survey goon endsurvey ... the same for each used survey endsurvey terikan ... and it should work. This is easiest solution. 2. Convert everything XX@YY into YY.XX using regexp replace. A little bit more work - but very clean solution. 3. Persuade us to modify therion in a way - that subsurveys will be created (may be into some - "user specified" - level). It is a litle bit more work on our side, but if you will have good arguments for it - no problem. Regards, S. Subject: Re: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Tue, 8 Feb 2005 15:39:21 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-08 08:53 +0100]: >> Wookey wrote: > >>> >However - whilst it now processes a 'null' set of data as in the example, >>> >as >>> >soon as I put back any data it goes wrong again: >>> >input goon.th2 >>> >(inside the terikan survey) and I get: >>> >therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon -- >>> >invalid station reference -- 69@goon > >> >> Well - I expected that you will report this error :) You could have mentionned it so I didn't spend two hours trying to work out if I was just being dumb... :-/ >> OK - the problem is - when stations are imported, they are inserted into >> subsurveys _if and only if this subsurvey exists_. In your example - you >> have no survey goon defined, therefore terikan.goon.69 is interpreted >> like goon.69@terikan. >> >> If therion would have import command before - you would probably >> reference stations like goon.69 and you would not create any survey >> structure. So this problem is probably only in the case - when somebody >> converted his surveys first and then he tries to use import command instead. True. Although it might be useful if it was possible to use the same dataset with either an import command or a set of converted svx->therion data. In this case the station references in the scrpas need to be consistent, and probably need to be 69@goon, not goon.69@ This makes the scraps modular so they can be put together in different ways without too much knowledge of the surrounding structure. Modularity in data is something we should strive for as much as possible. This discussion brings up another point I wanted to raise. The fact that I have to add a fake top-level survey in order to include a .3d file seems to me to be very naff. There must be a better solution. If I have a therion dataset inside survey terikan endsurvey terikan And a survex dataset which has terikan as the top level then it ought to be possible to put them together without having to makew the structure be survey dummy import terikan.3d survey terikan endsurvey terikan endsurvey dummy Maybe we need a concept like the -p1 in patch to tell it how many levels to strip off the input dataset in order to import it correctly? This is particularly an issue if I have a big dataset for the area containing several caves (Which I do:) We actually have top level: mulu (whole area) 2nd level: benarat - mountain api - another mountain 3rd level: terikan - cave bluemoon - cave cobweb - cave etc. So ideally I would want to import the top-level .3d file that included all the GPS fixes, surface surveys, surface loop closures etc - i.e the best possible relative fit of all the cave positions. Then use this at various places in the therion dataset for therion to draw separate surveys with. I can do this with the current version of therion by adding lots of empty surveys to match this structure, although still with the extra top-level 'dummy' which I don't like. It would definately be better to be able to say 'import ignoring the top 2 levels'. Ideal would be for Therion to look at the imported structure and try to match a level to the current survey level (this won't work if there are two surveys with the same name at different levels, but I don't think that happens often in real datasets?). It is obvious to a person that if a dataset contains terikan which contains goon, and the therion dataset has survey terikan and load of references to goon below then it matches up. It would be good if the computer could do that too, although I realise this is not trivial in practice. >> You can solve your problem three ways: >> >> 1. Define empty surveys at the beginning of the file >> >> import terikan.3d >> survey terikan >> survey goon >> endsurvey >> ... the same for each used survey >> endsurvey terikan >> >> ... and it should work. This is easiest solution. but it is naff :-) >> 2. Convert everything XX@YY into YY.XX using regexp replace. A little >> bit more work - but very clean solution. Except that it means I can't go back to using a full-therion dataset without changing all the structure round. I shouldn't have to decide before starting all the drawing whether I am going to get the station positions from a therion dataset or a survex dataset - it should be possible to do both with the same set of scraps. >> 3. Persuade us to modify therion in a way - that subsurveys will be >> created (may be into some - "user specified" - level). It is a litle bit >> more work on our side, but if you will have good arguments for it - no >> problem. OK- right, I am understanding the problem now. With a full therion dataset we have each survey explicitly created. With an imported survex dataset this does not happen. I think the importing of the dataset should implicitly create the hierarchy, at least so that references in .th2 files can 'just work' without us having to explicitly re-specify it in .th files. I think there is enough data in the .3d file to do this? At the very least we need a detailed explanation of this for the time being as it's not at all obvious :-) 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: problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 08 Feb 2005 17:05:35 +0100 To: therion@speleo.sk Wookey wrote: > You could have mentionned it so I didn't spend two hours trying to work out > if I was just being dumb... :-/ I am sorry... But as far as I remember, I sent you working sample of your data with import 3D file week or two ago... There was a solution with empty surveys - it could give you at least a small hint. OK - next time I will write some warnings to new stuff... > This discussion brings up another point I wanted to raise. The fact that I > have to add a fake top-level survey in order to include a .3d file seems to > me to be very naff. There must be a better solution. This I have already in TODO. I agree with you - I do not like it neither. I will try to arrange things, that no top level survey - endsurvey commands will be needed (default context will be survey - even no survey will be created). > Maybe we need a concept like the -p1 in patch to tell it how many levels to > strip off the input dataset in order to import it correctly? This is very good idea - very simple to implement. I will do it ASAP. > Ideal would be for Therion to look at the imported structure and try to > match a level to the current survey level (this won't work if there are two > surveys with the same name at different levels, but I don't think that > happens often in real datasets?). May be second step. > Except that it means I can't go back to using a full-therion dataset without > changing all the structure round. I shouldn't have to decide before starting > all the drawing whether I am going to get the station positions from a > therion dataset or a survex dataset - it should be possible to do both with > the same set of scraps. OK - you are probably right. > OK- right, I am understanding the problem now. With a full therion dataset > we have each survey explicitly created. With an imported survex dataset this > does not happen. I think the importing of the dataset should implicitly > create the hierarchy, at least so that references in .th2 files can 'just > work' without us having to explicitly re-specify it in .th files. I think > there is enough data in the .3d file to do this? The reason why I did not do this was, that it was again quite deep change in the complicated part of the code. But I can have a look at it once more - may be it is more simple than it looks at first sight (like a lot of other things were :-)). So until it will not be finished - you will have to create empty surveys... Regards, S. Subject: Re: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Tue, 8 Feb 2005 16:40:22 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-08 17:05 +0100]: >> Wookey wrote: > >>> >You could have mentionned it so I didn't spend two hours trying to work out >>> >if I was just being dumb... :-/ > >> >> I am sorry... But as far as I remember, I sent you working sample of >> your data with import 3D file week or two ago... There was a solution >> with empty surveys - it could give you at least a small hint. Did you? I seem to have failed to look at that/appreciate it. I didn't mean to complain too much - you are doing a brilliant job overall. It was just that I spend a couple of hours trying it again and find it doesn't work and you say 'ah yes I thought youd say that' :-) >> OK - next time I will write some warnings to new stuff... That would be good - I have far toomany things going on at once and tend to forget mails from more than a couple of days ago. (my inbox is 5800 at the moment, growing at about 50/day). >> So until it will not be finished - you will have to create empty surveys... no problem. Not that I understand what is going on - thanx for the prompt explanation. (the survey I was supposed to finish in mid-jan is now going to be rather late...) 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: problem importing .3d file From: Martin Sluka <martinsluka@mac.com> Date: Tue, 8 Feb 2005 18:07:32 +0100 To: therion@speleo.sk At 15:39 +0000 8.2.2005, Wookey wrote: ******************************************* > We actually have > top level: mulu (whole area) > 2nd level: benarat - mountain > api - another mountain > 3rd level: terikan - cave > bluemoon - cave > cobweb - cave > etc. It looks you waited for therion with this project, isn't it. :) Me too - 25 years old survey project of Cachtice cave. Good luck! Martin S. -- Subject: Re: problem importing .3d file From: Wookey <wookey@aleph1.co.uk> Date: Tue, 8 Feb 2005 18:29:18 +0000 To: therion@speleo.sk +++ Martin Sluka [05-02-08 18:07 +0100]: >> At 15:39 +0000 8.2.2005, Wookey wrote: >> ******************************************* >> > >>> >We actually have >>> >top level: mulu (whole area) >>> >2nd level: benarat - mountain >>> > api - another mountain >>> > 3rd level: terikan - cave >>> > bluemoon - cave >>> > cobweb - cave >>> > etc. > >> >> It looks you waited for therion with this project, isn't it. :) Me >> too - 25 years old survey project of Cachtice cave. I have indeed been waiting since about 1994 for something like Therion, before I decided to commit a lot of time to digitising cave survey drawings. I have avoided using things like coreldraw/Xara/freehand in the meantime as I didn't want to get data stuck in a proprietary format. The mulu data for the system I am currently drawing comes from 1984-2003. (and the early stuff is drawings-only - hence some of my earlier questions about that). I need to get it drawn up before the next expo in spring 2005.... 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: problem importing .3d file From: Martin Sluka <martinsluka@mac.com> Date: Wed, 9 Feb 2005 08:34:12 +0100 To: therion@speleo.sk At 18:29 +0000 8.2.2005, Wookey wrote: ******************************************* > The mulu data for the system I am currently drawing comes from 1984-2003. > (and the early stuff is drawings-only - hence some of my earlier questions > about that). > > I need to get it drawn up before the next expo in spring 2005.... Exact (only in scale 1:100) - the "my" cave was digged and partly explored in half past of 50th. The first map wass only 750 m and about 0,5 km nonsurveyed passages. The second - very professional surveying - with theodolite in 0.5 m high crawlings was made in 72-74 - but only 330 m of "main passages". After our Roumanian experience with real caving we started in 1979 to resurvey the cave from the "end" to entrance - now we have more than 4 km of survey shots. But all this is in very small volume - 100 x 150 x 350 m of limestone. So you may imagine, to draw it by hand or in iIlustrator. But therion works well, I have now 1,5 km in it. :) Good luck with your project, our meeting is in middle of April :( Martin -- Subject: [therion] Re: problem importing .3d file From: Martin Sluka <martinsluka@mac.com> Date: Wed, 9 Feb 2005 08:38:37 +0100 To: therion@speleo.sk But therion works well, I have now 1,5 km in it. :) And thanks to survex - without the analysis of surveying of caves included there the Stacho with Martin had much more complicated work. Martin -- Subject: [therion] Re: problem importing .3d file From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 09 Feb 2005 09:35:34 +0100 To: therion@speleo.sk OK, I have added two new options for import command and changed the survey structure policy. Now non-existing surveys are created. + import -filter <string> -- only stations with given prefix and shots between them will be imported - prefix will be removed from station names + import -surveys (create)|use|ignore -- specifies how to import survey structure. create = split stations into subsurveys, if subsurveys do not exists, create them use = split stations into existing subsurveys ignore = do not split stations into sub-surveys This option works only for .3d import. So now you can do following survey terikan import terikan.3d -filter terikan ... scraps & maps ... endsurvey You can download developer's snapshot to test them. S. Subject: translation From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 7 Feb 2005 09:15:50 +0100 To: Therion <therion@speleo.sk> Hi all, I have translated 0.3.6's user interface to spanish. You'll find a file with strings on http://www.infonegocio.com/tatel/ If you are on *nix, and want to translate therion to your own language as soon as posible, you could use translate.sh, wich is not more than a collection of awk and sed commands. Of course you need to edit strings first ;-) Cheers Subject: translation on therion wiki From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 7 Feb 2005 17:49:26 +0100 To: Therion <therion@speleo.sk> Hi again, translation stuff is on the wiki now (Tips and tricks page) Regards, Roman Subject: flowstone area needed From: Wookey <wookey@aleph1.co.uk> Date: Wed, 9 Feb 2005 19:38:19 +0000 To: Therion List <therion@speleo.sk> I have a few large areas of flowstone. Defining an area of this type would be good. The only problem is that it really needs some kind of 'directioal' elements so that the flow sysmbols show the correct direction. Still, that could ome later - just having the area would do for 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: [therion] flowstone area needed From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 10 Feb 2005 09:41:49 +0100 To: therion@speleo.sk We would like to add direction (or gradient) to area also for area:blocks, so I will put it on the top of TODO list. Adding new area type is no problem - the question is: What flowstone symbol do you use? Currently, there is implemented only UIS one, which I do not like. May be I can add some CUCC symbols :) - I would like to add at least your point gradient symbol (the black triangle) - the UIS arrow I do not like neither. S. Wookey wrote: > I have a few large areas of flowstone. Defining an area of this type would > be good. The only problem is that it really needs some kind of 'directioal' > elements so that the flow sysmbols show the correct direction. Still, that > could ome later - just having the area would do for now. > > Wookey Subject: Re: flowstone area needed From: Wookey <wookey@aleph1.co.uk> Date: Sun, 13 Feb 2005 23:25:07 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-10 09:41 +0100]: >> We would like to add direction (or gradient) to area also for >> area:blocks, so I will put it on the top of TODO list. Adding new area >> type is no problem - the question is: >> >> What flowstone symbol do you use? little curves. There is an example of the flowstone area here: http://wookware.org/poormansexample.gif >> I would like to add at least your >> point gradient symbol (the black triangle) - the UIS arrow I do not like >> neither. That is a BCRA symbol. As you say - it is rather useful/nice even though it is not in the UIS set. We should certainly implement the BCRA set. 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: translating types From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 15 Feb 2005 14:21:43 +0100 To: Therion <therion@speleo.sk> Hi, translating projection, point, line and area types does not work; when compiling, it complains about this. However, types are important items to translate. I'm on a hurry, because the planned stage is coming, and I've heard about "using AutoCAD", which is for me a big no-no-no. I think I could change this, but I would need translate types as fast as possible. What could I do to get types translated and working? Thanks, Roman Subject: Re: [therion] translating types From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 16 Feb 2005 09:22:17 +0100 To: therion@speleo.sk > What could I do to get types translated and working? I am very sorry, but it will not work. The problem is simple - xtherion is editing text files, and therion accepts only english as input file language. This can not be changed - it was discussed a lot, but therion language is some kind of programming language. And translating programming languages is not possible. When we have been discussing it before - the only solution was to write new user interface for that. OK - types can be translated somehow, but what obout other options (put in options line)? And what about text editor - where you are editing input th files also in english? It is the same with survex, there also all commands are not translated. I am sorry for the late answer - I am a little bit busy risght now. When do you have your session? Even we can not translate input language, we can do some helpful things we have already in TODO. E.g. generating PDF with all symbols available in therion in all symbol sets with keywords and regional translations. This could help people a lot. Also I have almost finished using LRUD data in map editor. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] translating types From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 16 Feb 2005 09:27:13 +0100 To: therion@speleo.sk On Wed, 16 Feb 2005 09:22:17 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> The problem is simple - xtherion is editing text files, and therion >> accepts only english as input file language. >> (...) >> When we have been discussing it before - the only solution was to >> write new user interface for that. OK, I understand. I was guessing that solution would not be trivial. >> OK - types can be translated somehow, but what obout other options >> (put in options line)? And what about text editor - where you are >> editing input th files also in english? It is the same with survex, >> there also all commands are not translated. Of course you are right. I think all the matter would need somewhat as an "abstraction layer" so translated types, options, etc, would be passed to therion in english, or so. Again, I understand this is not trivial. At this moment, get the people learning about 50 english words is probably easier than getting a new interface. >> When do you have your session? Date is not fixed yet, however things are moving faster than expected. I'll need to do hard lobbying work from now. It would be very helpful if I could send even a not-so-fully-translated, windows binary version to some people as fast as possible. I updated the translation script in wiki so types remain untouched, but I have no idea about compiling those all tex, tcltk, tkimg, etc, things, in order to get it working on windows :( >> Also I have almost finished using LRUD data in map editor. Aaah... very good new; I think it is at least as important as translation. Will there be a grid in map editor to make drawing to scale easier? Is there an idea about release date? Could this next release be "translated"? I'm doing my first serious Therion survey now, and taking notes for a writing. (Wookey: your starter guide is useful, thanks) I'll post some (probably dumb) questions next week or so. I'm quite happy with therion. It is by far the best caving survey software I tried. Authors and contributors can be proud of it. Regards, Roman Subject: Re: [therion] translating types From: Martin Sluka <martinsluka@mac.com> Date: Wed, 16 Feb 2005 12:07:02 +0100 To: therion@speleo.sk At 09:27 +0100 16.2.2005, Roman =?ISO-8859-15?Q?Mu=F1oz?= wrote: ******************************************* > I updated the > translation script in wiki so types remain untouched I'll add several examples of modification of layout parameters to generate different kinds of maps to wiki today. MS. -- Subject: Re: [therion] translating types From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 16 Feb 2005 12:20:13 +0100 To: therion@speleo.sk Roman Muñoz wrote: > Date is not fixed yet, however things are moving faster than > expected. I'll need to do hard lobbying work from now. It would > be very helpful if I could send even a not-so-fully-translated, windows > binary version to some people as fast as possible. I updated the > translation script in wiki so types remain untouched, but I have no idea > about compiling those all tex, tcltk, tkimg, etc, things, in order to > get it working on windows :( No problem. If you want to make your spanish installation - you will need to download following file: http://therion.speleo.sk/stats/get.php?filename=therion-batteries.zip Then you have to unzip it into same directory (e.g. C:\Cave), where your therion sources fow windows exists. So you will have there directories: therion therion-batteries In therion-batteries, you will need to modify common.iss and set SourceDir=C:\Cave OutputDir=C:\Cave Then you will need Inno Setup compiler (try google, no idea about download web page) to compile therion-full instalation script for windows. It will generate therion-full.exe in C:\Cave directory. Then you can rename it to therion-full-0.3.6-es.exe and put on some web page. If you are not able to compile therion under windows - and you have your xtherion in spanish, just do following: Unpack sources and install win32 therion. Copy therion.exe for program files to therion directory. Copy thbook.pdf to therion/thbook dir. Copy spanish version of xtherion.tcl into therion/xtherion dir. And that's all. After that, you can compile your own installation. >> Also I have almost finished using LRUD data in map editor. > > > > Aaah... very good new; I think it is at least as important as > translation. Will there be a grid in map editor to make drawing to scale > easier? Is there an idea about release date? Could this next release be > "translated"? Yes, grid is already there. I hope, I can finish it this weekend. XTherion translation - I do not know - I didn't had time to look at it. I will try. > I'm doing my first serious Therion survey now, and taking notes > for a writing. (Wookey: your starter guide is useful, thanks) I'll > post some (probably dumb) questions next week or so. I'm quite happy > with therion. It is by far the best caving survey software I tried. > Authors and contributors can be proud of it. ... and probably most complicated. A high-level interactive layer is still missing :( Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] translating types From: Martin Sluka <martinsluka@mac.com> Date: Wed, 16 Feb 2005 13:45:44 +0100 To: therion@speleo.sk At 12:20 +0100 16.2.2005, Stacho Mudrak wrote: ******************************************* > ... and probably most complicated. Simple cave - any simple software Complicated cave - therion ;) MS. -- Subject: Re: [therion] translating types From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 16 Feb 2005 13:04:06 +0100 To: therion@speleo.sk On Wed, 16 Feb 2005 12:20:13 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> Then you will need Inno Setup compiler (try google, no idea about >> download web page) to compile therion-full instalation script for >> windows. It will generate therion-full.exe in C:\Cave directory. Then >> you can rename it to therion-full-0.3.6-es.exe and put on some web >> page. I think I'm missing something. Is a setup.exe file what I am getting from Inno Setup. It installs two uninstall files. I don't need a windows C++ compiler? >> >> If you are not able to compile therion under windows - and you have >> your xtherion in spanish, just do following: >> >> Unpack sources and install win32 therion. >> Copy therion.exe for program files to therion directory. >> Copy thbook.pdf to therion/thbook dir. >> Copy spanish version of xtherion.tcl into therion/xtherion dir. >> >> And that's all. After that, you can compile your own installation. So I need to compile after all? Regards, Roman Subject: Re: [therion] translating types From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 16 Feb 2005 15:36:42 +0100 To: therion@speleo.sk Roman Muñoz wrote: > I think I'm missing something. Is a setup.exe file what I am getting > from Inno Setup. Yes. > It installs two uninstall files. ??? > I don't need a windows > C++ compiler? No. Inno setup just creates setup.exe (therion-full.exe), where it add all files needed for distribution. >> And that's all. After that, you can compile your own installation. > > > So I need to compile after all? No ;) I mean "compile" all executable files (therion.exe, pdftex.exe ...) to one single therion-full.exe file, that can be used to install therion on computer with all the stuff needed for it (tcl, tex, mpost etc...) OK - if it is too complicated, I can try to add translation to xtherion first. S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] translating types From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 16 Feb 2005 14:04:31 +0100 To: therion@speleo.sk On Wed, 16 Feb 2005 13:45:44 +0100 Martin Sluka <martinsluka@mac.com> wrote: >> Simple cave - any simple software >> >> Complicated cave - therion Er... I don't agree. My survey is a 300 m gallery. Only one scrap. Walls, contours, pits, floor-steps and stations, gradient, paleo, arqueo, labels and plan was mostly done. I took not more time than made with Toporobot and Illustrator. So why not use therion for simple caves if you know how it works? Most caves here are as simple as this is and even smaller. So I think giving to people template files near finished could work fine at this time. For the map editor, instructions "how to insert gradient arrows"-like could be done. This way, I think most friends could survey 90% caves we have here. I will try it for my lobbying work. BTW, in such a gallery I was unable to get 2 areas, because the second one floods the first and all space between. limits were, first, gallery end and one contour line(cul-de-sac), second, gallery walls (cave walls are made in only one wall line) and 2 contour lines. After this, I created open border lines intersecting walls wildly, without success. I needed to draw a closed line to get areas -not a big problem Regards, Roman Subject: xtherion i18n From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 16 Feb 2005 16:00:00 +0100 To: therion@speleo.sk OK, after studying TclTk manuals a little bit, i18n is already there - no additional packages are needed. All I need to do is to replace each string with [mc <original string>] and define .msg files for each language. With your list of translated strings, it can be done very fast. I will try to do it before weekend starts. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] xtherion i18n From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Wed, 16 Feb 2005 16:15:23 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >> OK, after studying TclTk manuals a little bit, i18n is already there - >> no additional packages are needed. All I need to do is to replace each >> string with [mc <original string>] and define .msg files for each >> language. >> >> With your list of translated strings, it can be done very fast. I will >> try to do it before weekend starts. Could you send me then development snapshot? I will create Czech translation. L. Subject: Re: [therion] xtherion i18n From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 16 Feb 2005 16:16:44 +0100 To: therion@speleo.sk Ladislav Blazek wrote: > Could you send me then development snapshot? I will create Czech translation. When I will have it :) , I will put it on the web. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: [therion] xtherion i18n From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Wed, 16 Feb 2005 16:21:38 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >> Ladislav Blazek wrote: > >>>> Could you send me then development snapshot? I will create Czech >>>> translation. > >> >> When I will have it :) , I will put it on the web. Aaah... sorry, I am little bit overworked. Maybe I can send you modified Roman's file with Czech strings. L. Subject: Re: [therion] xtherion i18n From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 16 Feb 2005 14:09:39 +0100 To: therion@speleo.sk Thank you very much! Roman On Wed, 16 Feb 2005 16:00:00 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> OK, after studying TclTk manuals a little bit, i18n is already there - >> no additional packages are needed. All I need to do is to replace each >> string with [mc <original string>] and define .msg files for each >> language. >> >> With your list of translated strings, it can be done very fast. I will >> try to do it before weekend starts. >> >> Regards, S. >> >> -=x=- >> Skontrolované antivírovým programom NOD32 >> Subject: xtherion i18n From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 17 Feb 2005 10:37:10 +0100 To: therion@speleo.sk There is a new developement snapshot on the web with xtherion supporting translated messages. The translation mechanism is simmilar to the one used by therion. To e.g. czech generate translation, do follwoing: cd xtherion cd lang ./process.pl export cz File xtexts_cz.txt is created. Edit this file in some UTF-8! editor. I am using gedit on linux. You can use also xtherion text editor - but you will need to insert encoding utf-8 to the begining of each file. When you are finished, send this file to me :) and try ./process.pl update to incorporate your translations into existing sources. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: Segfault when including survey data in plan From: Wookey <wookey@aleph1.co.uk> Date: Thu, 17 Feb 2005 04:30:36 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-01-11 10:08 +0100]: >> Wookey wrote: > >>> >This looks like a bug. And is there some subtlty about adding surveys >>> >(centrelines) to maps? > >> >> Yes, it is a bug. I have downloaded your data, made your changes and it >> really fails - no idea why, but I will fix it. >> >> If you would like to have map with centerline also, create a separate >> map with centerline only - it should work with it (at least on my >> machine it worked - see attached picture). OK. Done that and if I get rid of all the scraps then I get an image which has complete lines for the surface surveys but station-marks for the underground stations. Is that expected? See http://wookware.org/centrelineonly.pdf However when I put the scraps back in then I only see station inside scraps,not any stations or lines on centrelines which don't have correspondging scraps. Any idea why? I'd really like to get this owrking as it's the easiest way to see which bits I haven't done yet. I have noticed a problem with the need for a 'dummy' survey outside a .3d file import - it stops you using the suggested index.th and index.th2 files for centreline and scrap info (because you need a 'survey dummy' in both files around everything and it complains about 'duplicate survey'). This will go away when we get rid of the need for the dummy survey (maybe you already did that - I can't find the mail right now (I'm using the 20050209 snapshot)). I've also realsied that I can't do what I wanted to do - import more than one .3d file. I wanted to import one per cave, but of course thinking about it, this isn't going to work because the co-ordinates will overlap. I need to generate one .3d file covering al the caves. (no problem except for the need to strip extra hierarchy layers. I wonder if this is going to cuase problems when I want to be able to produce both one large overview survey and various small single-cave surveys. I need to think about this... Still it would be good if it gave a useful error - it took me some time to work out what the problem was as it just gave a tex overflow error - which I can't reproduce right now due to getting a different error: It says: therion: error -- file import -- index.th [15] -- invalid survey name -- de0/.deception I think it is faiing to cope with the oddly-name "de0/" survey. It has this peculiar name because the data is imported from compass and it was expedient to use this name. Survex eats it happily and so does aven so therion should. As ever current dataset here: http://wookware.org/terikan20050217.tgz you need to change index.th at top level to use terikan/terikan.3d and deception/deception.3d to illustrate the above points (I changed it to a single overall dataset to check it worked - it does - very cool - except that I can't get centrelines to appear - indeed it doesn't seem to mattermuch what I put in the various 'map' options I seem to get 'all scraps mentioned in any map but no centrelines' whatever I do?). 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: Segfault when including survey data in plan From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 17 Feb 2005 09:40:28 +0100 To: therion@speleo.sk > OK. Done that and if I get rid of all the scraps then I get an image which > has complete lines for the surface surveys but station-marks for the > underground stations. Is that expected? Yes. This is only because of symbol definition of line survey:underground. This symbol just puts marks on the stations. It can be changed easily. > See http://wookware.org/centrelineonly.pdf > > However when I put the scraps back in then I only see station inside > scraps,not any stations or lines on centrelines which don't have > correspondging scraps. Any idea why? I'd really like to get this owrking as > it's the easiest way to see which bits I haven't done yet. When therion has no scraps to export, it exports all centerline data. If it has some, it exports only 2D data and not centerline. If you wish to have also centerline data on the map, you need to do two things: 1. create some toplevel map, where you mix maps and surveys together, you would like to have on the output. 2. select and export this map > I have noticed a problem with the need for a 'dummy' survey outside a .3d > file import - it stops you using the suggested index.th and index.th2 files > for centreline and scrap info (because you need a 'survey dummy' in both > files around everything and it complains about 'duplicate survey'). > > This will go away when we get rid of the need for the dummy survey (maybe > you already did that - I can't find the mail right now (I'm using the > 20050209 snapshot)). dummy survey is still needed :( If you do not want to have it, use import inside terikan survey with option "-filter terikan" > Still it would be good if it gave a useful error - it took me some time to > work out what the problem was as it just gave a tex overflow error - which I > can't reproduce right now due to getting a different error: > > It says: > therion: error -- file import -- index.th [15] -- invalid survey name -- > de0/.deception > > I think it is faiing to cope with the oddly-name "de0/" survey. It has this > peculiar name because the data is imported from compass and it was expedient > to use this name. Survex eats it happily and so does aven so therion should. OK - adding / as a special survey character should be OK - I think. I will enable it right now. > As ever current dataset here: > > http://wookware.org/terikan20050217.tgz > > you need to change index.th at top level to use terikan/terikan.3d and > deception/deception.3d to illustrate the above points (I changed it to a > single overall dataset to check it worked - it does - very cool - except > that I can't get centrelines to appear - indeed it doesn't seem to > mattermuch what I put in the various 'map' options I seem to get 'all scraps > mentioned in any map but no centrelines' whatever I do?). Once more - if you want to mix centerline with maps, you need to define a top level map, where you will mix maps and survey names together. When exporting this map - centerline should appear. If you wish to view whole centerline for underground, just redefine symbol in layout: code mpost let l_survey_cave = l_survey_surface_SKBB; endcode S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: Segfault when including survey data in plan From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 17 Feb 2005 12:27:21 +0100 To: therion@speleo.sk > OK. Done that and if I get rid of all the scraps then I get an image which > has complete lines for the surface surveys but station-marks for the > underground stations. Is that expected? Second answer is NO :) Obviosly, there is another bug. I will try to fix it soon. > I have noticed a problem with the need for a 'dummy' survey outside a .3d > file import - it stops you using the suggested index.th and index.th2 files > for centreline and scrap info (because you need a 'survey dummy' in both > files around everything and it complains about 'duplicate survey'). If previous bug will be fixed - no problem to remove need for dummy survey :) > I've also realsied that I can't do what I wanted to do - import more than > one .3d file. I wanted to import one per cave, but of course thinking about > it, this isn't going to work because the co-ordinates will overlap. I need > to generate one .3d file covering al the caves. May be - I can add some -shift option for import command. E.g. -shift 1200 1300 500 m will shift all stations with given vector. This is no problem and it can be probably very usefull in some cases. > Still it would be good if it gave a useful error - it took me some time to > work out what the problem was as it just gave a tex overflow error - which I > can't reproduce right now due to getting a different error: I am curious to see this error - on my computer your data worked without errors. > It says: > therion: error -- file import -- index.th [15] -- invalid survey name -- > de0/.deception > > I think it is faiing to cope with the oddly-name "de0/" survey. It has this > peculiar name because the data is imported from compass and it was expedient > to use this name. Survex eats it happily and so does aven so therion should. This is already removed. Regards, S. -=x=- Skontrolované antivírovým programom NOD32 Subject: Re: Segfault when including survey data in plan From: Wookey <wookey@aleph1.co.uk> Date: Thu, 17 Feb 2005 11:49:32 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-17 12:27 +0100]: >> >> May be - I can add some -shift option for import command. E.g. >> -shift 1200 1300 500 m will shift all stations with given vector. This >> is no problem and it can be probably very usefull in some cases. Yes, I can imagine situations where this might be necessary. Put it on the todo list if it is easy. (I am now using one large .3d file for the whole mountain so it is not an issue for m). >>> >Still it would be good if it gave a useful error - it took me some time to >>> >work out what the problem was as it just gave a tex overflow error - which >>> >I >>> >can't reproduce right now due to getting a different error: > >> >> I am curious to see this error - on my computer your data worked without >> errors. Yes, sorry - the problem is that it takes a long time to write these mails as I try out the various options, and edit a lot of files, so at the end of the mail the dtaaset in in the status of the last test. I wrote this mail over 3 evenings and had this problem at the beginning but it went away whilst I changed other things :-( and now I can't remember the exact status that cuased it. >> This is already removed. cool - stargely the error does not appear when using the full-mountain benarat.3d file, only when using a small deception.3d file for that cave. 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: Re: Segfault when including survey data in plan From: Wookey <wookey@aleph1.co.uk> Date: Thu, 17 Feb 2005 11:58:26 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-17 09:40 +0100]: >> When therion has no scraps to export, it exports all centerline data. If >> it has some, it exports only 2D data and not centerline. If you wish to >> have also centerline data on the map, you need to do two things: >> >> 1. create some toplevel map, where you mix maps and surveys together, >> you would like to have on the output. Yes- I have donethis - the centrelineplan map is all the centreline data. It is mixed with the terikanplan survey. I noticed that I could have a survey called 'terikan' and a map called 'terikan' and this mostly worked anyway, but I did get an error saying 'no projection for survey' (from memory) because it thought I meant the centreline data, not the map once. I can see whay this would happen. Not sure if we should do anything about that or not? Now that survey names can be referred to in maps (instead of scrap names) then maybe we need to enforce that the namespace does not overlap? This could be annoying becuase you may often call a map the same as the cave name, which is also a survey name? >> 2. select and export this map OK - I think this is the thing I was not doing. Because therions magic 'automatic selection' mostly does what I want I do not have any selects in the dataset anymore. If I select the centrelineplan map, does that disable automatic selection of other maps so now I have to select all the maps I want to appear? >> If you wish to view whole centerline for underground, just redefine >> symbol in layout: >> >> code mpost >> let l_survey_cave = l_survey_surface_SKBB; >> endcode I take it from your second message that this did not in fact 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: [therion] Re: Segfault when including survey data in plan From: Martin Sluka <martinsluka@mac.com> Date: Thu, 17 Feb 2005 13:09:53 +0100 To: therion@speleo.sk At 11:58 +0000 17.2.2005, Wookey wrote: ******************************************* > error saying 'no projection for survey' map xxx -projection plan nnn endmap > I take it from your second message that this did not in fact work? > > Wookey check wiki - exaples MS. -- Subject: Re: Segfault when including survey data in plan From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 17 Feb 2005 13:31:10 +0100 To: therion@speleo.sk > whay this would happen. Not sure if we should do anything about that or not? We solved this problem very easily. To each map we add suffix, indicating that this is a map _m or .m . If there are more projections, you can add also projection type to the suffix (e.g. .mp, .me or .mx). The same we do with scraps. This way there are no conflicts and you see directly what is what. > OK - I think this is the thing I was not doing. Because therions magic > 'automatic selection' mostly does what I want I do not have any selects in > the dataset anymore. If I select the centrelineplan map, does that disable > automatic selection of other maps so now I have to select all the maps I > want to appear? Yes - usually it's only one top-level map. But I can probably advance magic of therion automatic selection - that this will not be necessary. >> code mpost >> let l_survey_cave = l_survey_surface_SKBB; >> endcode > > > I take it from your second message that this did not in fact work? Yes and no. It will help, if you will use centerline data defined properly in therion. It will not, if you will import them - because of bug deep in therion data structure. S. Subject: Re: Segfault when including survey data in plan From: Wookey <wookey@aleph1.co.uk> Date: Thu, 17 Feb 2005 15:58:11 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-17 13:31 +0100]: >>> >whay this would happen. Not sure if we should do anything about that or >>> >not? > >> >> We solved this problem very easily. To each map we add suffix, >> indicating that this is a map _m or .m . If there are more projections, >> you can add also projection type to the suffix (e.g. .mp, .me or .mx). >> The same we do with scraps. This way there are no conflicts and you see >> directly what is what. Yes that is sensible. The question is whether we should enforce this behaviour on people with warnings or error messages? >>> >OK - I think this is the thing I was not doing. Because therions magic >>> >'automatic selection' mostly does what I want I do not have any selects in >>> >the dataset anymore. If I select the centrelineplan map, does that disable >>> >automatic selection of other maps so now I have to select all the maps I >>> >want to appear? > >> >> Yes - usually it's only one top-level map. >> >> But I can probably advance magic of therion automatic selection - that >> this will not be necessary. Maybe. I've actually been finding the magic selection confusing over the last few days as I seem to get 'everything' even when I comment stuff out of map lists. I haven't exactly got to the bottom of it so I haven't sent mail about it (yet). The problem with 'automagic' software is that it can be very hard to work out what is going on when it is not doing what you want. Of course my dataset with many caves and multiple maps is more complicated than most so this probably isn't a problem (we should design to make the simple case easy - the complicated case is going to be complicated whatever we do). Let me do some more work on producing multiple maps from one dataset and then we can discuss the whole issue some more. I expect there will be a number of problems - like wanting to have labels and cross sections in different places on different maps - I don';t think we have that option at the moment. >>>> >>code mpost >>>> >>let l_survey_cave = l_survey_surface_SKBB; >>>> >>endcode >> >>> > >>> >I take it from your second message that this did not in fact work? > >> >> Yes and no. It will help, if you will use centerline data defined >> properly in therion. It will not, if you will import them - because of >> bug deep in therion data structure. Right. 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: Segfault when including survey data in plan From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 17 Feb 2005 17:12:03 +0100 To: therion@speleo.sk > Maybe. I've actually been finding the magic selection confusing over the > last few days as I seem to get 'everything' even when I comment stuff out of > map lists. I haven't exactly got to the bottom of it so I haven't sent mail > about it (yet). Well, the only way how to get what you want is to select maps in configuration file. > then we can discuss the whole issue some more. I expect there will be a > number of problems - like wanting to have labels and cross sections in > different places on different maps - I don';t think we have that option at > the moment. :) ... I am looking forward. S. Subject: Wiki From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Thu, 17 Feb 2005 11:12:18 +0100 (CET) To: therion@speleo.sk Wiki version of therion book updated to version 0.3.6 --- Lada Blazek Subject: windows binary translated From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 17 Feb 2005 20:53:07 +0100 To: Therion <therion@speleo.sk> Hi all, I managed to get windows binary translated. Simply rename a translated /therion/xtherion/xtherion file as xtherion.tcl and use it overwrite installed windows binary's one. Et voila! :) BTW, .iss scripts don't worked for me: First I needed to realize that there are more .iss files than common.iss Then I found therion.iss in therion's source (from tar.gz). Then I needed edit it to get no complain about application number, and wish.exe being now wish84.exe. Then I had to install windows binary and update to get therion.exe and thbook.pdf from it, and xtherion tcl from my own translated and renamed one. So I compiled it but after install it looks for wish.exe: If you point him to wish84, he asks for tcl84.dll... then I tried the wild way. I'll do a final test of translation prior to putting it all on wiki. Regards, Roman Subject: Re: [therion] windows binary translated From: "Martin Budaj" <m.b@speleo.sk> Date: Fri, 18 Feb 2005 08:16:53 +0100 (CET) To: therion@speleo.sk Roman Muñoz wrote: >> So I compiled it but after install it looks for wish.exe: If you point >> him to wish84, he asks for tcl84.dll... then I tried the wild way. >> >> I'll do a final test of translation prior to putting it all on wiki. I think it's not necessary to build separate binary packages for each translation -- now the mainstream package supports translation of xtherion with Spanish and Slovak translations included. Martin Subject: Re: [therion] windows binary translated From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Fri, 18 Feb 2005 08:46:34 +0100 (CET) To: therion@speleo.sk Martin Budaj napsal(a): >> I think it's not necessary to build separate binary packages for each >> translation -- now the mainstream package supports translation of xtherion >> with Spanish and Slovak translations included. Yesterday I sended Czech translation of xtherion to Stacho. L. Subject: Re: [therion] windows binary translated From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 18 Feb 2005 15:40:12 +0100 To: therion@speleo.sk On Fri, 18 Feb 2005 08:16:53 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >> I think it's not necessary to build separate binary packages for each >> translation -- now the mainstream package supports translation of >> xtherion with Spanish and Slovak translations included. Do you mean that windows version can be installed in spanish directly? If affirmative, how to do? Regards, Roman Subject: Re: [therion] windows binary translated From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 21 Feb 2005 08:56:24 +0100 (CET) To: therion@speleo.sk Roman Muñoz wrote: >>>> I think it's not necessary to build separate binary packages for each >>>> translation -- now the mainstream package supports translation of >>>> xtherion with Spanish and Slovak translations included. > >> >> Do you mean that windows version can be installed in spanish directly? >> If affirmative, how to do? Currently the developers' snapshot only. Version 0.3.7 will include the language support. If it would be helpful, we can make windows development binary to be used until 0.3.7 comes. Regards, Martin Subject: Re: [therion] windows binary translated From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 21 Feb 2005 07:27:10 +0100 To: therion@speleo.sk On Mon, 21 Feb 2005 08:56:24 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >> If it would be helpful, we can make windows development binary to be >> used until 0.3.7 comes. Thanks a lot. Since friends can simply overwrite xtherion.tcl, I think there is not need to make windows development binary, at least until centreline and LRUD data can be used in map editor window. Best regards, Roman Subject: New snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 18 Feb 2005 10:41:55 +0100 To: therion@speleo.sk There is a new developement snapshot on the web with following changes: + Import bug removed - now .3d files are imported correctly with entire survey structure. + XTherion CZ translation added. + Improved spanish translation. S. Subject: Re: New snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 18 Feb 2005 10:55:53 +0100 To: therion@speleo.sk I forget one thing. If you want to translate only untranslated strings, following is possible: ./process.pl export-empty cz S. Subject: devel snapshot - translations From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Mon, 21 Feb 2005 10:32:34 +0100 (CET) To: therion@speleo.sk Hi, how can I switch between different translations of XTherion? I changed following lines in xtherion.ini from # prefered language for messages # ::msgcat::mclocale sk to # prefered language for messages ::msgcat::mclocale cz But I have still english version of XTherion... Locales of my Slack installation are also set to CZ. L. Subject: Re: [therion] devel snapshot - translations From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 21 Feb 2005 10:37:46 +0100 To: therion@speleo.sk > # prefered language for messages > ::msgcat::mclocale cz > > But I have still english version of XTherion... > Locales of my Slack installation are also set to CZ. Is your xtherion.ini file loaded by xtherion? E.g. does some other changes take effect? On my linux (Mandrake), I need set locale this way: export LC_MESSAGES=sk and it works. Regards, S. Subject: Re: [therion] devel snapshot - translations From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Mon, 21 Feb 2005 10:52:38 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >> Is your xtherion.ini file loaded by xtherion? E.g. does some other >> changes take effect? >> >> On my linux (Mandrake), I need set locale this way: >> >> export LC_MESSAGES=sk My ~/.profile file contains: export LC_ALL=cs_CZ Do I need also line in xtherion.ini for enabling translated version of xtherion? L. Subject: Re: [therion] devel snapshot - translations From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 21 Feb 2005 10:55:15 +0100 To: therion@speleo.sk Ladislav Blazek wrote: > My ~/.profile file contains: > > export LC_ALL=cs_CZ > > Do I need also line in xtherion.ini for enabling translated version of > xtherion? L. No - it should work automatically. Simple test is (on my machine): tclsh % package require msgcat 1.4.1 % ::msgcat::mclocale sk_sk If you have en instead - your TclTk implementation ignores locale settings. S. Subject: Re: [therion] devel snapshot - translations From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Mon, 21 Feb 2005 11:00:49 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >> No - it should work automatically. Simple test is (on my machine): >> >> tclsh >> % package require msgcat >> 1.4.1 >> % ::msgcat::mclocale >> sk_sk >> >> If you have en instead - your TclTk implementation ignores locale >> settings. Thank you, I will test it today evening. L. Subject: New developement snapshot. From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 21 Feb 2005 10:34:55 +0100 To: therion@speleo.sk So current version of therion should support centerline with LRUD in map editor. As usually - it is implemented easiest way for programmer :) with minimal changes in current interface. So how it works: 1. Therion supports new map format export - xvi (xtherion vector image). 2. XTherion can load xvi images into backgroud, as any other bitmap image. There are some special bindings for vector images - e.g. if you insert point on station, type and station name are automatically set. When exporting xvi images - they are exported in 100dpi in layout-scale. Grid spacing is also taken from layout X grid-size. Waiting for feedback and comments :) S. Subject: Re: [therion] New developement snapshot. From: Martin Sluka <martinsluka@mac.com> Date: Mon, 21 Feb 2005 10:41:29 +0100 To: therion@speleo.sk At 10:34 +0100 21.2.2005, Stacho Mudrak wrote: ******************************************* > Waiting for feedback and comments :) May you, please, publish any short example, how it works? TIA MS. -- therion Digest of: get.501_600 Topics (messages 501 through 600): Re: New developement snapshot. 501 by: Stacho Mudrak 502 by: John Pybus 503 by: Stacho Mudrak 504 by: John Pybus 507 by: Stacho Mudrak 512 by: Stacho Mudrak wiki examples 505 by: Roman Muñoz 509 by: Stacho Mudrak 510 by: Martin Sluka 511 by: Ladislav Blazek 513 by: Martin Sluka bad option utf-8 506 by: Roman Muñoz 508 by: Stacho Mudrak 514 by: Roman Muñoz 515 by: Stacho Mudrak 516 by: Stacho Mudrak 517 by: Stacho Mudrak 518 by: Wookey 519 by: Olly Betts 520 by: M.J. Green 524 by: Stacho Mudrak 528 by: Martin Sluka 529 by: Martin Sluka next dumb question 521 by: Roman Muñoz 525 by: Stacho Mudrak 527 by: Martin Sluka 530 by: Eric Madelaine 531 by: John Pybus 532 by: Roman Muñoz 533 by: Ladislav Blazek 534 by: Stacho Mudrak invalid command message 522 by: Roman Muñoz 523 by: Stacho Mudrak Recent changes 526 by: Stacho Mudrak Re: 20050223 translation 535 by: Stacho Mudrak preliminary text 536 by: Roman Muñoz 537 by: Stacho Mudrak 538 by: Roman Muñoz 539 by: Stacho Mudrak 540 by: Martin Sluka last snapshot 541 by: Roman Muñoz 542 by: Stacho Mudrak 543 by: Martin Sluka 544 by: Roman Muñoz 545 by: Stacho Mudrak 546 by: Ladislav Blazek 547 by: Stacho Mudrak Re: xtherion.ini not found 548 by: Roman Muñoz 549 by: Stacho Mudrak 550 by: Roman Muñoz 551 by: Stacho Mudrak 555 by: Wookey 556 by: Roman Muñoz 557 by: Olly Betts Xtherion on MacOS X 552 by: Thierry GONON 553 by: Stacho Mudrak 560 by: Thierry GONON 561 by: Stacho Mudrak 564 by: Thierry GONON 565 by: Stacho Mudrak 567 by: Martin Sluka therion 0.3.6 in debian testing 554 by: Wookey sharp language 558 by: Roman Muñoz 559 by: Roman Muñoz 562 by: Stacho Mudrak 563 by: Ladislav Blazek 569 by: Wookey 571 by: John Pybus .ini files install 566 by: Roman Muñoz 568 by: Ladislav Blazek 570 by: Stacho Mudrak 591 by: Olly Betts Extended elevation 572 by: Stacho Mudrak 573 by: Roman Muñoz error message 574 by: Roman Muñoz 575 by: Stacho Mudrak statistics 576 by: Roman Muñoz 577 by: Martin Budaj 579 by: Roman Muñoz 580 by: Martin Sluka 581 by: Stacho Mudrak 582 by: Roman Muñoz 583 by: Stacho Mudrak 584 by: Martin Budaj Latest developement snapshot 578 by: Stacho Mudrak section lines 585 by: Roman Muñoz 586 by: Martin Budaj 587 by: Roman Muñoz 588 by: Martin Budaj 589 by: Roman Muñoz Therion 0.3.7 590 by: Martin Budaj Xtherion 0.3.7 connecting to the internet 592 by: Duncan Collis 597 by: Stacho Mudrak CMYK colour 593 by: Duncan Collis 594 by: Martin Budaj 595 by: Martin Sluka 596 by: Martin Sluka SVG export -- labels 598 by: Martin Budaj text uploaded on wiki 599 by: Roman Muñoz 600 by: Wookey Subject: Re: [therion] New developement snapshot. From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 21 Feb 2005 12:21:37 +0100 To: therion@speleo.sk Martin Sluka wrote: > At 10:34 +0100 21.2.2005, Stacho Mudrak wrote: > ******************************************* > >> Waiting for feedback and comments :) > > > > May you, please, publish any short example, how it works? > TIA > > MS. Subject: Re: [therion] New developement snapshot. From: John Pybus <john@pybus.org> Date: Mon, 21 Feb 2005 13:37:31 +0000 To: therion@speleo.sk Stacho Mudrak wrote: > Martin Sluka wrote: > >> At 10:34 +0100 21.2.2005, Stacho Mudrak wrote: >> ******************************************* >> >>> Waiting for feedback and comments :) >> >> >> >> >> May you, please, publish any short example, how it works? >> TIA I've tried your Tornala example with xtherion from the dev snapshot. When I try to insert the .xvi image I get: ------- bad search mode "-integer": must be -exact, -glob, or -regexp bad search mode "-integer": must be -exact, -glob, or -regexp while executing "lsearch -integer $xth(me,imgs,xlist) $imgx" (procedure "xth_me_imgs_xvi_create" line 62) invoked from within "xth_me_imgs_xvi_create $imgx" (procedure "xth_me_image_insert" line 176) invoked from within "xth_me_image_insert $xth(ctrl,me,images,posx) $xth(ctrl,me,images,posy) {} 0 {}" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 19) invoked from within "Button::_release .xth.me.af.ctrl.cf11.f.ic.insp" (command bound to event) ------- And moving around the canvas gives: ------- bad index "": must be integer or end?-integer? bad index "": must be integer or end?-integer? while executing "lindex $xth(me,imgs,xlist) $iidx" (procedure "xth_me_image_select" line 22) invoked from within "xth_me_image_select [lsearch $xth(me,imgs,xlist) $imgx]" (procedure "xth_me_image_choose" line 3) invoked from within "xth_me_image_choose $imgx" (procedure "xth_me_area_end_drag" line 10) invoked from within "xth_me_area_end_drag 20 "0" 459 389" (command bound to event) ------- $ rpm -q tcl tcl-8.3.5-88 John Subject: Re: [therion] New developement snapshot. From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 21 Feb 2005 15:44:15 +0100 To: therion@speleo.sk Isn't it just because of old version of TCL? S. John Pybus wrote: > Stacho Mudrak wrote: > >> Martin Sluka wrote: >> >>> At 10:34 +0100 21.2.2005, Stacho Mudrak wrote: >>> ******************************************* >>> >>>> Waiting for feedback and comments :) >>> >>> >>> >>> >>> >>> May you, please, publish any short example, how it works? >>> TIA > > > > I've tried your Tornala example with xtherion from the dev snapshot. When I try to insert the .xvi image I get: > > ------- > bad search mode "-integer": must be -exact, -glob, or -regexp > bad search mode "-integer": must be -exact, -glob, or -regexp > while executing > "lsearch -integer $xth(me,imgs,xlist) $imgx" > (procedure "xth_me_imgs_xvi_create" line 62) > invoked from within > "xth_me_imgs_xvi_create $imgx" > (procedure "xth_me_image_insert" line 176) > invoked from within > "xth_me_image_insert $xth(ctrl,me,images,posx) $xth(ctrl,me,images,posy) {} 0 {}" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 19) > invoked from within > "Button::_release .xth.me.af.ctrl.cf11.f.ic.insp" > (command bound to event) > ------- > > And moving around the canvas gives: > > ------- > bad index "": must be integer or end?-integer? > bad index "": must be integer or end?-integer? > while executing > "lindex $xth(me,imgs,xlist) $iidx" > (procedure "xth_me_image_select" line 22) > invoked from within > "xth_me_image_select [lsearch $xth(me,imgs,xlist) $imgx]" > (procedure "xth_me_image_choose" line 3) > invoked from within > "xth_me_image_choose $imgx" > (procedure "xth_me_area_end_drag" line 10) > invoked from within > "xth_me_area_end_drag 20 "0" 459 389" > (command bound to event) > ------- > > $ rpm -q tcl > tcl-8.3.5-88 > > John > > Subject: Re: [therion] New developement snapshot. From: John Pybus <john@pybus.org> Date: Mon, 21 Feb 2005 17:00:19 +0000 To: therion@speleo.sk Stacho Mudrak wrote: > Isn't it just because of old version of TCL? It may be - I'm still on RedHat 9 as getting linux working with my laptop's hardware was struggle enough and I'm not keen to do an upgrade and go through it all again. What's the minimum version required? The webpages don't specify anything, and all previous versions have worked fine with 8.3.5. If therion 0.3.7 is going to require 8.4, or whatever, then the docs/release notes will need changing to reflect this. Cheers, John Subject: Re: [therion] New developement snapshot. From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 09:27:52 +0100 To: therion@speleo.sk OK - I will try to remove -integer, may be it will help. But this option I have been using since 0.3.0... Regards, S. John Pybus wrote: > Stacho Mudrak wrote: > >> Isn't it just because of old version of TCL? > > > > It may be - I'm still on RedHat 9 as getting linux working with my laptop's hardware was struggle enough and I'm not keen to do an upgrade and go through it all again. > > What's the minimum version required? The webpages don't specify anything, and all previous versions have worked fine with 8.3.5. If therion 0.3.7 is going to require 8.4, or whatever, then the docs/release notes will need changing to reflect this. > > Cheers, > > John > > Subject: Re: New developement snapshot. From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 11:09:03 +0100 To: therion@speleo.sk Problems with TCL should be now fixed and translations of point/line/area types should be in status line. Some items in therion translations file (thlang/texts.txt) need to be translated for this. Regards, S. Subject: wiki examples From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 21 Feb 2005 17:55:50 +0100 To: Therion <therion@speleo.sk> Hi, When I enter wiki's examples page, my firefox begin to load something HUGE. I can hear disk cache working as an exploited slave. It takes some minutes to load (I'm on 512 Kb *DSL); after this, each time I scroll the page, cache starts working again. Thus it is, in practice, allmost unusable. I guess this is a matter of big pictures? Regards, Roman Subject: Re: [therion] wiki examples From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 09:52:41 +0100 To: therion@speleo.sk Same experience on PIII 700 256MB RAM. I have checked it - there are no thumbnails only original large images and thumbnails are created just by HTML width and height options. Somebody :) should make thumbnails and link images to them. Regards, S. Roman Muñoz wrote: > Hi, > When I enter wiki's examples page, my firefox begin to load something > HUGE. I can hear disk cache working as an exploited slave. It takes some > minutes to load (I'm on 512 Kb *DSL); after this, each time I scroll the > page, cache starts working again. Thus it is, in practice, allmost > unusable. > > I guess this is a matter of big pictures? > > Regards, > Roman > > Subject: Re: [therion] wiki examples From: Martin Sluka <martinsluka@mac.com> Date: Tue, 22 Feb 2005 10:13:34 +0100 To: therion@speleo.sk At 09:52 +0100 22.2.2005, Stacho Mudrak wrote: ******************************************* > Somebody :) should make thumbnails and link images to them. > > Regards, S. Ya, sir! MS. -- Subject: Re: [therion] wiki examples From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Tue, 22 Feb 2005 10:45:20 +0100 (CET) To: therion@speleo.sk Martin Sluka napsal(a): >> At 09:52 +0100 22.2.2005, Stacho Mudrak wrote: >> ******************************************* >> > >>>>Somebody :) should make thumbnails and link images to them. >>>> >>>>Regards, S. > >> >> Ya, sir! I am not sure if thumbnails are necessary. For now I replace images by links to original images. L. Subject: Re: [therion] wiki examples From: Martin Sluka <martinsluka@mac.com> Date: Tue, 22 Feb 2005 11:23:59 +0100 To: therion@speleo.sk At 10:45 +0100 22.2.2005, Ladislav Blazek wrote: ******************************************* > Martin Sluka napsal(a): > >> At 09:52 +0100 22.2.2005, Stacho Mudrak wrote: >> ******************************************* >> >>> Somebody :) should make thumbnails and link images to them. >>> >>> Regards, S. >> >> >> Ya, sir! > > > I am not sure if thumbnails are necessary. For now I replace images by > links to original images. L. My experience are simillar - the wiki generated the thumbnails from large picts. But maybe it is not correct. Anyway I'll try to make the thumbnails there. Martin S. -- Subject: bad option utf-8 From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 21 Feb 2005 19:29:18 +0100 To: Therion <therion@speleo.sk> Hi, I'm getting this error: bad option "utf-8": must be convertfrom, convertto, names, or system When trying to load .xvi images, including tornala's one Regards, Roman Subject: Re: [therion] bad option utf-8 From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 09:34:24 +0100 To: therion@speleo.sk XVI images have to be inserted as a "Background image" not loaded as .th2 files. In the tornala example - just open oko.th2 file. That's all. You have probably opened .xvi image in map or text editor or compiler. This editor adds "encoding utf-8" line to each file. When opened in a background - TCL interprets "encoding utf-8" which is obiously wrong. So could try it once more - unpack tornala example and load oko.th2 file to text editor? Whether it fails? S. Roman Muñoz wrote: > Hi, > I'm getting this error: > > bad option "utf-8": must be convertfrom, convertto, names, or system > > When trying to load .xvi images, including tornala's one > > Regards, > Roman > > Subject: Re: [therion] bad option utf-8 From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 22 Feb 2005 10:43:59 +0100 To: therion@speleo.sk On Tue, 22 Feb 2005 09:34:24 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> XVI images have to be inserted as a "Background image" not loaded as >> .th2 files. In the tornala example - just open oko.th2 file. That's >> all. Sorry, I think my explanations were not clear. I get this error when trying to insert .xvi file as background image. Tried once more: It continues. Effectively I can open oko.th2 and see .xvi image on it. But if I go to Archive->New and then try to load it as background image, I get this utf-8 error >> You have probably opened .xvi image in map or text editor or compiler. >> This editor adds "encoding utf-8" line to each file. When opened in a >> background - TCL interprets "encoding utf-8" which is obiously wrong. I've removed my Irurixo.xvi file and created it once more. I've examined it with less. I found no utf-8 strings in 91 lines. I tried to insert as background image: A message window appears about .xvi file already exists, Overwrite? I answered Yes. New window appears to choose background image. I choosed Irurixo.xvi and got utf-8 error again. Examined Irurixo.xvi once more with less: Now the file's first line *does* have the "encoding utf-8" line. And allmost any other 91 lines are now missing. I needed to edit Irurixo.th2 by hand in order to get Irurixo.xvi inserted correctly. Added this line borrowed from oko.th2 ##XTHERION## xth_me_image_insert {1594.485 1 1.0} {688.98 0} Irurixo.xvi #0{} So I think something is wrong in "Overwrite" step. Also,I found that my previous background images, which are screen captures from a 1:1000 survey, are far bigger than .xvi file. However, my layout has a "scale 1 1000" line. Not sure here: may be I made some mistake when capturing screens. I will check this again later. BTW, results (after manual editing of .th2 file) are very nice! It would be handier if other background images could be moved by dragging with mouse, but it is perfectly usable. Regards, Roman Subject: Re: [therion] bad option utf-8 From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 13:48:16 +0100 To: therion@speleo.sk Roman Muñoz wrote: > Sorry, I think my explanations were not clear. OK - I will try to reproduce your error - it really looks like a bug. > BTW, results (after manual editing of .th2 file) are very nice! It would > be handier if other background images could be moved by dragging with > mouse, but it is perfectly usable. Every background image (incl. xvi) can be moved by mouse. Just double-click on it with right button (on XVI - doubleclik on centerline or grid or passage) and drag by mouse. It is also written in Help -> Control... Drawing area and background images * RightClick = scroll drawing area * Double RightClick on the image = move the image S. Subject: Re: [therion] bad option utf-8 From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 14:00:08 +0100 To: therion@speleo.sk Roman Muñoz wrote: > .xvi image on it. But if I go to Archive->New and then try > to load it as background image, I get this utf-8 error > So I think something is wrong in "Overwrite" step. Oooops - it is not an error. The problem is very simple. Background images can be inserted only to file, that already has some name (because xtherion checks, whether they are in the path of .th2 file). Therefore, when you try to insert background image to new file, xtherion tries to save it first :) So in the first window - it asks you for the filename of th2 file (not XVI file). If you type there something like cave, he saves it as cave.th2 and then he asks you for background image - now you have to select xvi file. If you select XVI file first - it saves th2 file as XVI and then he tries to open it - but it is no more XVI file, but th2 file. OK - this can lead to the lot of mistakes - I will redo it more natural way. Thanks for pointing out. > Also,I found that my previous background images, which are screen > captures from a 1:1000 survey, are far bigger than .xvi file. However, > my layout has a "scale 1 1000" line. Not sure here: may be I made some > mistake when capturing screens. I will check this again later. As I wrote before - 100 dpi is assumed. If you have 1:1000 scan at 200 dpi, you have to use 1:1000/(200dpi/100dpi) = 1:500 scale in your xvi export command. A very simple mathematics :) S. Subject: Re: [therion] bad option utf-8 From: Stacho Mudrak <s.m@speleo.sk> Date: Tue, 22 Feb 2005 14:57:50 +0100 To: therion@speleo.sk > OK - this can lead to the lot of mistakes - I will redo it more natural way. Thanks for pointing out. It should be done now. You can try. Regards, S. Subject: Re: bad option utf-8 From: Wookey <wookey@aleph1.co.uk> Date: Tue, 22 Feb 2005 15:48:12 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-02-22 14:00 +0100]: >> As I wrote before - 100 dpi is assumed. If you have 1:1000 scan at 200 >> dpi, you have to use 1:1000/(200dpi/100dpi) = 1:500 scale in your xvi >> export command. A very simple mathematics :) Hmmm, I have the feeling this is a bit of a hack and there should be a better way...I will try using it and see. There should be a way for users to make centrelines match to drawings graphically, not having to know the resolution of the scan and re-generate the centreline using a strange scale to make it fit... I presume that this new centreline feature is only useful if you have your dataset in therion form, not survex form - right (i.e an imported 3d file can not be used to generate .xvi files)? 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: bad option utf-8 From: Olly Betts <olly@survex.com> Date: Tue, 22 Feb 2005 15:58:55 +0000 To: therion@speleo.sk On Tue, Feb 22, 2005 at 03:48:12PM +0000, Wookey wrote: >> There should be a way for users to make centrelines match to drawings >> graphically, not having to know the resolution of the scan and re-generate >> the centreline using a strange scale to make it fit... Tunnel seems to do this very well. I *think* it works like this: (1) you select a point on the background image and the corresponding point on you drawing then tell tunnel to translate to make the two coincide. (2) you select the point which matches from (1), and another pair of corresponding points, then tell tunnel to rotate and scale around the point in (1) to make the other pair coincide. Provided tcl/tk can rotate and scale images, it shouldn't be too hard to implement. >> I presume that this new centreline feature is only useful if you have your >> dataset in therion form, not survex form - right (i.e an imported 3d file >> can not be used to generate .xvi files)? I'd assume so - the .3d file doesn't currently contain LRUD. Cheers, Olly Subject: Re: [therion] Re: bad option utf-8 From: "M.J. Green" <mjg54@cam.ac.uk> Date: 22 Feb 2005 16:43:47 +0000 To: therion@speleo.sk On Feb 22 2005, Olly Betts wrote: > On Tue, Feb 22, 2005 at 03:48:12PM +0000, Wookey wrote: > > There should be a way for users to make centrelines match to drawings > graphically, not having to know the resolution of the scan and > re-generate the centreline using a strange scale to make it fit... > > Tunnel seems to do this very well. I *think* it works like this: > > (1) you select a point on the background image and the corresponding > point on you drawing then tell tunnel to translate to make the two > coincide. > > (2) you select the point which matches from (1), and another pair of > corresponding points, then tell tunnel to rotate and scale around > the point in (1) to make the other pair coincide. This is how tunnel works, it can work quite well, assuming that there is no distortion in the image, i.e. a nice scan rather than photographed, and if there are any loop closures, then the destortions for each loop is calculated the same. In case you want to use the same ordering of clicks, for the rotation and scaling, the first click is where the scan is at the same point as the computer centreline, the secound is on a point on the scan and the third is on the corresponding point on the centre line. The first and last clicks are typically survey stations, so you can tell tunnel to start and finish on them(using snap to node features), so there are no errors due to not quite clicking on the survey stations. Cheers, Martin Subject: Re: [therion] Re: bad option utf-8 From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Feb 2005 08:00:47 +0100 To: therion@speleo.sk Wookey wrote: > There should be a way for users to make centrelines match to drawings > graphically, not having to know the resolution of the scan and re-generate > the centreline using a strange scale to make it fit... We intended XVI background images for centerline data, for which drawings do not exists or they are drawn completely out of scale. In fact, there is no need to overlap XVI data with scanned images. It was only an information. If you have your drawings not in scale (i.e. wrong bearings, lengths etc...), than it would be probably much usefull to stretch bitmap to centerline data (like WinKarst is doing). Regards, S. Subject: Re: [therion] Re: bad option utf-8 From: Martin Sluka <martinsluka@mac.com> Date: Wed, 23 Feb 2005 09:11:51 +0100 To: therion@speleo.sk At 15:58 +0000 22.2.2005, Olly Betts wrote: ******************************************* > > There should be a way for users to make centrelines match to drawings > >> graphically, not having to know the resolution of the scan and re-generate >> the centreline using a strange scale to make it fit... > > > Tunnel seems to do this very well. I *think* it works like this: The therion too: 1. each handmade sketch include usually two survey points. 2. you may use each such sketch as one scrap - the survey points will calibrate it - but draw ONLY wals of each scrap. 3. join all scraps together and generate .XVI file. 4. Use .XVI file as backgroud image and draw all the map with all the details in scale. My 0.02 EUR Martin Sluka -- Subject: Re: [therion] Re: bad option utf-8 From: Martin Sluka <martinsluka@mac.com> Date: Wed, 23 Feb 2005 09:39:21 +0100 To: therion@speleo.sk At 09:11 +0100 23.2.2005, Martin Sluka wrote: ******************************************* > 4. Use .XVI file as backgroud image and draw all the map with all the details in scale. sorry - next release, recent is able to export only survey points and shots. if there are not the areas or lines crossing borders between two scraps, you may generate complet map this way, too Martin Sluka -- Subject: next dumb question From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 22 Feb 2005 19:01:41 +0100 To: therion@speleo.sk On Tue, 22 Feb 2005 14:00:08 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> So in the first window - it asks you for the filename of th2 file (not >> XVI file). Aah. Understood. I readed about saving th2 files first in Wookey's writing, but missed this window was asking me for it. I was not worried about relative paths. >> As I wrote before - 100 dpi is assumed. If you have 1:1000 scan at 200 >> dpi, you have to use 1:1000/(200dpi/100dpi) = 1:500 scale in your xvi >> export command. A very simple mathematics :) Yeah, something like this should have happen. Most probably image was being not visualized at 100 % when I dumped the screen. Dumped .pnm files are at 100x97 resolution. New images are actually smaller than xvi one, but I think this is not therion-related ;-) Dragging background images: I like it a lot. Thanks. Next dumb question: what about extended elevation? To use "extend" option in centerline is enough? Do I need have some scrap with projection "extended"? Could LRUD data be used in map editor? Best regards, Roman Subject: Re: [therion] next dumb question From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Feb 2005 08:11:11 +0100 To: therion@speleo.sk Roman Muñoz wrote: > Aah. Understood. I readed about saving th2 files first in Wookey's > writing, but missed this window was asking me for it. I was not worried > about relative paths. In any case - new version will inform you that it would like to save file explicitely. > Next dumb question: what about extended elevation? To use > "extend" option in centerline is enough? Do I need have some scrap with > projection "extended"? Could LRUD data be used in map editor? Extended elevation is currently my nightmare :) OK - I will try to explain. Currently - you are not able to export centerline in extended elevation projection. All you can do are scraps and maps in extended elevation with a very complicated "extend" point option syntax. Also stations need to be in special order etc. I would like to change it exactly the way, you suggested. To add extend option to centerline (remove it from point). Then extend centerline first - and then everything else will work normally. There will be no need to draw stations in scraps in specific order with complicated extend options, you will be able to export surveys in this projection to map etc... If users will agree (probably nobody until now did a lot of extended elevations - because it was so complicated), I can change this until 0.3.7 comes (probably). Regards, S. Subject: Re: [therion] next dumb question From: Martin Sluka <martinsluka@mac.com> Date: Wed, 23 Feb 2005 08:41:46 +0100 To: therion@speleo.sk At 08:11 +0100 23.2.2005, Stacho Mudrak wrote: ******************************************* > Extended elevation is currently my nightmare :) not only yours - remeber extended elevation module in toporobot :) MS. -- Subject: Re: [therion] next dumb question From: Eric Madelaine <madelain@nerim.fr> Date: Wed, 23 Feb 2005 12:36:54 +0100 To: therion@speleo.sk > If users will agree (probably nobody until now did a lot of extended elevations - because it was so complicated), I can change this until 0.3.7 comes (probably). I'm one of those that tried it, with some pain... and Stacho certainly remembers this. I have not done that much Therion since last summer, and no extended elevation at all. So for me it is perfectly ok if you change it completely. Eric. Subject: Re: [therion] next dumb question From: John Pybus <john@pybus.org> Date: Wed, 23 Feb 2005 12:27:21 +0000 To: therion@speleo.sk Stacho Mudrak wrote: > I would like to change it exactly the way, you suggested. To add extend option to centerline (remove it from point). Then extend centerline first - and then everything else will work normally. There will be no need to draw stations in scraps in specific order with complicated extend options, you will be able to export surveys in this projection to map etc... > > If users will agree (probably nobody until now did a lot of extended elevations - because it was so complicated), I can change this until 0.3.7 comes (probably). An excellent idea, change it now it only gets harder to change things as time goes by. Now that therion supports it, I'm keeping all my centreline data in survex format and importing .3d files. survex can create a flattened .3d with the 'extend' command. I'd like to be able to import these for my extended centreline. Cheers, John Subject: Re: [therion] next dumb question From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 23 Feb 2005 12:52:15 +0100 To: therion@speleo.sk On Wed, 23 Feb 2005 08:11:11 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> I would like to change it exactly the way, you suggested. To add >> extend option to centerline (remove it from point). Then extend >> centerline first - and then everything else will work normally. There >> will be no need to draw stations in scraps in specific order with >> complicated extend options, you will be able to export surveys in this >> projection to map etc... >> If users will agree (probably nobody until now did a lot of extended >> elevations - because it was so complicated), I can change this until >> 0.3.7 comes (probably). Please do it. I know, it's easy for me to say it, because I didn't any extended survey yet. I understand that long time users could have big extended surveys so this change could be harmful for them. But it would be useful, so I can only beg for it and hope all people will agree... Regards, Roman Subject: Re: [therion] next dumb question From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Wed, 23 Feb 2005 15:48:17 +0100 (CET) To: therion@speleo.sk Roman Muńoz napsal(a): >> Please do it. I know, it's easy for me to say it, because I didn't any >> extended survey yet. I understand that long time users could have big >> extended surveys so this change could be harmful for them. >> >> But it would be useful, so I can only beg for it and hope all people >> will agree... I vote also for change. I have only two extended surveys in Therion (small not complicated caves). If you change it later it will be pain change for more users. L. Subject: Re: [therion] next dumb question From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Feb 2005 15:50:58 +0100 To: therion@speleo.sk Ladislav Blazek wrote: > I vote also for change. I have only two extended surveys in Therion (small > not complicated caves). If you change it later it will be pain change for > more users. L. Changing existing data should be not too much work. Just to remove some -extend options from points (OK - I can throw warnings about them not errors) and adding some extend options to centerline data if necessary. S. Subject: invalid command message From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 22 Feb 2005 21:23:47 +0100 To: Therion <therion@speleo.sk> After trying to close whitout saving before -so got message about "Save it now?- I got Error: invalid command name ".xth.me.sf.sbar" invalid command name ".xth.me.sf.sbar" invalid command name ".xth.me.sf.sbar" while executing "$sbar configure -text [lindex $xth(gui,sbar,$aname) 0]" (procedure "xth_status_bar_pop" line 7) invoked from within "xth_status_bar_pop me" ("after" script) Subject: Re: [therion] invalid command message From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Feb 2005 07:56:23 +0100 To: therion@speleo.sk OK, I will check it. I have the same experience from time to time. Regards, S. Roman Muñoz wrote: > After trying to close whitout saving before -so got message about "Save > it now?- I got Error: invalid command name ".xth.me.sf.sbar" > > > invalid command name ".xth.me.sf.sbar" > invalid command name ".xth.me.sf.sbar" > while executing > "$sbar configure -text [lindex $xth(gui,sbar,$aname) 0]" > (procedure "xth_status_bar_pop" line 7) > invoked from within > "xth_status_bar_pop me" > ("after" script) > > Subject: Recent changes From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Feb 2005 08:19:13 +0100 To: therion@speleo.sk There are two important changes in latest snapshot: * import command can exist outside survey - endsurvey pair. Stations and shots outside survey context will not be imported. * in layout - code tex-map/atlas, there are supported international characters. So currently following stuff will work as expected code tex-map \cavename={Jaskyňa mŕtvych netopierov} endcode Regards, S. Subject: Re: 20050223 translation From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 24 Feb 2005 08:35:43 +0100 To: Roman Muñoz <tatel@infonegocio.com> CC: therion@speleo.sk Roman Muñoz wrote: > a) I've seen types translation. It seems to be visible only after type > is selected. It is not as handy as expected, but is better than nothing > anyway. Thanks a lot. Yes. May be adding translation line right above the list box would be better (at least you will not need to focus your eyes on the oposite corner of the screen). Also translation of list-box items should be possible. The only problem is - that options line can not be translated this way - therefore there will be still mixed english with some local language. May be another solution that is already in the TODO list wuld help (Wookey asked for it). Add context menu when right clicked on point/station. Via this menu - a type and most common options (like alignment, text, value) could be selected. This could be then translated. > b) I can't see types in xtext* file. If it would be necesary fix some > of them, where can I find them? Those translations are taken from therion symbol list. You have to edit thlang/texts.txt. > c) A lobbyed friend of mine was getting stuck right after opening > Therion. He don't realized that he needs to open existing files or > create new ones in order to activate user interface. Could we have some > status bar message displayed when pointer is on canvas and there are no > open files? Somewhat like "To activate user interface, open existing > file or create new one" Should be no problem. I'll put it into TODO list. > d) Same way, I think new warning about need to save recently > created th2 file should mention the "th2" thing explicitly. > > e) I observed that you have modified some of existing strings same way I > did, but not all of modified spanish strings have their english > equivalent. If you find it useful, I could do this in english too, > ideally after translation is completed and before 0.3.7 release. It would be great. The best way how to do it is to add en translation - not to modify source files. So just export empty xtexts_en.txt file and you can fill all strings you want. > f) I'm planning to do my writing in "english" too, and put both versions > on wiki after 0.3.7 release Thanks, S. Subject: preliminary text From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 25 Feb 2005 20:22:07 +0100 To: Therion <therion@speleo.sk> Hi all, I wrote a preliminary text about therion on "english" It is not finished, but I would get some feedback. So, if you have a little bit of spare time, you could visit http://www.infonegocio.com/tatel/therion_for_cavers.txt and drop a word about it on the list. Gramatical corrections will be welcome ;-) I know, this will be on wiki... when finished. Cheers, Roman Subject: Re: preliminary text From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 28 Feb 2005 14:06:59 +0100 To: therion@speleo.sk Great work! When finished, it will certainly help a lot of people. OK, my remarks: > You can add other specification lines to your centerline data. In fact, > you should specify (at least) date, declination, team members and data Declination can be entered also for entire survey (all centerlines in it) - and it can depend on date. At least, we use it this way more often. > source template.th > > layout xvi-export > scale 1 1000 > grid top > grid-size 1 1 1 m > endlayout "grid top" line is not necessary. Currently this is ignored and grid is created all the time on the bottom. > "Background image" panel control is the "Drawing area" panel control. > You can press the "Auto adjust" button so canvas dimensions adapt to > .xvi image automatically. Click on rectangle next to "Zoom 100%" to "Auto adjust" should be now called automatically - when new background image is inserted. > Passage-height points are important because 3D model are build according > to them. Insert a point where passage-height is known. Then select > "passage-height" from point's type menu. In the options textbox, > write: > > value <number> <number> > > Where first <number> is distance to ceiling and second one is dastance to floor. This is a BUG in therion-book - I am sorry. First number should mean height above water level and the second depth of water. I have seen this symbol only in this context of water level - never in the context of ceiling/floor specification. To add specification of UP/DOWN dimensions in the 2D map for 3D model, we have point type dimensions in the TODO list. Regards, S. Subject: Re: [therion] Re: preliminary text From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 28 Feb 2005 14:00:58 +0100 To: therion@speleo.sk On Mon, 28 Feb 2005 14:06:59 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> Declination can be entered also for entire survey (all centerlines in >> it) - and it can depend on date. At least, we use it this way more >> often. So it is calcalated automatically? Could I, say to have a survey with year 2000 declination value and centerlines in it will be adjusted to respective dates? >> "grid top" line is not necessary. Currently this is ignored and grid >> is created all the time on the bottom. >> "Auto adjust" should be now called automatically - when new background >> image is inserted. OK,I will update this. >> This is a BUG in therion-book - I am sorry. First number should mean >> height above water level and the second depth of water. I have seen >> this symbol only in this context of water level - never in the context >> of ceiling/floor specification. >> >> To add specification of UP/DOWN dimensions in the 2D map for 3D model, >> we have point type dimensions in the TODO list. Ooops. I will update this too. BTW, my model seems to have some height information, where it comes from? Probably I'll drop passage-height part, but I would replace it for more accurate information. Regards, Roman Subject: Re: [therion] Re: preliminary text From: Stacho Mudrak <s.m@speleo.sk> Date: Mon, 28 Feb 2005 16:29:43 +0100 To: therion@speleo.sk Roman Muñoz wrote: > So it is calcalated automatically? Could I, say to have a survey with > year 2000 declination value and centerlines in it will be adjusted to > respective dates? Yes. You can specify declination for 1990 and 2000 (e.g. -declination [1990 2.0 2000 3.0 deg]), and all centerlines between will be adjusted (e.g. in 1995, declination 2.5deg will be used). > Ooops. I will update this too. > BTW, my model seems to have some height information, where it comes > from? It is generated on the base of survey shot lengths (long shots = big passages, small shots = small passages). In any case - therion should use at least specified UD information - I will try to add it soon. Regards, S. Subject: Re: [therion] Re: preliminary text From: Martin Sluka <martinsluka@mac.com> Date: Mon, 28 Feb 2005 17:55:31 +0100 To: therion@speleo.sk At 16:29 +0100 28.2.2005, Stacho Mudrak wrote: ******************************************* >> So it is calcalated automatically? Could I, say to have a survey with >> year 2000 declination value and centerlines in it will be adjusted to >> respective dates? > > > Yes. You can specify declination for 1990 and 2000 (e.g. -declination [1990 2.0 2000 3.0 deg]), and all centerlines between will be adjusted (e.g. in 1995, declination 2.5deg will be used). You may generate the declination for one datum or for time interval on page: http://www.ngdc.noaa.gov/seg/geomag/jsp/struts/calcDeclination/ and copy/paste it to your .th file. MS. -- Subject: last snapshot From: Roman Muñoz <tatel@infonegocio.com> Date: Wed, 2 Mar 2005 09:18:44 +0100 To: Therion <therion@speleo.sk> Hi all, I compiled last snapshot. Pop-up strings are nice :) Are there any other changes? Regards, Roman Subject: Re: [therion] last snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 02 Mar 2005 11:53:07 +0100 To: therion@speleo.sk Roman Muñoz wrote: > Pop-up strings are nice :) I suddenly discovered this feature of BWidgets last week :) . It was one line of code. > Are there any other changes? I started to work on extended elevation, but still not finished (I have a very busy week now). S. Subject: Re: [therion] last snapshot From: Martin Sluka <martinsluka@mac.com> Date: Wed, 2 Mar 2005 12:07:10 +0100 To: therion@speleo.sk on wiki are small thumbnails picts in examples area and new part of FAQ - modification of structure of maps. Martin S. -- Subject: Re: [therion] last snapshot From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 09:06:07 +0100 To: therion@speleo.sk Hi, I have some concerns about pop-up strings. While they are nice to start up with Xtherion, once the user is used to GUI they could be annoying. So main concern is wether it's possible to get pop-up strings inactive, may be by clicking some checkbutton or so. Regards, Roman On Wed, 02 Mar 2005 11:53:07 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> Roman Muñoz wrote: > >>> > Pop-up strings are nice :) > >> >> I suddenly discovered this feature of BWidgets last week :) . It was >> one line of code. >> > >>> > Are there any other changes? > >> >> I started to work on extended elevation, but still not finished (I >> have a very busy week now). >> >> S. >> >> Subject: Re: [therion] last snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 03 Mar 2005 11:44:29 +0100 To: therion@speleo.sk > So main concern is wether it's possible to get pop-up strings inactive, > may be by clicking some checkbutton or so. There should be some balloon item in xtherion.ini. When set to 0, pup-up strings should not be visible any more. Regards, S. Subject: Re: [therion] last snapshot From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Thu, 3 Mar 2005 12:12:38 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >>>> So main concern is wether it's possible to get pop-up strings inactive, >>>> may be by clicking some checkbutton or so. > >> >> There should be some balloon item in xtherion.ini. When set to 0, pup-up >> strings should not be visible any more. Is it also possible to switch language somehow? For example: my locales are set to CZ but I would like to use xtherion in english. What is the purpose of following lines in xtherion.ini? ## prefered language for messages # ::msgcat::mclocale sk L. Subject: Re: [therion] last snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 03 Mar 2005 12:20:35 +0100 To: therion@speleo.sk > Is it also possible to switch language somehow? For example: my locales > are set to CZ but I would like to use xtherion in english. > What is the purpose of following lines in xtherion.ini? > > ## prefered language for messages > # ::msgcat::mclocale sk This line is exactly for that. S. Subject: Re: [therion] xtherion.ini not found From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 10:43:22 +0100 To: therion@speleo.sk On my debian box: $THERION is not set, even if Xtherion is running (echo $THERION shows nothing) xtherion ini is on ~/src/therion/xtherion/xtherion.ini. No search for xtherion.ini seems to be done in xtherion directory. So, after editing xtherion.ini, I need to move it manually under /etc. Else, Xtherion runs with default values since .ini file is not found. I think it should be made by "make install" automatically Regards, Roman On Thu, 03 Mar 2005 11:44:29 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >>> > So main concern is wether it's possible to get pop-up strings >>> > inactive, may be by clicking some checkbutton or so. > >> >> There should be some balloon item in xtherion.ini. When set to 0, >> pup-up strings should not be visible any more. >> >> Regards, S. Subject: Re: [therion] xtherion.ini not found From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 03 Mar 2005 13:15:11 +0100 To: therion@speleo.sk Probably the best place for xtherion.ini and therion.ini files on any linux is .therion directory in your home path. Have you tried this? > file is not found. I think it should be made by "make install" > automatically I will put it in my TODO list. Regards, S. Subject: Re: [therion] xtherion.ini not found From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 11:12:19 +0100 To: therion@speleo.sk You are rigth. I noticed that after editing xtherion, main menu was slower at loading. This seems not to be the case when placed on .therion. But I still think it would be better if this directory would be created by "make install" and xtherion.ini moved accordingly (or environment variable set rigthly) Regards, Roman On Thu, 03 Mar 2005 13:15:11 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> Probably the best place for xtherion.ini and therion.ini files on any >> linux is .therion directory in your home path. Have you tried this? >> > >>> > file is not found. I think it should be made by "make install" >>> > automatically > >> >> I will put it in my TODO list. >> >> Regards, S. Subject: Re: [therion] xtherion.ini not found From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 03 Mar 2005 13:37:39 +0100 To: therion@speleo.sk > be created by "make install" and xtherion.ini moved accordingly (or > environment variable set rigthly) Yes, I will do it. S. Subject: Re: xtherion.ini not found From: Wookey <wookey@aleph1.co.uk> Date: Thu, 3 Mar 2005 14:46:11 +0000 To: therion@speleo.sk +++ Roman Muñoz [05-03-03 10:43 +0100]: >> On my debian box: >> >> $THERION is not set, even if Xtherion is running (echo $THERION shows >> nothing) >> >> xtherion ini is on ~/src/therion/xtherion/xtherion.ini. No search for >> xtherion.ini seems to be done in xtherion directory. >> >> So, after editing xtherion.ini, I need to move it manually under >> /etc. Else, Xtherion runs with default values since .ini >> file is not found. I think it should be made by "make install" >> automatically Are you using the standard Debian package, or your own build? Presumably the latter. You are saying that you'd like ./therion.ini to be checked as well as /etc/therion.ini ? That would be sensible. File a bug to remind me to do this. (or even better stacho - you put it in upstream :-) 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: xtherion.ini not found From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 14:27:17 +0100 To: therion@speleo.sk On Thu, 3 Mar 2005 14:46:11 +0000 Wookey <wookey@aleph1.co.uk> wrote: >> Are you using the standard Debian package, or your own build? >> Presumably the latter. I'm using my own build >> You are saying that you'd like ./therion.ini to be checked as well as >> /etc/therion.ini ? That would be sensible. File a bug to remind me to >> do this. (or even better stacho - you put it in upstream :-) I can't find neither /etc/therion.ini nor /etc/xtherion.ini. Also, $THERION is not set. I don't realized this until now, because all is working quite fine with default values. Only after editing xtherion I realized that changes where not reflected (kbd encoding and balloons). I guess sarge package installs /etc/therion.ini? What I'd like is to have an install script wich makes what it is supposed to do, i.e, install things in directories where they are supposed to be. Else, you need to say new users not only they need to edit .ini files, but move them too. For a plain caver, it would be annoying to tinker with. For builds from source, no matter which directories hold this files while they are on search path. In a debian package, configuration files are supposed to go under /etc, rigth? So I think it should go like this. However, I noticed that main menu loads slowly with xtherion.ini installed under /etc. Since I don't have tried sarge package, I don't know exactly what happens with it. I'm considering to install sarge on another box after d-i rc3 release, then I could file bugs. Getting therion into sarge would be fine for me. But, even if Debian is quite common among linux distros in Spain, I don't know any spanish caver having installed Linux. I know a few (5-6 individuals?) running Mac. All the others are on windows. In fact, most are IT-allergics Regards, Roman Subject: Re: [therion] Re: xtherion.ini not found From: Olly Betts <olly@survex.com> Date: Thu, 3 Mar 2005 15:57:28 +0000 To: Roman Muñoz <tatel@infonegocio.com> CC: therion@speleo.sk On Thu, Mar 03, 2005 at 02:27:17PM +0100, Roman Mu?oz wrote: >> Also, $THERION is not set. If you want THERION to be set, you need to set it yourself. That's how environment variables work on UNIX - there isn't really a sensible mechanism for a program to add one when it is installed. Assuming your shell is bash, put this in your .bashrc: export THERION=/path/to/therion This will then be set in any new shells you start. To reread for an existing shell, type: . ~/.bashrc which will run the commands in that file. Cheers, Olly Subject: Xtherion on MacOS X From: Thierry GONON <thierrygonon@mac.com> Date: Thu, 3 Mar 2005 14:01:39 +0100 To: therion@speleo.sk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I finally take time to install a good Tcl/Tk version, and now, Xtherion can run on my Mac... But... When I try to compile the demo file (demo-padavka in that case), Xtherion answer : ####################### metapost log file ######################## therion: warning -- can't open data.log file for input can't open data.log file for input#################### end of metapost log file #################### therion: error -- metapost exit code -- 32512 It seem that I have a problem with metapost... Do you know this problem, and how I can solve it ?? Thank you very much ! Thierry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCJwqz1Au96VwreaARAhrEAJ9Bc8X/JIKE2cCgFVKvGwzen67hNwCggAYX CDOep/6evb3CAmnhiAKRCSQ= =qJr7 -----END PGP SIGNATURE----- Subject: Re: [therion] Xtherion on MacOS X From: Stacho Mudrak <s.m@speleo.sk> Date: Thu, 03 Mar 2005 14:05:02 +0100 To: therion@speleo.sk > It seem that I have a problem with metapost... Do you know this problem, and how I can solve it ?? Which TeX distribution do you have installed? It looks, that therion is not able to run metapost. Are you able to run "mpost" from command line? S. Subject: Re: [therion] Xtherion on MacOS X From: Thierry GONON <thierrygonon@mac.com> Date: Thu, 3 Mar 2005 19:14:05 +0100 To: therion@speleo.sk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I use the following version of TeX , in fact a teTex version : TeX (Web2C 7.5.2) 3.141592 kpathsea version 3.5.2 Copyright (C) 1997-2003 D.E. Knuth. Kpathsea is copyright (C) 1997-2003 Free Software Foundation, Inc. when I run mpost from command line, everything seem OK : it ask me for a file, indicating : This is MetaPost, Version 0.641 (Web2C 7.5.2) (/usr/local/teTeX/share/texmf.tetex/web2c/cp8bit.tcx) ** Thierry Le 3 mars 05, à 14:05, Stacho Mudrak a écrit : >> It seem that I have a problem with metapost... Do you know this problem, and how I can solve it ?? > > > Which TeX distribution do you have installed? > > It looks, that therion is not able to run metapost. Are you able to run "mpost" from command line? > > S. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCJ1Pu1Au96VwreaARAuqvAKDN55qhRrQ/uve7f9ZKT7w3bTDc4QCfT0dN 8NHTcVBeCnhZZ+Kfyow0Fp0= =5wLP -----END PGP SIGNATURE----- Subject: Re: Xtherion on MacOS X From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 04 Mar 2005 09:32:55 +0100 To: therion@speleo.sk > I use the following version of TeX , in fact a teTex version : > TeX (Web2C 7.5.2) 3.141592 > kpathsea version 3.5.2 > Copyright (C) 1997-2003 D.E. Knuth. > Kpathsea is copyright (C) 1997-2003 Free Software Foundation, Inc. > > when I run mpost from command line, everything seem OK : it ask me for a file, indicating : > This is MetaPost, Version 0.641 (Web2C 7.5.2) > (/usr/local/teTeX/share/texmf.tetex/web2c/cp8bit.tcx) So it looks to me - that tcl is calling different shell to execute system calls than your command console is. This different shell has probably not correct environment settings. In that case, you will probably need to set up exact path to mpost and pdfetex executables. You can do it via therion.ini. Copy therion.ini file to /etc. Edit following lines: # mpost-path "mpost" # pdftex-path "pdfetex" to mpost-path "/your/path/to/mpost" pdftex-path "/your/path/to/pdfetex" where /your/path/to is usually /usr/bin or /usr/local/bin. But I am not sure, how it is on Mac OS X. Another question: do you have same problems with demo files, when running therion from command line? Do following commands work? cd demo-padavka therion Hope this helps. Regards, S. P.S. MartinS has sent me something about his installation of teTeX that works. It is here: Last login: Fri Mar 4 08:41:14 on ttyp1 Welcome to Darwin! bash-2.05a$ mpost This is MetaPost, Version 0.641 (Web2C 7.3.8) **^C bash-2.05a$ tex This is TeX, Version 3.14159 (Web2C 7.3.8) **^C xxxxxxxxxxxxxxxxxxxxxxxx installed via: i-installer - http://www.rna.nl/ii.html xxxxxxxxxxxxxxxxxxxxxxxx Logiciels sur micros-ordinateurs freeBSD (linux, macOSX) Serveur d'applications libres pour l'unix d'Apple : Mac OSX Menu Aller > se connecter au serveur ... dans la zone SIO sélectionnez la machine : macosxserveur , et choisissez (à nouveau) macosxserveur : * Tout se trouve dans le réperrtoire OSX mais il marche encore : MacServeur-SIO : Vous trouverez sur le vieux Macintosh 6100 : MacServeur-SIO, qui se trouve dasn la zone AppleTalk SIO, un ensemble de logiciels du monde Open Source pour les utilisateurs scientifiques de MacOSX : Dans le répertoire MACOSX Offre spéciale : MacOS X (système unix-freeBSD- d'Apple) Attention sortie prochiane de PANTHER (MacOSX 10.3) Pour l'Observatoire, vous pouvez acquérir le système unix d'Apple chez MacWareHouse * Obtenir un devis : o Monsieur Roger TRUONG (roger.truong @ eu.mwhse.com) + tél : 01 41 84 44 57 + fax : 01 48 17 83 02 La configuration minimum requise pour le fonctionnement de MacOS X : * PowerMac G3, G4 Cube, G4 * iMac * PowerBook G3, G4 * iBook o et un minimum de 128 Mo de RAM SCISOFT pour Mac OS X : SciSoft = a collection of astronomical software for ESO users. L'ESO propose une collection de logiciels pour l'astronomie : iraf, midas, stsdas, pour le système d'exploitation unix d'Apple Mac OS X, téléchargeable à l'url : http://www.stecf.org/macosxscisoft/. Ou sur le site de versiontracker (SciSoft version 2003.2.3): http://www.versiontracker.com/dyn/moreinfo/macosx/20126 et pour toutes les plateformes: http://www.eso.org/science/scisoft/. Iraf et MacOSX NOAO a porté Iraf pour MacOSX dans sa version IRAF 2.12, voir à l'adresse http://iraf.noao.edu/iraf/web/macport.html Le site de Marcos, pour vous aider à installer le logiciel iraf sur l'unix d'apple, voir "The Macintosh IRAF web Page" à l'url http://www.owlnet.rice.edu/~marcosh/iraf/ LaTeX pour MacOSX Pour installer l'environnement LateX sur votre machine il vous faut l'ensemble teTex et sur MacOSX, le freeware TeXShop, ou iteXMac (previewer for teTeX - Open Source) pour pouvoir mettre en forme facilement vos textes : Ces freewares vous offrent : Une fenêtre d'édition, traitement de texte, et balises de mise en forme colorées. Une fenêtre de prévisualisation pour voir le résultat, d'un coup de clic. * teTeX : deux solutions o Il vous faut donc teTeX pour MaxOSX (distribution standard de teX pour les machines unix) + pour plus de facilité, uitliser i-Installer (trés facile), à l'adresse http://www.rna.nl/ + ou pour ceux qui préfère fink à l'adresse http://www.apple.com/downloads/macosx/unix_open_source/ # vous trouverez FinkCommander (GUI pour Fink) et Fink o Vous trouverez i-Installer et teTeX for Mac OSX à l'adresse http://www.rna.nl/ + i-Installer v2. i-Installer est une interface conviviale d'installation et de configuration d'applications unix pour Mac OSX, à partir d'internet. + http://www.rna.nl/tex.html distribution TeX pour Mac OS X: * Installer l'interface conviviale à l'ensemble logiciel teTeX o TeXShop : http://www.apple.com/downloads/macosx/ o iTeXMac : http://itexmac.sourceforge.net Subject: Re: [therion] Re: Xtherion on MacOS X From: Thierry GONON <thierrygonon@mac.com> Date: Fri, 4 Mar 2005 11:52:42 +0100 To: therion@speleo.sk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Stacho, Thank you for your help I tried the command line, and everything goes well... in the command line and it generates a good pdf atlas and a godd pdf map. In the therion.ini file, I've made the changes you indicate... but xtherion still don't work and give the same answer ! So, now, I don't have real problems to use therion, except that I must compile within the command line !! Thank you very much ! Thierry Le 4 mars 05, à 09:32, Stacho Mudrak a écrit : >> I use the following version of TeX , in fact a teTex version : >> TeX (Web2C 7.5.2) 3.141592 >> kpathsea version 3.5.2 >> Copyright (C) 1997-2003 D.E. Knuth. >> Kpathsea is copyright (C) 1997-2003 Free Software Foundation, Inc. >> when I run mpost from command line, everything seem OK : it ask me for a file, indicating : >> This is MetaPost, Version 0.641 (Web2C 7.5.2) >> (/usr/local/teTeX/share/texmf.tetex/web2c/cp8bit.tcx) > > > So it looks to me - that tcl is calling different shell to execute system calls than your command console is. This different shell has probably not correct environment settings. > > In that case, you will probably need to set up exact path to mpost and pdfetex executables. You can do it via therion.ini. Copy therion.ini file to /etc. Edit following lines: > > # mpost-path "mpost" > # pdftex-path "pdfetex" > > to > > mpost-path "/your/path/to/mpost" > pdftex-path "/your/path/to/pdfetex" > > where /your/path/to is usually /usr/bin or /usr/local/bin. But I am not sure, how it is on Mac OS X. > > Another question: do you have same problems with demo files, when running therion from command line? Do following commands work? > > cd demo-padavka > therion > > Hope this helps. > > Regards, S. > > P.S. MartinS has sent me something about his installation of teTeX that works. It is here: > > Last login: Fri Mar 4 08:41:14 on ttyp1 > Welcome to Darwin! > bash-2.05a$ mpost > This is MetaPost, Version 0.641 (Web2C 7.3.8) > **^C > bash-2.05a$ tex > This is TeX, Version 3.14159 (Web2C 7.3.8) > **^C > > xxxxxxxxxxxxxxxxxxxxxxxx > > installed via: i-installer - http://www.rna.nl/ii.html > > xxxxxxxxxxxxxxxxxxxxxxxx > > Logiciels sur micros-ordinateurs freeBSD (linux, macOSX) > > Serveur d'applications libres pour l'unix d'Apple : Mac OSX > > Menu Aller > se connecter au serveur ... dans la zone SIO sélectionnez la machine : macosxserveur , et choisissez (à nouveau) macosxserveur : > > * > Tout se trouve dans le réperrtoire OSX > > > > mais il marche encore : > > MacServeur-SIO : > > Vous trouverez sur le vieux Macintosh 6100 : MacServeur-SIO, qui se trouve dasn la zone AppleTalk SIO, un ensemble de logiciels du monde Open Source pour les utilisateurs scientifiques de MacOSX : > > Dans le répertoire MACOSX > > Offre spéciale : MacOS X (système unix-freeBSD- d'Apple) > > Attention sortie prochiane de PANTHER (MacOSX 10.3) > > Pour l'Observatoire, vous pouvez acquérir le système unix d'Apple chez MacWareHouse > > * Obtenir un devis : > o Monsieur Roger TRUONG (roger.truong @ eu.mwhse.com) > + tél : 01 41 84 44 57 > + fax : 01 48 17 83 02 > > La configuration minimum requise pour le fonctionnement de MacOS X : > > * PowerMac G3, G4 Cube, G4 > * iMac > * PowerBook G3, G4 > * iBook > o et un minimum de 128 Mo de RAM > > SCISOFT pour Mac OS X : > > SciSoft = a collection of astronomical software for ESO users. > > L'ESO propose une collection de logiciels pour l'astronomie : iraf, midas, stsdas, pour le système d'exploitation unix d'Apple Mac OS X, téléchargeable à l'url : http://www.stecf.org/macosxscisoft/. > > Ou sur le site de versiontracker (SciSoft version 2003.2.3): http://www.versiontracker.com/dyn/moreinfo/macosx/20126 > > et pour toutes les plateformes: http://www.eso.org/science/scisoft/. > > > > Iraf et MacOSX > > NOAO a porté Iraf pour MacOSX dans sa version IRAF 2.12, voir à l'adresse > > http://iraf.noao.edu/iraf/web/macport.html > > Le site de Marcos, pour vous aider à installer le logiciel iraf sur l'unix d'apple, voir "The Macintosh IRAF web Page" à l'url http://www.owlnet.rice.edu/~marcosh/iraf/ > > LaTeX pour MacOSX > > Pour installer l'environnement LateX sur votre machine il vous faut l'ensemble teTex et sur MacOSX, le freeware TeXShop, ou iteXMac (previewer for teTeX - Open Source) pour pouvoir mettre en forme facilement vos textes : > > Ces freewares vous offrent : > > Une fenêtre d'édition, traitement de texte, et balises de mise en forme colorées. > Une fenêtre de prévisualisation pour voir le résultat, d'un coup de clic. > > * teTeX : deux solutions > o Il vous faut donc teTeX pour MaxOSX (distribution standard de teX pour les machines unix) > + pour plus de facilité, uitliser i-Installer (trés facile), à l'adresse http://www.rna.nl/ > + ou pour ceux qui préfère fink à l'adresse http://www.apple.com/downloads/macosx/unix_open_source/ > # vous trouverez > FinkCommander (GUI pour Fink) et Fink > o Vous trouverez i-Installer et teTeX for Mac OSX à l'adresse http://www.rna.nl/ > + i-Installer v2. i-Installer est une interface conviviale d'installation et de configuration d'applications unix pour Mac OSX, à partir d'internet. > + http://www.rna.nl/tex.html distribution TeX pour Mac OS X: > * Installer l'interface conviviale à l'ensemble logiciel teTeX > > o TeXShop : http://www.apple.com/downloads/macosx/ > o iTeXMac : http://itexmac.sourceforge.net > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCKD371Au96VwreaARAvlAAJ9plAuarLKsaPyR9SzpPkS6b02BbwCgux5T selK4XEZ6CtAWRMafiAvqzY= =TWOr -----END PGP SIGNATURE----- Subject: Re: [therion] Re: Xtherion on MacOS X From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 04 Mar 2005 12:07:28 +0100 To: therion@speleo.sk Thierry GONON wrote: > In the therion.ini file, I've made the changes you indicate... but xtherion still don't work and give the same answer ! The problem is probably missing environment variables, when tcl executes some system calls. You may try to enter "--print-environment" into "Command line options" in therion compiler. Therion will print something like that: therion 0.3.7 configuration file: thconfig reading ... done INIT=/home/stacho/.therion:/etc:/usr/etc:/usr/local/etc SOURCE=/home/stacho/.therion:/usr/share/therion:/usr/local/share/therion METAPOST=mpost PDFTEX=pdfetex Here you can check, where it is searching for therion.ini file (INIT directories) and also whether METAPOST and PDFTEX are corretly set (with full path). If not - try to put therion.ini into some of the INIT directories. There is another dirty :) possibility. Modify following lines in thexpmap.cxx: this->path_mpost = "mpost"; this->path_pdftex = "pdfetex"; to this->path_mpost = "/path/to/mpost"; this->path_pdftex = "/path/to/pdfetex"; and recompile. May be it will help. If not - we have to change the way how therion is called by wish in MacOSX. S. > So, now, I don't have real problems to use therion, except that I must compile within the command line !! > > Thank you very much ! > > Thierry > > Le 4 mars 05, à 09:32, Stacho Mudrak a écrit : > >>> I use the following version of TeX , in fact a teTex version : >>> TeX (Web2C 7.5.2) 3.141592 >>> kpathsea version 3.5.2 >>> Copyright (C) 1997-2003 D.E. Knuth. >>> Kpathsea is copyright (C) 1997-2003 Free Software Foundation, Inc. >>> when I run mpost from command line, everything seem OK : it ask me for a file, indicating : >>> This is MetaPost, Version 0.641 (Web2C 7.5.2) >>> (/usr/local/teTeX/share/texmf.tetex/web2c/cp8bit.tcx) >> >> >> >> So it looks to me - that tcl is calling different shell to execute system calls than your command console is. This different shell has probably not correct environment settings. >> >> In that case, you will probably need to set up exact path to mpost and pdfetex executables. You can do it via therion.ini. Copy therion.ini file to /etc. Edit following lines: >> >> # mpost-path "mpost" >> # pdftex-path "pdfetex" >> >> to >> >> mpost-path "/your/path/to/mpost" >> pdftex-path "/your/path/to/pdfetex" >> >> where /your/path/to is usually /usr/bin or /usr/local/bin. But I am not sure, how it is on Mac OS X. >> >> Another question: do you have same problems with demo files, when running therion from command line? Do following commands work? >> >> cd demo-padavka >> therion >> >> Hope this helps. >> >> Regards, S. >> >> P.S. MartinS has sent me something about his installation of teTeX that works. It is here: >> >> Last login: Fri Mar 4 08:41:14 on ttyp1 >> Welcome to Darwin! >> bash-2.05a$ mpost >> This is MetaPost, Version 0.641 (Web2C 7.3.8) >> **^C >> bash-2.05a$ tex >> This is TeX, Version 3.14159 (Web2C 7.3.8) >> **^C >> >> xxxxxxxxxxxxxxxxxxxxxxxx >> >> installed via: i-installer - http://www.rna.nl/ii.html >> >> xxxxxxxxxxxxxxxxxxxxxxxx >> >> Logiciels sur micros-ordinateurs freeBSD (linux, macOSX) >> >> Serveur d'applications libres pour l'unix d'Apple : Mac OSX >> >> Menu Aller > se connecter au serveur ... dans la zone SIO sélectionnez la machine : macosxserveur , et choisissez (à nouveau) macosxserveur : >> >> * >> Tout se trouve dans le réperrtoire OSX >> >> >> >> mais il marche encore : >> >> MacServeur-SIO : >> >> Vous trouverez sur le vieux Macintosh 6100 : MacServeur-SIO, qui se trouve dasn la zone AppleTalk SIO, un ensemble de logiciels du monde Open Source pour les utilisateurs scientifiques de MacOSX : >> >> Dans le répertoire MACOSX >> >> Offre spéciale : MacOS X (système unix-freeBSD- d'Apple) >> >> Attention sortie prochiane de PANTHER (MacOSX 10.3) >> >> Pour l'Observatoire, vous pouvez acquérir le système unix d'Apple chez MacWareHouse >> >> * Obtenir un devis : >> o Monsieur Roger TRUONG (roger.truong @ eu.mwhse.com) >> + tél : 01 41 84 44 57 >> + fax : 01 48 17 83 02 >> >> La configuration minimum requise pour le fonctionnement de MacOS X : >> >> * PowerMac G3, G4 Cube, G4 >> * iMac >> * PowerBook G3, G4 >> * iBook >> o et un minimum de 128 Mo de RAM >> >> SCISOFT pour Mac OS X : >> >> SciSoft = a collection of astronomical software for ESO users. >> >> L'ESO propose une collection de logiciels pour l'astronomie : iraf, midas, stsdas, pour le système d'exploitation unix d'Apple Mac OS X, téléchargeable à l'url : http://www.stecf.org/macosxscisoft/. >> >> Ou sur le site de versiontracker (SciSoft version 2003.2.3): http://www.versiontracker.com/dyn/moreinfo/macosx/20126 >> >> et pour toutes les plateformes: http://www.eso.org/science/scisoft/. >> >> >> >> Iraf et MacOSX >> >> NOAO a porté Iraf pour MacOSX dans sa version IRAF 2.12, voir à l'adresse >> >> http://iraf.noao.edu/iraf/web/macport.html >> >> Le site de Marcos, pour vous aider à installer le logiciel iraf sur l'unix d'apple, voir "The Macintosh IRAF web Page" à l'url http://www.owlnet.rice.edu/~marcosh/iraf/ >> >> LaTeX pour MacOSX >> >> Pour installer l'environnement LateX sur votre machine il vous faut l'ensemble teTex et sur MacOSX, le freeware TeXShop, ou iteXMac (previewer for teTeX - Open Source) pour pouvoir mettre en forme facilement vos textes : >> >> Ces freewares vous offrent : >> >> Une fenêtre d'édition, traitement de texte, et balises de mise en forme colorées. >> Une fenêtre de prévisualisation pour voir le résultat, d'un coup de clic. >> >> * teTeX : deux solutions >> o Il vous faut donc teTeX pour MaxOSX (distribution standard de teX pour les machines unix) >> + pour plus de facilité, uitliser i-Installer (trés facile), à l'adresse http://www.rna.nl/ >> + ou pour ceux qui préfère fink à l'adresse http://www.apple.com/downloads/macosx/unix_open_source/ >> # vous trouverez >> FinkCommander (GUI pour Fink) et Fink >> o Vous trouverez i-Installer et teTeX for Mac OSX à l'adresse http://www.rna.nl/ >> + i-Installer v2. i-Installer est une interface conviviale d'installation et de configuration d'applications unix pour Mac OSX, à partir d'internet. >> + http://www.rna.nl/tex.html distribution TeX pour Mac OS X: >> * Installer l'interface conviviale à l'ensemble logiciel teTeX >> >> o TeXShop : http://www.apple.com/downloads/macosx/ >> o iTeXMac : http://itexmac.sourceforge.net >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFCKD371Au96VwreaARAvlAAJ9plAuarLKsaPyR9SzpPkS6b02BbwCgux5T > selK4XEZ6CtAWRMafiAvqzY= > =TWOr > -----END PGP SIGNATURE----- > > Subject: Re: [therion] Re: Xtherion on MacOS X From: Martin Sluka <martinsluka@mac.com> Date: Fri, 4 Mar 2005 12:30:35 +0100 To: therion@speleo.sk At 11:52 +0100 4.3.2005, Thierry GONON wrote: ******************************************* > except that I must compile within the command line !! There is realy something strange. I use therion under MacOSX several years, without any important problem. And I made standard instalations, nothing else. MartinS. -- Subject: therion 0.3.6 in debian testing From: Wookey <wookey@aleph1.co.uk> Date: Thu, 3 Mar 2005 14:35:44 +0000 To: Therion List <therion@speleo.sk> Hi guys - after some bother with Therion getting thrown out of the soon-to-be released version of Debian due to build machine problems, v0.3.6 is now back in, so it will be released as part of the standard distribution when we finally get round to releasing it :-) Just so you know. There may well be time to get the next 0.3.7 release in as well, which would be handy for the Spaniards as there is so much Debian-based Linux in Spain and 0.3.7 will have the internationalisation and spanish translations. We'll see how it goes. 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: sharp language From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 15:15:24 +0100 To: Therion <therion@speleo.sk>, Therion <therion@speleo.sk> HGi all, After re-reading my last postings, I found my own language somewhat sharp. So I must beg your pardon. I can only say that it's the nicotine (or better, lack of it in my blood) who was apeaking. I think I'll get out for some days or at least until I get some valium. Best regards, Roman Subject: sharp language From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 3 Mar 2005 15:15:24 +0100 To: Therion <therion@speleo.sk>, Therion <therion@speleo.sk> HGi all, After re-reading my last postings, I found my own language somewhat sharp. So I must beg your pardon. I can only say that it's the nicotine (or better, lack of it in my blood) who was apeaking. I think I'll get out for some days or at least until I get some valium. Best regards, Roman Subject: Re: [therion] sharp language From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 04 Mar 2005 09:39:56 +0100 To: therion@speleo.sk > So I must beg your pardon. I can only say that it's the nicotine (or > better, lack of it in my blood) who was apeaking. I think I'll get out > for some days or at least until I get some valium. Well, I did not realized that :) There is just one problem with configuration files, that we did not solved until now: 1. If installation will overwrite these files - than user will loose it's settings. 2. If it will not overwrite them, plain user will not have ability to set up new things. In any case - make install - under linux should create them at least. But what to do if those files already exist? Should we create some [x]therion.ini.template files? I have no idea. Regards, S. Subject: Re: [therion] sharp language From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Fri, 4 Mar 2005 10:02:08 +0100 (CET) To: therion@speleo.sk Stacho Mudrak napsal(a): >>>> So I must beg your pardon. I can only say that it's the nicotine (or >>>> better, lack of it in my blood) who was apeaking. I think I'll get out >>>> for some days or at least until I get some valium. > >> >> Well, I did not realized that :) >> >> There is just one problem with configuration files, that we did not >> solved until now: >> >> 1. If installation will overwrite these files - than user will loose >> it's settings. >> >> 2. If it will not overwrite them, plain user will not have ability to >> set up new things. >> >> In any case - make install - under linux should create them at least. >> But what to do if those files already exist? Should we create some >> [x]therion.ini.template files? I have no idea. I have one example from Slackware... There is followin setup for startup scripts... If file exists new file with .new suffix is created. L. Subject: Re: sharp language From: Wookey <wookey@aleph1.co.uk> Date: Fri, 4 Mar 2005 11:27:52 +0000 To: therion@speleo.sk +++ Stacho Mudrak [05-03-04 09:39 +0100]: >>> >So I must beg your pardon. I can only say that it's the nicotine (or >>> >better, lack of it in my blood) who was apeaking. I think I'll get out >>> >for some days or at least until I get some valium. > >> >> Well, I did not realized that :) neither did I - I don't know what you are talking about Roman :-) >> There is just one problem with configuration files, that we did not >> solved until now: >> >> 1. If installation will overwrite these files - than user will loose >> it's settings. >> >> 2. If it will not overwrite them, plain user will not have ability to >> set up new things. >> >> In any case - make install - under linux should create them at least. >> But what to do if those files already exist? Should we create some >> [x]therion.ini.template files? I have no idea. The debian packages solve this by having a concept of 'config' files. These are special files, which if they get overwritten on install (and have been changed since last time), then the installer asks if you want to use the old ones, the new ones, look at the differences etc. For a plain make install, I'm not sure what the normal thing is - I expect just overwriting the old ones is normal. 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: sharp language From: John Pybus <john@pybus.org> Date: Fri, 04 Mar 2005 18:28:37 +0000 To: therion@speleo.sk Wookey wrote: > The debian packages solve this by having a concept of 'config' files. These > are special files, which if they get overwritten on install (and have been > changed since last time), then the installer asks if you want to use the old > ones, the new ones, look at the differences etc. rpm does something similar; the installer adds .rpmnew to the new config file and informs the user. > For a plain make install, I'm not sure what the normal thing is - I expect > just overwriting the old ones is normal. Package management systems have an advantage over make install, in that they know whether the old config file has been altered by the user or not. If not they can just update it. Many (most?) source packages don't explicitly copy config files anywhere on make install, but have template versions in the tarball. Users building/upgrading from source can decide what to do. Builders of binary packages can include them using their package managers features. Either way, make install shouldn't be installing files in ~/. If you do install .ini files put them in /etc/. The user running make install may not be the user running the application (in fact will probably be root). John Subject: .ini files install From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 4 Mar 2005 09:42:56 +0100 To: therion@speleo.sk On Fri, 04 Mar 2005 09:39:56 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> 1. If installation will overwrite these files - than user will loose >> it's settings. I think we could check for the files. If they exist in rigth places, we could assume they are good, so install script a) does nothing b) rename them to .bkp (or .new, as suggested by Ladislav) -no settings are loosed. BTW, why the files can be on so many directories? I think they should be under /etc on *nix and under Program files\therion on windows. It would be simpler. May be Wookey, as debian developer, knows it better. I found some debian packages who ask when detected user-edited configuration files, (but at this moment I can't remember which ones) If this is a matter of shell scripting, I could work on it. >> 2. If it will not overwrite them, plain user will not have ability to >> set up new things. I'm missing something here. What things couldn't be edited? Or, do you mean that install will ask things to set good values? Regards, Roman Subject: Re: [therion] .ini files install From: "Ladislav Blazek" <lblazek@speleo.cz> Date: Fri, 4 Mar 2005 12:34:37 +0100 (CET) To: therion@speleo.sk Roman Muńoz napsal(a): >> On Fri, 04 Mar 2005 09:39:56 +0100 >> Stacho Mudrak <s.m@speleo.sk> wrote: >> >> > >>>> 1. If installation will overwrite these files - than user will loose >>>> it's settings. > >> >> I think we could check for the files. If they exist in rigth places, we >> could assume they are good, so install script a) does nothing b) rename >> them to .bkp (or .new, as suggested by Ladislav) -no settings are >> loosed. >> >> BTW, why the files can be on so many directories? I think they should be >> under /etc on *nix and under Program files\therion on windows. It would >> be simpler. This is *nix standard. You can have global configuration in /etc but each user can change settings for own session in ~/.therion directory L. Subject: Re: [therion] .ini files install From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 04 Mar 2005 12:35:08 +0100 To: therion@speleo.sk > I'm missing something here. What things couldn't be edited? Or, do you > mean that install will ask things to set good values? If I add new setting to xtherion.ini file, if it will not be rewritten, user will not see, that this setting is possible. OK - I think that creating .new files would be OK. Another point - many programs read settings from several places. /etc is a problem for non-root *nix users. S. Subject: Re: [therion] .ini files install From: Olly Betts <olly@survex.com> Date: Mon, 21 Mar 2005 08:21:12 +0000 To: Stacho Mudrak <s.m@speleo.sk> CC: therion@speleo.sk Sorry to come in a bit late... On Fri, Mar 04, 2005 at 12:35:08PM +0100, Stacho Mudrak wrote: >> If I add new setting to xtherion.ini file, if it will not be rewritten, >> user will not see, that this setting is possible. So you're talking about the case when a new option is added and the default setting is added to the shipped configuration file? It's particularly annoying to have your carefully tuned configuration swept aside by an upgrade when the only reason is to add a few "do nothing" lines to the default file. This is one think I dislike about RPMs - the attitude that it's OK to nuke my configuration files because you saved a backup is just unhelpful. I want my system to still work after an upgrade, not to have to remember to go back and fix up heaps of configuration files. Debian at least asks you up front what you want to do if the shipped configuration has changed and you modified it locally. Not perfect, but a lot more helpful. I'd much rather regard the shipped xtherion.ini as documentation to consult. Or alternatively write a simple "xtherion.ini updater" which checks which options are unused in the current xtherion.ini and adds them with default settings. Save a backup of the old one in case the update goes wrong - *that* is what backups are for. Cheers, Olly Subject: Extended elevation From: Stacho Mudrak <s.m@speleo.sk> Date: Sat, 05 Mar 2005 00:21:22 +0100 To: therion@speleo.sk There is a new developement snapshot with new extended elevation processing. Now you can work with it like with plan/elevation projections. Specifications can be done via extend option in centerline (see CHANGES file). Also export map -proj extended -fmt xvi should work (with UD data). If you are interested in testing, your suggestions and BUG reports are welcome. S. Subject: Re: [therion] Extended elevation From: Roman Muñoz <tatel@infonegocio.com> Date: Sat, 5 Mar 2005 08:47:57 +0100 To: therion@speleo.sk On Sat, 05 Mar 2005 00:21:22 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> There is a new developement snapshot with new extended elevation >> processing. Now you can work with it like with plan/elevation >> projections. Specifications can be done via extend option in >> centerline(see CHANGES file). Also >> >> export map -proj extended -fmt xvi >> >> should work (with UD data). If you are interested in testing, your >> suggestions and BUG reports are welcome. >> >> S. >> I simply wrote "extend reverse" before first station of passage I want extended to left side, and "extend normal" after the last one. It worked. No centerline -extend <spec> is given. If this is the expected way to do, it's really intuitive, and very easy indeed. I'm delighted. Regards, Roman Subject: error message From: Roman Muñoz <tatel@infonegocio.com> Date: Tue, 8 Mar 2005 23:55:07 +0100 To: Therion <therion@speleo.sk> Got this when exiting from Xtherion: invalid command name ".xth.te.sf.sbar" invalid command name ".xth.te.sf.sbar" while executing "$sbar configure -text [lindex $xth(gui,sbar,$aname) 0]" (procedure "xth_status_bar_pop" line 7) invoked from within "xth_status_bar_pop te" ("after" script) Regards, Roman Subject: Re: [therion] error message From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 09 Mar 2005 08:32:42 +0100 To: therion@speleo.sk I think I know where the problem is. I will try to fix it. S. Roman Muñoz wrote: > Got this when exiting from Xtherion: > > invalid command name ".xth.te.sf.sbar" > invalid command name ".xth.te.sf.sbar" > while executing > "$sbar configure -text [lindex $xth(gui,sbar,$aname) 0]" > (procedure "xth_status_bar_pop" line 7) > invoked from within > "xth_status_bar_pop te" > ("after" script) > > Regards, > Roman > > Subject: statistics From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 10 Mar 2005 00:05:39 +0100 To: Therion <therion@speleo.sk> Hi there, I would to have some nice statistics on my legend. But it seems as I need to do some black magic with those code tex-map things. There are some nice things as \cavelength, \topoteam or this kind of grial called \legendcontent. They look as what I need. But I'm getting stuck (again). Could someone give a complete-but-simple code tex-map section to display: cavelength, cavedepth, exploteam, topoteam, cartoteam ? Why statistics topo-length on shows nothing on my maps? I can't get even survey team members printed on pdf :( Regards, Roman Subject: Re: [therion] statistics From: "Martin Budaj" <m.b@speleo.sk> Date: Thu, 10 Mar 2005 09:36:09 +0100 (CET) To: therion@speleo.sk >> I would to have some nice statistics on my legend. But it seems as I >> need to do some black magic with those code tex-map things. There are >> some nice things as \cavelength, \topoteam or this kind of grial called >> \legendcontent. They look as what I need. But I'm getting stuck (again). It's not necessary to use code tex-map. Use statistics topo all statistics topo-length on etc. in your layout. >> Why statistics topo-length on shows nothing on my maps? I can't get even >> survey team members printed on pdf :( It works only if statistics topo is not off. It doesn't work if you import centreline from 3d or plt files. Martin Subject: statistics From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 11 Mar 2005 01:29:03 +0100 To: Therion <therion@speleo.sk> Hi, Still I can't get any statistics. Centerline data is not imported, but in therion's format There are my thconfig and .th files. Hope somebody will see what is wrong. Regards, Roman ##################### thconfig ################################ # thconfig template file # INPUT PART # We set source files here. source template_basic.th # LAYOUT PART # Anything between a layout/endlayout pair of lines is part # of the same layout. Layouts must have a name so we can call # them when needed. We can have as many layouts as needed. # In this example we have 2 layouts. We will use first one # for xvi image export to 1:1000 scale (default value: # 1:200 scale) layout xviexport #set output map's scale scale 1 1000 endlayout # We will use second one to set pdf map export layout normal # Scale used to draw. By default Therion uses 1:200 scale # We will use 1:1000 because it is what we used to export # centerline, so draws will be 1:1000 too. base-scale 1 1000 # Scale of output map. Relation between base-scale and # scale is used by Therion to set width of lines, etc. # To get true scale, be sure that printer does not use # any "fit on page" or similar options. scale 1 1000 # symbol set to use: UIS, ASF, CCNP, SKBB symbol-set UIS # This will set map's background color to 85% black color map-bg 85 # Wether to use transparency (on/off). When on, underlying # passages will be also visible (but dimmed). Default value # is "on" so we really don't need to set it here. transparency on # Opacity value is used when transparency is on. Default # value is 70, so underliying passages will be printed # 30% black opacity 70 # Map's header (title,legend, etc) position. # 0 0 => lower left corner of survey's "box" # 100 100 => upper right corner of survey's "box" # Third parameter are cardinal points assigned to header's # "box" nw => upper left corner, se => lower right corner # Possible values: n, s, e, w, ne, nw, se, sw. # "map-header 0 100 ne" means that upper left corner # of survey's box will coincide with upper right corner # of header's box # We want some distance between boxes, so we don't use 0 100, # but -20 100 (accepted range: -100 200) map-header -20 100 ne # Wether to use legend. (on/off/all) When on, only used # symbols are used on legend. all shows all symbols on # legend, used or not. Defaul value off legend on # Legend width default value is 14 cm legend-width 7 cm # Scale bar by default displays to-scale 100 m scale-bar 50 m # Map's language (used in automatically created texts, as # legend symbol names, etc) language en # We use comments to give some more information map-comment "City, State<br>UTM 30T X: 545988 Y: 4476879 Z: 468" statistics topo all statistics topo-length on # We want to have a grid under our survey grid bottom # grid size default value in X Y Z directions is 10 m grid-size 10 10 10 m # Now we will set some layout options that apply to atlas # size sets map size to be used on atlas. 15 x 20 fits well # on A4. So basically our atlas will be made in # 15 x 20 cm rectangles. size 15 20 cm # Set amount of overlapping (default 1 cm). 1-cm border # overlapping next "squares" will be used. Note this adds # to previos value "size" overlap 1 cm # page-setup sets paper size, page size, # page margins (left and upper) and units. In this example # paper size is A4 (21 x 29.7), page size is 17 x 28.2, # left margin is 3, upper margin is 1.5 and units are # centimeters. # To get good margins you should be aware that: # page width (17) = size (15) + overlap (1+1) # paper width (21) = page width (17) + left-rigth margins (3+ ) page-setup 21 29.7 17 28.2 3 1.5 cm endlayout # EXPORT PART # here we will set what we want to get: xvi images, map, # atlas, 3D model or centerline data in SQL file. # centerline in plan projection, format xvi using layout # xviexport. File will be called cave_plan.xvi export map -proj plan -fmt xvi -layout xviexport -o cave_plan.xvi # The same but now projection is extended export map -proj extended -fmt xvi -layout xviexport -o cave_extended.xvi # Final map in plan projection, using layout normal. It will # be called cave_plan.pdf. No need to use -fmt pdf to get # a pdf document export map -proj plan -layout normal -o cave_plan.pdf # The same but projection is now extended export map -proj extended -layout normal -o cave_extended.pdf # Now the atlases export atlas -proj plan -layout normal -o atlas_plan.pdf export atlas -proj extended -layout normal -o atlas_extended.pdf # 3D model. therion is the default format. It can be seen # in 3D viewer window. Other formats: 3dmf, wrml. You'll # need adequate software to see them. export model -fmt therion -o 3Dmodel.thm # Database. Creates an SQL file with centerline data. export database -o cave.sql ############# end thconfig ####################################### ############ template_basic.th ################################### # template_basic.th -.th template file- # FAST DESCRIPTION # This file contains centerline data. We need to define some # things: units, instruments, declination, etc, that apply. # This is done simply writing some instructions using keywords # as "units" "compass" "clino", etc. A dozen lines could work # perfectly for a simple cave like this. # Lines such this, begginning with "#" are comments. Therion # will ignore them. They are used to explain what each line # is for. Also, they can be used to activate or disable lines. # Write "#" at the beginning of a line to disable it. Remove # it to get the line active again # OK? Go... # SURVEY # Anything between a survey/endsurvey pair of lines is part of # the same survey. A survey can have a lot of things into it. # First of all, other surveys. So each survey must have # a name. This leads to a hierarchyc structure wich is useful # to add new passages or new caves. # The -title <Title> option sets <Title> to be printed on # final .pdf map # For now, in this simple case, the only important thing is # centerline. survey template -title "Example Cave" # CENTERLINE # Anything between a centerline/endcenterline pair of lines # apply to accompanying survey readings. So if you have # two teams with different styles, you should create two # centerline objects. This is, two centerline/endcenterline # pair of lines, each with different data definition lines # and respective survey readings. centerline # DATE # Format: YYYY.MM.DD # Interval (years) YYYY.MM.DD - YYYY.MM.DD # Want more precision? YYYY.MM.DD@HH.MM.SS.SS date 2000.10.15 # SURVEY TEAM MEMBERS # Add as many similar lines as you need team "Mack Theknife" team "Juxe Euskalduna" # DECLINATION # For a small cave like this, magnetic declination # can be specified on centerline itself. # You can also set two declination values for two # different years and get al centerline data corrected # automatically for given interval. But for this to work # it must be specified in a survey, not here in centerline. # So we use the simple method for now. # degrees = 360º, grades = 400º declination -3 deg # UNITS # Default units are 360 degrees and meters # If these are your units, you don't need to do anything # here. If you use other units, uncomment appropiate # line(s) # You use 400 grades compass & clino #units compass clino grad # Compass = 400º, clino = 360º # This IS the case with this example data, but we will # process it as both 360º for easier use as template. #units compass grad # Compass = 360º, clino = 400º #units clino grad # (grump) Where are my old good yards? #units lenght yards # VERTICALS # This line identifies as verticals readings of 90º and # -90º (so no clino correction will be done) # If clino units are set as 400 grades, readings of 100º # and -100º will be identified as verticals. # If you write UP and DOWN for verticals instead, you # don't need this line. infer plumbs on # DATA STYLE-AND-ORDER # If you use compass, clino and tape, set "normal" style. # If you have a topofil set "topofil" instead. # If you are a diver you can use "diving" # Keywords order must be the same that data order. # Adapt line order as needed. If you take inverse # readings you can add keywords as "backcompass". If you # are a diver you can use keywords as "depth". See # thbook.pdf for more information about keywords that # apply data normal from to length compass clino left right up down # Alternative settings # If you dont take LRUD data, comment previous line and # uncomment this: #data normal from to length compass clino # Use this if lenght is last reading onyour notes #data normal from to compass clino length ####### YOUR CENTERLINE DATA HERE ####### # In this example station 0 has fixed UTM coordinates. # It could be any other station, even more than one. The # more fixed points, the better. Note also that station 0 # is not the entrance, but a surface, GPS-taken point, # so we use flags surface/flags not surface to point it # out. Surface shots are not computed for cave statistics. fix 0 546413 4774838 233 flags surface 0 1 7.60 360.00 -3.00 0.50 0.80 0.80 1.00 flags not surface 1 2 7.00 359.00 -31.00 0.30 0.80 1.20 0.80 2 3 18.00 42.00 -2.00 1.20 1.80 1.55 0.25 3 4 6.00 36.00 -17.00 1.25 2.50 2.20 0.80 4 5 6.50 92.00 -6.00 1.50 3.00 0.80 1.20 5 6 8.70 92.00 2.00 0.50 4.00 3.00 1.00 6 7 9.60 31.00 -4.00 1.00 2.00 4.00 1.00 7 8 13.30 345.00 -2.00 1.50 3.50 3.00 1.00 8 9 7.30 56.00 10.00 0.50 1.50 2.00 1.00 9 10 3.10 45.00 25.00 1.00 2.50 1.00 1.00 10 11 9.30 139.00 -2.00 0.20 0.40 2.00 1.00 11 12 9.90 36.00 -2.00 1.80 2.00 0.80 0.00 12 13 5.70 32.00 0.00 1.00 1.00 0.50 0.80 13 14 3.00 3.00 -3.00 2.50 0.50 1.20 0.80 14 15 3.80 44.00 -7.00 4.00 3.00 3.00 1.00 15 16 21.30 38.00 -4.00 1.00 2.00 4.00 1.00 16 17 5.90 130.00 12.00 3.00 5.00 4.00 1.00 17 18 5.90 34.00 18.00 1.00 3.00 2.00 1.00 18 19 8.10 380.00 2.00 1.50 0.75 0.45 0.40 19 20 11.00 34.00 -2.00 1.50 0.75 0.40 0.40 20 21 4.90 360.00 -8.00 3.00 3.00 1.05 0.80 21 22 3.50 321.00 9.00 1.50 0.20 1.05 0.80 22 23 3.30 23.00 6.00 0.25 0.35 0.25 0.25 23 24 10.20 73.00 2.00 0.25 1.00 2.20 0.80 24 25 6.00 34.00 -3.00 5.00 0.50 1.20 0.80 25 26 4.90 40.00 -3.00 1.00 3.00 0.25 0.25 26 27 12.60 73.00 -2.00 0.75 3.50 3.20 0.80 27 28 6.40 93.00 -3.00 4.00 2.00 1.20 0.80 28 29 10.60 36.00 8.00 0.25 2.50 2.20 2.00 29 30 9.70 20.00 2.00 0.25 3.00 1.50 1.00 30 31 7.00 96.00 4.00 1.00 2.00 1.00 1.00 31 32 2.80 50.00 29.00 0.40 0.50 0.40 0.40 32 33 4.40 116.00 3.00 3.00 6.00 1.40 0.80 # Stations 34 to 40 are on 2nd passage, wich we would to # extend to reverse direction extend reverse 34 35 8.50 20.00 -5.00 1.00 2.00 1.25 0.25 35 36 3.70 45.00 4.00 0.80 2.00 0.25 0.25 36 37 3.60 51.00 13.00 0.25 0.25 0.25 0.15 37 38 2.00 41.00 16.00 0.00 2.50 2.00 0.20 38 39 4.60 115.00 20.00 1.50 1.00 2.00 1.00 39 40 4.00 393.00 -32.00 1.20 2.00 1.00 0.80 40 2 3.80 133.00 15.00 0.30 0.50 1.20 0.80 # Now we could write "extend normal" to get following # stations extended as usual. # But the only remainig stations are for two very short # shots. We think they don't apport nothing and are only # visually annoying. # So we want them ignored. They will not be on extended # centerline. extend ignore 41 10 3.10 159.00 6.00 1.00 2.50 1.20 0.80 11 42 4.00 137.00 0.00 0.20 0.80 2.50 1.00 ####### END OF DATA ################### endcenterline # THE DRAW # It is possible to write here draw data. However, usually # they are keep on a .th2 file. # You create .th2 files and its data by drawing on map # editor window. This line calls .th2 file so the effect # is the same that would be achieved writing draw data # directly on this file. # For now it's commented since we have not create it yet. # Uncomment it after tou create it. # Of course you should edit the name to fit your needs. #input template_basic.th2 # With centerline and draw data, work is done endsurvey ####################end template_basic.th ##################### Subject: Re: [therion] statistics From: Martin Sluka <martinsluka@mac.com> Date: Fri, 11 Mar 2005 08:29:10 +0100 To: therion@speleo.sk Roman, I'm not sure, but you are generating only xvi data, doesn't you. And legend doesn't work in xvi. Martin -- Subject: Re: [therion] statistics From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 11 Mar 2005 09:21:14 +0100 To: therion@speleo.sk Roman Muñoz wrote: > Hi, > Still I can't get any statistics. Centerline data is not imported, but > in therion's format Oops, now when you provided sources - it is clear to me. You are doing nothing wrong - currently therion export only statistics from centerline objects associated with scraps. And you have no scraps => no statistics. This item is in the TODO.S file (now completely in English :) + add statistics of surveys inserted into maps (create datamap structure when a survey map is created) So solution: 1. Put this on the top of TODO list - it should not take a long time to implement, I can hopefully do it today evening. 2. I would also add new configuration command to layout: statistics survey <survey-name> This will enable user to specify directly the survey, from which statistics will be taken. Example - you want have a map of just discovered passage, but in the header, you would like to have length of entire cave. So you will simply write: select new-discovery.entire-cave export map -layou-statistics survey entire-cave This should help also to correct therion, when he will wrongly associate centerline objects to scraps. Regards, S. P.S. If somebody is willing to modify order of items in my TODO.S file, feel free to ask for it :) Subject: Re: [therion] statistics From: Roman Muñoz <tatel@infonegocio.com> Date: Fri, 11 Mar 2005 14:19:52 +0100 To: therion@speleo.sk On Fri, 11 Mar 2005 09:21:14 +0100 Stacho Mudrak <s.m@speleo.sk> wrote: >> You are doing nothing wrong - currently therion export only statistics >> from centerline objects associated with scraps. And you have no scraps >> => no statistics. This item is in the TODO.S file (now completely in >> English :) Aha. I was suspecting it since last nigth I was able to get statistics when using .th2 file. Once confirmed, I can perfectly live with it. I think date displayed in pdf is only to display year, not month nor day. Rigth? BTW a) do you think that things are well explained in these template files? As you can guess, I'm plannig to include them on my writing. b) what is the meaning of these S, SM, MS, etc suffixes added to TODO files? Stacho-Martin? Subject: Re: [therion] statistics From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 11 Mar 2005 14:36:37 +0100 To: therion@speleo.sk Roman Muñoz wrote: > I think date displayed in pdf is only to display year, not month > nor day. Rigth? Yes - date and number formats are also in TODO list. But may be very soon, we will add some meta-language (simmilar to HTML) to generate simple map headers. A lot of users (including me :) ) have problems with TeX constructs. This will allow user to define custom header very easily. But I think - we should release 0.3.7 first (next week). There is already a lot of changes and there is no windows installer for them. > BTW a) do you think that things are well explained in these template > files? As you can guess, I'm plannig to include them on my writing. I like it very much - even I did not have time to study it too much (currently I have a lot of work :) , I will take them home and study it there - then I can write you some comments). When finished, it will be great starting point for new users. Pretty good job! > b) what is the meaning of these S, SM, MS, etc suffixes added to TODO > files? Stacho-Martin? Exactly. SM means what I (S) am asking Martin (M) to do :) And vice-versa. S. Subject: Re: [therion] statistics From: "Martin Budaj" <m.b@speleo.sk> Date: Fri, 11 Mar 2005 20:29:51 +0100 (CET) To: therion@speleo.sk Roman Muñoz wrote: The explanation is really useful -- e.g. map header alignment which makes often troubles. Only one remark: therion uses RGB color model, so following means 85% white. Cheers, Martin >> # This will set map's background color to 85% black >> >> color map-bg 85 Subject: Latest developement snapshot From: Stacho Mudrak <s.m@speleo.sk> Date: Fri, 11 Mar 2005 00:05:06 +0100 To: therion@speleo.sk Besides bug fixes, also 3D modelling was improved a little bit. Currently therion takes UD information from centerline (where available) and uses it for 3D model from plan scraps (not only passage height is used). Also new point type is available to enter 3D information into scraps: point X Y dimensions -value [<above> <below> [<units>]] Where <above>/<below> is distance to wall (ceiling/floor in plan projection) above/below centerline plane. When 3D modelling will be recoded, also elevation/extended projection scraps should be used for 3D modelling. But it is still far future. S. Subject: section lines From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 14 Mar 2005 01:46:59 +0100 To: Therion <therion@speleo.sk> Hi all, I guess that type section for lines only sets a concrete line width, and may be sets it not to be clipped, but it would be all. Rigth? I wonder wether these nice section lines I have seen, wich have an arrowhead are made ex profeso (type arrow, -clip off or so) or are pre-built. Regards, Roman Subject: Re: [therion] section lines From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 14 Mar 2005 08:17:13 +0100 (CET) To: therion@speleo.sk >> I guess that type section for lines only sets a concrete line width, >> and may be sets it not to be clipped, but it would be all. Rigth? If the line has control points (it's an arc not a segment) it is drawn in a special way where the middle part (which crosses the passage) is omitted (thbook footnote 15). Optionally you may specify direction arrows using direction option. >> I wonder wether these nice section lines I have seen, wich have an >> arrowhead are made ex profeso (type arrow, -clip off or so) or are >> pre-built. -direction begin, see above Martin Subject: Re: [therion] section lines From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 14 Mar 2005 13:54:10 +0100 To: therion@speleo.sk On Mon, 14 Mar 2005 08:17:13 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >> If the line has control points (it's an arc not a segment) it is drawn >> in a special way where the middle part (which crosses the passage) is >> omitted(thbook footnote 15). Optionally you may specify direction >> arrows using direction option. OK, now I get the arrow, but there are problems: section line is missing from first point to second: only begin of line and entire arrow is shown, or sometimes, part of perpendicular line is visible, but then it's on the passage. I think I'm missing something, but I can't figure what it is. a) cross-section is in its own scrap b) on "plan" scrap I insert a point section with option -scrap scrap99 c) I draw a line section (curve) from aprox. where the bottom of cross-section will be to desired point with option -direction end d) what I get is on attachment I guess there is a good reason to do it with a curve instead of a segment, but it's a pity, because the segment is much more handier. Regards, Roman Subject: Re: [therion] section lines From: "Martin Budaj" <m.b@speleo.sk> Date: Mon, 14 Mar 2005 14:41:24 +0100 (CET) To: therion@speleo.sk Roman Muñoz wrote: >> OK, now I get the arrow, but there are problems: section line is missing >> from first point to second: only begin of line and entire arrow is >> shown, or sometimes, part of perpendicular line is visible, but then >> it's on the passage. I think I'm missing something, but I can't figure >> what it is. You have probably misplaced the control points -- they determine how long segments will be drawn. See the attached picture which displays their correct position. >> I guess there is a good reason to do it with a curve instead of a >> segment, but it's a pity, because the segment is much more handier. You may draw a segment either, but you get solid line crossing the passage. Drawing a curve makes it possible to control the omitted part in the middle. Even if you draw a curve, displayed will be straight segments, not a curve. Regards, Martin Subject: Re: [therion] section lines From: Roman Muñoz <tatel@infonegocio.com> Date: Mon, 14 Mar 2005 15:02:46 +0100 To: therion@speleo.sk On Mon, 14 Mar 2005 14:41:24 +0100 (CET) "Martin Budaj" <m.b@speleo.sk> wrote: >> You have probably misplaced the control points -- they determine how >> long segments will be drawn. See the attached picture which displays >> their correct position. Ah cojones. I was unable to understand footnote. Now I see how to do. Thank you very much. >> You may draw a segment either, but you get solid line crossing the >> passage. Drawing a curve makes it possible to control the omitted part >> in the middle. Even if you draw a curve, displayed will be straight >> segments, not a curve. Yes, I have seen both. I guess the curve is needed in order to do the "clipping" because the segment has not control points. Ingenious. Regards, Roman Subject: Therion 0.3.7 From: "Martin Budaj" <m.b@speleo.sk> Date: Wed, 16 Mar 2005 11:39:44 +0100 (CET) To: therion@speleo.sk Hello all, new therion is available. Changes and improvements include: therion: * new (more intuitive) extended elevation arrangement * new import options: filter, surveys * new surface option: grid-flip * new centerline option: extend * new point type: dimensions * new scrap option: flip * new scrap/centerline option: station-names * reduced `extend' point option * all altitudes are exported as a difference against grid Z origin * XVI (xtherion vector image) map export * UD data from centerline used in 3D model generated from scraps * plt export with LRUD data * `/' supported as survey name character * unicode characters support in layout TeX code * fixed bugs: plumbed shots; join; statistics of centerline only maps xtherion: * limited i18n support * XVI support (automatic insertion of survey stations, LRUD data) * fixed bug with gamma correction M. Subject: Xtherion 0.3.7 connecting to the internet From: "Duncan Collis" <amoebatron@linuxmail.org> Date: Wed, 23 Mar 2005 14:08:29 +0800 To: therion@speleo.sk Hi. I just started with Therion, so probably there will be many more questions... I've noticed that when I start Xtherion, if I'm not connected to the internet I get a popup message from Win XP telling me that a program attempted to connect to therion.speleo.sk Once I've dismissed the message, Xtherion seems to work fine, but it considerably delays opening the editor. Is there any way I can tell Xtherion not to do this? Duncan Collis -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze Subject: Re: [therion] Xtherion 0.3.7 connecting to the internet From: Stacho Mudrak <s.m@speleo.sk> Date: Wed, 23 Mar 2005 10:30:46 +0100 To: therion@speleo.sk Duncan Collis wrote: > I just started with Therion, so probably there will be many more > questions... I am looking forward :) > Once I've dismissed the message, Xtherion seems to work fine, but it > considerably delays opening the editor. Is there any way I can tell > Xtherion not to do this? Not yet. I will add new option to xtherion.ini file in next release. But you can disable it very easily. Just comment out line 3293 in xtherion.tcl script. Change xth_ivc to # xth_ivc and it should connect no more. S. Subject: CMYK colour From: "Duncan Collis" <amoebatron@linuxmail.org> Date: Wed, 23 Mar 2005 14:18:05 +0800 To: therion@speleo.sk Martin Budaj wrote: >> ... therion uses RGB color model ... For printing surveys using offset lithography, it'd be very useful to be able to be able to specify colours using the CMYK model to give full control over the colours used. Might this be possible in a future release? Duncan Collis -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze Subject: Re: [therion] CMYK colour From: "Martin Budaj" <m.b@speleo.sk> Date: Wed, 23 Mar 2005 09:19:14 +0100 (CET) To: therion@speleo.sk Duncan Collis wrote: >>>> ... therion uses RGB color model ... > >> >> For printing surveys using offset lithography, it'd be very useful >> to be able to be able to specify colours using the CMYK model to >> give full control over the colours used. Might this be possible >> in a future release? Yes, it's possible in one of the next releases. Until now we produced mostly uncoloured maps (occasionaly with a blue water etc.), for which RGB is enough. Even more control would bring the support for spot colours, but currently I have no idea how much time would it take to implement it. Regards, Martin Subject: Re: [therion] CMYK colour From: Martin Sluka <martinsluka@mac.com> Date: Wed, 23 Mar 2005 09:18:15 +0100 To: therion@speleo.sk At 14:18 +0800 23.3.2005, Duncan Collis wrote: ******************************************* > it'd be very useful > to be able to be able to specify colours using the CMYK model to > give full control over the colours used. Duncan - in case you will prepare the outputs from therion to press, you may open PDFs in Illustrator and replace the colors - to CMYK or Pantone. To add true CMYK color space to therion is too complicated - I'm affraid. CMYK itself is very complicated task and there is no simple way to do it. If only conversion from CMYK values to RGB of monitor is not simple in any way. Martin Sluka -- Subject: Re: [therion] CMYK colour From: Martin Sluka <martinsluka@mac.com> Date: Wed, 23 Mar 2005 09:34:42 +0100 To: therion@speleo.sk At 09:19 +0100 23.3.2005, Martin Budaj wrote: ******************************************* > Yes, it's possible in one of the next releases. Until now we produced > mostly uncoloured maps (occasionaly with a blue water etc.), for which RGB > is enough. > > Even more control would bring the support for spot colours, but currently > I have no idea how much time would it take to implement it. Martin, there are many much more important and much more simple things to do. Find on net the last ICC profile definition to see the complexity of this "simple" problem. All source of color data are RGB. The human visual system is "RGB" too. And it is the reason all SOHO inkjet or laser printers use as input RGB too. The only CMYK to RGB conversiont is very, very complex task - you must convert not CMYK values to RGB values, but convert COLORs defined by CMYK to COLORrs defined by RGB (only to show colors on RGB monitor). And if you will simplify this problem saying "therion uses for RGB colors sRGB color space" - what about the CMYK? Which one - SWOP, Euroscale, Japan, coated, uncoated, web, my inkjet, somebody!s laser, .......... ? If anybody is working in prepress and is able to prepare color data to press he/she is able to simply replace colors in PDF file from RGB to CMYK or spot. My 0.02 EUR Martin -- Subject: SVG export -- labels From: "Martin Budaj" <m.b@speleo.sk> Date: Wed, 30 Mar 2005 20:33:32 +0200 (CEST) To: therion@speleo.sk Just working on SVG export. There are more ways how to handle labels -- but no perfect one. 1) Use SVG fonts (embedded). These would be supplied with Therion (converted from TeX fonts used in PDF output). pros: the SVG map will be nearly identical to PDF cons: large file (fonts are embedded) SVG fonts are unhinted hard to edit in drawing programs hard to add new font 2) Use system fonts pros: small file (fonts are not embedded) full unicode support (if unicode fonts are installed) cons: platform dependent problems with precise alignment of labels metapost can't calculate frames (e.g. for passage height) nor clipping paths 3) Use system fonts but supply font metrics for metapost pros: nice output with clipping paths, alignment etc. cons: unportable hard to generate metrics for the regular user 4) Use bitmaps as labels cons: unscalable would require additional convertor uneditable I'd like to get your comments, hints or suggestions, which one to prefer. I'd say the 1st one. Cheers, Martin Subject: text uploaded on wiki From: Roman Muñoz <tatel@infonegocio.com> Date: Thu, 7 Apr 2005 04:41:28 +0200 To: Therion <therion@speleo.sk> Hi there I have been very busy with anti-swpat things. I'll be very busy at least until April 27. So I uploaded my text to wiki. It is under "Therion book". Its not finished, but the basics are explained. No work is done for joining, etc. Best regards, Roman Subject: Re: text uploaded on wiki From: Wookey <wookey@aleph1.co.uk> Date: Thu, 7 Apr 2005 10:15:39 +0100 To: therion@speleo.sk +++ Roman Mu?oz [05-04-07 04:41 +0200]: >> Hi there >> >> I have been very busy with anti-swpat things. I'll be very busy >> at least until April 27. So I uploaded my text to wiki. It is under >> "Therion book". Its not finished, but the basics are explained. No work >> is done for joining, etc. It seems a large fraction of the Therion documentation team is too busy trying to save the world from swpats to get any documentation done (I'm going to a UKPO workshop in 2hrs time). 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.601_700 Topics (messages 601 through 602): Therion and survex 601 by: Philip Balister 602 by: Wookey Subject: Re: Therion and survex From: Wookey <wookey@aleph1.co.uk> Date: Fri, 15 Apr 2005 00:26:02 +0100 To: therion@speleo.sk +++ Philip Balister [05-04-14 18:59 -0400]: >> Hello, >> >> I've just installed Therion and would like to use it to draft a smallish >> map. The data is being processed in Survex. I'm aware I can modify the >> survex files and use them with Therion, but I am thinking there is a >> better way. A quick read of the therion book didn't help. But there is a >> reference in the Therion source to reading .3d files :) >> >> Does anyone have a quick intro to getting started with survex .3d files? >> Is there an archive of this list I can look through? As of v0.3.7 it does read .3d files. If we were organised this would be covered in the FAQ, but it isn't. You need to do: import survexfile.3d In my dataset this is withing a survey dummy endsurvey dummy pair but I think this is no longer necessary in the current code, and you can add options to 'import' to strip off some prefixes to make it match the level of your therion data. It's not trivial to get right though and could do with some examples in the FAQ. import should be documented in the thbook I think. If you read the back-issues of this list from1-2 months ago you can read about this option (problems with it and changes to solve them). HTH 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/