[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