I have a road network where I do a driving distance operation through pgrouting. This is my SQL:

SELECT * FROM driving_distance('SELECT gid AS id,source,target, cost FROM elveg',676663,1000,false,false);

From this query I get a strange result: http://bildr.no/view/1373984

Black is my road network and green is the result from the above query. From the image you see that some edges are not included(not green) while edges which can only be connected through this not included edge in fact is included?

How can this be? Am I doing something totally wrong here?

3 Answers 3


I have the same problem during working with pgRouting. That's why I read that threat. For everybody who has the same problem: I found a solution to get all edges nevertheless. The result of driving_distance delivers a lot of edges which are used. If you look into the road network in detail, it is recognizable that some parts in between two given edges are missing. Consequently the source and the target vertex of the missing edge is given. With the help of these information all driveable edges are determinable with the following steps:

  1. Choose all edges which are given by the result of driving_distance of pgRouting
  2. Choose all vertexes which are given by the result of driving_distance of pgRouting
  3. Choose all edges from your road network whose source vertex OR target vertex is like one of 2.
  4. Choose the edges of 3. whose source vertex AND target vertex is like one of 2. (It's not necessary that source and target vertex are the same. The source vertex just have to be one of the given vertexes; the same condition needs do be satisfied for the target vertex)
  5. Union the results of step 1 and step 4 to get all edges.

All these steps can summarized in one single SQL Statement but also can be handled seperated. The result is a network off all driveable edges within the catchment area.

Hopefully this explanation helps.


You have created routing table with too big tolerances.

When you have linestring table and you create edge/vertex table for routing algorithm, you need to give tolerance. For example

        |  a-line
c-line /
        |  -b-line

In example both a and b line should intersect at "o" but something went wrong somewhere. So easy "fix" is use that "1m" tolerance, but it his example it would probably "eat" c-line away because its lenght is "1m"

third edit: now that i picture again, it just looks like you routing edge/vertex table is broken, try regerate it using sane tolarenace see for howto "http://pgrouting.org/docs/howto/topology.html#pgrouting"

This one seems to be good example howto do it http://pgrouting.org/docs/foss4g2008/index.html

  • Hi, could you add more details?
    – R.K.
    Commented Jan 27, 2013 at 6:28
  • What do you mean simplexio? I use this table for regular shortest path routing and it works fine for that?
    – Espen
    Commented Jan 27, 2013 at 20:51
  • It's been a while i last time used pgrouting, but i think it need its own table . i mean "assign_vertex_id('<table>', float tolerance, '<geometry column', '<gid>')" functio which creates network topology from table Commented Jan 28, 2013 at 8:16
  • At the moment assign_vertex_id gives an error. So something is not working right here :-) ERROR: query string argument of EXECUTE is null CONTEXT: PL/pgSQL function assign_vertex_id(character varying,double precision,character varying,character varying) line 36 at EXECUTE statement
    – Espen
    Commented Jan 30, 2013 at 12:43
  • CREATE OR REPLACE FUNCTION assign_vertex_id(schema_name varchar, geom_table varchar, tolerance double precision, geo_cname varchar, gid_cname varchar) Is in latest version , so you need add schema there Commented Jan 30, 2013 at 12:55

I believe you may be running in to a known bug in pgrouting. the driving_distance function basically returns the cost to a node, not the cost to an edge, and the edge_id it returns is not necessarily the one it traversed to get to a node, and not all edges traversed will necessarily be included in the results.

note: https://github.com/pgRouting/pgrouting/issues/51

also note that in the documentation for 2.0 (http://docs.pgrouting.org/2.0/en/src/driving_distance/doc/dd_driving_distance.html#pgr-driving-distance), it's indicated that edge_id is "probably not a useful item". I'm currently in the process of determining whether this is still a bug in 2.0.

  • Ok, thanks for your reply. I am not currently working with this stuff anymore so I am not able to test it out.
    – Espen
    Commented Nov 13, 2013 at 7:17

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.