[GRASS5] [bug #1798] (grass) v.in.dxf writes bad dig_att file for labels

[John Gillette]

> From: Paul Kelly
> Subject: Re: [GRASS5] [bug #1798] (grass) v.in.dxf writes bad dig_att
> 
> 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.

I agree. I don't understand why it was changed since writing non-
integer to the dig_att file is incorrect. Am I missing something?

> 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 have something which appears to work.  I need more testing. I
use G_init_cats, G_write_vector_cats, and G_set_cat.  I haven't
looked at m.in.e00.  I will do that.  

I looked at a couple examples that use G_fopen_new to open the 
dig_att file and they use fprintf to write directly to it. Are
you sure G_write_vector_cats creates the dig_att file?
 
> 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?

I don't know that one.  I only use the less expensive 2D cad programs
so I don't have access to 3D dxf files.  I have not looked at v.in.dxf3d
yet but I'll try to do that.

> 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.

There are a LOT of cheaper programs out that support dxf files and
several local government sites in the US give dxf files as one possible
data type so my opinion is that Grass should definitely continue to 
support dxf.  I haven't looked at v.in.dwg.  Perhaps it also supports
dxf?

My interest in fixing v.in.dxf is for use with v.cadlabel and vector
contour maps.

In conclusion, I did get something working.  When I get it more tested
I will let you know exactly what I did and why and maybe you can double
check me. 

John