[pgrouting-users] Shooting star problem

Espen Isaksen espen.isaksen at gmail.com
Mon Dec 20 10:04:42 EST 2010 

No, we are using it on Linux so we'll try that.

I have tested shootingstar_sp_smart now and that solves my problem.
However, there seems to be some new problems with it regarding oneway
streets, but I have to test that a bit more tomorrow.

Thanks for your help!

Espen



On Mon, Dec 20, 2010 at 3:25 PM, Daniel Kastl <daniel at georepublic.de> wrote:
> Hi Espen,
> Do you use pgRouting on Windows?
> Otherwise I would recommend you to try 1.05, because several bugs have been
> fixed since then.
> Daniel
>
>
> 2010/12/20 Espen Isaksen <espen.isaksen at gmail.com>
>>
>> Hi!
>>
>> I am running pgrouting 1.03 at the moment.
>>
>> I tried running from 157334 to 157332 with two different bounding
>> boxes. Same problem as you see below:
>>
>> routing=# SELECT gid
>> FROM shootingstar_sp('elveg',157334,157332,1000, 'cost', true, true);
>>  gid
>> --------
>>  157334
>>  161375
>>  155338
>>  159163
>>  157333
>>  157332
>> (6 rows)
>>
>> routing=# SELECT gid
>> FROM shootingstar_sp('elveg',157334,157332,10, 'cost', true, true);
>>  gid
>> --------
>>  157334
>>  157334
>>  157333
>>  157332
>> (4 rows)
>>
>> Actually now it accepts running directly from 157333 to 157332 when
>> running 1000 m as bounding box, but it does not(as shown in my first
>> post) accept it if I start running from 157333 instead of 157334. So
>> the problem seems to be that the algorithm does not let me run
>> directly from my starting edge to the nearest edge in the direction of
>> the shortest path.
>>
>> I'll check out the other wrapper functions and tell you how it went.
>>
>> Thanks,
>> 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
>> >
>> >
>> _______________________________________________
>> 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
>
>

More information about the Pgrouting-users mailing list