[pgrouting-users] Oneway problem

Ricardo Bayley ricardo.bayley at gmail.com
Fri Oct 15 10:06:29 EDT 2010

```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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20101015/b7310348/attachment-0001.html
```