ORCAv2 (see ORCA2.xsd) is a PTV protocol designed to handle large amounts of data concerning transportation information over the network.
For all ORCA2 formatted responses, the timestamp information format is compliant with standard ISO 8601.
ISO 8601 provides several options that can be used to format a timestamp.
Optima supports XML dates, so you can either express an explicit timezone, or omit it.
If you push data without an explicit time zone, it is considered as expressed in the local time zone.
If you push data with an explicit timezone, it is nonetheless converted to the local timezone and stored accordingly.
The local date and time are set according to the AS process, and they are usually the same as those of the physical server where the AS is running.
Important: An ORCA2 formatted response can embed DATEXII elements, that may use different timestamp formatting.
Example of a DB set in the Europe/Rome timezone
In winter (UTC+1 in Rome), expressing an explicit timezone:
INPUT=2015-12-11T17:10:00.000+02:00
In DB=2015-12-11 16:10:00.000
In summer (UTC+2 in Rome), expressing an explicit timezone:
INPUT=2015-05-11T17:10:00.000+02:00
In DB= 2015-05-11 17:10:00.000
Handling time zones
In a typical Optima installation, the main components (Optima AS, Optima DB, TRE) are in the same timezone.
The reference timezone is that of the Optima AS (the timezone set for the daemon process or service running Optima).
In this case, when you define a payload it is not necessary to set the timezone.
The common best practice can be summarized as in the list:
- publicationTime=creationTime=now
- endTime<=creationTime
- startTime=endTime - [period of the data push]
- [period of the data push]=5 minutes
startTime and endTime define the real validity interval of the collected data.
Depending on the sensor technology, the data may be collected for the past five minutes, be elaborated and then pushed into Optima every 5 minutes with a slight delay.
Important: All timestamps are optional.
If they are not specified, they are set as:
- publicationTime=creationTime=now
- endTime= now-1 minute
- startTime=endTime - 5 minutes
In the next examples, you can see two other payloads without timezones.
Payload without timezone.
In the payload we see a difference of 5 minutes between startTime and endTime.
The publicationTime and creationTime are not specified.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Orca2Model xmlns="http://sistemaits.com/orca2/1">
<exchange>
<provider>myprovidername</provider>
</exchange>
<payloadPublication xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MeasuredPublication">
<MetaInfo>
<LocationUsed xsi:type="LocationUsedTDE" type="Street"/>
</MetaInfo>
<measuredData>
<trafficElement xsi:type="StreetTraffic" strt="1230194803510957" fsnd="102931237978" lane="1" flow="100" sped="31.389913999999997" accu="80" startTime="2022-02-28T10:20:00" endTime="2022-02-28T10:25:00"/>
</measuredData>
</payloadPublication>
</Orca2Model>
In the next payload, the endTime is not specified, because it implicitly coincides with the publication time.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Orca2Model xmlns="http://sistemaits.com/orca2/1">
<exchange>
<provider>myprovidername</provider>
</exchange>
<payloadPublication xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MeasuredPublication">
<MetaInfo>
<LocationUsed xsi:type="LocationUsedTDE" type="Street"/>
</MetaInfo>
<measuredData>
<trafficElement xsi:type="StreetTraffic" strt="1230194803510957" fsnd="102931237978" lane="1" flow="100" sped="31.389913999999997" accu="80" startTime="2022-02-28T10:20:00"/>
</measuredData>
</payloadPublication>
</Orca2Model>Topics in this section