[pgrouting-users] Shooting star problem

[Espen Isaksen]

Hi Daniel!

I tried using the shootingstar_sp_smart wrapper function, but there
seems to be some problems here as well. Running it on a network with
cost=reverse_cost=st_length(the_geom) is fine from 157333 to 157165.
However, once I bump the value of the cost on 157332 to 100000, then
the route avoids 157332 in both directions. And setting reverse_cost
makes no difference at all.

Is this the correct way to run the query:

SELECT gid
FROM shootingstar_sp_smart(
'elveg',
261728.74707,
6648944.62891,
261852.04834,
6649001.15576,
10000, 'cost', true, true);

   gid
---------
 1255980
 1255977
  157166
  157167
  155335
  158776
 1255978
 1255981
(8 rows)



SELECT gid
FROM shootingstar_sp_smart(
'elveg',
261852.04834,
6649001.15576,
261728.74707,
6648944.62891,
10000, 'cost', true, true);

   gid
---------
 1255980
 1255976
  158776
  155335
  157167
  157166
 1255979
 1255981
(8 rows)


Espen



On Mon, Dec 20, 2010 at 2:39 PM, Daniel Kastl <daniel at georepublic.de> wrote:
> Hi Espen,
> Have you tried to route with more than two road links, lets say from 157332
> to 157334?
> If you try both directions there, does it take two different routes as well?
> The starting points/edges are somtimes the ones, where issues are likely to
> occur.
> Which version of pgRouting do you use?
> I mostly use this wrapper function, that usually worked well for me:
> https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql
> It takes X/Y of start and end point as parameter, looks for the nearest edge
> and then splits it into two substrings and selects the right one.
> Maybe this wrapper cares better about special cases, because I haven't had a
> strange route with it.
> Daniel
>
> 2010/12/20 Espen Isaksen <espen.isaksen at gmail.com>
>>
>> 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
>> >
>> >
>> _______________________________________________
>> 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
>
>