RouteTracker not working

[bastian]

Hi there

I'm working with the ArcGIS Maps SDK for Swift (version 200.8) and using an mmpk that includes routing capabilities via a RouteTask. My goal is to implement navigation with automatic rerouting using RouteTracker. I can generate and display the initial route on the map, but I'm not receiving any trackingStatus updates after enabling rerouting and attempting to track user locations.

Here's a simplified version of my code:

// Route solving (works fine, route displays correctly)

let routeParameters = try await routeTask.makeDefaultParameters()

routeParameters.returnsDirections = true

routeParameters.returnsStops = true

routeParameters.directionsStyle = .campus

// Set stops and solve...

let routeResult = try await routeTask.solve(using: routeParameters)

// Rerouting setup

let reroutingParameters = ReroutingParameters(

routeTask: routeTask,

routeParameters: routeParameters

)

let routeTracker = RouteTracker(

routeResult: routeResult,

routeIndex: 0,

skipsCoincidentStops: true

)!

try await routeTracker.enableRerouting(using: reroutingParameters)

// Observation and tracking in a Task

Task {

for await trackingStatus in routeTracker.$trackingStatus {

guard let trackingStatus else { continue }

await self.updateProgress(using: trackingStatus) // This never triggers

}

for await location in locationModel.locations {

try await routeTracker?.track(location)

}

}

Observations:

• No errors are thrown during route solving, tracker creation, or rerouting enablement.
• The initial route geometry from routeResult.routes is correct and renders properly on the map.
• Locations passed to track(location) are of the following form, e.g.:
  Location: heading 81.42815691730715, speed 0.0, position (x: 8.148408059669505, y: 47.37600416066834, spatialReference: WKID 4326).
• I've confirmed routeTracker.reroutingIsEnabled is true after enabling.
• No updates are received in the for await loop on $trackingStatus, and when checking routeTracker.trackingStatus periodically (via a timer), it also remains nil.

Do you have any idea why I am not getting any trackingStatus updates?

Any insights would be greatly appreciated!

Thanks in advance!

[bastian]

Sorry for the code formatting, unfortunately I could not format it without getting an html error. Also, I cannot edit my own post since I only just created this account.  

// Route solving (works fine, route displays correctly)
let routeParameters = try await routeTask.makeDefaultParameters()
routeParameters.returnsDirections = true
routeParameters.returnsStops = true
routeParameters.directionsStyle = .campus
// Set stops and solve...
let routeResult = try await routeTask.solve(using: routeParameters)

// Rerouting setup
let reroutingParameters = ReroutingParameters(
    routeTask: routeTask,
    routeParameters: routeParameters
)
let routeTracker = RouteTracker(
    routeResult: routeResult,
    routeIndex: 0,
    skipsCoincidentStops: true
)!

try await routeTracker.enableRerouting(using: reroutingParameters)

// Observation and tracking in a Task
Task {
    for await trackingStatus in routeTracker.$trackingStatus {
        guard let trackingStatus else { continue }
        await self.updateProgress(using: trackingStatus)  // This never triggers
    }
    
    for await location in locationModel.locations {
        try await routeTracker?.track(location)
    }
}

[Ting]

Thanks for reaching out. I just want to check if you are using the developer license or not when working with RouteTracker? That is, without setting the license key while developing.

[bastian]

Hi Ting, thanks for your reply. We are not using the developer license, i.e. we are setting the license key during startup. 

[Ting]

Can you try not to set the license key (leave it in the developer mode) to test whether your code works or not? Thanks.

[bastian]

Hi Ting,

Thank you for your help—this indeed resolved the issue. I have two follow-up questions:

1. How can we enable rerouting when setting the license key? 
2. We've noticed that rerouting takes significant time to trigger. Users must deviate considerably from the current indoor route before the SDK recomputes a new path. This threshold feels too high for practical use, as users often need to traverse nearly the entire building for rerouting to occur. Is there a way to configure or adjust this rerouting threshold to make it more responsive?
   
   Thanks in advance for your help!

[Ting]

1. How can we enable rerouting when setting the license key? 

You'll need a Basic or higher license key to use the RouteTracker. See License levels and capabilities for more details.

1. This threshold feels too high for practical use, as users often need to traverse nearly the entire building for rerouting to occur.

I think the threshold is determined by both the edge geometries in the network (i.e. how dense are the roads), and a baked-in magic number for how far off the course to start reroute.

By the way, are you doing indoors navigation with route tracker rerouting?

@FrankKish I'll defer this to our network domain expert Frank as he knows more about how the rerouting internals work.

[bastian]

Hi Ting,

Thank you for your support. We are indeed primarily using the map, navigation, and rerouting features indoors. Could the magic number be based on outdoor or vehicle navigation, which likely requires a higher threshold?

[Ting]

Yes. Our current rerouting implementation is more geared towards a moving vehicle, which wouldn't work very well with pedestrians indoors. There isn't a public interface to fine-tune this behavior currently, unfortunately.

Would you mind logging a suggestion on the Ideas board? Thus, we can triage this improvement in our future releases.

@FrankKish will be able to provide more details.

[FrankK]

Ting's remark above is correct — the existing API is mainly intended for vehicles. It uses a threshold of about 12 meters, plus other factors such as bearing, to decide if a vehicle has deviated from the route.

The distance value used needs to strike a balance between promptly identifying when navigation is off-route vs. false positives, which is dependent on the accuracy of the incoming location data.