[GRASS5] [bug #1798] (grass) v.in.dxf writes bad dig_att file
paul-grass at stjohnspoint.co.uk
Sun Apr 13 15:47:18 EDT 2003
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.
More information about the grass-dev