[pgrouting-dev] BDSP Crashes
Razequl Islam
ziboncsedu at gmail.com
Fri Jul 6 10:33:40 PDT 2012
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"
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 at 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 at 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 at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at 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 at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>
>>> >
>>> <mailto:woodbri at swoodbridge. com
>>>
>>> <mailto:woodbri at swoodbridge.**com <woodbri at 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 at lists.osgeo.org
>>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at lists.osgeo.org>
>>> >
>>> <mailto:pgrouting-dev at lists. osgeo.org
>>>
>>> <mailto:pgrouting-dev at lists.**osgeo.org<pgrouting-dev at 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 at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>>> osgeo.org <pgrouting-dev at 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 at lists.osgeo.org <mailto:pgrouting-dev at lists.**
>>> osgeo.org <pgrouting-dev at 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 at 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 at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120706/a2f84d8c/attachment-0001.html>
More information about the pgrouting-dev
mailing list