openplans/OpenTripPlanner — pull request #933 by flamholz (2012-12-04 20:29:18+00:00)
Title: Prelude to breaking ties in getClosestEdges() by direction of travel

The general tenor of this change is to make it possible to score CandidateEdges by how well they are aligned with a direction of travel. This required a couple of additions/changes.

1) Add two new objects: LocationObservation and TraversalRequirements.
LocationObservation - mostly copied from the openplans tracking code and allows the client to pass in a timestamp, velocity, heading and accuracy information in addition to a coordinate.
TraversalRequirements - contains only the strict portions of RoutingRequest, those that would prevent us from traversing a particular edge. This way, you don't need to setup a RoutingRequest if all you want to do is find an edge/vertex (which is what the Thrift API sometimes wants to do).

2) Add new getClosestEdges methods to the StreetVertexIndexService that accept TraversalRequirements and LocationObservation instead of RoutingRequests and Coordinates.

3) Implement these methods on StreetVertexIndexServiceImpl. Reimplement older methods using new implementation.

4) Clean up CandidateEdge code a little so that it will be easier to account for the direction of travel in scoring.

5) Add some tests for the new getClosestEdges() method. Note that all project tests pass in my branch.

Minor stuff:
* Rename RoutingRequest.walkingOptions to RoutingRequest.bikeWalkingOptions for clarity.
* Lots of javadocs here and there.
* Start using the Google collections library to concatenate iterables. Clarified some code.
* Instead of dividing by 1000 everywhere, add a constant for the earths radius in meters, since this is what we actually use.
* Add MODE_ALL to TraverseModeSet so that TraversalRequirements can allow all TraverseModes by default.