Feature #377 alternative routes

[takb]

Pull Request Checklist

• 1. I have merged the latest version of the development branch into my feature branch and all conflicts have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the app.config file, I have added these to the app.config.sample file along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset (at least Germany) and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the importer etc.), I have generated longer distance routes for the affected profiles with different options (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end points generated from the current live ORS. If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage and why the change was needed.

Fixes #377 .

Information about the changes

• Key functionality added:

• routing API option "alternative_routes": n (int) added, uses GH alternative_route algorithm to return up to n routes for the query. Currently disables CH, and more than 2 waypoints are not supported. Parameters for the algorithm can be set with options "alternative_routes_weight_factor": (double) and "alternative_routes_share_factor": (double).

• Reason for change:
  This gets the algorithm to work basically, but a) the algorithm produces some funny results and b) CH support is underway (Faster alternative routes for longer routes graphhopper/graphhopper#1524), so we'll need to continue work on this feature in a while. The changes to RouteResultBuilder are also crying out for serious refactoring... So this is not done or anything, just stashing away interim results.

[rabidllama]

Mostly looks good, though I think we should do a small amount of refactoring in the RouteResultBuilder to reduce the duplication of the code that builds some of the route information.

There is a line of code in RoutingProfileManager (ln 463) that defines whether a route uses dynamic weights, which in turn is used to limit the length of routes requested. As the alternative routing algorithm does not used the optimised routing algorithms, we should add to that line a check for requesting alternative routes and if they are requested, then the distance check should also be carried out.

[rabidllama]

I would suggest that we refactor some of the code to reduce duplication of methods. For example, a lot of the code here is duplicated earlier, so it would be good if we could take this code and put it into a method that can be used for all places where this functionality is required. There are some differences relating to some aspects (e.g. loops), so it might need a bit of thought to get it working properly but it would certainly be a step in the right direction for cleaning up this class.

[rabidllama]

Would be better to name this _alternativeRouteCount to make it clearer what it is for (same for the getter and setter)