[GRASS5] v.in.dxf

[Roger Miller]

Folks, 

I followed up on Heiko's problem importing the sample dxf from
english-nature.org.uk.  I think I found the problem, but I'm not sure I
found the solution.

Polyline data in a dxf file are supposed to be included in an ENTITIES
section.  v.in.dxf reads some header data then searches for the ENTITIES
section before it starts translating data.  If v.in.dxf doesn't find an
ENTITIES section then it prints a message.  v.in.dxf should probably stop
at that point, but it doesn't.

The sample file that Heiko tried to import contained polyline data
outside of an ENTITIES section.  There was an ENTITIES section, but it 
was at the end of the file after the polyline data.  v.in.dxf skipped
allmost all of the file while searching for the ENTITIES section, then
interpreted the small part of the data that followed.  There was no line
data in that part of the file, so v.in.dxf quit without importing
anything and without giving any indication of a problem.

That would seem to be a very badly build dxf file, and perhaps it is
reasonable for v.in.dxf to fail to import that file.  However, both
StarOffice and Surfer 6 imported the same file without problems.  At the
very least if v.in.dxf fails to import the file then it needs to deliver
some message to the effect of "vector data not found."

My simple solution to the problem was to stop v.in.dxf from searching for
the ENTITIES section.  That is done just by commenting the call to
dxf_entities in find_lines.c.  With that change v.in.dxf tries to
interpret everything that follows the header section.  That allows
v.in.dxf to import the sample dxf file and I don't see that it causes any
general problems. However, it might have other side effects that I don't
understand.  Would someone else like to look at the code?


Roger Miller