[pgrouting-dev] Where to put pgr_tsptrsp in the source tree?

Stephen Woodbridge woodbri at swoodbridge.com
Thu Oct 10 08:08:08 PDT 2013


Hi all,

I'm looking at adding some of the new code I wrote to the repository and 
came up with this:

src/common/sql/
     pgr_pointtoedgenode
     pgr_flipedges
     pgr_texttopoints
     pgr_pointstovids
     pgr_pointstodmatrix (1)
     pgr_vidstodmatrix (1)

src/trsp/sql/
     pgr_trsp (recode into C/C++ and move to src/trsp/src)

So the (1) functions above could be placed in src/common or src/tsp. My 
thought is that they might also be useful for VRP if a add another 
function to unnest a distance matrix into the distance table needed for 
VRP, so I'm inclined to leave them in src/common.

pgr_tsptrsp() is a little harder to place because it is a higher level 
wrapper. So my choices are:

1. src/tsp
2. src/trsp
3. src/applications
4. put it in a gist

I do not think it belongs in 1 or 2.

I think eventually we might want to have a src/applications directory 
but I'm not sure what the rules should be for putting stuff in that and 
I don't want to create a dumping ground for wrappers. So, I'm not sure 
want to set a president for this yet.

So I guess, that means if goes into a gist.

pgr_tsptrsp() is still a little immature in that it only supports 
routing by vertex ids and TRSP supports routing by edge ids and routing 
by edge-pct that should also be supported also.

I go back to my fundamental rules for the source tree organization and 
why we eliminated all the wrapper functions:

1. focus on core low level functionality initially
2. functions have to be generally useful by the community
3. all function need to be tested
4. put wrappers in gists and decide later if they are generally useful

OK, I have convinced myself that pgr_tsptrsp() should go to a gist for now.

Open to thoughts and opinions on this. Got any feedback?

-Steve


More information about the pgrouting-dev mailing list