Electronic horizon

[chezzdev]

Description

This PR targets resolving EHorizon v3 integration.

Implementation

In the scope of the full integration, we would like to wrap all the generated NavigationNative APIs with Swift classes as well as provide some helper functions like mpp().

The initial implementation provides access to the main entry objects (GraphAccessor, RoadObjectsStore) via generated bindings through RouteController and PassiveLocationDataSource as well as adds the ability to subscribe to EHorizon update events.

[1ec5]

This PR is currently based on the bamx23/fix-objc-import branch, which should be unnecessary once the fixes in #2829 are in place.

[Udumft]

I understand that this is just the copy-pasted description from RoadObjectEdgeLocation, but I've read it several times and still didn't understand what it has to do with line-like road objects. I believe there are few typos in there :)

[etl]

That's just a typo: expect = except.

[Udumft]

Could we use this struct outside EH context? There are some manipulations with road labeling so maybe we could refactor that later and benefit from this struct in multiple places?

[1ec5]

Related: #2834 (comment). It might even make sense for MapboxDirections to consolidate various RouteStep properties into a public Road type that we could reuse here and elsewhere in MapboxCoreNavigation.

[1ec5]

More to do before this PR is in a minimally landable state:

• Document new public classes and structs
• Mention new entry point methods and standalone classes in the changelog
• Disable the e-horizon unit test due to Navigator.shared only accepts access token from Info.plist #2851

Some of the review feedback above would also be important to address as tail work immediately after landing:

• Unify electronicHorizonDelegate within Navigator: Electronic horizon #2834 (comment)
• Separate isEnterFromStartOrExitFromEnd from its type: Electronic horizon #2834 (comment)
• Weaken ownership of the the internal RoadObjectsStore: Electronic horizon #2834 (comment)
• Nest various road-related types under a RoadObject Road struct (which would be empty and unused for now): Electronic horizon #2834 (comment)
• Reduce redundancy between RoadObjectType, RoadObjectMetadata, and RouteAlert.Alert

[1ec5]

If you need to install this branch before it lands:

• For CocoaPods, use the podspecs and Podfile snippet in this gist.
• For SPM, use the following dependency:

  .package(name: "MapboxNavigation", url: "https://github.com/mapbox/mapbox-navigation-ios.git", .branch("pad-ehorizon"))

[1ec5]

@SiarheiFedartsou it’d be great if you or someone else familiar with the navigator’s inner workings could comment on these questions at some point:

• Percentage “along” a point? Electronic horizon #2834 (comment)
• Do the percentages from the start to the location and from the location to the end always add up to the object’s total length? Electronic horizon #2834 (comment)

I’m going to merge this PR in the meantime. There are a number of opportunities to continue refining the API anyways:

• Reduce redundancy between RoadObjectType, RoadObjectMetadata, and RouteAlert.Alert – apparently this will be driven by an upcoming change in MapboxNavigationNative: Unify RoadObjectType, RoadObjectMetadata, and RouteAlert.Alert #2868
• Consider eliminating ElectronicHorizon in favor of putting the start edge directly in the notification’s user info dictionary, then rename nested types like ElectronicHorizon.Edge: Electronic horizon position notification should directly contain pointer to edge tree #2906
• Consider consolidating RoadName and other road object–related types under a unified type and returning all the information about it at once: Electronic horizon #2834 (comment)
• Continue to refine and copyedit documentation comments like Electronic horizon #2834 (comment)