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