Problem running the pgr_trsp algorithm - pg9.3

[ecospinaa]

Hi, everyone

I was stuying de pgRouting Documentation 2.0.

I was trying to run the pgr_trsp algorithm as shown in the tutorial:

SELECT seq, id1 AS node, id2 AS edge, cost
FROM pgr_trsp('SELECT id, source, target, cost FROM edge_table',7, 12, false, false);

But i have this result:

seq|node|edge|cost
0|-1|0|0

I check the edge_table table a it´s works for other algorithms such as pgr_astar, but for pgr_trsp don´t work.

I also tried with other edge table, but I always get the same result.

Can anybody helpe with this issue?

thanks in advance for your time and help.

ecospinaa

[ecospinaa]

I was working with PostgreSQL 9.3

[dkastl]

If you want to open this as a bug report, could you provide some sample data to be able to reproduce the issue?

If you'Re looking for general help or assistance, it's better to discuss this on the mailing list, because only few people are reading Github issues.

[ecospinaa]

The sample data is the provided by the documentation 2.0:

DROP TABLE edge_table
CREATE TABLE edge_table (
id serial,
dir character varying,
source integer,
target integer,
cost double precision,
reverse_cost double precision,
x1 double precision,
y1 double precision,
x2 double precision,
y2 double precision,
the_geom geometry
);

INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 2,0, 2,1);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES (-1, 1, 2,1, 3,1);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES (-1, 1, 3,1, 4,1);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 2,1, 2,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1,-1, 3,1, 3,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 0,2, 1,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 1,2, 2,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 2,2, 3,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 3,2, 4,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 2,2, 2,3);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1,-1, 3,2, 3,3);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1,-1, 2,3, 3,3);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1,-1, 3,3, 4,3);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 2,3, 2,4);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 4,2, 4,3);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 4,1, 4,2);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 0.5,3.5, 1.999999999999,3.5);
INSERT INTO edge_table (cost,reverse_cost,x1,y1,x2,y2) VALUES ( 1, 1, 3.5,2.3, 3.5,4);

UPDATE edge_table SET the_geom = st_makeline(st_point(x1,y1),st_point(x2,y2)),
dir = CASE WHEN (cost>0 and reverse_cost>0) THEN 'B' -- both ways
WHEN (cost>0 and reverse_cost<0) THEN 'FT' -- direction of the LINESSTRING
WHEN (cost<0 and reverse_cost>0) THEN 'TF' -- reverse direction 
ELSE '' END;

SELECT pgr_createTopology('edge_table',0.001);

[ecospinaa]

Other additional info:

select * from pgr_version(); "PostgreSQL 9.3.2, compiled by Visual C++ build 1600, 64-bit"

select postgis_full_version(); "POSTGIS="2.1.1 r12113" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER"

select version(); "PostgreSQL 9.3.2, compiled by Visual C++ build 1600, 64-bit"

[woodbri]

This is not a problem on pg 9.2.8 on Ubuntu. I get the following results:

SELECT seq, id1 AS node, id2 AS edge, cost
FROM pgr_trsp('SELECT id, source, target, cost FROM edge_table',7, 12, false, false);
0;7;6;1
1;8;7;1
2;5;8;1
3;6;11;1
4;11;13;1
5;12;-1;0

"PostgreSQL 9.2.8 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit"

"(2.0.0,pgrouting-2.0.0,8,92e3848,develop,1.46.1)"

can someone check this on 9.3 Linux and leave a note. We need to identify if this is a windows problem, a pg 9.3 problem or both.

[dkastl]

You could add this test case to the Travis build and commit to develop branch. It should then compile and test several combinations of PostgreSQL and PostGIS, including the pg 9.3, as far as I remember: https://github.com/pgRouting/pgrouting/blob/develop/.travis.yml#L28

[woodbri]

@dkastl looks like pg 9.3 is failing trying to install postgis-2.0 https://travis-ci.org/pgRouting/pgrouting/jobs/23061438 Not sure if this is travis config issue, postgis issue, or pgrouting issue!

[woodbri]

Looks like this is a pg 9.3 compatibility issue for postgis-2.0. see this link: https://bitbucket.org/rafl/pg_image/commits/9afba4df5b66122ee89f167fb8c22f834ef526d6

So this implies that some if not all or our C functions that interface with SQL MIGHT also need the following added to them:

#if POSTGIS_PGSQL_VERSION >= 93
#include "access/htup_details.h"
#endif

to be compatible with 9.3, but we need to get a working version of postgis first to determine this.

UPDATE: Looks like we already did this and it is not related to this issue.

[woodbri]

I have add a new test case for this issue and it appears to be running ok on winnie: http://winnie.postgis.net:1500/job/pgRouting_2_PGVersion/1483/console

Closing as not reproducible. If you are still having problems with this then you might have an install issue on your system like multiple copies or old dll or a mix of 64bit and 32bit dlls. Check in with us on the list and we will help you sort it out if we can.