wrong segment selected

[milovanderlinden]

Hi there! I am setting up pgRouting with openstreetmap data. I have something odd. (See screenshots) I have two nodes in my network that are connected by two lines like this:

---

| | | | | | | | | | -----B-----

I use both cost and revers cost, but no matter how high I set the cost for edge B, it refuses to return edge A in a routing request.

The live example is here:  http://dogomaps.net/yours/test.html?flat=12.521319256979&flon=-70.041577813017&tlat=12.519669651038&tlon=-70.039394494879&v=motorcar&fast=1&layer=mapnik

Can it be that it does a select limit 1 under water or something that in my case always returns the wrong one?

[milovanderlinden]

Route selected by pgRouting

[milovanderlinden]

topology in qGIS, the symbol represents the number of connections to the node (triangle=3, square=4)

[anton]

It would be a huge help if you could attach a dump of your table around this suspicious place.

[milovanderlinden]

A dump seems to be too big. I got one ready but it will not upload.

Basically, what I do is: 1 - Grab the planet file for Aruba: wget  http://planet.openstreetmap.nl/planet-aruba-latest.osm.gz

2 - Use osm2pgsql to load the openstreetmap data into my database: ./osm2pgsql -H <server> -l -s -d <database> -U <db-user> -W planet-aruba-latest.osm.gz

3 - And then run the script (see attachement) to generate the tables for routing: psql -h <server> -U <db-user> -d <db-user> -W -f osm2pgrouting.sql

[milovanderlinden]

Script to create tables from the openstreetmap tables for routing

[anton]

I didn't mean the entire dump - just few edges around that suspicious place would be enough.

[simonnuttall]

In this simple example there are two edges, one has cost 35, the other 4, but shortest_path() chooses the 35.

drop table if exists edge;

CREATE TABLE edge (
  id int4 NOT NULL,
  start int4 NOT NULL,
  finish integer NOT NULL,
  cost float8 NOT NULL,
  reverse_cost float8 NOT NULL);

truncate edge;

insert into edge values (35, 100, 200, 35, 35);
insert into edge values ( 4, 100, 200,  4,  4);

SELECT * FROM shortest_path('SELECT id, start::int4 as source, finish::int4 as target, cost, reverse_cost from edge', 100, 200, true, true);

routing=# SELECT * FROM shortest_path('SELECT id, start::int4 as source, finish::int4 as target, cost, reverse_cost from edge', 100, 200, true, true);
 vertex_id | edge_id | cost 
-----------+---------+------
       100 |      35 |   35
       200 |      -1 |    0
(2 rows)

If I swap the order of the inserts in the above, it does give the right answer. I'm using a version recently downloaded from SVN.

I haven't looked at the original problem described in this ticket, but the symptoms I'm seeing here seem related.

[simonnuttall]

The comment I raised has been answered at:  http://lists.osgeo.org/pipermail/pgrouting-users/2010-June/000312.html