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

Stephen Woodbridge woodbri at swoodbridge.com
Tue May 14 07:14:11 PDT 2013


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



More information about the pgrouting-dev mailing list