Positioning Information

To calculate an ETA, position information has to be sent to PTV Drive&Arrive regularly. As an example, current position information can be received from

• OBU via real tracking services which aggregates position information of different suppliers

• a mobile application which sends position information direct to PTV Drive&Arrive in appropriate format

• a fleet management solution extension which will get information form specific systems and send to PTV Drive&Arrive

• any component in your IT infrastructure or your transport chain that is aware of the position

Position information must be send together with SCEMID to identify corresponding trip and stop. This requires SCEMID handling in real tracking services, mobile applications and fleet management solution extensions

Will all positions be used to calculate a current ETA?

Regular position updates for an exact ETA calculation are expected. 'Regular' means not every second and not once per hour. It would be useful to have position information between every minute up to every 3 minutes. If we receive too many positions in a short time period, we may ignore them.

If positions have accuracy, speed and heading, these parameters will be used. If such information is absent, please do not send it to PTV Drive&Arrive. Please do not send heading = 0 or speed = 0 in absence of such information. Positions with bad accuracy will be ignored.

Positions should be in chronological order. In case of disorder, we will ignore positions send with time stamps older than events send before.

In order to detect breaks or rest positions must be sent right from the start of the trip.

 

How often an ETA will be calculated?

Only position updates are able to trigger an ETA calculation, but not every update will actually lead to an ETA update. If PTV Drive&Arrive does not receive position updates for a specific stop anymore, an ETA violation will not be created at present. At the moment, ETA is re-calculated at a maximum every 9 minutes as default. See: ETA Calculation Interval

Please refer to the description of the API (object "event") to see an example of a request for position updates

 

What data is needed for an event in which format?

In order to process events in PTV Drive&Arrive, coordinates in WGS 84 are expected and a time stamp of the detected position. In order to calculate a realistic ETA, we need periodic position information. A position update must contain a SCEMID to identify the stop to which the data is sent for.

How an SCEMID is handed over from transport service provider to someone who sends positions?

The transport service provider has to handover the SCEMID to someone how sends positions. In addition, the owner of the SCEMIDs can distribute them freely among all stakeholders in its transport chain.

To send positions to the PTV Drive&Arrive the POST method: https://driveandarrive-v1.cloud.ptvlogistics.com/em/event with HTTP-POST must be called:

{
   "source": "PTVEMAPP_iOS_1.0",
   "event": {
      "eventType": "POSITION",
      "eventSubtype": "GPS",
      "visibility": false,
      "eventPayLoad": {
         "heading": 34,
         "speed": 4,6,
         "accuracy": 5,
         "coordinate": {
            "locationX": 8.000000,
            "locationY": 49.000000
         },
         "time stamp": "2014-03-07T07:00:00.000+01:00",
      },
      "scemid": "P27SAAEKNH"
   }
}

The SCEMID send in the event POST corresponds to the next destination station on this tour. The time stamp is the current time of the position locationX, locationY in WGS 84 coordinates.

Who can see positions send through events?

Coordinates sent via POSITION event (visibility = true) to PTV Drive&Arrive can only be get via journal GET having the appropriate token and a corresponding SCEMID. Coordinates will not be sent in notifications and are not accessible elsewhere.

How can the sender of a position update avoid that his position is visible?

The sender of the position update can avoid that his coordinates are visible over the PTV Drive&Arrive API by setting visibility (true = visible, false = invisible) attribute in event POST. If visibility is set to false any coordinates are invisible in the tour journal and will only used for calculation of ETA.

How ETA is calculated if stop sequence is not as planned.

Assume we have a trip with 5 stops and driver starts with stop 4. After loading he sends the state DEPARTED for stop 4. Now he is driving to stop 2 and new stop sequence is 2,3,5 (stop 4 was already processed and ETA is not calculated for this stop again. At stop 2 driver recognized that he forgot something at stop 4. He is driving to stop 4 again, i.e. stop sequence will be 4,5. The state DEPARTED of stop 4 is ignored.