[pgrouting-users] Shooting star problem

[Daniel Kastl]

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