Actually, pathfinding is doable, if you optimize properly. Work out from both sides, not just one; eliminate all paths that arrive at a node (intersection) reached with a better time; put on hold the x% of paths with the worst distance / time ratio. What you end up with is more or less a diamond area connected on opposite points by the start and end of the path, with every intersection inside the area being a node, and the maximum number of paths corresponding roughly to the surface area of the diamond plus the distance through the middle of the diamond. This is workable, assuming the distance you need to cover isn't more than 10 miles or so, and if it is, you can modify the path to travel into three segments, with the middle segment being travel on trunk lines, of which there are few

This would be much more efficient if programmed in C / C++, however. Perl is a memory hog.

Comment onRe: Odd Ball Challenge