I commented out the part from xodr_parser where all the lanes other than of "driving" type are ignored, so the rtree in MapInterface should have all lanes.
Then I queried the 3 nearest lanes from a given point using (the python binding) of FindNearestLanes.
For this point I would expect the 3 nearest lanes to be of type sidewalk (5), border (6) and driving (1):
![point_sw](https://user-images.githubusercontent.com/42185809/61440669-59bdec00-a944-11e9-8b9a-6574f4902b80.png)
But the function returns two lanes of type 1 and one of type 6:
![Screenshot from 2019-07-17 09-09-22](https://user-images.githubusercontent.com/42185809/61440777-9558b600-a944-11e9-9a82-30c493ffdf1a.png)
When trying it for a different point:
![point_outside](https://user-images.githubusercontent.com/42185809/61440795-a1dd0e80-a944-11e9-99bc-f4a8c4188a68.png)
Here the function works. It returns (as expected) lanes of type none (0), border (6) and sidewalk (5).
I also tried it with random other points along the road, for some points it gives the expected results, for others not.
I circumvented this problem by creating my own function to find the nearest lanes which uses:
boost::geometry::index::satisfies([&](rtree_lane_value const& v) {return distance(v.second->get_line(), point) <= radius; }),
instead of boost::geometry::index::nearest(point, num_lanes);
.
This returns the expected results (but requires a radius parameter).
I also created a function to find all the lanes that are intersected by a given line and when doing the rtree query using boost::geometry::index::intersects(line_segment),
it didn't return anything when it clearly should. Using a own lambda (here using modules::geometry Collide) solved this problem too.