[pgrouting-users] PGR 2.0 - Refactored the TYPEs and Added a seq column

Stephen_Woodbridge1 · May 14, 2013, 1:30am

Hi All,

Another big change just got pushed to the repository for sew-devel-2_0.

This change involved refactoring and abstracting our return types from our functions. Basically every function was create a new return type that was the same but a little different mostly in the column names.

So what we now have are:

     CREATE TYPE pgr_costResult AS
     (
         seq integer,
         id1 integer,
         id2 integer,
         cost float8
     );

     CREATE TYPE pgr_geomResult AS
     (
         seq integer,
         id1 integer,
         id2 integer,
         geom geometry
     );

     CREATE TYPE pgr_vertexResult AS
     (
         x float8,
         y float8
     );

and I have eliminated 6 of the old types, namely:

     pgr_pathResult
     pgr_geoms
     pgr_apspEdge
     pgr_linkPoint
     pgr_kspResult
     pgr_kspGeoms

You will also notice that I have added a seq column to the first two types and this can be used to maintain order if you need two.

So what are id1 and id2? these are just generic names, you will have to looks at the specify function to see what it returns in these slots.

The docs have NOT been updated to reflect these changes, but Daniel and I will work on this over the next few days.

CALL FOR HELP!

One of the things that we really could use some help with is building test cases. I would like to see a minimum of one test per function call and ideally one for each of the variation that a function has.

This should not be that hard to do, because we have cut down significantly on the number of functions by abandoning most of the wrapper functions. But there are still a lot of functions in the src/common/sql/ directory that have no test. When I was converting the code for the changes above, I found a bunch functions in the matching code that clearly have never worked correctly because they had assignments like:

variable = equation;

which basic computes the boolean comparison of variable and equation and then throws away the result. Oooops! This must be written like:

variable := equation;

to do an assignment.

Anyway having the tests that we do have made it much faster to identify problems in the code I changed and to make sure everything was working as it was before I made the changes. I'm just worried about the things we do not have test for! and should should you!

Let me know how it goes when you have a chance to give it a try.

Thanks,
-Steve

Alec_Gosse · May 14, 2013, 1:16pm

Hello,

This looks like a nice concise list of return types.

In relation to our discussion on bulk routing, however, I was thinking that I would need to add a routeId column to the ptr_costResult type in order to return multiple routes from the same query, unless there is a function structure that I am not aware of?

Alec

On May 13, 2013, at 9:30 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi All,

Another big change just got pushed to the repository for sew-devel-2_0.

This change involved refactoring and abstracting our return types from our functions. Basically every function was create a new return type that was the same but a little different mostly in the column names.

So what we now have are:

   CREATE TYPE pgr_costResult AS
   (
       seq integer,
       id1 integer,
       id2 integer,
       cost float8
   );

   CREATE TYPE pgr_geomResult AS
   (
       seq integer,
       id1 integer,
       id2 integer,
       geom geometry
   );

   CREATE TYPE pgr_vertexResult AS
   (
       x float8,
       y float8
   );

and I have eliminated 6 of the old types, namely:

   pgr_pathResult
   pgr_geoms
   pgr_apspEdge
   pgr_linkPoint
   pgr_kspResult
   pgr_kspGeoms

You will also notice that I have added a seq column to the first two types and this can be used to maintain order if you need two.

So what are id1 and id2? these are just generic names, you will have to looks at the specify function to see what it returns in these slots.

The docs have NOT been updated to reflect these changes, but Daniel and I will work on this over the next few days.

CALL FOR HELP!

One of the things that we really could use some help with is building test cases. I would like to see a minimum of one test per function call and ideally one for each of the variation that a function has.

This should not be that hard to do, because we have cut down significantly on the number of functions by abandoning most of the wrapper functions. But there are still a lot of functions in the src/common/sql/ directory that have no test. When I was converting the code for the changes above, I found a bunch functions in the matching code that clearly have never worked correctly because they had assignments like:

  variable = equation;

which basic computes the boolean comparison of variable and equation and then throws away the result. Oooops! This must be written like:

  variable := equation;

to do an assignment.

Anyway having the tests that we do have made it much faster to identify problems in the code I changed and to make sure everything was working as it was before I made the changes. I'm just worried about the things we do not have test for! and should should you!

Let me know how it goes when you have a chance to give it a try.

Thanks,
-Steve
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

Stephen_Woodbridge1 · May 14, 2013, 2:02pm

On 5/14/2013 9:16 AM, Alec Gosse wrote:

Hello,

This looks like a nice concise list of return types.

In relation to our discussion on bulk routing, however, I was
thinking that I would need to add a routeId column to the
ptr_costResult type in order to return multiple routes from the same
query, unless there is a function structure that I am not aware of?

Yeah, I thought of this because ksp needed and extra column and didn't get it. I didn't want to have just one type with lots of columns that we null for many functions.

I think we can create an additional type(s) the has 3 id columns if we need it.

CREATE TYPE pgr_cost3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, cost float8 );

CREATE TYPE pgr_geom3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, geom geometry );

My main goal was to stop the proliferation of every algorithm has its own type.

-Steve

Alec

On May 13, 2013, at 9:30 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi All,

Another big change just got pushed to the repository for
sew-devel-2_0.

This change involved refactoring and abstracting our return types
from our functions. Basically every function was create a new
return type that was the same but a little different mostly in the
column names.

So what we now have are:

CREATE TYPE pgr_costResult AS ( seq integer, id1 integer, id2
integer, cost float8 );

CREATE TYPE pgr_geomResult AS ( seq integer, id1 integer, id2
integer, geom geometry );

CREATE TYPE pgr_vertexResult AS ( x float8, y float8 );

and I have eliminated 6 of the old types, namely:

pgr_pathResult pgr_geoms pgr_apspEdge pgr_linkPoint pgr_kspResult
pgr_kspGeoms

You will also notice that I have added a seq column to the first
two types and this can be used to maintain order if you need two.

So what are id1 and id2? these are just generic names, you will
have to looks at the specify function to see what it returns in
these slots.

The docs have NOT been updated to reflect these changes, but Daniel
and I will work on this over the next few days.

CALL FOR HELP!

One of the things that we really could use some help with is
building test cases. I would like to see a minimum of one test per
function call and ideally one for each of the variation that a
function has.

This should not be that hard to do, because we have cut down
significantly on the number of functions by abandoning most of the
wrapper functions. But there are still a lot of functions in the
src/common/sql/ directory that have no test. When I was converting
the code for the changes above, I found a bunch functions in the
matching code that clearly have never worked correctly because they
had assignments like:

variable = equation;

which basic computes the boolean comparison of variable and
equation and then throws away the result. Oooops! This must be
written like:

variable := equation;

to do an assignment.

Anyway having the tests that we do have made it much faster to
identify problems in the code I changed and to make sure everything
was working as it was before I made the changes. I'm just worried
about the things we do not have test for! and should should you!

Let me know how it goes when you have a chance to give it a try.

Thanks, -Steve _______________________________________________
pgrouting-dev mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

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

Alec_Gosse · May 14, 2013, 2:14pm

That sounds good to me. I would propose using the third id column for the additional functionality so that the first 3 columns match the smaller types. I'll working on building a bulk trsp function outputting pgr_*3Result.

Will you commit the types or should I add them to my branch?

Alec

On May 14, 2013, at 10:02 AM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

On 5/14/2013 9:16 AM, Alec Gosse wrote:

Hello,

This looks like a nice concise list of return types.

In relation to our discussion on bulk routing, however, I was
thinking that I would need to add a routeId column to the
ptr_costResult type in order to return multiple routes from the same
query, unless there is a function structure that I am not aware of?

Yeah, I thought of this because ksp needed and extra column and didn't get it. I didn't want to have just one type with lots of columns that we null for many functions.

I think we can create an additional type(s) the has 3 id columns if we need it.

CREATE TYPE pgr_cost3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, cost float8 );

CREATE TYPE pgr_geom3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, geom geometry );

My main goal was to stop the proliferation of every algorithm has its own type.

-Steve

Alec

On May 13, 2013, at 9:30 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi All,

Another big change just got pushed to the repository for
sew-devel-2_0.

This change involved refactoring and abstracting our return types
from our functions. Basically every function was create a new
return type that was the same but a little different mostly in the
column names.

So what we now have are:

CREATE TYPE pgr_costResult AS ( seq integer, id1 integer, id2
integer, cost float8 );

CREATE TYPE pgr_geomResult AS ( seq integer, id1 integer, id2
integer, geom geometry );

CREATE TYPE pgr_vertexResult AS ( x float8, y float8 );

and I have eliminated 6 of the old types, namely:

pgr_pathResult pgr_geoms pgr_apspEdge pgr_linkPoint pgr_kspResult
pgr_kspGeoms

You will also notice that I have added a seq column to the first
two types and this can be used to maintain order if you need two.

