Alternative routing in PTV Developer

Plan optimal and cost-effective routes for any vehicle and provide users with reliable arrival times.
Post Reply
User avatar
Bernd Welter
Site Admin
Posts: 3033
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Alternative routing in PTV Developer

Post 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
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
User avatar
Bernd Welter
Site Admin
Posts: 3033
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: Alternative routing in PTV Developer

Post 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.
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
Post Reply