Year: 2015

Setting up your GDAL and OGR Environmental Variables

Table of Contents

    Windows 11

    Open the start menu, and search for: environment variables

    Choose the Edit the system environment variables

    Choose Environment Variables.

    Edit the Path Variable by adding an entry for you path to ogr2ogr.

    I would recommend installing ogr2ogr using the OSGeo4W network installer and the default path. If you have done this the path is: C:\OSGeo4W\bin

    You also need to add 2 new entries into the base environmental variables, one for:

    GDAL_DATA

    With path:

    C:\OSGeo4W\share\gdal

    One for:

    PROJ_LIB

    With path:

    C:\OSGeo4W64\share\proj

    Adjust the paths accordingly if you have not used the default install locations.

    Windows 10

    I recently upgraded to Windows 10, and have been setting up my GIS workspace settings.

    Setting up your Windows path environmental variables can easily be done through the command line.

    These commands can be run directly in the command line and don’t require a computer restart to take effect. To run the command prompt, simply open up the windows search (Windows Key + S) and search for “cmd”:

    Screenshot[3]

    Then run the command to add the path.

    Update: PROJ_LIB also needs to be set, to prevent “PROJ: proj_create_from_wkt: Cannot find proj.db” errors.

    Determine where your QGIS is installed. I recommend using the OSGeo4W network installer and using the default location. Which would be: C:\OSGeo4W\bin

    If it is installed there, just run:

    setx PATH "%PATH%;C:\OSGeo4W\bin"
setx GDAL_DATA "C:\OSGeo4W\share\gdal"
setx PROJ_LIB "C:\OSGeo4W\share\proj"

    In the past a 64 bit install was installed by default into: C:\OSGeo4W64\bin

    If it is installed there run:

    setx PATH "%PATH%;C:\OSGeo4W64\bin"
setx GDAL_DATA "C:\OSGeo4W64\share\gdal"
setx PROJ_LIB "C:\OSGeo4W64\share\proj"
    Screenshot[6]

    Restart your command prompt.

    Screenshot[7]

    Success.

    No more:
    ‘org2ogr’ is not recognized as an internal or external command, operable program or batch file.

    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