[pgrouting-users] Shooting star problem

Espen Isaksen espen.isaksen at gmail.com
Thu Dec 23 05:18:45 EST 2010 

No problem, Christmas time is busy here as well :-)

Ok, I'll probably report a bug. Just want to test with another dataset
first, just in case there is something wrong with my road network. No
problem understanding that customer projects have priority.

Espen





On Tue, Dec 21, 2010 at 5:30 PM, Daniel Kastl <daniel at georepublic.de> wrote:
> 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
>
> _______________________________________________
> 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