[pgrouting-users] Shooting star problem

Daniel Kastl daniel at georepublic.de
Mon Dec 20 09:25:18 EST 2010 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20101220/d1f67921/attachment.html

More information about the Pgrouting-users mailing list