10
10
OGR supports reading most versions of AutoCAD DXF and writing AutoCAD 2000
11
version files. The entire contents of the file is represented as a single
12
layer named "entities". DXF is an ASCII format used for interchanging
13
AutoCAD drawings between different software packages.<p>
11
version files. DXF is an ASCII format used for interchanging AutoCAD drawings
12
between different software packages. The entire contents of the file is
13
represented as a single layer named "entities". <p>
16
16
DXF files are considered to have no georeferencing information through OGR.
33
33
<li> POINT: Produces a simple point geometry feature.
34
34
<li> MTEXT, TEXT: Produces a point feature with LABEL style information.
35
35
<li> LINE, POLYLINE, LWPOLYLINE: translated as a LINESTRING or POLYGON
36
depending on whether it is closed.
37
<li> CIRCLE, ELLIPSE, ARC: Translated as a LINESTRING, interpolating the
36
depending on whether it is closed. Rounded polylines (those with their
37
vertices' budge attributes set) will be tesselated.
38
Single-vertex polylines are translated to POINT.
39
<li> CIRCLE, ELLIPSE, ARC: Translated as a LINESTRING, tesselating the
38
40
arc into line segments.
39
41
<li> INSERT: An attempt is made to insert the block definition as defined
40
42
in the insert. Linework blocks are aggregated into a single feature with
41
43
a geometry collection for the geometry. Text blocks are returned as one or
44
more text features. To avoid merging blocks into a geometry collection the
45
DXF_MERGE_BLOCK_GEOMETRIES config option may be set to FALSE.
43
46
<li> DIMENSION: This element is exploded into a feature with arrows and
44
leaders, and a feature with the dimensio label.
47
leaders, and a feature with the dimension label.
48
<li> HATCH: Line and arc boundaries are collected as a polygon geometry, but
49
no effort is currently made to represent the fill style of HATCH entities.
47
53
A reasonable attempt is made to preserve line color, line width, text size
49
55
Currently no effort is made to preserve fill styles or complex line style
52
The approximation of arcs, ellipses and circles as linestrings is done
53
by splitting the arcs into subarcs of no more than a threshhold angle. This
54
angle is the OGR_ARC_STEPSIZE. This defaults to four degrees, but may be
55
overridden by setting the configuration variable OGR_ARC_STEPSIZE.<p>
58
The approximation of arcs, ellipses, circles and rounded polylines as
59
linestrings is done by splitting the arcs into subarcs of no more than a
60
threshhold angle. This angle is the OGR_ARC_STEPSIZE. This defaults to
61
four degrees, but may be overridden by setting the configuration variable
64
<h2>DXF_INLINE_BLOCKS</h2>
66
The default behavior is for INSERT entities to be expanded with the
67
geometry of the BLOCK they reference. However, if the DXF_INLINE_BLOCKS
68
configuration option is set to the value FALSE, then the behavior is different
72
<li> A new layer will be available called blocks. It will contain one or
73
more features for each BLOCK defined in the file. In addition to the usual
74
attributes, they will also have a BlockName attribute indicate what block
76
<li> The entities layer will have new attributes BlockName, BlockScale,
78
<li> INSERT entities will populate these new fields with the corresponding
79
information (they are null for all other entities).
80
<li> INSERT entities will not have block geometry inlined - instead they will
81
have a point geometry for the insertion point.
84
The intention is that with DXF_INLINE_BLOCKS disabled, the block references
85
will remain as references and the original block definitions will be
86
available via the blocks layer. On export this configuration will result in the
87
creation of similar blocks. <p>
89
<h2>Character Encodings</h2>
91
Normally DXF files are in the ANSI_1252 / Win1252 encoding. GDAL/OGR attempts
92
to translate this to UTF-8 when reading and back into ANSI_1252 when writing.
93
DXF files can also have a header field ($DWGCODEPAGE) indicating the
94
encoding of the file. In GDAL 1.8.x and earlier this was ignored but from
95
GDAL 1.9.0 and later an attempt is made to use this to recode other
96
code pages to UTF-8. Whether this works will depend on the code page naming
97
and whether GDAL/OGR is built against the iconv library for character recoding.
100
In some cases the $DWGCODEPAGE setting in a DXF file will be wrong, or
101
unrecognised by OGR. It could be edited manually, or the DXF_ENCODING
102
configuration variable can be used to override what id will be used by
103
OGR in transcoding. The value of DXF_ENCODING should be an encoding name
104
supported by CPLRecode() (ie. an iconv name), not a DXF $DWGCODEPAGE name.
105
Using a DXF_ENCODING name of "UTF-8" will avoid any attempt to recode the
106
text as it is read.<p>
57
109
<h2>Creation Issues</h2>
59
111
DXF files are written in AutoCAD 2000 format. A standard header (everything
135
Note that in GDAL 1.8 and later, the header and trailer templates can
136
be complete DXF files. The driver will scan them and only extract the needed
137
portions (portion before or after the ENTITIES section). <p>
139
<h3>Block References</h3>
141
It is possible to export a "blocks" layer to DXF in addition to the
142
"entities" layer in order to produce actual DXF BLOCKs definitions
143
in the output file. It is also possible to write INSERT entities if
144
a block name is provided for an entity. To make this work the follow
148
<li> A "blocks" layer may be created, and it must be created before the
150
<li> The entities in the blocks layer should have the BlockName field
152
<li> Objects to be written as INSERTs in the entities layer should have a
153
POINT geometry, and the BlockName field set.
154
<li> If a block (name) is already defined in the template header, that will be
155
used regardless of whether a new definition was provided in the blocks layer.
158
The intention is that a simple translation from DXF to with DXF_INLINE_BLOCKS
159
set to FALSE will approximately reproduce the original blocks and keep
160
INSERT entities as INSERT entities rather than exploding them.<p>
162
<h3>Layer Definitions</h3>
164
When writing entities, if populated the LayerName field is used to set the
165
written entities layer. If the layer is not already defined in the template
166
header then a new layer definition will be introduced, copied from the
167
definition of the default layer ("0").
169
<h3>Line Type Definitions</h2>
171
When writing LWPOLYLINE entities the following rules apply with regard to
172
Linetype definitions.<p>
175
<li> If the Linetype field is set on the written features, and that Linetype
176
is already defined in the template header then it will be referenced from
177
the entities regardless of whether an OGR style string existed.
178
<li> If the Linetype is set, but the Linetype is not predefined in the
179
header template, then a definition will be added if the feature has an
180
OGR style string with a PEN tool and a "p" pattern setting.
181
<li> If the feature has no Linetype field set, but it does have an OGR
182
style string with a PEN tool with a "p" pattern set then an automatically
183
named Linetype will be created in the output file.
184
<li> It is assumed that patterns are using "g" (georeferenced) units for
185
defining the line pattern. If not the scaling of the DXF patterns is likely to be wrong - potentially very wrong.
188
The intention is that "dot dash" style patterns will be preserved when written
189
to DXF and that specific linetypes can be predefined in the header template,
190
and referenced using the Linetype field if desired.<p>
added
removed
ogr/ogrsf_frmts/dxf/drv_dxf.html
