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

[Alec Gosse]

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