Martin Budaj wrote: > On Thu, 18 Aug 2005 11:26:26 +0100, Wookey wrote > > >>Hmm, so as it goes wrong with the default (scale 1:200) that suggets >>I have one scrap which is >560m long. I don't think I do have >>anything that big (I try to keep scraps to <200m). >> >>If anyone cares to investigate this then the benarat dataset >>illustrates the problem. > > > It's the scrap faketerikan_s15, which contains two survey stations (used for > calibration?) really far from the passage.
Ah yes. All those faketerikan scraps use the same two (fake) stations - which are just two random well-spaced stations in the fake survey we generated from the original drawing. This scheme worked a lot better than using fake stations with each scrap (as used on the fakebluemoon survey) - that led to a lot of distortions in scraps where there should have been none. > --- > > How to find where the problem is: > * therion log window displays metapost's progress, it displays [33] just > before the error; that means that picture number 33 has been sucessfuly > processed and the error is in the next one > * run therion in the -d (debug) mode > * go to thTMPDIR > * open the file data.mp and find picture 34 (it starts "beginfig(34);" ;-) > * find the "current_scrap" assignment preceding the picture > * it's "faketerikan_s15 at terikan.dummy" Thanx - that's useful to know. I've been wondering what all those numbers meant :-) As you say, a message like 'scrap <foo> is too large to be processed' would be better. 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/
