[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