[pgrouting-users] Shooting star problem

[Espen Isaksen]

On Mon, Dec 20, 2010 at 11:11 AM, Daniel Kastl <daniel at georepublic.de> wrote:
> Hi Espen,
> Your projection unit is "meter", I guess. So if you decrease your bounding
> box to 10, then, there are no other edges in your select than the two you
> want to get as a result.

Yes that is understandable. Just hoped it would not jump to a
different "shortest path" when I increased the bounding box :-)


> But thank you for trying this, because it shows, that your result passes one
> link twice. Could you find out, if the cost of passing edge 157333 twice
> would be higher than taking the "long" way?

The cost of 15733 is 104.8033 so passing twice would be 209.6066 and
the cost of going around is 229.675.

If I rearrange the query and do not use the wrapper function I get this result:

routing=# SELECT * FROM shortest_path_shooting_star('SELECT gid as id,
source, target, cost, reverse_cost,x1, y1,x2, y2, rule, to_cost FROM
elveg order by id',157333,157332,true,true);

 vertex_id | edge_id |       cost
-----------+---------+------------------
    269628 |  157333 |         104.8033
    269630 |  159163 |          62.3978
    266068 |  155337 |          75.4899
    256213 |  155336 |          29.7317
    266065 |  158776 |          62.0563
    269628 |  157332 | 61.7253486704361
(6 rows)


Espen



> Then the search result would be correct, but of course trying to pass one
> edge twice wouldn't be OK.
> Thank you for reporting this!
> Daniel
>
> 2010/12/20 Espen Isaksen <espen.isaksen at gmail.com>
>>
>> Hi!
>>
>> I am running the following query:
>>
>> SELECT gid
>> FROM shootingstar_sp('elveg',157332,157333,100, 'cost', true, true);
>>
>> and I get:
>>
>>  gid
>> --------
>>  157332
>>  157333
>> (2 rows)
>>
>>
>> which seems correct. Now if i flip the direction with the this query:
>>
>> SELECT gid
>> FROM shootingstar_sp('elveg',157333,157332,100, 'cost', true, true)
>>
>> then I get:
>>
>>  gid
>> --------
>>  157333
>>  159163
>>  155337
>>  155336
>>  158776
>>  157332
>> (6 rows)
>>
>> which is not correct. There should not be any extra costs on the edges:
>>
>>  gid   |       cost       |   reverse_cost   | to_cost | rule
>> --------+------------------+------------------+---------+------
>>  157332 | 61.7253486704361 | 61.7253486704361 |         |
>>  157333 |         104.8033 |         104.8033 |         |
>> (2 rows)
>>
>>
>> >From my understanding I should get 2 rows in both queries. Am I
>> missing something here?
>>
>> If I decrease the bounding box in the second query to 10, then I get
>> this result:
>>
>>  gid
>> --------
>>  157333
>>  157333
>>  157332
>> (3 rows)
>>
>> I thought I should get the same result for a larger bounding box as
>> long as the shortest path(least cost) is within the smallest bounding
>> box?
>>
>> Image of the road network can be seen here:
>> http://dl.dropbox.com/u/8829/road_network.png
>>
>> Espen
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de
> Web: http://georepublic.de
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
>