I use the contour plugin (v1.1) within QGIS 2.4 to create contour lines. I have streets with different travel costs. I observe problems for streets with low travel costs if they are surrounded by streets with high travel costs. The low cost street is "piercing" into the low speed area (cf. picture). The points are created as the travel cost markers from Dijkstra algorithm using pgrouting 2.0.5. The Dijkstra algo. calculates correct values for every street.

The problem I observe is now, that due to low speed areas left and right to the highway, the isolines are connecting both areas over the highway (yellow). Based on values, the correct behavior would be the one shown in green.

Can someone recommend me a way of preventing such results?

Before I used GDAL TIN interpolation and contour mapping, which leads to better results if it comes to complex networks. On the other hand it adds transformation errors (rasterizing) and extra steps to the calculations.

Section of my map showing two 60 sec. isolines without connection. Green: The likely correct isoline. Yellow: The wrong connections for the isolines. Original result

  • I need to bring this up again. Is there a way to get finer interpolations with QGIS in the meantime? I have again run into this problem and find it very problematic. Maybe should I switch to ARCgis network analyzer?
    – Frank
    Commented Oct 14, 2015 at 15:26

2 Answers 2


I don't know the contour plugin of QGIS and how it is related to pgRouting.

The pgRouting drivetime function though does right now very strong simplification in the alphashape calculation. Therefore the resulting polygons often look similar to your screenshots.

If you're able to compile pgRouting, then you could try a recent improvement of the alphashape function, which allows to specify the "alpha" value and contains various other fixes as well (see this pull request for some explanation).

The patch is currently only available in the pgRouting develop branch and needs more testing and documentation. Feedback is always welcome.

  • Thank you. I checked each node and the drive times obtained from pgrouting (Dijkstra) match the expected result sketched in green. Therefore the reason must lie in the Contour mapping. Would you recommend to use GDAL TINs?
    – Frank
    Commented Aug 11, 2014 at 12:32
  • I have read up on pgrouting's alphashapes. Seems like your team does no interplolation and alphashape returns only the amount of nodes within distance? Interpolation would also interpolate the driving distance on the edge to the queried value.
    – Frank
    Commented Aug 11, 2014 at 16:23
  • Right, we don't do interpolation. There is a function that returns all nodes and the costs to get there from a start point, but further processing like interpolation had to be "manually". Not sure PostGIS has tools for that.
    – dkastl
    Commented Aug 12, 2014 at 0:52

The behavior is due to the point interpolation. Without additional points in between, TIN or IDW interpolation interpolates based on the surrounding points (as expected, because the topology information was removed by the extraction of the nodes).

Using the existing tools, one can densify the network using Underdark's function described here: How to create points in a specified distance along the line in QGIS? and add enough sampling points to support the information of the well / sink aka the highway crossing.

At the end the question remains if there's a much better way using the information from topology instead of extracting points and working on reduced information.

EDIT: I finally solved the problem by using alpahshapes from PostGIS2.2.1 or pgrouting 2.1.0. An example can be found in the documentation of pgrouting or in PostGIS.

In my experience one should avoid the old TIN method in favor of alphashapes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.