Skip to content

Interpretation of Bridge Opening

The interpretation of a bridge opening is explained in detail based on the following topics:

In the Bridge Openings data service, a (planned) bridge opening is indicated. This is represented as a SituationPublication, where, in addition to the standard situation definition, a situationRecord is provided with the specialization GeneralNetworkManagement. This specialization is used within the DATEX II standard to describe dynamic traffic situations. In the case of bridge openings, the generalNetworkManagementType is always set to bridgeSwingInOperation.

<situationRecord xsi:type="GeneralNetworkManagement" id="RWS05_NLIJM0233Y5126800143_3157135_01" version="1">
  ..
 <generalNetworkManagementType>bridgeSwingInOperation</generalNetworkManagementType>
</situationRecord>

Bridge Statuses

Bridge statuses are considered from the perspective of road traffic. If a bridge is open, road traffic cannot proceed. Road traffic refers to motor vehicles; bicycle and pedestrian paths via a fixed elevated bridge section are not included.

Bridge statuses are communicated when they are relevant for road users. A bridge opening should preferably be reported as soon as the first signal is given that the bridge is about to open, such as the activation of pre-warning lights. This is the moment when vehicles are no longer allowed to cross. The closing of the bridge is reported when road traffic is no longer obstructed, for example, when the barriers reopen or traffic lights turn green.

The standard event sequence is generally described in Interpretatie handelingen van de wegbeheerder. This section provides specific interpretations regarding bridge openings.

For a bridge opening, the following status definitions apply:

  • Normal or idle status (until b): The event timing is known and is announced in advance.
  • Transition from idle to active status (from b to c): From this moment, the bridge is no longer available for road traffic (e.g., traffic lights are red, or barriers are closed).
  • Active status (from c to d): From this moment, the bridge is fully open for maritime traffic.
  • Transition from active to idle status (from d to e): From this moment, the bridge is no longer fully open for maritime traffic. At the end of this phase, the bridge is closed to ships and available again for road traffic.
  • Normal or idle status (after e): From this moment, the bridge is again available for road traffic.

Availability of Statuses

Not all statuses will be available for every bridge.

Availability of Announcements

If a bridge is closed (normal or idle status) and there is no announcement of an upcoming opening, no status will be reported.

Bridge open

A bridge being open means "the bridge is not accessible to road traffic," regardless of whether the bridge is in the process of opening (beingImplemented) or is already open (implemented). In further examples, implemented is used, but beingImplemented can also be inferred.

Element Domain Explanation
probabilityOfOccurrence certain The status change is certain
operatorActionStatus implemented
beingImplemented		 The bridge opening is in progress
validityTimeSpecification > overallStartTime <dateTime> The start time of the bridge opening ("now")

Brug closed

Element Domain Explanation
probabilityOfOccurrence certain The status change is certain
operatorActionStatus implemented
beingImplemented		 The bridge closing is in progress
lifeCycleManagement > end true The cycle of bridge opening and closing is completed
validityTimeSpecification > overallStartTime <dateTime> The start time of the bridge opening
validityTimeSpecification > overallEndTime <dateTime> DThe end time of the bridge opening ("now")

Bridge Scheduling

It is possible to announce an upcoming bridge opening or a scheduled service for a bridge. A schedule is defined for a specific time, a specified opening duration, and an expected probability that the bridge will actually open at that time. A schedule can also be combined with an actual opening.

Element Domain Explanation
probabilityOfOccurrence riskOf probable See explanation below
operatorActionStatus approved approved is always used for pre-announcements
validityTimeSpecification > overallStartTime <dateTime> The scheduled start time of the bridge opening
validityTimeSpecification > overallEndTime <dateTime> The scheduled end time of the bridge opening

Explanation probabilityOfOccurrence

Value Start Time in the Future Comment
riskOf more than 60 minutes This is a scheduled service (e.g., 24 or 48 hours in advance)
probable between 10 and 60 minutes 60 minutes It is expected with reasonable certainty that the bridge will open (e.g., 20 to 30 minutes in advance)
certain mless than 10 minutes It is very certain that the bridge will open in a few minutes (e.g., 5 to 10 minutes in advance)

Obstructions

Obstructions are categorized based on the type of traffic affected. An obstruction can apply to road traffic, maritime traffic, or both. If only maritime traffic is obstructed, this does not result in DATEX messages, as only messages for road traffic are transmitted. The messages do not differentiate between obstructions for road traffic and those affecting both types. To distinguish obstruction cases, a cause element with causeType set to infrastructureFailure is included in both start and end obstruction messages.

