Conversation
Time in traverse is calculated with mm length and mm/s GetSpeedForMode is now in mm/s not m/s
|
I don't think we want to change the profilerequest values to not be in m/s since that API is used by the outside world and most people are not familiar with mm/s. However we may want to think about how to eliminate the cast on each traverse, that may well be why street searches are slow. |
|
Fixed conflicts because file was deleted. And tested again with my saved requests. |
|
Revisiting this in October 2020, after combining r5 with analysis-backend. Because this is a pure refactor and should not change results, but does touch core routing code, it is probably best to do this after creating a round of regression tests. |
|
Accidentally closed when cleaning up branches. I would like to revisit these old pull requests and determine whether they're still relevant. |
This also changes calculations for time when traversing from m / m/s100 -> mm/ mm/s. Which means 2 divisions less (mm-> m and m/s100 -> m/s). CalculateSpeed function returns speed in mm/s now and ProfileRequest#getSpeedForMode also in mm/s since speed was always multiplied by 1000 where it was used. Everything should work the same as before since I checked all the usages but I can't test analyst.
Currently speeds for walk,bike and car are saved as m/s in ProfileRequest and are multiplied by 1000 on each getSpeedForMode call. Should this be changed? Since this is called on each traverse with walk/bike mode.