PTV xTerritory 1.20.1 Blog Series #3 – Consider incompatibilities of locations and territories

xTerritory-Server-Icon_Puzzleteil-grau_64pIncompatibilities ensure that certain locations are kept separate to certain territories during the location assignment. A typical use case are sales representative that should not serve certain customers or field worker with specific qualifications. So an incompatibility is a property that disqualifies a location for certain territories.

Needs and Benefits

To distribute locations with incompatibilities a PTV xTerritory Server has to be installed and if applicable, a High-performance routing network for calculating routes. With these prerequisites you have the possibility that during the distribution of locations to territories, incompatibilities between locations and territories can be taken into account.This enables you to depict real customer relationships during the planning process. The incompatibilities have to be set as properties in the locations.

WebinarsThere is also an use case documentation for this new feature available. This was the last post of our PTV xTerritory Blog Series and if you want to know more about the PTV xTerritory features and also about the other new features of the PTV xServer 1.20.1 release I recommend you to join our webinar that will be presented on Tuesday. During the webinar you have the opportunity to ask your questions that you might have after the blog series or you maybe will get in the webinar.

Further information about all PTV xServer you can find on our product site.

 

PTV xTerritory 1.20.1 Blog Series #2 – Activity limits for territory planning

xTerritory-Server-Icon_Puzzleteil-grau_64pIn our last post we indicated that activity limits can have a major impact on the tour estimation by setting for example TourPeriodLimits for each territory. By setting activity limits in general you ensure that the sum of all its activities is roughly constrained. Because a territory can only have exactly one limit assigned, the entire territory will be limited by this single constraint on the basis of the sum of all its activities. Having multiple limits constraining one and the same territory is therefore not possible. Furthermore one limit has to be uniquely assigned to one territory.

Why is this useful?

  • Limits give more fine-grain control over the calculation process during territory planning, location assignment and change territories by optionally limiting the sum of activities within territories.
  • Limits constrain the sum of activities of territories (for each territory individually by a unique limit) to fit to individual site conditions or employee experience.

Activity limits when planning territories

The following sample scenario will help you to understand how territories can be limited right from their initial planning by using exact limit values.

  1. There are three existing locations, each given with the following activity values:
    • Location A: activity = 60.0
    • Location B: activity = 50.0
    • Location C: activity = 30.0

    This totals to an overall sum of activity of 140.0 for all three existing locations.

  2. Furthermore, the number of territories to be planned (not yet existing) are: exactNumberOfTerritories = 3.
  1. Finally, the three activity limits (as many as exactNumberOfTerritories) that you want to be considered by the PTV xTerritory server for the three future territories are:
    • Activity limit for future territory I: maximumValue = 30.0
    • Activity limit for future territory II: maximumValue = 60.0
    • Activity limit for future territory III: maximumValue = 50.0

    All three activity limits must not carry any territory assignment, since there are no assignable territories yet.

Planning results
xTerritory Activity Limits

Since the limit values exactly fit the specified activity values, the expected result is that location A is assigned to territory II, location B is assigned to territory III, and location C is assigned to territory I.

There is also an use case documentation available if you need further information and additionally you can see the activity limits in our Code Sample Browser.

After getting to know about the activity limits of the PTV xTerritory Server, you will get a glance at considering of incompatibilities of locations and territories in the next post of our blog series tomorrow.

 

PTV xTerritory 1.20.1 Blog Series #1 – Tour Estimator

xTerritory-Server-Icon_Puzzleteil-grau_64pWith the PTV xServer 1.20.1 Release the PTV xTerritory provides now a quick way to estimate the route travel times within a territory. And this without using the PTV xTour Server.

Different periods

The output format (time in seconds) can be split in service period and driving period. The service period is the activity value of a location interpreted as time in seconds spent for providing service by an employee at a particular location. A driving Period is the server calculated time from one location to another within a territory. It is estimated by the average distance to a location’s nearest neighbouring locations.                                          The estimated driving time from a territory’s center to the territory itself is the average distance to the territory center’s nearest five locations.

Why is this useful?

  • It is very difficult to consider driving periods between locations and service periods at locations in the tour estimation for exactly one territory. For this reason tour estimates on basis of the PTV xTerritory Server are helpful to plan better calculated tours with the PTV xTour Server. So it can be regarded as a prior step for a more fine-grained tour calculation by the PTV xTour server with many more parameters.
  • The PTV xTerritory Server is able to interpret activity values as service periods. For example you can use the activity value as a service period for a service employee who provides at certain service at a location or for a truck driver who unloads certain goods at a location.
  • The PTV xTerritory server allows constraining tour periods by setting a single TourPeriodLimit for each territory. With this, a service tour period can be limited to, for example 8 hours of a typical work day.

How it works

tour_estimationEstimating tour periods for territories is a concept by which activity values of locations are interpreted as service periods, e.g. working hours of a service employee, and driving periods between locations are summed up. This sum then represents an estimated round trip time for a tour through all locations of a territory. This concept provides the basic mechanism for planning, distributing and changing territories according to a tour estimate. It can be regarded as a prior step for a more fine-grained tour calculation by the PTV xTour server with many more parameters. In general, for an estimate of a round trip tour period within a territory, service times and driving times are the only time contributions that are considered. The driving period from a territory center to the territory itself is not considered by the PTV xTerritory’s tour estimation. Nonetheless, this particular driving time is provided within the territory summary as additional value.

Tour estimation and activity limits

Setting limits with the PTV xTerritory server is possible for each territory and the three use cases: territory planning, location assignment and change territories.                       Limiting the duration of a tour period for a territory can have a major impact on the calculation results in all use cases. However, when limits are applied, it can become impossible to find a valid calculation result. If this occurs, more reasonable values for the limits themselves or other planning parameters within the planningProfile need to be considered.                                                                                                                           For further information of activity limits read the next post of our PTV xTerritory 1.20.1 Blog Series.

Additionally to this post you can read its use case documenation here.

PTV xTerritory 1.20.1 Blog Series

xTerritory-Server-Icon_Puzzleteil-grau_64pThe PTV xTerritory Server allows you to plan and change territories and territory centers based on locations such as, for example, customer addresses, or based on smaller administrative area units such as postcode areas. Common use cases are in the management of sales representatives, the planning of warehouse locations and their delivery areas and in delivery planning.

Moreover the PTV xTerritory Server is one of the newbies in our PTV xServer family and was presented in the PTV Server 1.20 Release but nevertheless the 1.20.1 Release already includes three new features of the PTV xTerritory Server which you will discover in the following Blog Series.

#1 Tour Estimator

On our first post we will present you the tour estimator that provides a quick way to estimate the route travel times within a territory without using PTV xTour Server.

#2 Activity limits for territory planning

There we will explain how it is possible to set activity limits for territories to limit the total numer of activities within a single territory.

#3 Consider incompatibilities of locations and territories

Last but not least you will get to know how incompatibilites of locations and territories can be considered in the PTV xTerritory.

1.20.1

If you want to see how these features are included in the PTV xTerritory Server you can join the Webinar on 15th of September additionally to this blog series. There we will present all new features of the PTV xServer 1.20.1 Release including these three.

 

Blog Series Emissions #summary

Emissionsberechnung_80x80Our Emission Wednesdays have come to an end. How did you like our blog series? Got an idea of emissions and their calculation with PTV xServer?

If you are interested in further information, we collected all important links for you:

Webinar

On the 15th of September, there will be a Webinar about the new PTV xServer Release 1.20.1. There, we will also present the new emission calculation with COPERT Australia and UK DEFRA. Interested? Register now.

Any other information needed? Don’t hesitate to contact our Support Team.

Blog Series Emissions #3b Carbon Reporting

Emissionsberechnung_80x80In our last post you learned about carbon reporting with PTV xRoute and comprehensive approaches. Today, we focus on factor-based approaches and their calculation with PTV xRoute.

Factor-based approaches contain emission factors but no consumption values. Consumption values are chosen by the user and can be based on own average fuel consumption or different recommended consumption default values. See our post about emission standards for details. CEN and UK DEFRA are examples for this type of calculation approach.

What you need to have

  • PTV xRoute Server
  • PTV Map including the area where emissions are calculated
  • In case of calculation according to factor-based data approaches there is no specific data or license needed.

What you need to do

You need to send a PTV xRoute request for either the method calculateExtendedRoute or calculateAdvancedTour. The route must at least contain two waypoints and you have to specify the data standard type you want to use e.g. CEN_2012. Additionally, you set the consumption of your fleet or the expected consumption for the route as average or the current measured value. This is described in the proceeding sample request. As a result you receive the values for the available greenhouse gases supported by the standard.

Sample Request

In the PTV xRoute request you specify at least two waypoints and your vehicle routing profile. Set the cenVersion attribute in the ResultListOptions element according to the emission standard you want to use. Don’t be confused about the naming. Here, you can also choose other emission standards than CEN although it is called ‘cenVersion’. All comprehensive approaches will be set via this cenVersion even if they are not CEN. If you want to use CEN 2012, as done in this sample, set the cenVersion to CEN_2012.

...  
"details": {
    "cenEmissionConfiguration": {
      "$type": "CENEmissionConfiguration",
      "fleetSpecificAverageFuelConsumption": "8.7",
      "cenVersion": "CEN_2012"
    },
    "emissions": {
    "$type": "EmissionType",
    "emissionLevel": "BASIC"
    }
  }
}

The fuel consumption is also specified in the request within the “cenEmissionConfiguration”. There are three types of consumptions available which can be set in the request:CENEmissionConfig

In this example the fleet specific average fuel consumption of 8.7 l/100km is used.

The granularity of the emission information returned is handled the same like for comprehensive approaches. There are three emission levels available:

  • BASIC, if you only need the total emissions of the route
  • STATIONS, if you want to obtain the emission per part of the route
  • SEGMENTS, if you additionally want to obtain the emissions per Segment

In the sample request, the level BASIC is used. Therefore, the response contains the total emissions summed up for the entire route.

Sample Response

The listed values in the response depend on the emission standard. Have a look at the documentation for CENEmissions2011, CENEmission2012, CO2DecreeFrance2011, AustraliaNGA2011 or UKDEFRA2014 for detailed information.

The response of the sample request contains several sections:

  • The first general section “Emissions” with the values of the greenhouse gases
  • The second section “vehicleSpecific”: The emissions based on the vehicle specific fuel consumption. The fuel consumption of the vehicle is set by request or in the vehicle Profile.
  • The third section “fleetSpecific”: The emissions based on a fleet specific fuel consumption.
  • The fourth section “basedOnHBEFA”: The emissions based on the fuel consumption as it was calculated by HBEFA 3.1 or higher. The values based on HBEFA 2.1 will not be correct. If you do not want to calculate emissions based on HBEFA, use HBEFAVersion NO_HBEFA.

If you would have provided other consumption values for the route or the actual fuel consumption in the request, there would also be sections for their values in the response:

...
"emissions": {
      "$type": "Emissions",
      "hydrocarbons": 0.26766972687899987,f
      "methane": 0.02248425285899999,
      "hydrocarbonsExMethane": 0.24518547402000002,
      "carbonMonoxide": 15.616740881359998,
      "carbonDioxide": 4.230746730810099,
      "sulphurDioxide": 0.186552613168,
      "nitrogenOxides": 0.8886238383990003,
      "nitrousOxide": 0.053431981629999965,
      "ammonia": 0.5341401447849998,
      "benzene": 0.03460969095000001,
      "toluene": 0.02489327998599999,
      "xylene": 0.020610580044,
      "lead": 0,
      "particles": 0,
      "fuel": 1.3325186338024397
    },
    "cenEmissions": {
      "vehicleSpecific": {
        "$type": "CENEmissions2012",
        "energyUseTank2Wheel": 66.26502399999997,
        "energyUseWell2Wheel": 77.58358399999999,
        "energyUseWell2Tank": 11.31856000000002,
        "co2eTank2Wheel": 4.9801664,
        "co2eWell2Wheel": 5.926809600000004,
        "co2eWell2Tank": 0.9466432000000041,
        "fuelConsumption": 1.5331504000000014
      },
      "fleetSpecific": {
        "$type": "CENEmissions2012",
        "energyUseTank2Wheel": 72.06321359999998,
        "energyUseWell2Wheel": 84.37214759999998,
        "energyUseWell2Tank": 12.308933999999994,
        "co2eTank2Wheel": 5.415930960000001,
        "co2eWell2Wheel": 6.445405439999999,
        "co2eWell2Tank": 1.029474479999998,
        "fuelConsumption": 1.6673010599999993
      },
      "basedOnHBEFA": {
        "$type": "CENEmissions2012",
        "energyUseTank2Wheel": 42.89876173256145,
        "energyUseWell2Wheel": 50.226189978806374,
        "energyUseWell2Tank": 7.327428246244928,
        "co2eTank2Wheel": 3.224068428347786,
        "co2eWell2Wheel": 3.836907881670089,
        "co2eWell2Tank": 0.6128394533223032,
        "fuelConsumption": 0.9925334624459093
      },
      ...

In our PTV xServer Codesample Browser you can find some examples for emission calculation according to Factor-based ApproachesThere, the result is visualized like this:

EmissionCalcCodeSampleBrowser_CENinput

EmissionCalcCodeSampleBrowser_CENoutput

Conclusion

  • PTV xRoute Server allows calculating emissions for the methods calculateExtendedRoute or calculateAdvancedTour
  • For factor-based approaches no additional data and licensing is required
  • In the request you specify route, vehicle type and emission standard type and for factor-based approaches the fuel consumption
  • As a response you receive the values for the available greenhouse gases supported by the standard as provided in the request for the given consumption value type: fleet, route or actual consumption specific.

An use case documentation can be found here. Please remember that UK DEFRA is only available with the new PTV xServer 1.20.1 release, which has just been released yesterday. With this, the use case description will be updated containing the UK DEFRA information and other improvements. Just take another look on the use case docu right now.

Further links:

BlogSeriesThis was the last post of our “Emission Wednesday Series”. We hope you did get an impression of emission calculation with PTV xRoute. A short summary of all topics will follow next week.