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