[pgrouting-users] Shooting star problem
Daniel Kastl
daniel at georepublic.de
Tue Dec 21 11:30:52 EST 2010
Hi Espen,
Sorry for the late reply. The combination of Christmas and Japanese New Year
makes this time very busy.
So if it's still the case with 1.05 it's probably a bug. The best place to
report this would be in the bug tracker
https://github.com/pgRouting/pgrouting/issues. As soon as someone has a time
to tackle the problem, we will take a look. I hope you understand that
customer projects usually have priority, but we won't forget about it if
it's in the Github issue tracker.
If you could write a summary of the problem there, that would be great.
Otherwise I will try to add it.
Regarding wrapper functions:
Initially wrapper functions weren't supposed to be part of the source code.
So while reducing the number of parameters and do some internal calculation,
it became easier to use, but also some parameters weren't possible to change
anymore.
I must admit that wrappers might need some cleanup (parameters and function
names), but at least there should be a wrapper with bounding box for each
algorithm as far as I remember.
Shooting_star_smart wrapper we put into a repository called "contrib". It
was quite difficult to think about all possibilities a route could take to
select the right substrings. So there might be cases we forgot about.
You're free to take the wrappers as an example and change and extend them to
your needs. If you can find a possibility to improve them, you're very
welcome to share with everyone. In general we hope to collect more useful
wrapper functions in the "contrib" repository.
Daniel
2010/12/21 Espen Isaksen <espen.isaksen at gmail.com>
> Just a quick note that upgrading to 1.05 did not resolve my problem.
>
> 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
> >
> >
> _______________________________________________
> 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/20101222/afe037c0/attachment-0001.html
More information about the Pgrouting-users
mailing list