Route Access Restrictions visualisation #3603
Conversation
Udumft
added
platform parity
Udumft
force-pushed
the
vk/844-access-restrictions
branch
from
b4af7ca
to
5d85aff
Compare
| @@ -47,7 +47,7 @@ class NavigationMapViewTests: TestCase { | |||
| ]) | |||
|
|
|||
| XCTAssertEqual(congestionSegments.count, 1) | |||
| XCTAssertEqual(congestionSegments[0].0.count, 10) | |||
| XCTAssertEqual(congestionSegments[0].0.count, 6) | |||
There was a problem hiding this comment.
This is caused by the change in merging method. Previously it would duplicate bordering points. For example when merging segments with coords 1 -> 2 -> 3 it would result in [1, 2, 2, 3]. With change above it would result in [1,2,3].
I didn't notice changes in resulting route lines drawing, but TBH I didn't test it too much. Does anybody knows if such merging was intended.
| /** | ||
| Attribute name for the route line that is used for identifying restricted areas along the route. | ||
| */ | ||
| public let RestrictedRoadClassAttribute = "isRestrictedRoad" |
There was a problem hiding this comment.
There are also few convenience constants exposed to user, like table of route line widths depending on zoom level (RouteLineWidthByZoomLevel). The only value for restricted areas display I could think of is dash array attributes which may be potentially useful, but I doubt it since if user is implementing his own layers he won't need to align dashing parameters to anything mapbox-provided.
Udumft
force-pushed
the
vk/844-access-restrictions
branch
from
5d85aff
to
b55430b
Compare
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
Udumft
force-pushed
the
vk/844-access-restrictions
branch
from
b55430b
to
95ca99b
Compare
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
| var fractionTraveled = 0.0 // not traversed at all | ||
| var routeLineGradient = navigationMapView.routeLineRestrictionStops(features, fractionTraveled: fractionTraveled) | ||
| XCTAssertEqual(routeLineGradient[0.0], navigationMapView.routeRestrictedAreaColor) | ||
| XCTAssertEqual(routeLineGradient[1.0], navigationMapView.traversedRouteColor) |
There was a problem hiding this comment.
After modifications of route line gradients calculation in this commit this test starts failing. I see that it has changed how ending segment is handled, but it still looks odd to me: In this particular case routeLineGradient[0.75] == routeRestrictedAreaColor (0.75 is the border between 2nd restricted segment and last non-restricted segment). Since it is "not soft" gradient, I would expect that routeLineGradient[0.75.nextUp] == traversedColor, but that is not the case and in fact it's routeLineGradient[0.75.nextUp.nextUp] == traversedColor. I am not sure why there is this little gap and how it appears.
@ShanMa1991 maybe you could help me with it?
There was a problem hiding this comment.
Hi, yes, this gap exits. Because right now when we choose soft, we expect that the gradient stop of one segment is the [segmentStartPercentTraveled + stopGap, segmentEndPercentTraveled - stopGap]. Because the stopGap is based on the length of current congestion segment length, which would avoid the out of bound issue between a very long segment and a very short segment.
And when we choose sharp gradient, we actually still use the constraints of the current segment as [segmentStartPercentTraveled.nextUp, segmentEndPercentTraveled.nextDown]. So for example, for the 3rd segment in this test, the actual end percentage is 0.7500000000000001, but we record the 0.75 for its end. And for the 4th segment, the actual start percentage is 0.7500000000000001, because it's different than the 3rd one, we record it with 0.7500000000000002 as the start. Thus there's a 0.0000000000000002 gap between the 3rd segment and the 4th segment in the line gradient stops. It's larger than the previous 0.0000000000000001 but could avoid the check of next segment and the segment length issue.
And for the 0.0000000000000002 gap, because right now when we choose sharp gradient, we're using the following Expression:
lineLayer.lineGradient = .expression(
Exp(.step) {
Exp(.lineProgress)
UIColor.blue
0.75
UIColor.blue
0.7500000000000002
UIColor.red
}
)
And we have a following result, which still shows a sharp transition in the lowest zoom level.
And the edge case is that what if the fractionTraveled is in this gap, for example, 0.7500000000000001. In this case, the minimumSegment would record (0.75, associatedFeatureColor), and then apply to the gradientStops. There's still a sharp change between the two segments.
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
Sources/MapboxNavigation/NavigationMapView+VanishingRouteLine.swift
Outdated
Show resolved
Hide resolved
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
…ine; added constants for colors; added delegate methods for layer and shape configuration; included restrictions layer to layers handling pipeline; update calculating features, stops, road classes; added new route line types for layer identifier
…adsFeatures calculations; refactored route line gradients stops calculation for congestion and restricted areas;
…restrictions class to route fixture; removed obsolete argument for restrictedRoadsFeatures calculation.
…abling restricted areas gradient drawing depending on corresponding property and routeLineTracksTraversal.
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
Udumft
force-pushed
the
vk/844-access-restrictions
branch
from
6b036ec
to
2cdf5cd
Compare
|
No breaking changes detected in MapboxCoreNavigation |
|
No breaking changes detected in MapboxNavigation |
| public var showsRestrictedAreasOnRoute: Bool = false { | ||
| didSet { | ||
| if let routes = self.routes { | ||
| show(routes, legIndex: self.currentLegIndex) |
There was a problem hiding this comment.
So if we make resume button to switch on/off of navigationMapView.showsRestrictedAreasOnRoute during active navigation, we have the following result, because if we call the navigationMapView.show(_:legIndex) directly, the previous stored route points and upcoming route point index are cleared. There'll be a 1 second gap of showing the whole route line when routeLineTracksTraversal enabled. Until the next routeProgress comes in and re-store the upcoming route point index and fractionTraveled, could we get the right route line display.
But we could make this as a tail work because right now the CarPlay start with the showsRestrictedAreasOnRoute enabled or disabled, the gap is very small and almost non. There's not much case that it would be turned on/off during active navigation.
There was a problem hiding this comment.
Added a ticket for tracking this.
This PR adds possibility to draw portions of a route which pass restricted roads.
The overlay is implemented as a separate customizable route line layer
.