Hey Stephen,
I am working with the TRSP code. Instead of returning an error when the path cannot be found, I was wondering how difficult it would be to change the function to return no path result instead?
Hi
What do you actually mean with "no path"
Do you mean a path with len==0?
regards
max
On Wed, 27 Jun 2012 10:19:03 -0400
Steve Horn <steve@stevehorn.cc> wrote:
Hey Stephen,
I am working with the TRSP code. Instead of returning an error when
the path cannot be found, I was wondering how difficult it would be
to change the function to return no path result instead?
yeah, path with len==0 is another way to say it.
On around line 423 of GraphDefinition.cpp the *err_msg variable is assigned “Path Not Found” and a -1 is returned.
This causes the plpgsql function to abort. Instead of aborting I would like to continue processing.
On Wed, Jun 27, 2012 at 10:29 AM, Max Weninger <max.weninger@gmail.com> wrote:
Hi
What do you actually mean with “no path”
Do you mean a path with len==0?regards
max
On Wed, 27 Jun 2012 10:19:03 -0400
Steve Horn steve@stevehorn.cc wrote:Hey Stephen,
I am working with the TRSP code. Instead of returning an error when
the path cannot be found, I was wondering how difficult it would be
to change the function to return no path result instead?
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
–
Steve Horn
To clarify:
When I say “I would like to continue processing” I mean to say that I would like my plpgsql function to continue processing (the function that is calling into the turn_restrict_shortest_path).
On Wed, Jun 27, 2012 at 10:40 AM, Steve Horn <steve@stevehorn.cc> wrote:
yeah, path with len==0 is another way to say it.
On around line 423 of GraphDefinition.cpp the *err_msg variable is assigned “Path Not Found” and a -1 is returned.
This causes the plpgsql function to abort. Instead of aborting I would like to continue processing.
On Wed, Jun 27, 2012 at 10:29 AM, Max Weninger <max.weninger@gmail.com> wrote:
Hi
What do you actually mean with “no path”
Do you mean a path with len==0?regards
max
On Wed, 27 Jun 2012 10:19:03 -0400
Steve Horn steve@stevehorn.cc wrote:Hey Stephen,
I am working with the TRSP code. Instead of returning an error when
the path cannot be found, I was wondering how difficult it would be
to change the function to return no path result instead?
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users–
Steve Horn
–
Steve Horn
Hi
You would need to change GraphDefinition.cpp like
Just "straight out of my brain" 
Return 0 instead of -1
dont set err_msg
and add something like
*path = (path_element_t *) malloc(sizeof(path_element_t)));
*path_count = 1;
and set the attributes with "defaults" that you want
to use to "mark" this path as "empty"
(*path)[0].vertex_id = xxx;
(*path)[0].edge_id = yyy;
(*path)[0].cost = zzz;
regards
max
To clarify:
When I say "I would like to continue processing" I mean to say that I
would like my plpgsql function to continue processing (the function
that is calling into the turn_restrict_shortest_path).On Wed, Jun 27, 2012 at 10:40 AM, Steve Horn <steve@stevehorn.cc>
wrote:> yeah, path with len==0 is another way to say it.
>
> On around line 423 of GraphDefinition.cpp the *err_msg variable is
> assigned "Path Not Found" and a -1 is returned.
>
> This causes the plpgsql function to abort. Instead of aborting I
> would like to continue processing.
>
>
> On Wed, Jun 27, 2012 at 10:29 AM, Max Weninger
> <max.weninger@gmail.com>wrote:
>
>> Hi
>>
>> What do you actually mean with "no path"
>> Do you mean a path with len==0?
>>
>> regards
>>
>> max
>>
>> On Wed, 27 Jun 2012 10:19:03 -0400
>> Steve Horn <steve@stevehorn.cc> wrote:
>>
>> > Hey Stephen,
>> > I am working with the TRSP code. Instead of returning an error
>> > when the path cannot be found, I was wondering how difficult it
>> > would be to change the function to return no path result instead?
>>
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>
>
>
>
> --
> Steve Horn
>
>
I think this would be fine to make such a change. The SQL function should not abort with an error is no path is found but probably just return NULL or in the case of a set returning function just return no rows.
Patches or a pull request would be appreciated.
-Steve W
On 6/27/2012 10:48 AM, Steve Horn wrote:
To clarify:
When I say "I would like to continue processing" I mean to say that I
would like my plpgsql function to continue processing (the function that
is calling into the turn_restrict_shortest_path).On Wed, Jun 27, 2012 at 10:40 AM, Steve Horn <steve@stevehorn.cc
<mailto:steve@stevehorn.cc>> wrote:yeah, path with len==0 is another way to say it.
On around line 423 of GraphDefinition.cpp the *err_msg variable is
assigned "Path Not Found" and a -1 is returned.This causes the plpgsql function to abort. Instead of aborting I
would like to continue processing.On Wed, Jun 27, 2012 at 10:29 AM, Max Weninger
<max.weninger@gmail.com <mailto:max.weninger@gmail.com>> wrote:Hi
What do you actually mean with "no path"
Do you mean a path with len==0?regards
max
On Wed, 27 Jun 2012 10:19:03 -0400
Steve Horn <steve@stevehorn.cc> wrote:> Hey Stephen,
> I am working with the TRSP code. Instead of returning an
error when
> the path cannot be found, I was wondering how difficult it
would be
> to change the function to return no path result instead?_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
<mailto:Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-users--
Steve Horn--
Steve Horn_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
Works perfectly. Thanks Max!
On Wed, Jun 27, 2012 at 11:01 AM, Max Weninger <max.weninger@gmail.com> wrote:
Hi
You would need to change GraphDefinition.cpp like
Just “straight out of my brain”Return 0 instead of -1
dont set err_msgand add something like
*path = (path_element_t *) malloc(sizeof(path_element_t)));
*path_count = 1;and set the attributes with “defaults” that you want
to use to “mark” this path as “empty”(*path)[0].vertex_id = xxx;
(*path)[0].edge_id = yyy;
(*path)[0].cost = zzz;regards
max
To clarify:
When I say “I would like to continue processing” I mean to say that I
would like my plpgsql function to continue processing (the function
that is calling into the turn_restrict_shortest_path).On Wed, Jun 27, 2012 at 10:40 AM, Steve Horn steve@stevehorn.cc
wrote:yeah, path with len==0 is another way to say it.
On around line 423 of GraphDefinition.cpp the *err_msg variable is
assigned “Path Not Found” and a -1 is returned.This causes the plpgsql function to abort. Instead of aborting I
would like to continue processing.On Wed, Jun 27, 2012 at 10:29 AM, Max Weninger
<max.weninger@gmail.com>wrote:Hi
What do you actually mean with “no path”
Do you mean a path with len==0?regards
max
On Wed, 27 Jun 2012 10:19:03 -0400
Steve Horn steve@stevehorn.cc wrote:Hey Stephen,
I am working with the TRSP code. Instead of returning an error
when the path cannot be found, I was wondering how difficult it
would be to change the function to return no path result instead?
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users–
Steve Horn
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
–
Steve Horn
On 6/27/2012 10:19 AM, Steve Horn wrote:
Hey Stephen,
I am working with the TRSP code. Instead of returning an error when the
path cannot be found, I was wondering how difficult it would be to
change the function to return no path result instead?
I think you might be able to just just comment out the if block at trsp.c:536-541
This is where the error is thrown from. With that commented out then the code should just return without an error. You will not know why it failed, because no error message will be throw. I suppose you could throw a NOTICE instead of an error with something like:
elog(NOTICE, "Error computing path: %s", err_msg);
You will notice that the block already has a commented out
//elog(ERROR, "Error computing path: %s", err_msg);
Try uncommenting that nad change the ERROR to NOTICE and then comment out the ereport(...); section.
Let us know how that works.
-Steve W