Start of Obstruction

Element Domain Explanation
probabilityOfOccurrence certain Obstructions are not pre-planned
operatorActionStatus implemented The obstruction is immediately active
cause > causeType infrastructureFailure
validityTimeSpecification > overallStartTime <dateTime> The time from which the obstruction is active ("now")

End of Obstruction

At the end of an obstruction, just like when a bridge closes, the situation is concluded using a lifeCycleManagement.end element set to true.

Element Domain Explanation
probabilityOfOccurrence certain Lifting the obstruction is certain
operatorActionStatus implemented The obstruction is being ended.
cause > causeType infrastructureFailure The start time of the obstruction
validityTimeSpecification > overallStartTime <dateTime> The time from when the obstruction is active ('now')
validityTimeSpecification > overallEndTime <dateTime> The end time of the obstruction
lifeCycleManagement > end true The cycle is completed with the cancellation of the obstruction

Example Lifecycle

If a bridge opens within 5 minutes of a scheduled opening (before or after), the existing schedule is adjusted. The table below provides an example of the different statuses in the cycle. The times are shortened to hh:mm:ss format for readability.

Field Name / Step Planning Update Open Close
Timestamp of sending 09:15 09:23 09:23 09:25
situation.version 1 2 3 4
probabilityOfOccurrence probable certain certain certain
operatorActionStatus approved approved implemented beingTerminated
validityTimeSpecification > overallStartTime 09:26:00 09:23:52 09:23:52 09:23:52
validityTimeSpecification > overallEndtime 09:30:00 09:27:52 09:27:52 09:25:22
lifeCycleManagement > management true
example xml See step 1 below See step 3 below See step 4 below

Step 1: According to the schedule, the bridge opens at 09:26:00 for 4 minutes, until 09:30:00

Voorbeeld xml - step 1 
<payloadPublication lang="nl" modelBaseVersion="3" xsi:type="SituationPublication">
    <publicationTime>2023-02-04T12:00:09.138Z</publicationTime>
    <publicationCreator>
        <country>nl</country>
        <nationalIdentifier>NDW</nationalIdentifier>
    </publicationCreator>
    <situation id="PZH02_NLGOU002700535900110_1065435" version="1">
        <overallSeverity>unknown</overallSeverity>
        <situationVersionTime>2017-05-29T09:15:48Z</situationVersionTime>
        <headerInformation>
            <confidentiality>noRestriction</confidentiality>
            <informationStatus>real</informationStatus>
        </headerInformation>
        <situationRecord xsi:type="GeneralNetworkManagement" id="PZH02_NLGOU002700535900110_1065435_01" version="1">
            <situationRecordCreationTime>2017-05-29T09:15:48Z</situationRecordCreationTime>
            <situationRecordVersionTime>2017-05-29T09:15:48.000Z</situationRecordVersionTime>
            <probabilityOfOccurrence>probable</probabilityOfOccurrence>
            <source>
                <sourceName>
                <values>
                    <value lang="nl">PZH02</value>
                </values>
                </sourceName>
            </source>
            <validity>
                <validityStatus>definedByValidityTimeSpec</validityStatus>
                <validityTimeSpecification>
                <overallStartTime>2017-05-29T09:26:00.000Z</overallStartTime>
                <overallEndTime>2017-05-29T09:30:00.000Z</overallEndTime>
                </validityTimeSpecification>
            </validity>
            <locationReference xsi:type="loc:PointLocation">
                <pointByCoordinates>
                    <bearing>250</bearing>
                    <pointCoordinates>
                        <latitude>52.024437</latitude>
                        <longitude>4.667765</longitude>
                    </pointCoordinates>
                </pointByCoordinates>
            </locationReference>
            <operatorActionStatus>approved</operatorActionStatus>
            <complianceOption>mandatory</complianceOption>
            <generalNetworkManagementType>bridgeSwingInOperation</generalNetworkManagementType>
        </situationRecord>
    </situation>
</payloadPublication>

Step 2: The bridge opens at 09:23:52. Following the received 'open' message, the planning is adjusted in this step.

  • The probabilityOfOccurrence is set to certain.
  • The start time is updated to the actual opening time.
  • The end time is updated to the new expected end time (still 4 minutes after opening).

Step 3: The bridge status is updated immediately after Step 2. The operatorActionStatus is set to implemented. The times remain unchanged.

