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