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.
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
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.
- 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.
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.
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 --
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
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
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.
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
+++ 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/
participants (7)
-
Eric Madelaine -
Ladislav Blazek -
Martin Budaj -
Martin Sluka -
Olly Betts -
Stacho Mudrak -
Wookey