dijkstra (#16) - No return values of dijkstra function (#322) - Message List
Hi,
I'm new in the forum and i want to know if anyone could help me with my problem...
I have installed pgrouting in an opensuse 11.1 enviroment and i'm testing the dijkstra algorithm to calculate routes.
I follow the tutorial ( http://www.utdallas.edu/~ama054000/rt_tutorial.html) and everything seems to be right with the tutorial, the problem appears when i do exactly the same steps with my geometry data, the function dijkstra_sp doesn't return any values! No error show in console, the query just return nothing....
Query:
SELECT the_geom FROM dijkstra_sp('streets_dijsktra',3851,709);
It seems to create the vertices_tmp table correctly and the attributes:cost, length, source, target and the_geom seems to be correct too....
Some vertices are neither source or target in my original geometry table, this is correct? I think this could be the problem why the algorithm couldn't find any path..
How can i verify if my geometry data is correct in order to be processed by dijkstra_sp function?
I used geoserver to see the vertices_tmp geometry data and the geometry data in my original table and seems to be rigth but i'm just starting with pgrouting, postgis and all that stuff so if anyone could give me an idea about what could be wrong i will be very appreciated!
If anyone need my geometry data i could send an email with the info needed
Thanks a lot, Santiago
-
Message #1344
I have tested others paths with the data provided in the the tutorial (edges.shp) and the result of the testing was incorrect, for example if i want to know the shortest path from the node 52 to the node 7 the result is incorrect. The correct answer will be a path with 3 edges but the result showed me a path with 6 edges and i have set the length to 1 for all edges in order to dijkstra return the shortest path....
I think there's a problem in the assign_vertex_id function because if i check in the vertices_tmp table for a target node for example 49 the query returns only 3 source nodes 22,48,26 but the source nodes 51 and 24 should be there too....
I dont know what could be wrong.. maybe something went wrong in the installation process?
Thanks, Santiago.
smontico01/08/10 04:44:38 (11 months ago)-
Message #1348
How did you run the assign_vertex_id function to create the topology?
Not sure this is the reason for your problem, but it's a very common issue, that leads to strange results when the tolerance value for snapping is in a different unit than your projection is.
daniel01/09/10 10:09:47 (11 months ago)-
Message #1351
Hi Daniel,
I run the function assign_vertex_id like this:
SELECT assign_vertex_id('streets,dijkstra',0.0001,'the_geom','gid')
I copied the tolerance value from the tutorial and then i have changed this value in order to see if i can fix my problem and the amount of rows in vertices_temp increase when i decrease the tolerance to a maximum of 5698 aprox and decrease when i increase the tolerance to 100 for example...
As you suposse i dont know exactly which is the correct value of tolerance to my geometry data :(
Can be a problem of my geometry data? I have a table with streets information and each row represents one street and the gemoetry data is a multilinestring field for each row. The data is in the correct format in order to use pgrouting?
Thanks, Santiago.
smontico01/12/10 01:48:59 (10 months ago)-
Message #1356
The snapping tolerance depends on the data projection. It's usually either a "meter" or a "degree" projection. WGS84 for example is "degree" and you should keep snapping tolerance very low (because one degree would be huge, right?). And Google projection is for example "meter".
Multilinestring shouldn't be an issue. Is your data some well-known data such as Navteq or OpenStreetMap?? Those shoudl usually work.
This is a PostgreSQL dump file from a workshop that lacks the attributes, which assign_vertex_id will update later: http://files.postlbs.org/foss4g2008/Data/ways_without_topology.sql
It's kind of a basic sample data for routing. You could take a look and compare it with your data. Have you tried one of the workshops with sample data?
daniel01/12/10 02:43:11 (10 months ago)-
Message #1357
Daniel,
The data is particular of my city (Montevideo,Uruguay) i dont really know the source where it comes from....
I have used the shp2psql to populate the table with the information because the data was available in a shapefile.
I didn't try with the sample data of the workshop, i have tried with the data of the tutorial ( http://www.utdallas.edu/~ama054000/rt_tutorial.html) and it seems to work....
Anyway in this tutorial or in general there's something that i dont understand; I've set the length field to 1 for all rows. By doing this, I expected that when calculating any path, the result would be the one with the minimum number of edges, but this is not working like this. Am I missing something??
If you want my geometry data i can send it to you if you want to test something to see what could be wrong, but i dont want to bother you...
Thanks, Santiago.
smontico01/12/10 03:22:26 (10 months ago)-
Message #1358
I didn't try the tutorial you mention, but you whether you set the length as 1 or not, it matters what you take as "cost". If you take length as cost, in your case the shortest path would be the one with minimum edges, right?
Well, you can send me your data (or a part of your data if it's too large), and I can take a look. Send it to "daniel [at] georepublic [dot] de".
daniel01/12/10 10:32:16 (10 months ago)-
Message #1361
I didn't try the tutorial you mention, but you whether you set the length as 1 or not, it matters what you take as "cost". If you take length as cost, in your case the shortest path would be the one with minimum edges, right?
In my case i take the length as cost as you say and think that the shortest >>>> path would be the one with minimum edges too, thats why i'm asking if i am >>>> missing something...
Well, you can send me your data (or a part of your data if it's too large), and I can take a look. Send it to "daniel [at] georepublic [dot] de".
I just send the mail for you, thank you very much Daniel!
smontico01/12/10 21:09:10 (10 months ago)
-
-
-
-
-
-
-
Message #1345
Hi Santiago,
I'm also working my way through routing and had a similar problem. I think you'll find your instructions are out of date. Step two tells you to run two sql files - there are in fact three. At the end of step 2, after running routing_core_wrappers.sql, you should do the same with routing_topology.sql. That sorted things out for me, I hope it does for you.
HappyDayz01/08/10 22:32:34 (11 months ago)-
Message #1346
Hi HappyDayz?,
Thank you for anwser!
I have installed all the products following this tutorial: http://cartosig.upv.es/es/blogs/jomarlla/own/2008/08/16/compilar-pgrouting-102 (in spanish), i think the sql file you are telling me comes with the version 1.03 and i have installed the version 1.02, maybe i have to upgrade my pgrouting version then :(
I kept investigating what could be wrong with my problem and i have a question, may be you can help me... In my geometry data i have a table with streets information and each street is represented with a multilinestring geometry column, this table has a source and target attribute then i run the assign_vertex_id function.
Is this correct? or i have to change some other thing before running the assign_vertex_id function?
What do the source and target attributes represent? I think after running the assign_vertex_id function the geom attribute contains the information about the edges of the topology but i dont understand why i have only one source and target for all the edges that represent the street.
Checking the topology i see that in geoserver not all intersection has an associated vertice, is this correct? Or every street intersection should have an associated vertice?
Thanks a lot! Santiago.
smontico01/08/10 23:59:58 (11 months ago)-
Message #1347
Perhaps you are experiencing the other problem I had. I had orginally intended to use OpenStreetMap? data for my experiments. As I am using XP I couldn't use the OSM2PGSQL conversion utility and I could only get the routing to work along the length of a single MULTILINESTRING - no good at all! I think the problem is that where two lines cross there is no vertex. You can try this by inserting two MULTILINESTRINGS, that cross, into an empty pgrouting enabled table - there will be no vertices after you have run the assign _vertex_id.
I've been playing with this for the last couple of days and have found a way of creating the vertices. I have no doubt that what I am about to say will make experienced users cringe, but they are not here at the moment!
For the purposes of my playing I create a temporary table with just half a dozen joining and crossing MULTILLINESTRINGS. I then use ST_AsText combined with ST_Union to create a single WKT GEOMETRYCOLLECTION of MULTILINESTRINGS from the temporary table. The MULTILINESTRINGS within the GEOMETRYCOLLECTION now have the new vertices, where the lines cross, in them. I then split the collection into separate MULTILINESTRINGS and insert them into the new database individually. Now when I run the assign_vertex_id all the crossing points are in the vertex list and the routing works. Whether this will work on a large scale I don't know as I haven't tried it yet.
If you want the sql strings I use, I can email them to you but not until Monday as I am away for a couple of days.
HappyDayz01/09/10 01:06:03 (11 months ago)
-
-
