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