Page 1 of 1

Alternative routing in PTV Developer

Posted: Wed Mar 04, 2026 8:13 am
by Bernd Welter
Hi there,
in the old school routing APIs of xRoute1 the mechanism of alternative routings allowed to request them for a list of 2 or more waypoints.

In XRoute2 and Developer Routing API there's a limitation to

xroute2 Technical Concept : Calculate Alternative Routes says:
Alternative routes can only be requested for a route containing exactly 2 waypoints.
  • How can I compensate this in Developer?
  • Do I simply have to create multiple Start-Destination routes such as
    • A:B
    • B:C
    • ...
    • Y:Z
    and concatenate them?
Bernd

Re: Alternative routing in PTV Developer

Posted: Thu Mar 05, 2026 3:41 pm
by Bernd Welter
Received feedback from DEV (Frank S. ;-) ):
Concatenation doesn't seem to be avalid approach: As each leg may contribute with up to 3 alternatives the potential number of combinations too big if you want to apply this on a route with many waypoints. Probably it is more meaningful to look deeper into what you expect from the alternatives (as described in the article above)
Create different alternatives based on regular routings and simply change some of the underlying parameters, e.g.
  • shortest versus fastest
  • different monetary settings
  • timePreferenceOverDistance (new in calculateRoutePost 1.37):
    timePreferenceOverDistance
    integer <int32> [ 0 .. 100 ]
    Specifies the weighting between travel time and travel distance when calculating a route. The value defines the preference for minimizing travel time over minimizing travel distance.

    0: Route is optimized purely for shortest distance.
    100: Route is optimized purely for shortest travel time.
    1-99: A weighted combination of travel time and distance is applied, with higher values giving more importance to travel time.
    For motorized profiles, values between 80 and 90 typically provide the most realistic and efficient routing behavior whereas values below 30 often produce routes that are not realistically driveable. Such low values are mainly useful for determining theoretical lower bounds on distance rather than for practical route planning.
    This parameter will be ignored, if a routeId is specified.