Restrict SG projection during SG matching on directly connected route segments

[adeveloper-wq]

During our test rides there were occasions where routes where crossing itself (can be caused by round trips). On such intersections currently the SG projection (part of SG matching) may project the SG on two different route segments. This may result in an erroneous matching. The SG should only be projected on continuous route segments.

[adeveloper-wq]

We discussed it today. We think it's an edge case that doesn't occur very often (based on recorded tracks). We consider the following to be the most robust solution that doesnt affect the previous matching: Split the route at intersections (where the route intersects) into multiple route segments and perform individual SG matching for these segments. This leaves normal tracks without intersections unaffected. For the intersection edge cases, however, we would be protected against projections of SGs onto different route segments. Although it is possible that false negatives could occur at the ends of the individual route segments (if an SG Map goes beyond an end), we still consider this to be the best solution.

[adeveloper-wq]

Implementing the discussed concept is not as trivial as assumed (GeoDjango and Shapely do not have native APIs for the splitting of a Linestring at own intersection points). We will therefore postpone this for the time being and work on other things. The current progress is on the following branch: https://github.com/priobike/priobike-sg-selector/tree/feature/robustness-against-route-intersections

[PhilippMatthes]

See #79 for a possible solution and explanation of that solution