Coordinate Truncation

[JThramer]

Fixes #309. Adds number formatter that truncates coordinates to relevant number of decimal places, depending on shapeFormat setting.

[JThramer]

cc @mapbox/navigation-ios

[1ec5]

Tying the requested waypoint coordinates’ precision to the requested shape format is a good idea, but there’s a simpler, more robust way to round numbers for machine consumption than to use a number formatter, which is meant for human consumption.

Here’s a suggestion for the changelog:

Fixed an error requesting a route with very many waypoints.

[1ec5]

We’d get better performance by keeping just one number formatter around instead of recreating it twice for each waypoint. Given the large number of waypoints required to trigger the error being fixed, the difference might be measurable.

Additionally, the default NumberFormatter.locale depends on the application locale. So if the system language is set to Spanish and the application is localized into Spanish, all requests will produce errors, because Spanish uses a comma as the decimal separator.

Use the standard library math functions instead:

extension Double {
    func rounded(to precision: Double) -> Double {
        return (self * precision).rounded() / precision
    }
}

return "\(coordinate.longitude.rounded(to: 1e6)),\(coordinate.latitude.rounded(to: 1e6))"

[akitchen]

I agree, NumberFormatters are known to be expensive to create (or perhaps they only used to be?)

this is worth profiling, and possibly statically memoizing an instance or using @1ec5’s suggestion

[1ec5]

Formatters are generally expensive to create because the actual formatting is done by ICU, which is generic enough to support lots of languages and configurations, based on locales defined by CLDR. As far as I know, NumberFormatter doesn’t do a whole lot of caching between instances, because each instance’s configuration is mutable and each configuration option can drastically affect output.

Anyways, formatters are only for output that’s meant for display to the user. This string is going into a URL query parameter that is interpreted as two standard POSIX doubles. So to fix the localization issue I pointed out, we’d need to set locale to en_US_POSIX. (It isn’t enough to set the decimal separator, because some languages like Arabic use non-Western numerals.) But at that point, we might as well use the standard library math functions, because we don’t benefit at all from NumberFormatter.

[1ec5]

The return value goes directly into a URL query parameter, not JSON. What we’re implementing here is really String(describing:precision:) for a CLLocationCoordinate2D.