Important 2018 update
I'm not sure which update of QGIS 2.x and 3.x changed it, but as of 2018 November and probably earlier, geometry generator symbology styling does get exported with the native QGIS dxf exporter. Generated polygon geometries styled with outline only will be exported as polylines; albeit with many vertices still.
So all of the below is no longer necessary.
Answering my own question: I found a way to generate the above-mentioned layers dynamically using Virtual Layers, which don't even require your source data to be in a database. Essentially I translated the above into Spatialite syntax the best I could.
I have tested this with spatialite, shapefiles, even xlsx source data. I believe this solution also gets around the apparent limitation that Spatialite itself does not allow views of a different geometry type from the original table?
Go to Layer > Add Layer > Add/Edit Virtual Layer, the above dialog box should appear. Give your layer an appropriate name.
Import the tree data layer
Use one of the following queries, adapted to your field names, with whatever other fields you want to SELECT (e.g. treeid, rpz_m in this case), and any filters (WHERE ...) These are what I've used:
RPZ (circle polygon)
SELECT treeid, rpz_m,
st_buffer(geometry,rpz_m) AS geometry
RPZ (line) - note I've put the line as a separate layer as it makes labeling much easier, also so you can optionally export just the circle as a polygon
SELECT treeid, rpz_m,
rpz_m*cos(radians(45)), rpz_m*-1*sin(radians(45)))) AS geometry
RPZ (circle outline + line)
SELECT treeid, rpz_m,
ST_ExteriorRing(ST_Buffer(geometry,rpz_m))) AS geometry
Crown Area (polygon) - exports even crown spread as a circle (CASE WHEN...), otherwise (ELSE) as a polygon
SELECT treeid, n, e, s, w,
CASE WHEN n = s AND n = e AND n = w THEN ST_Buffer(geometry,n)
FROM layer_name WHERE n != 0;
Crown Area (convex hull polygon - not in original post but expanded on here, refer to link for accuracy limitations) (as above, exports even crown spread as a circle)
SELECT n, e, s, w,
CASE WHEN n = s AND n = e AND n = w THEN st_buffer(geometry,n)
st_union(st_buffer(translate(geometry, -(case when w=0 then 0.1 else w/2.0 end),0),case when w=0 then 0.1 else w/2.0 end),
st_union(st_buffer(translate(geometry,case when e=0 then 0.1 else e/2.0
end,0),case when e=0 then 0.1 else e/2.0 end),
st_union(st_buffer(translate(geometry,0,case when n=0 then 0.1 else n/2.0
end),case when n=0 then 0.1 else n/2.0 end),
st_buffer(translate(geometry,0,-(case when s=0 then 0.1 else s/2.0 end)),case
when s=0 then 0.1 else s/2.0 end))))) END
FROM layer_name WHERE n is not null;
Edit (30 Dec 2017): Modified original code to include case function to convert any 0s to 0.1 (or whatever minimum number). Otherwise if you have a 0 value in any of the crown spread fields it will not work. At any rate, if you have a 0 in just one field the resultant polygon will not be accurate. (see link above). Note also division by 2.0, not 2, to avoid result being cast as an integer.
Of course, if you have trees with no crown spread data, make sure that the values are NULL instead of 0.
(Optional) You may wish to force the appropriate geometry just to be sure - especially if you do not include "AS geometry" in the above code, otherwise it might come out as a geometry collection that QGIS cannot style.
Test the code works, if it says No errors then load
Style the layers appropriately, add a label to the line.
- Now go ahead and change the values in your original data source,
save, refresh QGIS and watch it automatically update :)
- Export to DXF when you're done and the data will come through. The layering might be off though (see export limitations below).
Results (in AutoCAD):
DXF export as polylines - note number of vertices on circles!
DXF export with rough polygons as hatch (see export limitations below)
SQL code notes:
- For newbies (like me...), if you keep getting syntax errors when using virtual layers with non-SQL databases, try enclosing your field names with double quotes ("") to escape noncompliant characters... make sure your layer name is compliant... etc.
- Probably not very efficient with large datasets
- In fact I have barely any experience with databases so any suggestions to condense or improve the code are welcome!
DXF export limitations:
- If your lines come out way too thick mess around with the export scale or your styles (e.g. use map units instead of millimetres, whatever)
- All lines - including circular ones - will be exported as polylines, not CAD arcs/splines/circles. Your dxf will be relatively large (e.g. 756 trees with RPZ and crown area will be ~10MB) because of the number of vertices, especially for circular buffers. To avoid this I think you'll need proprietary solutions like TCI Corp's CurveFit, also found in FME - FOSS recommendations very welcome!
- GIS polygons will be exported as AutoCAD hatch polygons, only if they are styled with a solid fill. Any other combination will result in polylines of varying thickness.
- For some reason the dxf layers don't correspond to the QGIS layers but come out grouped by value (1, 2, 3...) with RPZ and PCA on the same layer. If your RPZ and PCA lines are in different colours, however, it won't be hard to merge all the layers and then separate RPZ and PCA by colour using QSELECT in AutoCAD EDIT (30 Dec 2017): As of 2.18.15 the above no longer happens; dxf export by layer name option now works properly.