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

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@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

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@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@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

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@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@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

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@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@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@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

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@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@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@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@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

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

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@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@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@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@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@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

>>

>

_______________________________________________

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Hello Espen,

my fault. I did not read FT != TF. Your sql updates are ok. Setting

reverse_cost will not have any effect for calculating a forward route.

Gr

Ralf

Am Montag 18 Oktober 2010 09:12:10 schrieb Espen Isaksen:

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@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@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@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@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@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

>>

>> _______________________________________________

>> 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

Ok, no problem. But that leaves the question still open of why it does

not work. Anyone have an idea?

Espen

On Mon, Oct 18, 2010 at 12:00 PM, Ralf Suhr <Ralf.Suhr@itc-halle.de> wrote:

Hello Espen,

my fault. I did not read FT != TF. Your sql updates are ok. Setting

reverse_cost will not have any effect for calculating a forward route.

Gr

Ralf

Am Montag 18 Oktober 2010 09:12:10 schrieb Espen Isaksen:

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@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@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@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@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@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

>>

>> _______________________________________________

>> 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

_______________________________________________

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Have you found any solution for this problem? I have the same problem with Navteq data.

/Henrik