Thank you for taking a look. For now you should drop this issue, and get back to working on your plan. I will try to do some more testing on my server and see if I can figure out what is happening here.
My server is running an outdated Debian lenny that I have not had time to update. It has 4GB memory 64 bit OS and is generally very stable, but as I said it is out dated so that might be the problem.
If you check in your test program and my csv file, I can try running that here and see what I get.
Hi Steve,
I could not reproduce the crashing bug in my pc. I have created the st
table from data as you instructed. Here is the summary:
routing=# \d st;
Table "public.st <http://public.st>"
Column | Type | Modifiers
----------+------------------+--------------------------------------------------
gid | integer | not null default
nextval('st_gid_seq'::regclass)
id | double precision |
source | double precision |
target | double precision |
cost | numeric |
rev_cost | numeric |
the_geom | geometry |
Indexes:
"st_pkey" PRIMARY KEY, btree (gid)
"st_the_geom_gist" gist (the_geom)
Check constraints:
"enforce_dims_the_geom" CHECK (st_ndims(the_geom) = 2)
"enforce_geotype_the_geom" CHECK (geometrytype(the_geom) =
'MULTILINESTRING'::text OR the_geom IS NULL)
"enforce_srid_the_geom" CHECK (st_srid(the_geom) = 4326)
The table has 41580 rows. Then first I run the the following query and
got the mentioned output
routing=# select * from bidir_dijkstra_shortest_path('select gid as id,
source::integer, target::integer, cost::double precision as cost,
rev_cost:: double precision as reverse_cost from st', 1187405, 1187508,
true, true);
vertex_id | edge_id | cost
-----------+---------+------------------
1187405 | 28874 | 11.3385436250298
1187406 | 28819 | 16.928515840577
1187508 | -1 | 0
(3 rows)
After that I ran your query, just changing some of the variables, like
gid in place of link_idand cost and rev_cost respectively in place of
cost_time and rcost_time respectively. This query also returned the
mentioned result without any problem.
routing=# select * from st, (select gid, the_geom from
bidir_dijkstra_shortest_path('select gid as id, source::integer,
target::integer, cost::double precision as cost, rev_cost:: double
precision as reverse_cost from st a', 1187405, 1187508, true, true), st
where edge_id = gid) as rt where st.gid = rt.gid;
gid | id | source | target | cost |
rev_cost |
the_geom | gid
| the_geom
-------+----------+---------+---------+------------------+------------------+--------------------------------------------------------------------------------------------------------------+-------+--------------------------------------------------------------------------------------------------------------
28819 | 25345248 | 1187508 | 1187406 | 16.928515840577 |
16.928515840577 |
0105000020E610000001000000010200000002000000B806B64AB038B4BFEF38454772C9494059A31EA2D11DB4BFBD5296218EC94940
| 28819 |
0105000020E610000001000000010200000002000000B806B64AB038B4BFEF38454772C9494059A31EA2D11DB4BFBD5296218EC94940
28874 | 25345111 | 1187405 | 1187406 | 11.3385436250298 |
11.3385436250298 |
0105000020E610000001000000010200000002000000F623456458C5B3BF44696FF085C9494059A31EA2D11DB4BFBD5296218EC94940
| 28874 |
0105000020E610000001000000010200000002000000F623456458C5B3BF44696FF085C9494059A31EA2D11DB4BFBD5296218EC94940
(2 rows)
I have run several other queries with success.
I am not sure what is causing your server crash. It will be very helpul
if you provide some more information on the server like memory etc. I am
running ubuntu 12.04 on a core i5 processor with 4GB memory. Another
thing may be helpful, running shortest_path instead of
bidir_dijkstra_shortest_path first. If it runs correct, then we are sure
that every other things are right with the query. Then just change the
shortest_path to bidir_dijkstra_shortest_path.
I am still trying to break it. Please let me know if there are other
ways to do it.
-Razequl
On Mon, Jul 2, 2012 at 6:51 PM, Razequl Islam <ziboncsedu@gmail.com
<mailto:ziboncsedu@gmail.com>> wrote:
Hi Steve,
I downloaded the csv file and used my test application. But it ran
fine and produced the following output:
1187405 | 25345111 | 11.338544
1187406 | 25345248 | 16.928516
1187508 | -1 | 0.000000
I ran some other queries on the graph but could not crash the
program. So I suspect the problem may lie in the wrapper classes. I
will create a table and run the query.
-Razequl
On Mon, Jul 2, 2012 at 10:25 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:
Argh! sorry my bad. Try:
http://imaptools.com:8080/dl/ test.tgz
<http://imaptools.com:8080/dl/test.tgz>
-Steve
On 7/1/2012 11:45 PM, Razequl Islam wrote:
Hi Steve,
I am trying to download the csv but ending up with 404 Not
Found error.
Please confirm the URL works. I am also getting the same
problem with
http://imaptools.com/dl/test. tgz
<http://imaptools.com/dl/test.tgz>
-Razequl
On Sun, Jul 1, 2012 at 7:37 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>
<mailto:woodbri@swoodbridge. com
<mailto:woodbri@swoodbridge.com>>> wrote:
Razqequl,
I have not looked into the reason, but my intuition it
that it may
be because this graph has about 50K edges so it will be
larger than
most anything that you generated by hand, and the edge
and node
numbers are very large because this is an extract from
a 10s of
million of edges graph. There were no error message
other than the
generic postgresql message the the server crashed. You
will probably
fine you have a segv in your test program.
I can download a zipped copy of the csv file. The first
row is the
column names.
http://imaptools.com/dl/bdsp- big-bug.zip
<http://imaptools.com/dl/bdsp- big-bug.zip
<http://imaptools.com/dl/bdsp-big-bug.zip>>
-Steve
On 7/1/2012 5:18 AM, Razequl Islam wrote:
Hi Steve,
Bad news 
As I mentioned, I already have a test application
to read from text
file, it will be very helpful if you send me a csv file
containing the
graph. Also please let me know if there is any
error message. I am
looking into my code for a possible reason.
-Razequl
On Sun, Jul 1, 2012 at 3:19 AM, Stephen Woodbridge
<woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>
<mailto:woodbri@swoodbridge. com
<mailto:woodbri@swoodbridge.com>>
<mailto:woodbri@swoodbridge
<mailto:woodbri@swoodbridge>. com
<mailto:woodbri@swoodbridge. com
<mailto:woodbri@swoodbridge.com>>>> wrote:
Hi Razequl,
I tried a larger test and it crashed the server.
You can test it like this:
# fetch a test file from my server
wget http://imaptools.com/dl/test. tgz
<http://imaptools.com/dl/test. tgz
<http://imaptools.com/dl/test. tgz
<http://imaptools.com/dl/test.tgz>>>
# extract the tarfile into directory test
tar xzf test.tgz
# load the file into your test database into
table "st"
shp2pgsql -s 4326 -c -D -I -N skip
test/bdsp-bug.shp st |
psql -U
user -h localhost mydatabase
# get into psql or pgadmin and run the following
psql -U user -h localhost mydatabase
SELECT * FROM st, (
SELECT gid,the_geom
FROM
bidir_dijkstra_shortest_path(
'SELECT link_id as id,
source::integer,
target::integer,
cost_time::double
precision as
cost ,
rcost_time as
reverse_cost
FROM st a',
1187405,
1187508,
true,
true
), st where edge_id = link_id
) as rt
WHERE st.gid=rt.gid;
This crashes my server!
If you want to write a testmain.cpp, I can
provide the
graph data in
a csv file that you could read in and pass to
your code
instead of
the query to get the data from table st.
-Steve
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
<mailto:pgrouting-dev@lists. osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>>
<mailto:pgrouting-dev@lists
<mailto:pgrouting-dev@lists>. osgeo.org <http://osgeo.org>
<mailto:pgrouting-dev@lists. osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>>>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/
mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/
mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev> > >
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
<mailto:pgrouting-dev@lists. osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/
mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev> >
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
<mailto:pgrouting-dev@lists. osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev> >
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
<mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev