[pgrouting-users] Shortest Path TRSP

Hi,

I am trying to use trsp shortest path function, but get a "Source Not Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
     'SELECT id_tron as id, source::integer, target::integer,
         cost::double precision as cost, rev_cost::double precision as reverse_cost FROM reseau_global',
     15326,
     8756,
     true,
     'SELECT to_cost::double precision, target_id::integer, via_path::text FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my turn restriction table.
In the latter, target_id column contains destination edges ids and via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

--
Christophe

Hi

The message "Source not Found" says that trsp
has not found the source node in the table reseau_global
Are you sure there is a node 15326?

Regards

max

On Mon, 27 Feb 2012 22:42:04 +0100
"Christophe Damour (SIGéal)" <sigeal@sigeal.com> wrote:

Hi,

I am trying to use trsp shortest path function, but get a "Source Not
Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
     'SELECT id_tron as id, source::integer, target::integer,
         cost::double precision as cost, rev_cost::double precision
as reverse_cost FROM reseau_global',
     15326,
     8756,
     true,
     true,
     'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my turn
restriction table.
In the latter, target_id column contains destination edges ids and
via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

Hi again

Ok this is strange. Since the soure vertex is already
checked before the trsp is called. The message you
described comes directly from the C++ impl. of trsp
where it is checked again

Does the values of your source and target columns start from 0?
Since if this is not the case some "renumbering" is done internally
Maybe there is a bug.

Regards

max

On Mon, 27 Feb 2012 22:55:22 +0100
Max Weninger <max.weninger@gmail.com> wrote:

Hi

The message "Source not Found" says that trsp
has not found the source node in the table reseau_global
Are you sure there is a node 15326?

Regards

max

On Mon, 27 Feb 2012 22:42:04 +0100
"Christophe Damour (SIGéal)" <sigeal@sigeal.com> wrote:

> Hi,
>
> I am trying to use trsp shortest path function, but get a "Source
> Not Found" error.
> Here is my query :
> SELECT edge_id FROM turn_restrict_shortest_path(
> 'SELECT id_tron as id, source::integer, target::integer,
> cost::double precision as cost, rev_cost::double precision
> as reverse_cost FROM reseau_global',
> 15326,
> 8756,
> true,
> true,
> 'SELECT to_cost::double precision, target_id::integer,
> via_path::text FROM reseau_global_rest'
> ), reseau_global
> WHERE edge_id = id_tron;
>
> reseau_global is my network table, and reseau_global_rest is my
> turn restriction table.
> In the latter, target_id column contains destination edges ids and
> via_path a list of forbidden origin edges.
>
> What am I doing wrong ?
>
> Thank for any hints,
>

On 2/27/2012 4:42 PM, "Christophe Damour (SIGéal)" wrote:

Hi,

I am trying to use trsp shortest path function, but get a "Source Not
Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
'SELECT id_tron as id, source::integer, target::integer,
cost::double precision as cost, rev_cost::double precision as
reverse_cost FROM reseau_global',
15326,
8756,
true,
'SELECT to_cost::double precision, target_id::integer, via_path::text
FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my turn
restriction table.
In the latter, target_id column contains destination edges ids and
via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

Typically this means that you are probably entering edge_ids for source and target and not node_ids.

Also, there is another version of the API that does take edge_ids for the start and end of the route rather than node_ids. You would call it like this:

SELECT edge_id FROM turn_restrict_shortest_path(
  'SELECT id_tron as id, source::integer, target::integer,
  cost::double precision as cost, rev_cost::double precision as
  reverse_cost FROM reseau_global',
  15326, -- start edge_id
  0.5. -- percent along start edge
  8756, -- end edge_id
  0.5 -- percent along end edge
  true,
  'SELECT to_cost::double precision, target_id::integer, via_path::text
  FROM reseau_global_rest'
  ), reseau_global
  WHERE edge_id = id_tron;

Using the edge + percent is better because it allow you to take into account restrictions and onewayness of the start and end edges that can not be done with the version you are using. This was a recent update to git so you might want to pull an updated versions.

-Steve W

If you think it is a bug, I'm happy to take a look at it, but ideally you should try to reduce the problem to a small graph that is reproducable.

-Steve

On 2/27/2012 5:01 PM, Max Weninger wrote:

Hi again

Ok this is strange. Since the soure vertex is already
checked before the trsp is called. The message you
described comes directly from the C++ impl. of trsp
where it is checked again

Does the values of your source and target columns start from 0?
Since if this is not the case some "renumbering" is done internally
Maybe there is a bug.

Regards

max

On Mon, 27 Feb 2012 22:55:22 +0100
Max Weninger<max.weninger@gmail.com> wrote:

Hi

The message "Source not Found" says that trsp
has not found the source node in the table reseau_global
Are you sure there is a node 15326?

Regards

max

On Mon, 27 Feb 2012 22:42:04 +0100
"Christophe Damour (SIGéal)"<sigeal@sigeal.com> wrote:

Hi,

I am trying to use trsp shortest path function, but get a "Source
Not Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
      'SELECT id_tron as id, source::integer, target::integer,
          cost::double precision as cost, rev_cost::double precision
as reverse_cost FROM reseau_global',
      15326,
      8756,
      true,
      'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my
turn restriction table.
In the latter, target_id column contains destination edges ids and
via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Hi

Just noticed this change.

Great! - Now I can remove some code
where I did something similiar :slight_smile:

Regards

max

On Mon, 27 Feb 2012 17:03:11 -0500
Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Also, there is another version of the API that does take edge_ids for
the start and end of the route rather than node_ids. You would call
it like this:
...

Using the edge + percent is better because it allow you to take into
account restrictions and onewayness of the start and end edges that
can not be done with the version you are using. This was a recent
update to git so you might want to pull an updated versions.

Hi,

Thank you very much for all the helpfull answers...
I finally worked it out by casting id_tron to integer (id_tron::integer as id) in the query passed to turn_restrict_shortest_path function.
(type of id_tron column is numeric...).
May this should raise an error message ?

Another question : I am testing this on a vps running Ubuntu Natty, but my development box is a windows 7 64 one.
Is it possible to get pgRouting trsp branch binaries for windows (compiling for windows seems somewhat complicated) ?

Kind regards,

--
Christophe

Le 27/02/2012 23:07, Stephen Woodbridge a écrit :

If you think it is a bug, I'm happy to take a look at it, but ideally you should try to reduce the problem to a small graph that is reproducable.

-Steve

On 2/27/2012 5:01 PM, Max Weninger wrote:

Hi again

Ok this is strange. Since the soure vertex is already
checked before the trsp is called. The message you
described comes directly from the C++ impl. of trsp
where it is checked again

Does the values of your source and target columns start from 0?
Since if this is not the case some "renumbering" is done internally
Maybe there is a bug.

Regards

max

On Mon, 27 Feb 2012 22:55:22 +0100
Max Weninger<max.weninger@gmail.com> wrote:

Hi

The message "Source not Found" says that trsp
has not found the source node in the table reseau_global
Are you sure there is a node 15326?

Regards

max

On Mon, 27 Feb 2012 22:42:04 +0100
"Christophe Damour (SIGéal)"<sigeal@sigeal.com> wrote:

Hi,

I am trying to use trsp shortest path function, but get a "Source
Not Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
      'SELECT id_tron as id, source::integer, target::integer,
          cost::double precision as cost, rev_cost::double precision
as reverse_cost FROM reseau_global',
      15326,
      8756,
      true,
      'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my
turn restriction table.
In the latter, target_id column contains destination edges ids and
via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

_______________________________________________
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

Hi

Is there any documantation available how to use the
startPos and endPos parameters - for the new "edge based" trsp API?

...

  0.5. -- percent along start edge
  0.5 -- percent along end edge

...

How to interpret those values?

Thanks

max

On Mon, 27 Feb 2012 17:03:11 -0500
Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

On 2/27/2012 4:42 PM, "Christophe Damour (SIGéal)" wrote:
> Hi,
>
> I am trying to use trsp shortest path function, but get a "Source
> Not Found" error.
> Here is my query :
> SELECT edge_id FROM turn_restrict_shortest_path(
> 'SELECT id_tron as id, source::integer, target::integer,
> cost::double precision as cost, rev_cost::double precision as
> reverse_cost FROM reseau_global',
> 15326,
> 8756,
> true,
> true,
> 'SELECT to_cost::double precision, target_id::integer,
> via_path::text FROM reseau_global_rest'
> ), reseau_global
> WHERE edge_id = id_tron;
>
> reseau_global is my network table, and reseau_global_rest is my turn
> restriction table.
> In the latter, target_id column contains destination edges ids and
> via_path a list of forbidden origin edges.
>
> What am I doing wrong ?
>
> Thank for any hints,
>

Typically this means that you are probably entering edge_ids for
source and target and not node_ids.

Also, there is another version of the API that does take edge_ids for
the start and end of the route rather than node_ids. You would call
it like this:

SELECT edge_id FROM turn_restrict_shortest_path(
  'SELECT id_tron as id, source::integer, target::integer,
  cost::double precision as cost, rev_cost::double precision as
  reverse_cost FROM reseau_global',
  15326, -- start edge_id
  0.5. -- percent along start edge
  8756, -- end edge_id
  0.5 -- percent along end edge
  true,
  true,
  'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
  ), reseau_global
  WHERE edge_id = id_tron;

Using the edge + percent is better because it allow you to take into
account restrictions and onewayness of the start and end edges that
can not be done with the version you are using. This was a recent
update to git so you might want to pull an updated versions.

-Steve W
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

The percentage is along the line in the direction it is defined in the database. The start point is 0.0 and the end point of the line is 1.0. So if you use ST_Line_Locate_Point() [1] the return is appropriate for percent along edge.

-Steve

[1] http://www.postgis.org/documentation/manual-1.5/ST_Line_Locate_Point.html

On 2/28/2012 9:03 AM, Max Weninger wrote:

Hi

Is there any documantation available how to use the
startPos and endPos parameters - for the new "edge based" trsp API?

...

   0.5. -- percent along start edge
   0.5 -- percent along end edge

...

How to interpret those values?

Thanks

max

On Mon, 27 Feb 2012 17:03:11 -0500
Stephen Woodbridge<woodbri@swoodbridge.com> wrote:

On 2/27/2012 4:42 PM, "Christophe Damour (SIGéal)" wrote:

Hi,

I am trying to use trsp shortest path function, but get a "Source
Not Found" error.
Here is my query :
SELECT edge_id FROM turn_restrict_shortest_path(
'SELECT id_tron as id, source::integer, target::integer,
cost::double precision as cost, rev_cost::double precision as
reverse_cost FROM reseau_global',
15326,
8756,
true,
'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
), reseau_global
WHERE edge_id = id_tron;

reseau_global is my network table, and reseau_global_rest is my turn
restriction table.
In the latter, target_id column contains destination edges ids and
via_path a list of forbidden origin edges.

What am I doing wrong ?

Thank for any hints,

Typically this means that you are probably entering edge_ids for
source and target and not node_ids.

Also, there is another version of the API that does take edge_ids for
the start and end of the route rather than node_ids. You would call
it like this:

SELECT edge_id FROM turn_restrict_shortest_path(
   'SELECT id_tron as id, source::integer, target::integer,
   cost::double precision as cost, rev_cost::double precision as
   reverse_cost FROM reseau_global',
   15326, -- start edge_id
   0.5. -- percent along start edge
   8756, -- end edge_id
   0.5 -- percent along end edge
   true,
   'SELECT to_cost::double precision, target_id::integer,
via_path::text FROM reseau_global_rest'
   ), reseau_global
   WHERE edge_id = id_tron;

Using the edge + percent is better because it allow you to take into
account restrictions and onewayness of the start and end edges that
can not be done with the version you are using. This was a recent
update to git so you might want to pull an updated versions.

-Steve W
_______________________________________________
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

Hi

Thanks for the explanation - now it make sense :slight_smile:
And the new "version" works great

Before I solved all those "special" cases in
"user space" by selecting source or target nodes and
also adding edges if required

Now since this is solved in the trsp my code becomes
much easier and clearer.

Regards

max

On Tue, 28 Feb 2012 09:15:23 -0500
Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

The percentage is along the line in the direction it is defined in
the database. The start point is 0.0 and the end point of the line is
1.0. So if you use ST_Line_Locate_Point() [1] the return is
appropriate for percent along edge.

-Steve

[1]
http://www.postgis.org/documentation/manual-1.5/ST_Line_Locate_Point.html

On 2/28/2012 9:03 AM, Max Weninger wrote:
> Hi
>
> Is there any documantation available how to use the
> startPos and endPos parameters - for the new "edge based" trsp API?
>
> ...
>> 0.5. -- percent along start edge
>> 0.5 -- percent along end edge
> ...
>
> How to interpret those values?
>
> Thanks
>
> max
>
> On Mon, 27 Feb 2012 17:03:11 -0500
> Stephen Woodbridge<woodbri@swoodbridge.com> wrote:
>
>> On 2/27/2012 4:42 PM, "Christophe Damour (SIGéal)" wrote:
>>> Hi,
>>>
>>> I am trying to use trsp shortest path function, but get a "Source
>>> Not Found" error.
>>> Here is my query :
>>> SELECT edge_id FROM turn_restrict_shortest_path(
>>> 'SELECT id_tron as id, source::integer, target::integer,
>>> cost::double precision as cost, rev_cost::double precision as
>>> reverse_cost FROM reseau_global',
>>> 15326,
>>> 8756,
>>> true,
>>> true,
>>> 'SELECT to_cost::double precision, target_id::integer,
>>> via_path::text FROM reseau_global_rest'
>>> ), reseau_global
>>> WHERE edge_id = id_tron;
>>>
>>> reseau_global is my network table, and reseau_global_rest is my
>>> turn restriction table.
>>> In the latter, target_id column contains destination edges ids and
>>> via_path a list of forbidden origin edges.
>>>
>>> What am I doing wrong ?
>>>
>>> Thank for any hints,
>>>
>>
>> Typically this means that you are probably entering edge_ids for
>> source and target and not node_ids.
>>
>> Also, there is another version of the API that does take edge_ids
>> for the start and end of the route rather than node_ids. You would
>> call it like this:
>>
>> SELECT edge_id FROM turn_restrict_shortest_path(
>> 'SELECT id_tron as id, source::integer, target::integer,
>> cost::double precision as cost, rev_cost::double precision as
>> reverse_cost FROM reseau_global',
>> 15326, -- start edge_id
>> 0.5. -- percent along start edge
>> 8756, -- end edge_id
>> 0.5 -- percent along end edge
>> true,
>> true,
>> 'SELECT to_cost::double precision, target_id::integer,
>> via_path::text FROM reseau_global_rest'
>> ), reseau_global
>> WHERE edge_id = id_tron;
>>
>> Using the edge + percent is better because it allow you to take
>> into account restrictions and onewayness of the start and end
>> edges that can not be done with the version you are using. This
>> was a recent update to git so you might want to pull an updated
>> versions.
>>
>> -Steve W
>> _______________________________________________
>> 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