shootingstar (#18) - wrong values for vertex_id in result set (#225) - Message List
I've tested shortest_path functions with all three algorithms but shortest_path_shooting_star() gives me wrong values for column 'vertex_id' and many of them are inexistent too (column edge_id is correct)! I've noticed that with a refresh of source/target index the result is different but with an analyze/reindex the problem is not fixed. I've in vertices_tmp table 34470 (counted) records but in 'vertex_id' I also have values bigger than 40100. Values 'source' and 'target' in ways are assigned correctly. Example query (it's the default):
SELECT * FROM shortest_path_shooting_star('SELECT gid as id, source, target, length as cost, reverse_cost, x1, y1, x2, y2, rule, to_cost FROM ways', 8668, 9329, true, true) AS rt
Result: records with 'edge_id' from 8668 to 9329 but wrong 'vertex_id' values
The other question is: why only with this function (for Dijkstra and A* is ok) there isn't last record (perhaps it depends from above problem..)? See http://pgrouting.postlbs.org/wiki/ShootingStar --> "There is one more row after the last edge, which contains the vertex identifier of the target path"
-
Message #797
Did you take edge ID's as source and target for Shooting*?
A* and Dijkstra route from vertex to vertex, Shooting* does from edge to edge.daniel02/18/09 09:55:48 (21 months ago)-
Message #799
Yeah, for Shooting* I take edge ID's and the route is correct, BUT in the column 'vertex_id' there are wrong values (and many inexistent)! I don't know why..
d.l.g.02/18/09 12:12:36 (21 months ago)-
Message #800
How if you use a wrapper like in this example: WorkshopFOSS4G2008/ch09#WrapperfunctionWITHboundingbox
Or could you post a part of your query result here to take a look.
daniel02/18/09 13:35:08 (21 months ago)-
Message #801
This is an example (from capetown osm data Workshop). There are 30523 vertices_tmp, 40585 ways. Edge ID's are
start edge: gid=8668 source=4874 target=5384
end edge: gid=9329 source=5808 target=5809
1)
Query: SELECT * FROM shortest_path_shooting_star('SELECT gid as id, source, target, length as cost, reverse_cost, x1, y1, x2, y2, rule, to_cost FROM ways', 8668, 9329, true, true) AS rt
Result: edge_id is correct and ordered but vertex_id is wrong. And there isn't last record with vertex_id information and edge_id=-1vertex_id;edge_id;cost
62377;8668;0.0654576907903706
63148;8678;0.0515517672118488
62563;8679;0.0599572230296121
63065;8583;0.0240581101489102
63066;8641;0.367604621725962
62504;8068;2.54257394441227
6287;14192;0.366230316241358
6288;14193;0.122676124453466
... too long ...
7504;15196;0.0601016954845696
7502;15195;0.0582438615163934
7500;9329;0.122223878355237
2)
Query: SELECT id, gid, astext(the_geom) AS the_geom FROM shootingstar_sp('ways', 8668, 9329, 0.1, 'length', true, true)
Result: gid is correct BUT sequence order is wrong and there is no information about what is verse of route throughid;gid;the_geom
1;8068;"MULTILINESTRING((18.507268 -33.9032955,18.5061376 -33.9042989, ... ... -33.9163336,18.487808 -33.9165848,18.4866554 -33.9168498,18.485293 -33.9170886))"
2;8583;"MULTILINESTRING((18.5101669 -33.9010915,18.5103726 -33.9012244))"
3;8641;"MULTILINESTRING((18.5103726 -33.9012244,18.510195 -33.9013665,18.509783 -33.9015786, ... ...,18.5084994 -33.9023657,18.507268 -33.9032955))"
4;8668;"MULTILINESTRING((18.5086566 -33.900111,18.509212 -33.9004771))"
5;8678;"MULTILINESTRING((18.509212 -33.9004771,18.5096535 -33.9007611))"
6;8679;"MULTILINESTRING((18.5096535 -33.9007611,18.5101669 -33.9010915))"
7;9329;"MULTILINESTRING((18.4775889 -33.9113361,18.4778618 -33.9102605))"
8;11677;"MULTILINESTRING((18.4819419 -33.9152779,18.4817537 -33.9152288,18.4815011 -33.9151872,18.4812016 -33.9151522,18.4809908 -33.915136))"
..too long ..
27;15197;"MULTILINESTRING((18.4788437 -33.9115559,18.47946 -33.9116637))"
28;15198;"MULTILINESTRING((18.47946 -33.9116637,18.4801123 -33.9117777))"
29;15199;"MULTILINESTRING((18.4801123 -33.9117777,18.4806015 -33.9118703))"d.l.g.02/19/09 02:01:11 (21 months ago)-
Message #803
First, good to tell me that this is the workshop OSM data, isn't it? Since I have it here, too, I just run the queries and got this result:
foss4g2008=# SELECT * FROM shortest_path_shooting_star('SELECT gid as id, source, target, length as cost, reverse_cost, x1, y1, x2, y2, rule, to_cost FROM ways', 8668, 9329, true, true) AS rt; vertex_id | edge_id | cost -----------+---------+--------------------- 11830 | 8668 | 0.0654576907903706 12711 | 8678 | 0.0515517672118488 12029 | 8679 | 0.0599572230296121 12616 | 8583 | 0.0240581101489102 222 | 8641 | 0.367604621725962 11968 | 8068 | 2.54257394441227 11970 | 14192 | 0.366230316241358 19129 | 14193 | 0.122676124453466 19131 | 14373 | 0.0563407200514377 17482 | 12683 | 0.00113917433024668 17484 | 13062 | 0.0422598477798289 17472 | 12671 | 0.0193726470392315 17473 | 13071 | 0.0446155127331235 17447 | 12649 | 0.00205514258475668 17448 | 12650 | 0.191796437357105 17450 | 12651 | 0.0511130097404378 16307 | 11677 | 0.0891714420210499 16309 | 11956 | 0.0109351598604472 16435 | 11957 | 0.0412586339214844 16652 | 11958 | 0.141871421129324 16654 | 11959 | 0.0523265052359561 16656 | 11960 | 0.0987089357557738 16658 | 11961 | 0.0287839186074424 16660 | 15199 | 0.0463029271616241 12509 | 15198 | 0.0615147968770334 13411 | 15197 | 0.0581220082351489 13451 | 15196 | 0.0601016954845696 13468 | 15195 | 0.0582438615163934 13481 | 9329 | 0.122223878355237 (29 rows)foss4g2008=# SELECT id, gid, astext(the_geom) AS the_geom FROM shootingstar_sp('ways', 8668, 9329, 0.1, 'length', true, true); id | gid | the_geom ----+-------+------------------------------------------------------------------------------- 1 | 8668 | MULTILINESTRING((18.5086566 -33.900111,18.509212 -33.9004771)) 2 | 8678 | MULTILINESTRING((18.509212 -33.9004771,18.5096535 -33.9007611)) 3 | 8679 | MULTILINESTRING((18.5096535 -33.9007611,18.5101669 -33.9010915)) 4 | 8583 | MULTILINESTRING((18.5101669 -33.9010915,18.5103726 -33.9012244)) 5 | 8641 | MULTILINESTRING((18.5103726 -33.9012244,18.510195 ...)) 6 | 8068 | MULTILINESTRING((18.507268 -33.9032955,18.5061376 ...)) 7 | 14192 | MULTILINESTRING((18.485293 -33.9170886,18.4847866 ...)) 8 | 14193 | MULTILINESTRING((18.4813775 -33.9176272,18.4813278 ...)) 9 | 14373 | MULTILINESTRING((18.4800485 -33.9175977,18.4798743 ...)) 10 | 12683 | MULTILINESTRING((18.4806523 -33.917673,18.4806434 -33.9176659)) 11 | 13062 | MULTILINESTRING((18.4806434 -33.9176659,18.4804931 ...)) 12 | 12671 | MULTILINESTRING((18.4803551 -33.9173706,18.4802371 -33.9172265)) 13 | 13071 | MULTILINESTRING((18.4802371 -33.9172265,18.4801785 -33.9171482,18.4801431 -33.9170615,18.4801219 -33.9169498,18.4801334 ...)) 14 | 12649 | MULTILINESTRING((18.4801334 -33.9168346,18.4801355 -33.9168162)) 15 | 12650 | MULTILINESTRING((18.4801355 -33.9168162,18.4801766 ...)) 16 | 12651 | MULTILINESTRING((18.4817187 -33.9156986,18.4818119 ...)) 17 | 11677 | MULTILINESTRING((18.4819419 -33.9152779,18.4817537 -33.9152288,18.4815011 -33.9151872,18.4812016 -33.9151522,18.4809908 ...)) 18 | 11956 | MULTILINESTRING((18.4809908 -33.915136,18.4809379 -33.915048)) 19 | 11957 | MULTILINESTRING((18.4809379 -33.915048,18.4807831 -33.9146999)) 20 | 11958 | MULTILINESTRING((18.4807831 -33.9146999,18.4803655 ...)) 21 | 11959 | MULTILINESTRING((18.4803612 -33.913473,18.4803569 ...)) 22 | 11960 | MULTILINESTRING((18.4803869 -33.9130029,18.4805586 -33.9121267)) 23 | 11961 | MULTILINESTRING((18.4805586 -33.9121267,18.4805972 ...)) 24 | 15199 | MULTILINESTRING((18.4801123 -33.9117777,18.4806015 -33.9118703)) 25 | 15198 | MULTILINESTRING((18.47946 -33.9116637,18.4801123 -33.9117777)) 26 | 15197 | MULTILINESTRING((18.4788437 -33.9115559,18.47946 -33.9116637)) 27 | 15196 | MULTILINESTRING((18.4782068 -33.9114429,18.4788437 -33.9115559)) 28 | 15195 | MULTILINESTRING((18.4775889 -33.9113361,18.4782068 -33.9114429)) 29 | 9329 | MULTILINESTRING((18.4775889 -33.9113361,18.4778618 -33.9102605)) (29 rows)This looks actually OK. Serial ID's can be different values when you start inserting data and the sequence is already a certain value.
If there is something that looks not OK in my result, please let me know. Could be that I still didn't exactly understand the question yet.
daniel02/19/09 10:35:35 (21 months ago)-
Message #806
Your data seems to be correct but my problem is independent from serial ID's.
1) Could you control if in your result (first row) vertex_id=11830 is correct? It should be in field source (or target) at gid=8668.
Have you noted that there isn't last record with vertex_id information and edge_id=-1 ?
This is another example from FOSS4G2008_japan VMware image on db='osm_full': so data are from capetown and I have not changed anything. You can control that edge ID's are
start edge: gid=8668 source=4596 target=5085
end edge: gid=9329 source=5501 target=5502
Query is the same as in (1) above
vertex_id | edge_id | cost
10615 | 8668 | ...
...vertex_id=10615 id different from 4596 or 5085! and last record missed
2) You can see that your data are ordered while mine are unordered because my result not starts from edge_id=8668 and not end to 9329
It seems as if in some internal query of shooting_star_sp function there is a JOIN (or WHERE condition) that reorder final result (or perhaps not..)
I've also tried this query for db=osm_full and result is the same:
id | gid | the_geom
1 | 8068 | ...
...d.l.g.02/20/09 01:34:35 (21 months ago)-
Message #976
Hi! I got the same problem. anybody get the answer ?
marcandre07/09/09 23:50:06 (17 months ago)-
Message #977
Hi! I have the same problem. anybody get the answer ?
( sorry for the poor english )
marcandre07/10/09 00:29:32 (17 months ago) -
Message #978
Can you please be more specific?
anton07/10/09 18:12:34 (17 months ago)-
Message #979
it seems to be the same problem. in my result with shortest_path_shooting_star(), the vertex_id are not good it supposed to be the source's id of the vertex in my table used in my request, the vertex "54400059" has for source's id "298" and in my result the vertex "54400059" has for vertex_id "2271" none of the result has the good vertex_id.
i use assign_vertex_id() for the construction of the table vertices_tmp
marcandre07/10/09 22:31:27 (17 months ago)-
Message #981
Ah, I see. Shhoting* is edge-based algorithm, so there should not be any vertex_id column in a result. I added it for the compatibility - didn't want to create one more type for output, so it shares one with Dijkstra/A*. Please don't look at vertex_id column, use edge_id instead. Later you can get real vertex ids by linking your result with your original table and refer to source and target columns.
anton07/13/09 10:10:09 (17 months ago)
-
-
-
-
-
-
-
-
-
