pgr_trsp on windows returns no route

[matt-gen]

I've been using pgr_dijkstra successfully for several months and am now trying to switch to pgr_trsp.
I've been unable to get any sort of route back from pgr_trsp, so I started fresh and with the sample data, and am still unable to get any route back.

Installed a fresh Windows PostgreSQL v9.4.1 x64 on my local dev box, and used the Application Stack Builder to install PostGIS v2.1.7 which includes pgRouting 2.0.
Created the sample data from http://docs.pgrouting.org/2.0/en/doc/src/developer/sampledata.html
Running the basic sample queries from http://docs.pgrouting.org/2.0/en/src/dijkstra/doc/index.html return valid routes.
Running the basic sample queries from http://docs.pgrouting.org/2.0/en/src/trsp/doc/index.html just returns an empty route.

seq  node  edge  cost
  0    -1     0     0

I initially tried it on some of our other Windows servers with PostgreSQL v9.3/9.4 where pgr_dijkstra works, but got back the same empty route for pgr_trsp.

I don't easily have a way to test a linux installation, but if you think that may be the issue, I will try and put one together to test.

[woodbri]

Create a test database and install pgrouting.
then fetch this file http://imaptools.com:8080/dl/parallel.sql
Open that in pgadmin3 in a sql window and execute it
then run this command:

select * from pgr_trsp('select * from parallel', 1, 4, false, true);

I get the following response on Linux:

 seq | id1 | id2 | cost
-----+-----+-----+------
   0 |   1 |   1 |    1
   1 |   2 |   2 |    2
   2 |   3 |   5 |    1
   3 |   4 |  -1 |    0
(4 rows)

[matt-gen]

Thanks for such a quick response. Unfortunately my issue persists.

select * from parallel;

select * from pgr_trsp('select * from parallel', 1, 4, false, true);

select * from pgr_dijkstra('select * from parallel', 1, 4, false, true);

[robe2]

woodbri - confirmed I get the same thing on my windows box. Which pgrouting are you using woodbri. Wonder if its difference between released and development.

Output for

pgr=# SELECT * from pgr_version();
 version |       tag       | build |  hash   | branch | boost
---------+-----------------+-------+---------+--------+--------
 2.0.0   | pgrouting-2.0.0 | 0     | f26831f | master | 1.53.0
(1 row)

and this is on version

pgr=# SELECT version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit

I'll install the development version of pgrouting to see if I see the issue there, unless you are testing with the released version and don't see it.

[robe2]

Put in another ticket. Having issues compiling the development branch noted here:

#337

[woodbri]

@robe2 I'm using:

pgrouting=# select * from pgr_version();
 version |       tag       | build |  hash   | branch  | boost
---------+-----------------+-------+---------+---------+--------
 2.0.0   | pgrouting-2.0.0 | 170   | 5cdd106 | develop | 1.54.0
(1 row)

[matt-gen]

Managed to get a CentOS VM going, installed fresh PostgreSQL 9.4.1 and

gisdb=# SELECT * from pgr_version();
version |       tag       | build |  hash   | branch | boost
---------+-----------------+-------+---------+--------+--------
2.0.0   | pgrouting-2.0.0 | 0     | f26831f | master | 1.53.0

pgr_trsp works correctly.

[woodbri]

Yeah, I'm not sure what is going on with this, it is working on Ubuntu 14.04 also, so I suspect that it is a windows specific problem which is a pain to sort out because I don't have my windows development environment setup up anymore. I'll try to work with @robe2 to get it sorted out but it might take a while.

[robe2]

woodbri, Tho: Well the good news is that the build generated from Vicky's ksp improve branch
https://github.com/cvvergara/pgrouting/tree/ksp-improve-boost
does behave correctly under windows 64-bit 9.4.1

 version |       tag       | build |  hash   | branch  | boost
---------+-----------------+-------+---------+---------+--------
 2.0.0   | pgrouting-2.0.0 | 170   | 5cdd106 | develop | 1.53.0
(1 row)

SELECT * FROM pgr_dijkstra('select * from parallel', 1, 4, false, true);

get output:

 seq | id1 | id2 | cost
-----+-----+-----+------
   0 |   1 |   1 |    1
   1 |   2 |   2 |    2
   2 |   3 |   5 |    1
   3 |   4 |  -1 |    0

You can download the build here:

http://winnie.postgis.net/download/windows/pg94/buildbot/ (the one called pgrouting-pg94-binaries-ksp_improve_boostw64gcc48.zip )

I still have to check the 9.3 because that one is throwing some errors which I think according to Vicky are related to trsp.

[matt-gen]

