i still feel that the precondition for calling this function is that things are in order. ie we shouldnt have to account for this because upstream callers were already made to do so. that said its not a huge deal but also kind of contradicts the throw on line 158.

Yea, not sure if you saw my commit comment. After switching helpers::Project() to double's the unit test MapMatch::interpolation() was hitting the throw::logic_error(). Here are the values:

prev_match.distance_along:  0.85524916907388349
curr_match.distance_along:  0.85524916648864746

The difference starts on the 9th decimal. Float's only have 7.2 decimal digits of precision so, in a sense, we were already rounding to 7 decimal digits by using float. Given that our projection logic employs both flat-earth approximation for projecting and haversine for distances - and then we combine those computations to calculate percentage_along - I think we have to anticipate we will see wobbles like this.

yeah my point was only that the idea was that we would fix the wobbliness upstream from this function by fixing the distance along in the match objects before this function ever gets called. but its fine to not widen the scope of this PR (which is what i meant by "not a huge deal").

why do you say the projection logic uses flat-earth approximation (https://github.com/valhalla/valhalla/blob/master/valhalla/midgard/util.h#L593)? the distance approximator certainly does do that, but its used just for the check of whether one point is closer than another. its implementation, while inaccurate for absolute distance, should produce distances that sort properly when comparing whether one pair of points is closer or further than another pair of points.

Correct, we use projector_t::operator() for projection, which is a flattened-earth approach. However, inside helpers::Project() we use PointLL::Distance() which uses law-of-cosines (I was mistaken when I said haversine). However, the point remains that PointLL::Distance() attempts to take into account earth curvature, whereas projector_t::operator() does not.

Point being, the percentage_along is based on a projected point (using flattened earth) as a percentage of a distance along a segment's length (using curved earth). I don't have a problem with the approach, just noting that results derived by combining these two systems will likely have slight variances against ideal expectations (e.g., a pure cartesian 2D approach) depending on where we are on the globe, segment lengths, etc. Not to mention law-of-cosines known weakness for shorter distances.

Hence the need for tolerances.

maybe i misunderstood what you meant by flat earth, but i had assumed you meant cartesian or strictly 2d. you'll notice we do at least scale delta X based on the latitude to account for longitunial geodesics converging at the poles. i wouldnt consider this "flat earth" or "cartesian", but i agree its not a proper projection function that would intersect a perpendicular geodesic with the geodesic between two points.

perhaps your larger point though is actually that because the projection doesnt perfectly (it cant anyway, but even less perfectly) place the projected point along the geodesicl, using law of cosines to measure distance will give different results based on how off the geodesic the projected point is?

Correct.