Category: QGIS

GIS to CAD using ogr2ogr – Part 1 – Shp to DXF with Contour Data

GIS to CAD using ogr2ogr – Part 2 – GML to DXF with OS MasterMap
GIS to CAD using ogr2ogr – Part 3 – Point Annotation to Text in CAD

The power of GDAL, and specifically ogr2ogr is pretty impressive. This conversion is from shp to DXF, which is a somewhat universal CAD format so further conversion should be possible.

This post will cover contour export while maintaining 3D elevation, in addition to contour values as layers in CAD. The data used is OS terrain 50.

OS Terrain 50:

https://www.ordnancesurvey.co.uk/opendatadownload/products.html

In QGIS:

Screenshot[1]

Contours in 3D:

ogr2ogr -f DXF contour_zfield.dxf SX99SW_line.shp -zfield PROP_VALUE

With the -zfield creating the 3d elevation.

Great result:

Screenshot[3]

The alternative is to just store the z-value as layers.

ogr2ogr -f DXF contour_layer.dxf SX99SW_line.shp -sql "SELECT PROP_VALUE AS Layer FROM SX99SW_line"

Layers work great:

Screenshot[2]

With the ogr2ogr DXF driver, if you have an input column called “Layer” then it will be used to group features as a layer in DXF. We use a SQL query to achive this. Prop_Value is the height field in my input data.

And putting them all together:

ogr2ogr -f DXF contour_zfield_layer.dxf SX99SW_line.shp -zfield PROP_VALUE -sql "SELECT PROP_VALUE AS Layer FROM SX99SW_line"

Result not as expected, flat output:

Screenshot[4]

Adding our SQL select statement removes our zfield attribute as such ogr2ogr cannot access it. Lets resolve this:

ogr2ogr -f DXF contour_zfield_2_layer.dxf SX99SW_line.shp -zfield PROP_VALUE -sql "SELECT PROP_VALUE AS Layer, * FROM SX99SW_line"

Excellent:

Screenshot[5]

Layers and height.

GIS to CAD using ogr2ogr – Part 2 – GML to DXF with OS MasterMap
GIS to CAD using ogr2ogr – Part 3 – Point Annotation to Text in CAD

Multi Ring Buffer – Buffer the Buffer or Incrementally Increasing Distance?

Does it matter, and who cares?

Multi-ring buffers can be useful for simple distance calculations as seen in:
X Percent of the Population of Scotland Lives Within Y Miles of Glasgow
And:
X Percent of the Population of Scotland Lives Within Y Miles of Edinburgh

For these I simply created multiple buffers using the QGIS buffer tool. This works for small samples, but was quite frustrating. I had initially hoped to do the whole analysis in SQLite, which worked pretty well initally, but struggled on the larger buffers. It took too long to run the queries, and did not allow for visualisation. I think using PostGIS would however be pretty feasible.

But creating a multi-ring buffer plugin for QGIS also seemed like a good learning experience. Which got me thinking, does it matter if you create increasingly large buffers around the original feature, or if you buffered the resulting buffer sequentially. My hypothesis was that there would be pretty significant differences due to the rounding of corners.

I asked on StackExchange but the conversation did not really take off:
http://gis.stackexchange.com/questions/140413/multi-ring-buffer-methodology

My question is not about the overlapping-ness of the buffers, since I think multi-ring buffers should be “doughnuts” anyway. But rather if smoothing will occur. The only answer was to try it myself.

Buffer styles:
Buffer the resulting buffer sequentially: Sequential
Buffer the original feature with increasing buffer distance: Central
[table caption=”Speed – In seconds”]
Features, Rings,Central, Sequential
1, 5, 0.59, 0.56
55, 5, 8.06, 6.38
1, 200, 60.83, 31.76
3, 200, 62.89, 40.89
55, 200, 628.38, 586.67
1, 2000, 203.84, 67.00
[/table]

No matter how you do it the sequential style is quicker, but that may be down to my code.

Rendering

Interestingly, although understandably, the sequential style results in a lot more vertices in the outer rings. For comparison, for a 500 ring buffer the outermost ring had the following vertice counts:
[table]
Style, Vertices
Central,488
Sequential,30918
[/table]

We can see this with editing turned on.
Central:
Central_editing
Sequential:
Sequential_editing

We can also see a smoother profile in the sequential buffer. However the difference is not major, and hard to discern with the naked eye.

So we have at most about around a 10m discrepancy, with 500 50m rings, so around 25000m of distance from the original feature.
Screenshot[34]
This impacts rendering time dramatically, an example with our 500 rings:

Central:

Sequential:

So quicker to create but slower to draw. So which one is better, quicker calculation, or quicker rendering? Or should we not do 200+ ring buffers?

Hard to say. In version 0.2 of the Multi Ring Buffer Plugin. There is an option for either in the advanced tab.

Plugin: https://plugins.qgis.org/plugins/Multi_Ring_Buffer/
Please report any issues through GitHub: https://github.com/HeikkiVesanto/QGIS_Multi_Ring_Buffer/issues