Thanks for the suggestion @robe2 , I installed ksp-improve-boost on 9.4.1, getting the same pgr_version() as you.
pgr_dijkstra works, pgr_trsp still gives an empty result though.

SELECT * FROM pgr_trsp('select * from parallel', 1, 4, false, true);

[robe2]

Ah bah I was testing the wrong thing. Okay still a problem. That was too easy I guess..

[robe2]

Okay this is one of those weird ones where it works fine in my mingw64 install, but doesn't on the VC++ build I install it on. I was meaning to also have pgrouting test against the VC++ builds. Anyway that's probably why it passes the tests fine but fails in the general environment.

woodbri -- do you support DEBUG level notices so I can switch my postgres to DEBUG level to track what is up here?

[woodbri]

DEBUG you can uncomment this line:
https://github.com/pgRouting/pgrouting/blob/master/src/trsp/src/trsp.c#L16
and it will turn on NOTICE from the C code.

[woodbri]

@robe2 look here:
https://github.com/pgRouting/pgrouting/blob/master/src/ksp/src/ksp.c#L316
@cvvergara found this and maybe this is the problem that trsp does not have the MSC ifdef like the link above.

[woodbri]

@robe2, I made a change to trsp.c in develop branch to try fix this issue and pushed it. Ineed to build on winnie and the the user to test it out and see if it fixes the problem. I can make a change to master if it does and bump the version.

[woodbri]

@robe2 We just merged all of @cvvergara changes for ksp and dijkstra into develop. So we should only look at development for now.

[woodbri]

@Tho77 if you can pull a build of develop from postgis.net and see if the changes I added to develop resolve your problem, that would help. Thanks.

[matt-gen]

Installed the one stamped today at 2:46pm.
http://winnie.postgis.net/download/windows/pg94/buildbot/pgrouting-pg94-binaries-2.0w64gcc48.zip

SELECT * FROM pgr_trsp('select * from parallel', 1, 4, false, true);

is still empty.

[woodbri]

OK, thank you for checking. I'll have to leave this to @robe2 to figure out as it is some kind of windows compatibility or build issue.

[robe2]

Okay will take a look later this weekend.

[robe2]

This looks like a character encoding issue. I put the debug line in, and when I ran on my default VC++ instance (which happens to default to WIN1252 ) it gave the below error, however if I create a new database using template0 with UTF-8 and run in pgAdmin it gives the right anwer. However since my psql is set to win1252 encoding, it gives the same error below even on my utf8 database unless I do

\encoding UTF8
SELECT * FROM pgr_trsp('select * from parallel', 1, 4, false, true);

Gives expected:
 seq | id1 | id2 | cost
-----+-----+-----+------
   0 |   1 |   1 |    1
   1 |   2 |   2 |    2
   2 |   3 |   5 |    1
   3 |   4 |  -1 |    0

NOTICE: Calling compute_trsp
NOTICE: start turn_restrict_shortest_path
NOTICE: columns: id 1 source 2 target 3 cost 4
NOTICE: columns: reverse_cost cost 5
NOTICE: Min vertex id: 1 , Max vid: 6
NOTICE: Total 8 edge tuples
NOTICE: Fetching restriction tuples
NOTICE: Sql for restrictions is null.
NOTICE: Total 0 restriction tuples
NOTICE: Calling trsp_node_wrapper
NOTICE: Message received from inside:

ERROR: character with byte sequence 0x8d in encoding "WIN1252" has no equivalent in encoding "UTF8"
********** Error **********

ERROR: character with byte sequence 0x8d in encoding "WIN1252" has no equivalent in encoding "UTF8"
SQL state: 22P05

I did run the regress tests against VC++ and they all passed the last two times I ran, however on the first run, I got an error in bdstar which I haven't been able to repeat and forgot to log.

[robe2]

