Let's eliminate this one. We don't care about the edges for now.

There is a table m_measurement_directions and I think this would be the result * camera_inverted = - 1 => flop * measured_along_vehicle_dir = -1 => flip + flop + toggleLR * measured_along_kilometrage_dir = -1 => flip + flop + toggleLR

with rotate180 = flip + flop

Let's skip the inverted edge for now, as we can subsume them with track direction, if necessary.

Currently the axis does not know about the kilometrage, so it might not be wise to define the factors based on something not known up front. Suggestion: * Vehicle has front and back, so these are defined relative to vehicle - Camera Scan Direction is relative to vehicle direction - camera_direction_inverted - Driving Direction is relative to vehicle direction with forward = positive velocity - measured_along_vehicle_dir * Vehicle has no knowledge about GIS, so these are defined in the postprocessing: - vehicle orientation - relative to edge direction: measured_along_edge_dir - Track direction - relative to track direction: measured_along_kilometrage_dir