2

I am trying the driving distance function of pgRouting 2.0 beta, with an extract of OSM data. The problem I have is illustrated on the following image :

enter image description here

On this picture i try to get all the ways accessible in 5 min from the downtown of the small city. For this purpose, I use the driving distance function. Clearly, the result is not ok : ways that should be returned are not, ways that shouldn't are (and far away from the area).

I'm pretty sure it's a problem during the creation of the topology, so I've tried various tool to import data and create the topology :

  • osm2postgis, osmosis + pgr_createTopology function of pgRouting
  • osm2po

With exactly the same kind of problem each time.

I've changed the tolerance of disconnected edge of the pgr_createTopology function and tried a large range of values, without success.

I haven't much experience in GIS, PostGIS and pgrouting.

I'm using PostGIS 9.2 + pgRouting 2.0 beta.

3
  • Can you run a shortest path query with a result that looks OK?
    – dkastl
    Commented Jul 14, 2013 at 10:23
  • No, i get a result with a similar problem (ways disconnected)
    – Xavier
    Commented Jul 15, 2013 at 10:15
  • Then your topology is probably created wrong, see answer below.
    – dkastl
    Commented Jul 15, 2013 at 13:18

2 Answers 2

2

When you run pgr_createTopology, then the "snapping tolerance" is essential to have the same unit as your geometry. There are 2 cases:

  1. Your projection is in "degree", then a value must be much smaller than 1, for example 0.00001
  2. Or your projection in in "meter", then the value might 1 for example.
1
  • It seems that openstreetmap projection is in degrees. I've tried both 0.000001 and 1 for the "snapping tolerance" with no change in the error. The path is still composed by disconnected edges.
    – Xavier
    Commented Jul 15, 2013 at 14:53
2

Are you calling pgr_drivingdistance and then using id2 (the "edge id") to join back to your edge table?

If so, the pgr_drivingdistance function actually currently has a bug which causes this 'edge id' to not represent the actual path taken to get to that node. see https://github.com/pgRouting/pgrouting/issues/203

There's currently an open pull request to fix the issue (https://github.com/pgRouting/pgrouting/pull/204). You can try pulling down this branch, re-building and re-installing, and see if it fixes your issue

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.