oops sorry launched the wrong instance. Stay tuned. :(

[robe2]

Well it seems to work when I compile on my machine and install. I'll repull winnie's binaries to see whats up. This time I triple checked I was running on the right instance with:

pgr=# SELECT version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit
(1 row)


pgr=# SELECT postgis_full_version();
NOTICE:  Function postgis_topology_scripts_installed() not found. Is topology su
pport enabled and topology.sql installed?

                                            postgis_full_version


--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------------
 POSTGIS="2.2.0dev r13489" GEOS="3.5.0dev-CAPI-1.9.0 r4054" PROJ="Rel. 4.8.0, 6
March 2012" GDAL="GDAL 1.11.1, released 2014/09/24" LIBXML="2.7.8" LIBJSON="0.12
" (core procs from "2.2.0dev r13445" need upgrade) RASTER (raster procs from "2.
2.0dev r13445" need upgrade)
(1 row)


pgr=# SELECT * FROM pgr_version();
 version |       tag       | build |  hash   | branch  | boost
---------+-----------------+-------+---------+---------+--------
 2.0.0   | pgrouting-2.0.0 | 170   | 5cdd106 | develop | 1.53.0
(1 row)


pgr=# SELECT * FROM pgr_trsp('select * from parallel', 1, 4, false, true);
NOTICE:  Calling compute_trsp
NOTICE:  start turn_restrict_shortest_path

NOTICE:  columns: id 1 source 2 target 3 cost 4
NOTICE:  columns: reverse_cost cost 5
NOTICE:  Min vertex id: 1 , Max vid: 6
NOTICE:  Total 8 edge tuples
NOTICE:  Fetching restriction tuples

NOTICE:  Sql for restrictions is null.
NOTICE:  Total 0 restriction tuples
NOTICE:  Calling trsp_node_wrapper

NOTICE:  Message received from inside:
NOTICE:  XdB
NOTICE:  ret = 0

NOTICE:  *path_count = 4

NOTICE:  In finish, trying to disconnect from spi 0
NOTICE:  Ret is 0
NOTICE:  Total cost is: 4.000000
NOTICE:  Going to free path
 seq | id1 | id2 | cost
-----+-----+-----+------
   0 |   1 |   1 |    1
   1 |   2 |   2 |    2
   2 |   3 |   5 |    1
   3 |   4 |  -1 |    0
(4 rows)

and I get above.

@woodbri @dkastl would really help at this point if one of you could update the hash on develop so I can tell if I'm testing the same thing and winnie is not getting a stale binary from somewhere.

[woodbri]

Just bumped the VERSION hash

[robe2]

Thanks hash changed when I pulled winnies's build but gives broken answer. So going to compare systems next.

[robe2]

Okay I may be crazy, but it seems setting the debug on was what fixed it on my system. If I take it out, it doesn't work anymore. Perhaps a timing issue and the debug notice is slowing it down enough so it can finish.

[woodbri]

More likely turning on DEBUG is enabling more code to compile which is changing the order of things in memory, and somebody is overwriting memory somewhere. Could this be an issue like you can not pass relative pointers to a DLL?

At some point I'll run valgrind on trsp and see if that shows any memory read/write access errors. But I have my plate full at the moment.

[woodbri]

Then again I thought this used to work just fine on windows, but maybe not.

[sanak]

@robe2
I fixed GraphDefinition initialization bug, and it was merged to develop_2_1_0 by @cvvergara.
So, I think that your following temporary fix is not necessary anymore.
3edbc88

[sanak]

@cvvergara, @robe2
I think that the following is necessary.

git revert 3edbc88

[cvvergara]

Why? is it causing a problem?

[sanak]

#336 (comment)

We'll just have to make a note of that in docs until the issue is properly fixed.

Yes, missing GraphDefinition initialization caused this problem and I fixed it properly.

[cvvergara]

ok, its fixed with those initializations, but then the @robe2 temp fix, can be removed?

[sanak]

Yes, I think that it can be removed.
About master branch, I confirmed that it fixed the issue on my local ming64gcc48 environment by #403 which doesn't include temporary fix.

[sanak]

Sorry, again.
But, isn't the following necessary in Release 2.1.0 ?

git revert 3edbc88

3edbc88

[robe2]

@sanak I thought you just said your fixes to trsp made my hack not necessary anymore?

But let me check -- I broke something on winnie, so she's having trouble testing.

[robe2]

@sanak I talked with Vicky. She doesn't want to make any more changes to 2.1 and doesn't want to risk taking the hack out. So she wants to do it on 2.2. I'm fine with that. We can do it immediately after we release 2.1.

[sanak]

@robe2

I thought you just said your fixes to trsp made my hack not necessary anymore?

Yes.

@robe2, @cvvergara

I talked with Vicky. She doesn't want to make any more changes to 2.1 and doesn't want to risk taking the hack out. So she wants to do it on 2.2. I'm fine with that. We can do it immediately after we release 2.1.

Okay, no problem.
Thanks for confirmation!

[cvvergara]

TRSP might get a total rewrite on V2.3, so I repoened so we dont forget that this issue is not forgotten for testing

[dkastl]

What about opening a new issue instead with a reference to this one?
Might be easier to follow.

[robe2]

Yah I think that would be easier and people running 2.1 won't think the issue is not fixed.

[cvvergara]

Looks like it was fixed on V2.1, but the milestone for 2.1 is closed, So I will tag as fixed in develop and close it.
The label name will help find it by label.