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@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@gmail.com>
>>
>> On Mon, Dec 20, 2010 at 11:11 AM, Daniel Kastl <daniel@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@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@lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>> >
>> >
>> >
>> > --
>> > Georepublic UG & Georepublic Japan
>> > eMail: daniel.kastl@georepublic.de
>> > Web: http://georepublic.de
>> >
>> > _______________________________________________
>> > Pgrouting-users mailing list
>> > Pgrouting-users@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>> >
>> >
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl@georepublic.de
> Web: http://georepublic.de
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
>
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
