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 many experience in GIS, postgis and pgrouting, i would be very pleased if you have some tricks or an idea about the problem !

Thank you for your help !

Xavier

(I'm using postgis 9.2 + pgRouting 2.0 beta)

|improve this question
  • Can you run a shortest path query with a result that looks OK? – dkastl Jul 14 '13 at 10:23
  • No, i get a result with a similar problem (ways disconnected) – Xavier Jul 15 '13 at 10:15
  • Then your topology is probably created wrong, see answer below. – dkastl Jul 15 '13 at 13:18
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.
|improve this answer
  • 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 Jul 15 '13 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

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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