this bug's URL: http://intevation.de/rt/webrt?serial_num=1798
-------------------------------------------------------------------------
Subject: v.in.dxf writes bad dig_att file for labels
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: cvs 4/3/2003
This is a known problem most recently discussed in [GRASSLIST:5986] with Paul Kelly's response [GRASSLIST:5992]. I know what the problem is.
In label_box.c,
fprintf (label_fd->fd, "L %f %f %s\n",xinfo(0),yinfo(0),label);
clearly prints the label information in the dig_att file, which is wrong.
I have more details if someone can help me with the coding.
We need to add an index for the dig_att file and open the dig_cat file.
John Gillette
jg-Linux@NOSPAMtriad.rr.com
-------------------------------------------- Managed by Request Tracker
This change at the top of the label_box.c looks relevant:
...
** Modified by Benjamin Horner-Johnson 1998-OCT-01
** changed label from int to char, allowed 1 character labels
...
Before that if the label was an integer it would have been OK to have it
only in the dig_att file but to properly implement this improvement it
maybe should have been changed to write the cats file as well.
m.in.e00 might have some clues, as it seems to handle this fairly well. I
notice in src/misc/m.in.e00/info.c it calls the function
G_write_vector_cats() which seems to be the way to go; it doesn't write
the dig_cats file directly (although it does directly create the dig_att).
I could have a go at some of this but I would need to look into it more
and don't have that much time at the minute. It would be really good to be
able to merge the functionality of v.in.dxf3d into v.in.dxf as well. The
z-values of the lines should also be in the dig_cats file (and also are
handled incorrectly by v.in.dxf3d). Is it possible for there to be a
z-value and a label or more than one label for each line in the DXF file?
We might need to have separate dig_cats files that could be renamed if
necessary like m.in.e00 does.
Also v.in.dxf3d assumes the z-values are in the '30' field in the DXF file,
but I have a dxf file from an architecture source (heights of buildings)
where they are in the '38' field. This could be made a command-line option
with a default of 30 but we need to know all the possibilities (or have a
good idea of them).
But apart from fixing these obvious bugs we really shouldn't do any more
as GRASS 5.1 already has v.in.dwg which is probably better.
Paul