2

I use OSM data imported into PgRouting database. I developped a web application with a map to use OSM data.

I trace routes using shooting_star_sp() function. For example, to have time cost between 2969 and 70890 nodes, I use :

SELECT sum(time_cost_car) FROM ways, (SELECT * FROM shootingstar_sp('ways', 2969, 70890, 0.1, 'time_cost_car', true, true))as rt WHERE ways.gid=rt.gid;

And the result is 861 (seconds). I think it's correct.

Now, I want to create polygon on my map to create isochron area. I followed this tutorial : http://underdark.wordpress.com/2011/09/25/a-closer-look-at-alpha-shapes-in-pgrouting/ It uses driving_distance() function. But the produced polygon seems to be wrong. I have performed the previous time cost calculation using the tutorial approach :

SELECT cost FROM driving_distance('SELECT gid AS id, source::int4 AS source, target::int4 AS target, time_cost_car::float8 AS cost FROM ways', 2969, 1000, false, false) WHERE vertex_id=70890;

And the result is 600 (seconds). That's wrong.

So what is the difference between shootingstar_sp() and driving_distance() ? How can I create a correct isochron polygon ?

Best regards,

RudyWI


I think a part of the problem is resolved. The following request returns 1337 (seconds), it seems to be correct :

SELECT cost FROM driving_distance('SELECT gid AS id, source::int4 AS source, target::int4 AS target, time_cost_car::float8 AS cost FROM ways', 2969, 100000, true, false) WHERE vertex_id=70890;

However, the polygon produced by the following request seems to be wrong :

SELECT * FROM alphashape('SELECT id, ST_X(the_geom) AS x, ST_Y(the_geom) AS y FROM nodes JOIN (SELECT * FROM driving_distance(''SELECT gid AS id, source::int4 AS source, target::int4 AS target, time_cost_car::float8 AS cost FROM ways'', 2969, 30, true, false)) AS route ON nodes.id = route.vertex_id');

Do you kwow why ?

I'm not sure about JOIN with "nodes.vertex_id". What is "vertex_id" ? Why not "edge_id" ? how to be sure "nodes.id" semantic corresponds to "vertex_id" ?

The source parameter used into "driving_distance()" ("2969" in my example) is vertex_id ? edge_id ? or another id ?


I have performed other tests to illustrate the problem :

`SELECT sum(cost) FROM (SELECT * FROM shortest_path('SELECT gid AS id, source::int4 AS source, target::int4 AS target, length::float8 AS cost FROM ways', 25069, 13530, true, false)) AS foo;

Result => 16.7790377846424

SELECT sum(length) FROM ways, (SELECT gid, the_geom AS the_geom FROM shootingstar_sp('ways', 25069, 13530, 0.1, 'length', true, false)) as rt WHERE ways.gid=rt.gid;

Result => 63.5863605213523`

The result retuned by shootingstar_sp() seems to be OK. But to generate the polygon, I use driving_distance() which returns the same result as shortest_path(). This result seems to be wrong.

So, what is the difference between shortest_path() (or driving_distance()) and shootingstar_sp() ?

1 Answer 1

1

Checking the parameters in your function calls, it seems like the first call instructs pgRouting to assume a directed graph (the "true,true"), while the second one tells it that the graph is undirected (the "false,false").

This could explain why the second call finds a faster route.

4
  • It was a good idea, but it does not seem to be the problem. I have performed the following request : SELECT cost FROM driving_distance('SELECT gid AS id, source::int4 AS source, target::int4 AS target, time_cost_car::float8 AS cost, time_cost_car::float8 AS reverse_cost FROM ways', 2969, 1000, true, true) WHERE vertex_id=70890; The result is still 600 (seconds).
    – RudyWI
    Commented Oct 3, 2012 at 15:45
  • shouldn't you be summing up the costs?
    – underdark
    Commented Oct 3, 2012 at 16:23
  • The same request without "reverse_cost" : SELECT cost FROM driving_distance('SELECT gid AS id, source::int4 AS source, target::int4 AS target, time_cost_car::float8 AS cost FROM ways', 2969, 1000, true, false) WHERE vertex_id=70890; Does not return any result (0 line). I don't understand. Do you have any idea ?
    – RudyWI
    Commented Oct 4, 2012 at 8:45
  • In a directed graph, edges without reverse cost will only be traversable in one direction. It's well possible that no it's impossible to find a route in such a setting.
    – underdark
    Commented Oct 4, 2012 at 16:26

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.