Use most common/popular ref and destination

[freenerd]

Ways can have several ref and destinations. These are usually ; delimited. Currently we are only always using the first one. Instead, we should use the most common or popular one.

As an example, imagine a cross-country road that has the following refs on the way:

• I-80
• I-80;I-81
• I-80;I-81;DETOUR-20
• I-80
• I-90;I-80
• I-90;I-80
• I-80

It would be great if the user would always only get I-80 as the ref.

We could implement this via a pre-processing step where we create a priority list (based on occurence, maybe mixed with length of staying on segments) and when deciding for a ref within a way, we should use the one with highest priority.

[freenerd]

During the pre-processing step, we may also handle mode changes #18 and waypoints #7

[freenerd]

Note that it likely makes sense to have one combined priority list for destinations and ref, since OSRM is mixing the destination:ref tags into the destinations field

[TheMarex]

Cross-linking #115 (comment) here as another test case for this.

[freenerd]

There is a prototypical implementation in #77

[lyzidiamond]

Per convo with @1ec5 and @mcwhittemore, there are two separate-but-related issues at play here:

1. When on a multiplexed road like I-80;I-90, instructions should pick the better one for the route. Considerations include: the previous instruction (if the user is already traveling on I-80 they should continue on it), the subsequent instruction (if the user is traveling on I-80 but will be continuing onto I-90 after they split), the instructions on the majority of the route (if most of the route travels on I-80, regardless of immediately preceding and subsequent instructions).
2. When taking an exit with multiple destinations like Salem;Seattle, instructions should pick the better one for the route. Considerations include: the next instruction (if the next move is related to one of the destinations), the length of time until the next instruction (per Choose destination based on up-coming steps. #115 (comment)), the final destination (if the user is going to Seattle, we should pick Seattle).

This project is only considering one instruction at a time and translating it, so the decision-making work needs to happen before the instructions make their way into this tool.

[lyzidiamond]

Per my comment above, this tool's job is to take tokens and return the requested sentence using those tokens in a given language. Until/unless this project goes through a significant refactor, any decisionmaking about what tokens get passed into this tool should happen elsewhere. Closing for now.