You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of v0.40.0, the RouteResponse(matching:options:credentials:) initializer, which Directions.calculateRoutes(matching:completionHandler:) uses to convert a Map Matching API response to Directions API–like model objects, produces Route objects whose shapes are misencoded. The coordinates are all shrunken towards Null Island. For example, a route around Cupertino only has coordinates off the coast of Liberia.
RouteResponse(matching:options:credentials:) encodes each Match object as JSON then decodes it as a Route. Whenever we encode or decode to and from a Route or Match, we need to pass in an options object; otherwise, PolyLineString(from:) defaults to RouteShapeFormat.default, which is Polyline5 encoding. We were setting the options on the decoder but not the encoder. Had the options been provided in both directions or omitted entirely, the geometry would’ve been roundtripped correctly. But d98e073 for #406 added the options in only one direction:
The following test is supposed to exercise this scenario, but it gets lucky because it doesn’t specify a shape format explicitly, so both the encoder and decoder end up using the same Polyline5 encoding by default:
If I modify the test to set the shape format explicitly, the test fails:
diff --git a/Tests/MapboxDirectionsTests/RoutableMatchTests.swift b/Tests/MapboxDirectionsTests/RoutableMatchTests.swift
index 7d84bd5..047a0db 100644
--- a/Tests/MapboxDirectionsTests/RoutableMatchTests.swift+++ b/Tests/MapboxDirectionsTests/RoutableMatchTests.swift@@ -29,6 +29,7 @@ class RoutableMatchTest: XCTestCase {
var routeResponse: RouteResponse!
let matchOptions = MatchOptions(coordinates: locations)
+ matchOptions.shapeFormat = .polyline6
matchOptions.includesSteps = true
matchOptions.routeShapeResolution = .full
for waypoint in matchOptions.waypoints[1..<(locations.count - 1)] {
Test Case '-[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch]' started.
/Users/mxn/hub/MapboxDirections.swift/Tests/MapboxDirectionsTests/RoutableMatchTests.swift:71: error: -[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch] : XCTAssertEqual failed: ("0.0") is not equal to ("33.0")
/Users/mxn/hub/MapboxDirections.swift/Tests/MapboxDirectionsTests/RoutableMatchTests.swift:72: error: -[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch] : XCTAssertEqual failed: ("-1.0") is not equal to ("-117.0")
/Users/mxn/hub/MapboxDirections.swift/Tests/MapboxDirectionsTests/RoutableMatchTests.swift:99: error: -[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch] : XCTAssertEqual failed: ("0.0") is not equal to ("33.0")
/Users/mxn/hub/MapboxDirections.swift/Tests/MapboxDirectionsTests/RoutableMatchTests.swift:100: error: -[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch] : XCTAssertEqual failed: ("-1.0") is not equal to ("-117.0")
Test Case '-[MapboxDirectionsTests.RoutableMatchTest testRoutableMatch]' failed (18.400 seconds).
/cc @mapbox/navigation-ios
The text was updated successfully, but these errors were encountered:
As of v0.40.0, the
RouteResponse(matching:options:credentials:)
initializer, whichDirections.calculateRoutes(matching:completionHandler:)
uses to convert a Map Matching API response to Directions API–like model objects, produces Route objects whose shapes are misencoded. The coordinates are all shrunken towards Null Island. For example, a route around Cupertino only has coordinates off the coast of Liberia.RouteResponse(matching:options:credentials:)
encodes each Match object as JSON then decodes it as a Route. Whenever we encode or decode to and from a Route or Match, we need to pass in an options object; otherwise,PolyLineString(from:)
defaults toRouteShapeFormat.default
, which is Polyline5 encoding. We were setting the options on the decoder but not the encoder. Had the options been provided in both directions or omitted entirely, the geometry would’ve been roundtripped correctly. But d98e073 for #406 added the options in only one direction:mapbox-directions-swift/Sources/MapboxDirections/RouteResponse.swift
Lines 48 to 52 in 2885885
The following test is supposed to exercise this scenario, but it gets lucky because it doesn’t specify a shape format explicitly, so both the encoder and decoder end up using the same Polyline5 encoding by default:
mapbox-directions-swift/Tests/MapboxDirectionsTests/RoutableMatchTests.swift
Lines 69 to 73 in 2885885
If I modify the test to set the shape format explicitly, the test fails:
/cc @mapbox/navigation-ios
The text was updated successfully, but these errors were encountered: