[GRASS5] [bug #1950] (grass) v.in.dxf occasionally fails to read LINE and other entities

this bug's URL: http://intevation.de/rt/webrt?serial_num=1950
-------------------------------------------------------------------------

Subject: v.in.dxf occasionally fails to read LINE and other entities

Platform: other
grass obtained from: Other (CDROM etc)
grass binary for platform: Compiled from Sources
GRASS Version: 5.0.0

It has been reported that the program to convert dxf files into GRASS vector files (v.in.dxf) will sometimes fail to process AutoCAD entities (e.g., see mail at http://op.gfz-potsdam.de/GRASS-List/Archive/msg08563.html).

I have encountered similar difficulties, although on other occasions v.in.dxf seems to work as specified. The latest failure occurred on a file exported into dxf format by an Intergraph CAD application.

Examining the source code for v.in.dxf/find_lines.c (I encountered this problem with GRASS 5.0.0, but the source code for 5.0.2 is the same), I noted that find_lines.c expects all LINE and similar entities to be contained within the ENTITIES section of a dxf file. However, the dxf format allows entities to appear within the BLOCKS section as well (cf.: www.relief.hu/h_dxf12.html). Any lines defined outside the ENTITIES section will apparently be missed.

I've tried one workaround by defining a string like

GLOBAL_DXF char blox[8];

in dxf2vect.h and initializing it in init_chars.c as

strcpy (blox, "BLOCKS");

Then, I've rewritten line 8 of entities.c to read

while ((strcmp (dxf_line, entitie) != 0) && (strcmp (dxf_line, blox) != 0))

This allows find_lines.c to read entities after the BLOCKS section begins.

This is probably not the best way to deal with the conversion, but I hope the description is helpful. I think v.in.dxf is a very valuable module, since many cadastral spatial databases are produced on CAD systems.

Regards,

Don Heth, Professor
Department of Psychlogy
University of Alberta

-------------------------------------------- Managed by Request Tracker