Voorbeeld xml - stap 3 
<payloadPublication lang="nl" modelBaseVersion="3" xsi:type="SituationPublication">
    <publicationTime>2023-02-04T12:00:09.138Z</publicationTime>
    <publicationCreator>
        <country>nl</country>
        <nationalIdentifier>NDW</nationalIdentifier>
    </publicationCreator>
    <publicationTime>2017-05-29T09:23:52.000Z</publicationTime>
    <publicationCreator>
        <country>nl</country>
        <nationalIdentifier>NLNDW</nationalIdentifier>
    </publicationCreator>
    <situation id="PZH02_NLGOU002700535900110_1065440" version="1">
        <overallSeverity>unknown</overallSeverity>
        <situationVersionTime>2017-05-29T10:05:33.000Z</situationVersionTime>
        <headerInformation>
            <confidentiality>noRestriction</confidentiality>
            <informationStatus>real</informationStatus>
        </headerInformation>
        <situationRecord xsi:type="GeneralNetworkManagement" id="PZH02_NLGOU002700535900110_1065440_01" version="1">
            <situationRecordCreationTime>2017-05-29T09:15:48.000Z</situationRecordCreationTime>
            <situationRecordVersionTime>2017-05-29T09:23:52.000Z</situationRecordVersionTime>
            <probabilityOfOccurrence>certain</probabilityOfOccurrence>
            <source>
                <sourceName>
                <values>
                    <value lang="nl">PZH02</value>
                </values>
                </sourceName>
            </source>
            <validity>
                <validityStatus>definedByValidityTimeSpec</validityStatus>
                <validityTimeSpecification>
                <overallStartTime>2017-05-29T09:23:52.000Z</overallStartTime>
                <overallEndTime>2017-05-29T09:27:52.000Z</overallEndTime>
                </validityTimeSpecification>
            </validity>
            <locationReference xsi:type="loc:PointLocation">
                <coordinatesForDisplay>
                    <latitude>52.024437</latitude>
                    <longitude>4.667765</longitude>
                </coordinatesForDisplay>
                <pointByCoordinates>
                    <bearing>250</bearing>
                    <pointCoordinates>
                        <latitude>52.024437</latitude>
                        <longitude>4.667765</longitude>
                    </pointCoordinates>
                </pointByCoordinates>
            </locationReference>
            <operatorActionStatus>implemented</operatorActionStatus>
            <complianceOption>mandatory</complianceOption>
            <generalNetworkManagementType>bridgeSwingInOperation</generalNetworkManagementType>
        </situationRecord>
    </situation>
</payloadPublication>

Step 4: The bridge closes earlier than planned at 09:25:22.

  • The operatorActionStatus is set to beingTerminated.
  • The end time is updated to the actual closing time.
  • The cycle is completed.
Voorbeeld xml - stap 4 
<payloadPublication lang="nl" modelBaseVersion="3" xsi:type="SituationPublication">
    <publicationTime>2023-02-04T12:00:09.138Z</publicationTime>
    <publicationCreator>
        <country>nl</country>
        <nationalIdentifier>NDW</nationalIdentifier>
    </publicationCreator>
    <publicationTime>2017-05-29T09:23:52.000Z</publicationTime>
    <publicationCreator>
        <country>nl</country>
        <nationalIdentifier>NLNDW</nationalIdentifier>
    </publicationCreator>
    <situation id="PZH02_NLGOU002700535900110_1065435" version="1">
        <overallSeverity>unknown</overallSeverity>
        <situationVersionTime>2017-05-29T09:25:22.000Z</situationVersionTime>
        <headerInformation>
            <confidentiality>noRestriction</confidentiality>
            <informationStatus>real</informationStatus>
        </headerInformation>
        <situationRecord xsi:type="GeneralNetworkManagement" id="PZH02_NLGOU002700535900110_1065435_01" version="1">
            <situationRecordCreationTime>2017-05-29T09:15:48.000Z</situationRecordCreationTime>
            <situationRecordVersionTime>2017-05-29T09:25:22.000Z</situationRecordVersionTime>
            <probabilityOfOccurrence>probable</probabilityOfOccurrence>
            <source>
                <sourceName>
                <values>
                    <value lang="nl">PZH02</value>
                </values>
                </sourceName>
            </source>
            <validity>
                <validityStatus>definedByValidityTimeSpec</validityStatus>
                <validityTimeSpecification>
                <overallStartTime>2017-05-29T09:23:52.000Z</overallStartTime>
                <overallEndTime>2017-05-29T09:25:22.000Z</overallEndTime>
                </validityTimeSpecification>
            </validity>
            <locationReference xsi:type="loc:PointLocation">
                <pointByCoordinates>
                    <bearing>250</bearing>
                    <pointCoordinates>
                        <latitude>52.024437</latitude>
                        <longitude>4.667765</longitude>
                    </pointCoordinates>
                </pointByCoordinates>
            </locationReference>
            <management>
                <lifeCycleManagement>
                <end>true</end>
                </lifeCycleManagement>
            </management>
            <operatorActionStatus>beingTerminated</operatorActionStatus>
            <complianceOption>mandatory</complianceOption>
            <generalNetworkManagementType>bridgeSwingInOperation</generalNetworkManagementType>
        </situationRecord>
    </situation>
