kodonnell

@CNugteren - possibly related to here: how do you make the tuning database useful across releases? E.g. everyone might report their results for gemm, and then after a big code...

Afraid I can't offer too much intelligent @karussell, as I've been out of the game too long. The following may be so: can we just create a standalone mapping dict...

> Yes, world wide it will take at least 1GB RAM more if just junctions nodes, plus 1GB for the way IDs. Maybe 'expensive' is a relative term - for...

Somewhat relevant discussion [here](https://discuss.graphhopper.com/t/suitability-for-map-matching-fuzzy-cellular-data/1003) - that is, cellular data can also have varying separations between trilaterated (non-GPS) coordinates, and it'd be preferrable to not split the route. I imagine the...

Agreed that, assuming 'normal' behaviour, it is probably fine. If it's not 'normal' - e.g. non-sequential - then this could be a very poor metric. A Levenshtein approach may handle...

> So the transition metric favors straight connections between both GPS coordinates. Doesn't that illustrate my point? I.e. it favours straight connections, not the shortest/fastest connection. I'd assume that (unless...

> Hmm, but that's an assumption about the behavior of people (a behavioral prior), whereas the current transition probability only makes an assumption about how movement constrained by a road...

> Favoring straight connections is equivalent to favoring shortest routes because the linear distance between A and B is a lower bound for the length of any path between A...

> note that the linearDistance is computed outside both for loops Ah, that's the key point I missed - for my use case I've had to use snapped coordinates (for...

As an aside, I'm having reasonable success with just using a scaled route distance (e.g. `routeLength / 10000`) as the transition metric. To be fair, my use case is quite...