# [pgrouting-users] Oneway problem

Espen Isaksen espen.isaksen at gmail.com
Mon Oct 18 03:12:10 EDT 2010

```Ok, sorry for not being clear here(and my absence this weekend).

Oneway=FT means one way in the direction of the geometry, oneway=TF
means one way in the opposite direction of the geometry. A regular two
way road has a null value in the oneway column.

So I got three values in the oneway column, TF, FT and null.

For starters I set cost and reverse_cost equal to the length column as this:

update elveg set cost=length
update elveg set reverse_cost=length

Then I up the cost for oneway streets by setting the value of the cost
column higher where the one way street is the same direction as the
geometry and the reverse_column higher where the one way street is in
the opposite direction of the the geometry:

update elveg set cost=length+1000000 where oneway='FT' ;
update elveg set reverse_cost=length+1000000 where oneway='TF'

Sorry if I am completely misunderstanding this stuff, but I thought
this should be fairly easy.

Espen

On Fri, Oct 15, 2010 at 4:06 PM, Ricardo Bayley
<ricardo.bayley at gmail.com> wrote:
> Espen,
> I dont understand why you set both cost and reverse_cost to the same value ?
> Shouldn´t you be setting
> cost = length
> reverse_cost = length + 100000 ?
> (or the other way around depening on the one_way value)
> update elveg set cost= length where oneway='FT' ;
> update elveg set reverse_cost= length+1000000 where oneway='TF'
>
> Ricardo
>
> On Fri, Oct 15, 2010 at 10:54 AM, Espen Isaksen <espen.isaksen at gmail.com>
> wrote:
>>
>> 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
>> >>
>> >
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
>
```