support for algorithms with multiple trees/routes

[robfitzgerald]

this PR begins the work to support search algorithms which return more than one tree and/or route. a quick review on those possibilities:

$n$ trees	one route	many routes
$1$	Dijkstra's, a* search
$\gt 1$	bi-directional search	k-shortest path

in this PR, the SearchApp and CompassApp are rewritten to support these cases, which spilled into a few other concerns:

• since each route has it's own summary the route stats/info was moved inline with each route (see here)
  • added the key ".route[i].path" for the actual serialized route
  • value at ".route[i].path" is null if no path, {} (an object) for one path, or [{}] (an array of objects) for multiple paths
  • same structure for trees
• the edge list output plugin was rolled in as a variant of the traversal output plugin
• edge vs vertex orientation handling streamlined
• k-shortest path algorithm has a stub but is not yet implemented
• removed or re-wrote some summary output annotations from the initial output section and summary output plugin based on other changes

[nreinicke]

This all looks good! There's a key error in the notebook but that should be a quick fix

[nreinicke]

looks like there's one more place to update in the notebook to use r["route"].

[nreinicke]

Hmm actually I'm hitting an error when running this on a tomtom config:

{'error': "Error: missing field origin_vertex",
 'request': {'destination_edge': 731331,
  'destination_x': -104.78222,
  'destination_y': 39.555836,
  'model_name': '2016_TOYOTA_Camry_4cyl_2WD',
  'name': 'Least Distance',
  'origin_edge': 380279,
  'origin_x': -105.230087,
  'origin_y': 39.756719,
  'query_weight_estimate': 44.37301171875,
  'road_classes': [1, 2, 3, 4, 5, 6],
  'start_time': '05:00:00 PM',
  'start_weekday': 'tuesday',
  'weights': {'distance': 1, 'energy_liquid': 0, 'time': 0}}}

The config is set up to use edge as its search orientation and it's properly adding the edge ids but for some reason it's getting into the vertex oriented search

[robfitzgerald]

Interesting. I did mess with (and simplify) the handling of edge vs vertex oriented queries and looks like I messed up the logic. I'll look into it when I come in, which will be closer to 11 today

[robfitzgerald]

@nreinicke found it. SearchApp::run_edge_oriented now wraps SearchApp::run_vertex_oriented, and i was attempting to inject the missing parameters into the query to allow for this. but instead of injecting the VertexIds, I injected the coordinates (origin_x|y).

[robfitzgerald]

i need to double-check this again. i may have forgotten to slap the original edge pair back on the result for edge-based searches.

[robfitzgerald]

ok! now fixed^2, should be good, tested w/ vertex-oriented and edge-oriented configs.

[nreinicke]

sweet! just tested again and everything seems to be working great!