Calculating a route with rectangular geographic restrictions

This use-case describes how to calculate a routeClosed A route corresponds to a path of a vehicle through the underlying transport network. The main attributes of a route are the distance and the time that the vehicle travels along the path. with rectangular geographic restrictions.

Benefits

  • Using the xRoute API makes it easy to obtain routes based on rectangular geographic restrictions.
  • Using the xData API makes it easy to create new high-performance routing networks using search space bounds.
  • Using the rectangular geographic restrictions could enhance the performance especially for the creation of high-performance routing networks and distance matrices.

Prerequisites

Please ensure following prerequisites are fulfilled before you start with the use case:

  • Installed and licensed PTV xData service
  • Installed and licensed PTV xRoute service

Programming Guide

In this example we provide our waypointsClosed A waypoint is a geographic location used to specify start, destination and possible stopovers for a route. A, B and C as x, y coordinates in the default EPSG:4326 format (see RequestBase.coordinateFormat).

At the very beginning a high-performance routing network with rectangular geographic restrictions is calculated.

A calculateRoute is then done with routing type HIGH_PERFORMANCE_ROUTING to use the high-performance routing network previously calculated.

Once xRoute has processed the request, the callback routingCompleted is invoked which gives us access to the result of the calculation in the form of a RouteResponse object which contains the response routing type.

After the route is calculated successfully, the high-performance routing network is deleted.

One of the downsides when using rectangular geographic restrictions is that we can get a wrong (or bad) route because of the limitation of search bounds. This problem is illustrated with the next two samples.

This first example below shows how to request a calculateRoute when the search space bounds have no effect on the route. The rectangle is big enough to contain the optimal route.

This second example below shows how to request a calculateRoute when the search space bounds have an effect on the route. The route is modified so as it doesn't go beyond the rectangle. The results show that this is not the optimal route.

Please refer to the documentation of the RouteRequest for more information on request parameterization.

The rectangular geographic restrictions with search space bounds can even be used in a calculateRoute request without high-performance routing networks.