[pgrouting-users] Code tidy up?

[Stephen Woodbridge]

Hi Dave,

These are all items on the we need to do this list and most of them have 
tickets open. Daniel and I are buried in project work and our developer 
Anton, has moved on to other stuff. So we are looking for a developer or 
someone that is interested in working with us to tackle any of these tasks.

I understand you frustration, in the past I wrote my own set of standard 
wrapper functions because the existing one was somewhat random. I had 
planned to generalize them and contribute them, but I never got the time 
to do that.

We definitely need a test suit. The chaos that we current have with 
shooting star is the result of not having one. Things got released 
without any formal testing.

I don't know if you have had a chance to look at git/github but if you 
are working on any of these pieces, it would be nice if you cloned the 
pgrouting repository and checked all you changes into that clone, then 
it would be easy for us to pull and merge your changes int he future.

If you want to discuss changes before you make them, I would suggest 
moving the discussion over to the dev list and I will help you out 
there. I hope to have time in march to pull some of these isues together.

Thank you for your thoughts and suggestions, I fully support them.

Best regards,
   -Steve

On 2/16/2012 2:55 AM, Dave Potts wrote:
>
>
> Hi list
>
> Is there ever going to be a tidy up off the code associated with the demos
> of the pgr functions?
>
>
> In some cases you have to set the cost field to the value length.
> In some cases you have to set the primary key to id
> Some methods allow you to list the reverse_cost.
> For the traveling sales man you have to include a 2nd undocumented table
>
>
> Please note I am not suggesting a total rewrite off the code, just a tidy
> up, a bit of renaming, tidying up the api, better documentation.
>
> Something like a common interface
>
> e.g.
>
> xxxx('table_name,cost_field,reverse_cost_field,method_specfic_stuff)
>
> It might also help if we had a standard network for testing purpose and a
> list of expected results.
>
> Currently I find it very hard to program up a solution for pgr_route
> without knowning what the correct results should be.  If I had a test
> database, it would make life easier.
>
> Having test data might cut down on the number of questions that are being
> asked on the list.
>
> Dave.