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
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
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
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.
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.
+++ 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/
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
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
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.
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 --
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 --
participants (6)
-
M.J. Green -
Martin Sluka -
Olly Betts -
Roman Muñoz -
Stacho Mudrak -
Wookey