We are currently clearing out previously loaded trajectories when conversion requests are initiated, so the viewer is empty if the conversion request is cancelled and the user goes back to /viewer.
Desired behavior: if the conversion process is cancelled, and the user navigates back to the viewer, the previously loaded trajectory should still be there.
Acceptance Criteria
A user can navigate back to their previously loaded trajectory when cancelling an autoconversion request.
Details
Should probably also retain time stamp, agent selections, and playback settings (looping) etc?
Make sure we are correctly managing websocket connections and not opening and closing too many connections to the server.
Use Case
We are currently clearing out previously loaded trajectories when conversion requests are initiated, so the viewer is empty if the conversion request is cancelled and the user goes back to
/viewer.Desired behavior: if the conversion process is cancelled, and the user navigates back to the viewer, the previously loaded trajectory should still be there.
Acceptance Criteria
A user can navigate back to their previously loaded trajectory when cancelling an autoconversion request.
Details
Should probably also retain time stamp, agent selections, and playback settings (looping) etc? Make sure we are correctly managing websocket connections and not opening and closing too many connections to the server.