You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These implementations have some differences, here are the main differences:
GraphFinder has support for finding nearby Places as well as Stops.
GraphFinder has a maxDistance parameter.
NearbyStopFinder has Duration and MaxStopCount parameters.
NearbyStopFinder takes AreaStops into account while GraphFinder does not.
NearbyStopFinder fetches the whole search tree and traverses it again in order to find the stops. This could probably be optimized by using a TraverseVisitor as is done in StreetGraphFinder.
NearbyStopFinder is located in the graph_builder package even though it is being used in routing during AccessEgress search.
Proposed solution:
Create a single unified approach to nearby stop finding. The new stop finder should support the superset of configuration parameters from the two current solutions.
Is your feature request related to a problem? Please describe.
Duplicated code and different approaches causes more maintenance burden and more code we have to understand.
Goal / high level use-case
Simplify the overall code of OTP.
Remove dependencies from routing to graph_builder.
Describe alternatives you've considered
Leave it as it is.
Only move the NearbyStopFinder. This would get rid of the dependency to graph_builder.
The text was updated successfully, but these errors were encountered:
There are some architectural problems with the code for finding nearby stops.
Nearby stop finding is implemented in two separate places:
org.opentripplanner.routing.graphfinder.GraphFinder
org.opentripplanner.graph_builder.module.nearbystops.NearbyStopFinder
These implementations have some differences, here are the main differences:
GraphFinder
has support for finding nearby Places as well as Stops.GraphFinder
has a maxDistance parameter.NearbyStopFinder
has Duration and MaxStopCount parameters.NearbyStopFinder
takesAreaStops
into account whileGraphFinder
does not.NearbyStopFinder
fetches the whole search tree and traverses it again in order to find the stops. This could probably be optimized by using aTraverseVisitor
as is done inStreetGraphFinder
.NearbyStopFinder
is located in thegraph_builder
package even though it is being used in routing duringAccessEgress
search.Proposed solution:
Create a single unified approach to nearby stop finding. The new stop finder should support the superset of configuration parameters from the two current solutions.
Is your feature request related to a problem? Please describe.
Duplicated code and different approaches causes more maintenance burden and more code we have to understand.
Goal / high level use-case
Describe alternatives you've considered
NearbyStopFinder
. This would get rid of the dependency to graph_builder.The text was updated successfully, but these errors were encountered: