[pgrouting-users] Oneway problem

[Espen Isaksen]

I'm sorry Ralf, I do not understand what you mean here. I'll give some
more description of the data to make it more clear from my side.

This is the edge being a one way street:

  gid   | target | source |  cost   | reverse_cost | oneway
--------+--------+--------+---------+--------------+--------
 157332 | 714814 | 714597 | 1 | 1000062 | TF


>From my understanding I should be able to create a route in the
direction of the edge, but the reverse_cost should come into play when
I route the opposite direction? An thus make the route go around.

And the direction is the direction of the geometry right?

Espen






On Fri, Oct 15, 2010 at 2:37 PM, Ralf Suhr <Ralf.Suhr at itc-halle.de> wrote:
> If the edge in database have the same start- and endnode you need only update
> the reverse_cost column.
>
> In case the direction (start-, endnode) are in reversed order the update will
> only on cost column.
>
> Am Freitag 15 Oktober 2010 14:23:16 schrieben Sie:
>> But I think I have understood this correctly then. That is why I did this:
>>
>> update elveg set cost=length+1000000 where oneway='FT' ;
>> update elveg set reverse_cost=length+1000000 where oneway='TF'
>>
>> This should do exactly what you explained.
>>
>> However, I wonder if this should concern me?
>> http://pgrouting.postlbs.org/ticket/212
>>
>> Espen
>>
>> On Fri, Oct 15, 2010 at 2:08 PM, Ralf Suhr <Ralf.Suhr at itc-halle.de> wrote:
>> > Hi Espen,
>> >
>> > one edge is defined by to nodes in pgrouting.
>> > You need to match the definition of oneway street to the edge.
>> >
>> > If the direction of edge and oneway street are the same, then only the
>> > reverse_cost must be higher. In case direction from edge are opposite to
>> > oneway street, the reverse_cost become the the cost for driving the
>> > oneway street.
>> >
>> > Gr
>> > Ralf
>> >
>> > Am Freitag 15 Oktober 2010 13:34:47 schrieb Espen Isaksen:
>> >> Hi!
>> >>
>> >> I have a feeling there is something I do not understand concerning
>> >> routing with oneway streets, but after hours of testing and googling I
>> >> have to ask you guys on this list.
>> >>
>> >> I have a street network for Norway in my database and I have added the
>> >> columns cost and reverse_cost. I have initially set both columns to
>> >> the value of the length of the geometry.
>> >>
>> >> Then I updated cost and reverse cost by this:
>> >>
>> >> update elveg set cost=length+1000000 where oneway='FT' ;
>> >> update elveg set reverse_cost=length+1000000 where oneway='TF' ;
>> >>
>> >> I have this sql running shooting star. The sql is from the FOSS4G
>> >> workshop:
>> >>
>> >> SELECT rt.gid, ST_AsGeoJSON(rt.the_geom) AS geojson,
>> >> length(rt.the_geom) AS length, elveg.gid
>> >> FROM elveg,
>> >> (SELECT gid, the_geom
>> >> FROM shootingstar_sp(
>> >>                         'elveg',
>> >>                         157334,
>> >>                         157165,
>> >>                         10000, 'cost', true, true)
>> >>                      ) as rt
>> >> WHERE elveg.gid=rt.gid
>> >>
>> >>
>> >> What happens is that if I set the cost column high, the route will not
>> >> travel on this road in both directions. And whatever I set
>> >> reverse_cost, there is no changes to the route.
>> >>
>> >> Do I need to explain pgrouting to use the reverse_cost column? And why
>> >> is the cost column working both directions?
>> >>
>> >> Espen
>> >> _______________________________________________
>> >> 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
>>
>