Bug report #7327

dxf export drops elevation data

Added by G Stewart over 7 years ago. Updated over 1 year ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Vectors
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:16314

Description

When exporting a dxf of land height contours, the elevation data is not exported.
QGIS uses LWPOLYLINE for lines exported to dxf. The Elevation data should be saved on the 38 value for the LWPOLYLINE, before defining all the vertex's.

(If you were to use the old sytle POLYLINE then it would be on the 30 value, or if you were to use 3DPOLYLINE then it would go on the 70 value).

History

#1 Updated by Giovanni Manghi over 7 years ago

  • Category set to Vectors
  • Status changed from Open to Feedback

likely part of the #4381 issue.

#2 Updated by G Stewart over 7 years ago

I don't think it is the same issue - but yes it could be fixed at the same time.
I saw that issue - about corrupted files wich is as they suggest due to the extraneous headers that AutoCAD doesn't like. This is commonly a problem with AutoCad and dxf, I worked with a specialty programme which had the same problem 15 years ago. It could always be fixed by simply deleting the extra header data from the dxf file.
I have other (current) specialty software that can read the dxf that is written by QGIS, and the elevation data is not included. If you look into the dxf file (it is plain text) you can see that the entity dotted pair for the LWPOLYLINEs does not include the "38 pair" which specifies the z value.
Actually this issue would be very easy to rectify by sombody who know the QGIS code (I don't)- simply write the elevation field (say EL = xxx) as 38 xxx into the entity string for each polyline.

#3 Updated by Alister Hood almost 7 years ago

Can anyone get rid of the feedback tag?
This issue is still around, but #4381 isn't.

#4 Updated by Alister Hood almost 7 years ago

Sorry, actually I don't know if this issue is still around - My shape file was actually 2D so I had to use ogr2ogr with the -zfield option.

#5 Updated by G Stewart almost 7 years ago

I haven't used the feature lately so I can't confirm if it has been fixed, though I suspect it hasn't. Any elevation contour, regardless of whether it was 2D or 3D must han an elevation value (otherwise it's not an elevation contour) that can be exported to the dxf so this should be easily confirmed by just about anybody. As noted before, you can see the structure of the dxf file in any text editor. Start by searching for the word "LWPOLYLINE".

The current dxf definition for the exported contour looks (in part) like this:
"...
0
LWPOLYLINE
5
20000
8
0
100
AcDbEntity
100
AcDbPolyline
70
0
90
27
10
706986.85
20
7663702.09
10
706956.83
20
7663704.41
...."

You'll note that the structure is "10 x-cord 20 y-cord (repeat)". the value 10 signifies that the following number will be the x-cordinate of a vertex, similarly a value of 20 signifies a y-cordinate. The old 3DPOLYLINE structure used a 30 to signify a z-cordinate. But the new LWPOLYLINE entity, which QGIS is using, (see the 0 value in the string above for the entity type) stores the z-cordinate (ie the elevation) on the 38 value. Hence in the string above, if the elevation was "EL", it should read:
"...
0
LWPOLYLINE
5
20000
8
0
100
AcDbEntity
100
AcDbPolyline
70
0
90
27
38
EL
10
706986.85
20
7663702.09
10
706956.83
20
7663704.41
...."

The posiiton of the 38 value is not particularly sensitive, as long as it comes after the 0 value, and preferably before any of the verticies (ie the 10 & 20 values).
That's all that is required to fix this issue. Hope this helps understand / fix this issue.

#6 Updated by Paolo Cavallini over 6 years ago

Any plan to fix this? Thanks.

#7 Updated by Giovanni Manghi about 5 years ago

  • Status changed from Feedback to Open

seems still valid.

#8 Updated by Giovanni Manghi about 3 years ago

  • Regression? set to No
  • Easy fix? set to No

#9 Updated by Giovanni Manghi over 1 year ago

  • Resolution set to end of life
  • Status changed from Open to Closed

Also available in: Atom PDF