<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hello<BR>
<BR>
I get different results on each run. Your result is one of them.<BR>
<BR>
Both the target_id and rule ids are edgeids refering to gid and should be correct. They originally referred to objid, but I remapped them to gid.<BR>
I will reduce the size of the network and send you new testdata.<BR>
<BR>
Regards<BR>
Espen<BR> <BR>
<DIV>
<DIV id=SkyDrivePlaceholder></DIV>> Date: Thu, 8 Mar 2012 09:21:12 -0500<BR>> From: woodbri@swoodbridge.com<BR>> To: espoern@hotmail.com; pgrouting-dev@lists.osgeo.org<BR>> Subject: Re: [pgrouting-dev] pgRouting and the Shortest Path Shooting Star algorithm<BR>> <BR>> Espen,<BR>> <BR>> I have CC the list as there might be helpful information to others in my <BR>> response.<BR>> <BR>> I get the following results on my Linux system. Is this what you are <BR>> getting on your system?<BR>> <BR>> trsp_bug=# SELECT kollektivnett32.objid::integer, qry1.*<BR>> FROM turn_restrict_shortest_path(<BR>> 'SELECT gid AS id,<BR>> source::int4,<BR>> target::int4,<BR>> minutes::double precision AS cost,<BR>> rminutes::double precision AS reverse_cost<BR>> FROM kollektivnett32',<BR>> 17914,<BR>> 24470,<BR>> true,<BR>> true,<BR>> 'SELECT to_cost,<BR>> gid AS target_id,<BR>> rule AS via_path<BR>> FROM kollektivnett32_turns<BR>> WHERE costtype=''V''') qry1<BR>> inner join kollektivnett32<BR>> on qry1.edge_id=kollektivnett32.gid;<BR>> <BR>> objid | vertex_id | edge_id | cost<BR>> -------+-----------+---------+-------------------<BR>> 39510 | 17914 | 39553 | 1.22921517354843<BR>> 39503 | 19542 | 39546 | 1.16385126125265<BR>> 39502 | 15062 | 39545 | 1.13463764875839<BR>> 39501 | 10238 | 39544 | 0.894134798291999<BR>> 39495 | 19538 | 39538 | 0.866380394768565<BR>> 39496 | 19468 | 39539 | 0.933687082563116<BR>> 39497 | 19470 | 39540 | 0.657732599215612<BR>> 39498 | 19473 | 39541 | 0.908336115840503<BR>> 39499 | 19452 | 39542 | 0.375975675882557<BR>> 39500 | 9999 | 39543 | 0.467548379399679<BR>> 39493 | 18169 | 39536 | 0.722558560770379<BR>> 39492 | 19474 | 39535 | 0.359215445372181<BR>> 39491 | 18166 | 39534 | 0.372316300710597<BR>> 39490 | 6151 | 39533 | 0.7529314841121<BR>> 39514 | 14128 | 39557 | 0.247611717608335<BR>> 39513 | 2820 | 39556 | 0.642005590638696<BR>> 39494 | 19535 | 39537 | 1.08148812344578<BR>> 39475 | 19518 | 39518 | 0.985412403126148<BR>> 39476 | 19519 | 39519 | 1.00870667860245<BR>> 39477 | 19524 | 39520 | 1.10356478488934<BR>> 39478 | 7347 | 39521 | 2.31489365914156<BR>> 2912 | 19418 | 2630 | 0.710630767866117<BR>> (22 rows)<BR>> <BR>> Ok, I have a couple of observations:<BR>> <BR>> 1. the route does not get to the destination node which seems like that <BR>> might indicate a bug<BR>> <BR>> 2. I see you are using "rule AS via_path", is rule formatted the way you <BR>> would pass it to shooting_star? If so this is wrong. I unfortunately <BR>> implemented via_path to be a list of edges in the reverse order of rule.<BR>> <BR>> IF for RULE:<BR>> target_id: 1, rule: 2,3,4,5<BR>> <BR>> THEN for via_path<BR>> target_id: 1, via_path: 5,4,3,2<BR>> <BR>> Since all your restrictions only involve a single edge this does not <BR>> matter. So moving on to the next potential problem. Consistency of edge <BR>> ids could be a problem.<BR>> <BR>> For example, in the kollektivnett32_turns table what are the target_id <BR>> and rule ids? These should be the edge ids not the node ids and you <BR>> using: gid, objectid_1, objectid, or some other field for these values?<BR>> <BR>> When you select your edges in the first query you have "gid as id", you <BR>> have to match the column used in the kollektivnett32_turns table as the <BR>> edge id to define the id in the first query. So if the <BR>> kollektivnett32_turns uses objectid values your first query needs to be <BR>> "objectid::integer as id"<BR>> <BR>> Also it would be good it you can reduce the problem to a simple 10-20 <BR>> node/edge graph that is easier to debug and understand. Most cases can <BR>> be demonstrated using a simple graph like:<BR>> <BR>> o o<BR>> | |<BR>> | |<BR>> o---------o---o--------o<BR>> | | | |<BR>> | | | |<BR>> o-------o---------o---o--------o---------o<BR>> | | | |<BR>> | | | |<BR>> o---------o---o--------o<BR>> | |<BR>> | |<BR>> o o<BR>> <BR>> Just label the nodes and the edges, and set up the restrictions, then <BR>> you can run simple tests to verify that it works as expected on simple <BR>> cases.<BR>> <BR>> -Steve<BR>> <BR>> On 3/8/2012 5:12 AM, Espen O wrote:<BR>> > Hi<BR>> ><BR>> > Here is our testdata http://dl.dropbox.com/u/525315/example.rar<BR>> ><BR>> > It contains the following:<BR>> ><BR>> > *File *<BR>> ><BR>> > <BR>> ><BR>> > *Description *<BR>> ><BR>> > Kollektivnett32.sql<BR>> ><BR>> > <BR>> ><BR>> > Network table<BR>> ><BR>> > kollektivnett32_turns.sql<BR>> ><BR>> > <BR>> ><BR>> > Turn restrictions table<BR>> ><BR>> > example_query.sql<BR>> ><BR>> > <BR>> ><BR>> > Example query from node 17914 to 24470<BR>> ><BR>> > expected_route.jpg<BR>> ><BR>> > <BR>> ><BR>> > Image of expected result (24,2 minutes including turn costs)<BR>> ><BR>> > Regards Espen<BR>> ><BR>> ><BR>> > > Date: Wed, 7 Mar 2012 10:43:50 -0500<BR>> > > From: woodbri@swoodbridge.com<BR>> > > To: pgrouting-dev@lists.osgeo.org<BR>> > > Subject: Re: [pgrouting-dev] pgRouting and the Shortest Path Shooting<BR>> > Star algorithm<BR>> > ><BR>> > > On 3/7/2012 8:39 AM, Espen O wrote:<BR>> > > > Hi<BR>> > > ><BR>> > > > We are very interested in version 1.03/1.05 of pgRouting and the<BR>> > > > Shortest Path Shooting Star algorithm. However, there is a problem with<BR>> > > > way restrictions in shooting star if there is more than one rule for an<BR>> > > > edge. It also doesn’t seem to take into account the reverse cost.<BR>> > We are<BR>> > > > interested in fixing these bugs.<BR>> > > ><BR>> > > > Stephen Woodbridge has developed an alternative<BR>> > > > “turn_restricted_shortest_path” which is very promising. We have tested<BR>> > > > the Windows version compiled by Sanak (2012/03/04), but it is very<BR>> > > > unstable and seems to return inconsistent answers when running the same<BR>> > > > input data multiple times.<BR>> > ><BR>> > > Hi Espen,<BR>> > ><BR>> > > I would like to get a copy of you graph and queries that return<BR>> > > inconsistent results. I have not seen this behavior and I think I need<BR>> > > to understand what is happening. If we have a bug I want to get it fixed.<BR>> > ><BR>> > > Can you dump your database something like:<BR>> > ><BR>> > > pg_dump -fP -Z0 -f mydump.sql.gz -t <table_1> -t <table_2> ... -U <user><BR>> > > -h localhost <mydatabase><BR>> > ><BR>> > > and email that and the queries you are running. I would be greatly<BR>> > > appreciated and I will analyze it and get any bugs fixed that we need to.<BR>> > ><BR>> > > Thanks,<BR>> > > -Steve<BR>> > ><BR>> > > > We are working on Windows 2008 server 32 bit, not Linux. Is there<BR>> > anyone<BR>> > > > who can give us the detailed setup for compiling on Windows (pgRouting<BR>> > > > 1.03 2010/01/30 by Martin is the most stable we have tested) so we can<BR>> > > > start to debug the source code? We have tried Sanaks recipe<BR>> > > > (/sanak/pgrouting/blob/master/BUILD.msvc90), but we get a lot of errors<BR>> > > > (Microsoft Visual C++ 2008 Express Edition and the required libraries).<BR>> > > ><BR>> > > > Regards<BR>> > > > Espen<BR>> > > ><BR>> > > ><BR>> > > > _______________________________________________<BR>> > > > pgrouting-dev mailing list<BR>> > > > pgrouting-dev@lists.osgeo.org<BR>> > > > http://lists.osgeo.org/mailman/listinfo/pgrouting-dev<BR>> > ><BR>> > > _______________________________________________<BR>> > > pgrouting-dev mailing list<BR>> > > pgrouting-dev@lists.osgeo.org<BR>> > > http://lists.osgeo.org/mailman/listinfo/pgrouting-dev<BR>> <BR></DIV> </div></body>
</html>