Tag Info

Hot answers tagged

2

try to order your result by sequence of your routing table. by doing that you will get your road segments in right order this is what i am doing this: SELECT pt.gid, seq, id1 AS node, id2 AS edge, cost, geom as line FROM pgr_dijkstra('SELECT gid as id, source::int4, target::int4, shape_leng::float8 as cost FROM my_table', ...


2

You are referring to the wrong documentation (the old version). The pgRouting 2.0 documentation is available here: http://docs.pgrouting.org/ It's important that pgRouting has been built with support for driving distance. This should be the case for binaries, but if you compile yourself, you need to enable it with the flag -DWITH_DD=ON. If driving distance ...


2

Although you are using a different routing function but problem was the same I was facing and I hope this can help you out try to order your result by sequence of your routing table. by doing that you will get your road segments in right order this is what i am doing this: SELECT pt.gid, seq, id1 AS node, id2 AS edge, cost, geom as line FROM ...


2

You implicitly CROSS JOINed the tables so you got a cartesian product. Since you don't want to merge the geometries together you should use the UNION ALL which is an entirely different construct: SELECT a.geom FROM the_network a UNION ALL SELECT b.geom FROM buildings_to_network_lines_table b Now that you have a correct SELECT query you can use it in ...


1

source and target attribute contain node ID's. Each node ID should be unique, but it can appear multiple times in source and target column, because a node can be the connecting point for more than one road link. Depending of the direction (defined by the geometry) of the road link the node ID is source or target.


1

pgr_createTopology() will always recreate the topology for the whole network. So if you want to preserve source and target, you shouldn't run this function. It's no problem to use data, that already has network topology attributes (you may want to renumber it, because lower numbers will be better for performance). If you want to fill in the values manually, ...


1

There should be a message for each failure, but eventually one (or more) have been forgotten? You could try do debug the problem by modifying the pgr_createTopology function, for example by adding more intermediate output to the pgsql function. There is no pgRouting log, except the messages generated with raise notice.


1

I have the exact same problem and I have figured that out why it is happening. When you run your routing for Dijkstra with particular "source" and "target" it runs fine and gives you the shortest path. But when you are choosing same "source" and "target" for pgr_ksp it gives nothing. It is only because from that particular "source" there is no possible way ...


1

Just to close this loose end, since I asked the question a new package was released called osmar which contains a vignette of how to implement shortest path algorithms in R using Open Street Map data: http://osmar.r-forge.r-project.org/ . It uses the function get.shortest.paths from the igraph package. Excellent article on this can be found here: ...



Only top voted, non community-wiki answers of a minimum length are eligible