[GRASSLIST:1122] Re: DXF import in GRASS 5.0.x CAVEATS (was: Vector and Sites Importation Errors)

[Thierry Laronde]

Hello Andy,

Just to allow others searching the archives for this kind of tips to find
these ones, I cc to the list.

On Thu, Sep 04, 2003 at 04:02:44AM -0500, Andy Callan wrote:
> Attached you will find the specific file in ASCII format 

The ASCII file, at least in the state in which I had have it is NOT in
an orthodox DXF format. There is no linefeed '\n' but only some
carriage returns '\r' hence the error message given by v.in.dxf. Secondly,
The beginning of the sections is marked with the initial character repeated
twice and no carriage return or newline.

For the carriage return, are these files generated under Mac?

Formatting "a little" the file like this :

$  cat Yilmav13ascii.dxf | sed 's/   /|/g' | tr '\r|' '\n\n' | more

I find this:

$ACADVER
  1AAC1012   9

which should be formated this way:
$ACADVER
  1
AC1012
  9

That is to be interpreted as AC1012 that is ACAD DXF version 13.

Assuming that the mess in the file is created by transferring the file
between two different system, remains the problem of the version.

Here are some tips:

1) ACAD DXF VERSION supported by GRASS 5.0.x v.in.dxf :

The program was originally written for R10. It should work without much
ado for R11/R12, but will fail with higher. The versions read as follow :

[ACADVER]
AC1006 -> R10
AC1009 -> R11/R12 /* The very same thing */
AC1012 -> R13
AC1014 -> R14

So try first to export in a ASCII DXF version 10 or 11/12.

2) 8 bits text support (for the record)

The DXF ASCII is an ASCII file i.e. all characters used are 7 bits ones.
If some texts use 8 bits characters these characters will be (at least in
my files, but I haven't found the specification in the doc) transcripted
with two leading % followed by the decimal value of the character.

Example : pâté -> p%%226t%%233

There is two consequences:

1) Due to DXF itself: the maximum length of the string is 256 characters.
If you have 8bits characters these will be transcripted using 5 characters
so the actual string you will have will be truncated;

2) v.in.dxf DOES NOT transcript back the characters.

If you have such strings, running the following script on the files
(mainly the ones in dig_att) will do the job (here the first argument
given to the script will be the name of the file to transcript):

-----------------
#!/bin/sh

file=$1

i=128
while [ $i -lt 256 ]; do
	ovalue=`printf %o $i`
	# XXX Adjust the following line to match your version of echo
	# Using a `-e' parameter and perhaps giving a leading 0 to the
	# octal value may be necessary for echo to print the correct
	# character! TEST BEFORE and beware that bin/sh may use a builtin!
	car=`echo '\'$ovalue`
	echo "s/%%$i/$car/g"
	i=$(( $i + 1 ))
done > ${TMPDIR:=/tmp}/$$.sed

sed -f $TMPDIR/$$.sed $file > $file.new

rm $TMPDIR/$$.sed

exit 0
----------------

3) Text values produced by v.in.dxf

v.in.dxf will create by default a box surrounding the text, and will put
the TEXTs in the file in the dig_att using the strings as categories, the 
coordinates associated being the ones of the insertion point.

So, say that if you have an area with a text describing it whose insertion 
point is within the area, you will have a handy way to associate this text
with this area.

BUT BEWARE!

But beware that this very feature of v.in.dxf MUST not be rely upon in future
versions since this is more of a bug. Actually, the category must be an
integer value and if you run v.support on the vector file you created by
importing the DXF, v.support will try to "convert" the text to an integer... 
and you will have results that you probably didn't expected!


Hope these tips will help.
-- 
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C