Couple of bugs after pgr_nodeNetwork applying

[tezkz]

1)Need of casting "id::integer". The pgr_nodeNetwork function creates new "noded" table with "id" of bigint type, but SQL statement of many Routing Functions assumes "id" int4 type. Casting "id::integer" helps to solve this bug. For TRSP example: a) source_node/target_node syntax - SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_trsp('SELECT id::integer as id,source::integer,target::integer,cost::float FROM test', 10, 9, false, false); returns normal edge ids

seq	node	edge	cost
0	10	12	0.29335
1	8	10	0.2535
2	9	-1	0

but they contains strange values without casting of "id" to integer

seq	node	edge	cost
0	10	144356580	0.29335
1	8	144356308	0.2535
2	9	-1	0

b) source_edge/target_edge syntax - SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_trsp('SELECT id::integer,source::integer,target::integer,cost::float FROM test_noded', 12, 0.5, 9, 0.5, false, false); returns normal result

seq	node	edge	cost
0	-1	12	0.45335
1	7	10	0.6521
2	1	9	0

but error "Start id was not found" occurs without casting of "id" to integer

2. The pgr_nodeNetwork creates a lot of EMPTY GEOMETRY in new "noded" table.

[dkastl]

First all, thank you for reporting this issue!

For better understanding I have a few questions:

Regarding (1) you say that the node ID is of type bigint, which is correct (see https://github.com/pgRouting/pgrouting/blob/develop/src/common/sql/pgrouting_topology.sql#L534). Not correct is, that this node ID is the id of the routing function sql argument. The sql argument requires id, source, target, etc. from the network table. Correct is again that for the network table these must be of type integer.

Regarding (2) can you provide some simple example to reproduce this? This would help a lot.

[tezkz]

I had in mind "pgr_nodeNetwork" function. Sorry for my mistake. I've corrected the issue.

[cvvergara]

Main discussion in #419

[cvvergara]

Not working on pgr_nodeNetwork for version 3.0