</payloadPublication>

Explanation of Elements in Bridge Openings

Bridge openings form a small subset of the functional capabilities of DATEX-II messages. The following elements of the situation component are relevant for messages regarding bridge openings.

Element Description
situation.id A situation has a unique ID over time. This means that when a situation arises, it receives an ID that has never been assigned to any other active or past situation. The ID remains the same as long as the situation is active.
The structure of the ID for bridges from BGV is, for example:
The ID consists of three parts separated by two underscores. The part "PNH02_NLZAA0233O6308300007" is unique and always the same per bridge. "PNH02" is the supplier prefix, and "NLZAA0233O6308300007" is the ISRS code of each bridge.
The postfix number (in this example: 314148) is the sequence number and is unique.

The ISRS code is a unique ID for nautical objects. In the future, an interface will be available on vaarweginformatie.nl, where bridge data such as location and bridge height can be retrieved using this ISRS code. | | situation.version | A situation can be modified multiple times during its existence. Each modification receives a version number that is at least 1 higher than the previous version number. | | situation > versionTime | When a situation is modified, the version time is updated to reflect the time of the change. | | situationRecord | A bridge opening, unlike other situations, always consists of only one component. Therefore, within a situation, there is always one situationRecord. | | situationRecord.id | Starts with the value of situation.id, followed by a fixed postfix "_01" (because there is always exactly one situationRecord per situation). | | situationRecord.version | A situationRecord can be modified multiple times during its existence. Each modification receives a version number that is at least 1 higher than the previous version number. | | situationRecordVersionTime | When a situationRecord is modified, the version time is updated to reflect the time of the change. | | probabilityOfOccurrence | The likelihood that the event described in the situationRecord will occur.
Possible values:
- certain
- probable
- riskOf | | source | Since a data provider may supply information (by assignment) from multiple sources, the source of a situation component must always be specified. The mandatory "source" element contains one required sub-element: sourceName. | | validity | The validity indicates the validity period of the situationRecord. Within validity, an overallStartTime is included, which contains the start time of the situation. The overallEndTime contains the end time of the situation (in the case of "bridge closed" or a bridge schedule). | | cause | The cause element can be used to specify the reason for a situation component. This element is only used for bridge openings in case of an obstruction. | | locationReference | This element specifies the location. For bridge openings, it is always of type PointLocation. | | > coordinatesForDisplay | This element displays the location using coordinates based on the WGS84 system. It has two required elements: latitude and longitude. | | > alertCPoint | If a VILD code is known for a bridge, it is included in alertCPoint. For bridges, this is always of type AlertCMethod2Point. If no VILD code is known, this element is entirely omitted. The sub-elements have a fixed value for bridges. See the examples in the appendix. The VILD code is included in the sub-element alertCMethod2PrimaryPointLocation.alertCLocation.specificLocation. | | > pointByCoordinates | This contains the latitude and longitude within the sub-element pointCoordinates, based on the WGS84 system. | | management > lifeCycleManagement | This element is only included when a situation has ended or been canceled. In such cases, the sub-elements end or cancel are set to true. | | operatorActionStatus | The status of the action in the situationRecord. Possible values: .
Mogelijke waarden:
- requested
- approved
- beingImplemented
- implemented
- beingTerminated | | complianceOption | Indicates whether the described situation is an advisory or a mandatory action. For bridge openings, this field is always set to "mandatory." | | generalNetworkManagementType | Description of the situation. For bridge openings, this is always set to "bridgeSwingInOperation." |

Go back to the previous page