[GRASSLIST:1090] Vector and Sites Importation Errors

I am exploring the capabilities of GRASS and trying to play around with some of our
data but have been running into some errors and I could not find much info on the
web about them so I would greatly appreciate any responses if these look familiar.
I had no problems getting raster data in but vector and sites have proven more
problematic. Also the OpenOSX version of GRASS 5.0.2 I am using does not
recognize any of the MapInfo import commands(eg v.in.mif and s.in.mif), were
these added in a later release? TIA

While attempting to import DXF vector files (both binary and ASCII versions) I got
the following error:

  CONVERSION OF /Users/andrewcallan/Desktop/Yilmav12ascii.dxf TO DIG FILE:
      end of file while looking for HEADER

       (I looked at the ascii version and at the top of the file there is a "HEADER"
heading, is this not the format grass needs?)

While attempting to display a sites file that appeared to import correctly from .dbf
I got the following error:

  ERROR: G_site_new_struct: invalid # dims or fields
      can not chdir(/var/spool/clientmqueue/): No such file or directory

While attempting to import an ERSI shapefile I got a similar error:

  can not chdir(/var/spool/clientmqueue/): No such file or directory

Cheers,

  Andy Callan
  SIPA Resources International NL
  University of Western Australia
  University of Notre Dame

En réponse à Andy Callan <acallan1@nd.edu>:

While attempting to import DXF vector files (both binary and ASCII
versions) I got
the following error:

  CONVERSION OF /Users/andrewcallan/Desktop/Yilmav12ascii.dxf TO DIG
FILE:
      end of file while looking for HEADER

DXF binary is not supported. For ASCII DXF, the format is relatively
straightforward so there must just be some bad formatting. Would you mind
sending me privately an example of the DXF ASCII file you try to import so
that I can give it a look (and tell me what program created this file)?

Cheers,

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@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C