ORCAv2 (see ORCA2.xsd) is a PTV protocol designed for handling 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 can use different timestamp formatting.
Example of a DB set in 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 under the same time zone.
The reference time zone 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's not necessary to set the time zone.
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 is the real validity interval of the collected data.
Depending on the sensor technology, the data could 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, two other payloads without time zones.
Payload without time zone.
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