In order to build the polyline features used to render the lines on the map, we can't take the full resulting geometry, because we need to be able to highlight individual route legs when those are hovered. In order to build the legs, we first first decode the final routeline to get a list of individual coordinates through which the lines go and then compare the coordinates with the snappoints' coordinates. When there's a match, we "break" the route line into 2 individual route legs.
There was a bug, that when looking for coordinates that are the same (snappoint's coordinate the same as the current routeline's coordinate), we started the search everytime from the beginning of the route's coordinates. Therefore, for different snappoints with the same location, we took the same "portion" of a routeline, creating a total mess on the map. This fix changes the algorithm to search for the next snappoint from the index where the last search succeeded.
The solution briefly:
In order to build the polyline features used to render the lines on the map, we can't take the full resulting geometry, because we need to be able to highlight individual route legs when those are hovered. In order to build the legs, we first first decode the final routeline to get a list of individual coordinates through which the lines go and then compare the coordinates with the snappoints' coordinates. When there's a match, we "break" the route line into 2 individual route legs.
There was a bug, that when looking for coordinates that are the same (snappoint's coordinate the same as the current routeline's coordinate), we started the search everytime from the beginning of the route's coordinates. Therefore, for different snappoints with the same location, we took the same "portion" of a routeline, creating a total mess on the map. This fix changes the algorithm to search for the next snappoint from the index where the last search succeeded.
This PR closes #209