So what are id1 and id2? these are just generic names, you will
have to looks at the specify function to see what it returns in
these slots.

The docs have NOT been updated to reflect these changes, but Daniel
and I will work on this over the next few days.

CALL FOR HELP!

One of the things that we really could use some help with is
building test cases. I would like to see a minimum of one test per
function call and ideally one for each of the variation that a
function has.

This should not be that hard to do, because we have cut down
significantly on the number of functions by abandoning most of the
wrapper functions. But there are still a lot of functions in the
src/common/sql/ directory that have no test. When I was converting
the code for the changes above, I found a bunch functions in the
matching code that clearly have never worked correctly because they
had assignments like:

variable = equation;

which basic computes the boolean comparison of variable and
equation and then throws away the result. Oooops! This must be
written like:

variable := equation;

to do an assignment.

Anyway having the tests that we do have made it much faster to
identify problems in the code I changed and to make sure everything
was working as it was before I made the changes. I'm just worried
about the things we do not have test for! and should should you!

Let me know how it goes when you have a chance to give it a try.

Thanks, -Steve _______________________________________________
pgrouting-dev mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

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

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

Stephen_Woodbridge1 · May 14, 2013, 2:14pm

On 5/14/2013 10:14 AM, Alec Gosse wrote:

That sounds good to me. I would propose using the third id column for
the additional functionality so that the first 3 columns match the
smaller types. I'll working on building a bulk trsp function
outputting pgr_*3Result.

Will you commit the types or should I add them to my branch?

Go ahead and add then to your branch. I'm going to try to get some other things fixed.

Thanks,
-Steve

Alec

On May 14, 2013, at 10:02 AM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

On 5/14/2013 9:16 AM, Alec Gosse wrote:

Hello,

This looks like a nice concise list of return types.

In relation to our discussion on bulk routing, however, I was
thinking that I would need to add a routeId column to the
ptr_costResult type in order to return multiple routes from the
same query, unless there is a function structure that I am not
aware of?

Yeah, I thought of this because ksp needed and extra column and
didn't get it. I didn't want to have just one type with lots of
columns that we null for many functions.

I think we can create an additional type(s) the has 3 id columns if
we need it.

CREATE TYPE pgr_cost3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, cost float8 );

CREATE TYPE pgr_geom3Result AS ( seq integer, id1 integer, id2
integer, id3 integer, geom geometry );

My main goal was to stop the proliferation of every algorithm has
its own type.

-Steve

Alec

On May 13, 2013, at 9:30 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi All,

Another big change just got pushed to the repository for
sew-devel-2_0.

This change involved refactoring and abstracting our return
types from our functions. Basically every function was create a
new return type that was the same but a little different mostly
in the column names.

So what we now have are:

CREATE TYPE pgr_costResult AS ( seq integer, id1 integer, id2
integer, cost float8 );

CREATE TYPE pgr_geomResult AS ( seq integer, id1 integer, id2
integer, geom geometry );

CREATE TYPE pgr_vertexResult AS ( x float8, y float8 );

and I have eliminated 6 of the old types, namely:

pgr_pathResult pgr_geoms pgr_apspEdge pgr_linkPoint
pgr_kspResult pgr_kspGeoms

You will also notice that I have added a seq column to the
first two types and this can be used to maintain order if you
need two.

So what are id1 and id2? these are just generic names, you
will have to looks at the specify function to see what it
returns in these slots.

The docs have NOT been updated to reflect these changes, but
Daniel and I will work on this over the next few days.

CALL FOR HELP!

One of the things that we really could use some help with is
building test cases. I would like to see a minimum of one test
per function call and ideally one for each of the variation
that a function has.

This should not be that hard to do, because we have cut down
significantly on the number of functions by abandoning most of
the wrapper functions. But there are still a lot of functions
in the src/common/sql/ directory that have no test. When I was
converting the code for the changes above, I found a bunch
functions in the matching code that clearly have never worked
correctly because they had assignments like:

variable = equation;

which basic computes the boolean comparison of variable and
equation and then throws away the result. Oooops! This must be
written like:

variable := equation;

to do an assignment.

Anyway having the tests that we do have made it much faster to
identify problems in the code I changed and to make sure
everything was working as it was before I made the changes. I'm
just worried about the things we do not have test for! and
should should you!

Let me know how it goes when you have a chance to give it a
try.

Thanks, -Steve _______________________________________________
pgrouting-dev mailing list pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

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

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

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