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

[Stephen Woodbridge]

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 at 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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
> _______________________________________________ pgrouting-dev mailing
> list pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>