0

I am using pgr_dijkstra for finding the shortest path between two given nodes. The network map is actually a grid based one and I have created all the necessary columns and working fine. But I do not understand how does the id2 (which is edge) given?

Query in QGIS

The values given for id2 (e.g., 59721224, 59721496 ...) can not be found any of my tables. So how does this id2 (edge) values are given? Every single time I query pgr_dijkstra, id2 values are changing but none of the other columns are changing.

This is how my wp_norway_network1 table looks: wp_norway_network1

  • It might help if you can show (illustrative) data on your input network. – BradHards Nov 14 '13 at 8:42
  • I have added my input network 'wp_norway_network1' table screenshot here – kaja Nov 14 '13 at 18:21
2

id2 59721224 for example is the edge that connects vertex IDs 2 and 3. That's why the last record has a value of -1.

Edge ID is the id you specify in the first argument (SQL query) of the pgr_dijkstra function. In your case it's the gid of the table named wp_norway_network1. Because pgr_dijkstra requires the column name id, you had to write gid AS id.

  • I have added the screenshot of my wp_norway_network1 table. As you can see, there is not edge id with 8 digits ((e.g., 59721224, 59721496 ...) . All the gid in that table are 4 digits. So my problem is, how does it get those 8 digit edge ids? – kaja Nov 14 '13 at 18:20
  • It's a bit difficult to look at this with screenshots. Would you be able to send some sample data, which allows to reproduce your case, to the pgRouting mailing list? This would make it easier to find out, if it's a bug. – dkastl Nov 16 '13 at 23:36
  • You can find my question here with the files: pgrouting-users.974093.n3.nabble.com/… – kaja Nov 17 '13 at 5:04
  • The files are uploaded again to make it accessible for everyone: pgrouting-users.974093.n3.nabble.com/… – kaja Nov 19 '13 at 18:52
1

I finally figured out the problem. In my query presently I have

'SELECT gid AS id'

changing that to

'SELECT gid::integer AS id' solved the problem.

  • This issue stumped me for too long. As well my source/target id numbers were Navteq reference ids, which were in the billion range. Passing these in as source/target caused the same issue where the returned vertex ids were randomly something else. I assume it has something to do with integer overflow in the C code. – Matt Aug 15 '14 at 18:44

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.