information about vehicle mobility for vehicle related situation records (Bugzilla Bug 415)

[datexii]

This issue was created automatically with bugzilla2github.py

Bugzilla Bug 415

Date: 2022-10-19T17:46:01+02:00 From: @ingeniumfaber To: Bard de Vries <b.devries@u-trex.nl> CC: @iancornwellmottmac

Last updated: 2023-12-07T11:54:10+01:00

[datexii]

Comment 1734

Date: 2022-10-19 17:46:01 +0200 From: @ingeniumfaber

we cannot explicitely express in DATEX II Situation record originate by a vehicle the information the vehicle is moving so the related location information linked to the situation record is to be frequentely updated in case of information services where location accuracy is crucial.

it seems useful to introduce a boolean attribute to indicate a "movingVehicle" status for the situation record so that we can assume the location is to be tracked with high frequency based on the use case. this attribute could be linked to VehicleObstruction and RoadWorks class (or MaintenanceVehicles) or even associated to location referencing itself in a more general way

[datexii]

Comment 1879

Date: 2023-11-28 14:29:57 +0100 From: @iancornwellmottmac

If this is about a roadworks/maintenance situation moving, you can do that in Roadworks already. Or if it is about slow-moving obstructing vehicles, the concept of moving vehicle is inherent. Such a feature might be redundant, so the request is presumably about convenience. We are not sure that this feature is worthwhile overall.

There are related cases of rapid change of location where the focus is not the vehicle but the change of location. This is known to be a problem for some service providers. Should we give some indication at the general level of whether the Situation is relatively fast moving? How would that be defined? Some service providers have considered they might take a moving point and publish a warning on a linear location instead.

Requires more thought - enumerate the kinds of situation where the concept makes sense and how we would identify the movement today.

[datexii]

Comment 1883

Date: 2023-12-01 14:13:51 +0100 From: @iancornwellmottmac

The original comment identifies two specific cases: VehicleObstruction and Roadworks. In the case of Obstruction there is already an optional Mobility class, with mobility type and speed, as well as VehicleObstruction having vehicleObstructionType from which the likely movement characteristics can be inferred. In the case of Roadworks, it also has the same optional Mobility class.

Apart from those cases:

• RoadOrCarriagwayOrLaneManagementType has a type rollingRoadBlock "Traffic officers or police are driving slowly in front of a queue of traffic to create a gap in the traffic to allow for clearance activities to take place in safety on the road ahead." So you can see that the location will move.
• queues tend to propagate upstream, but that is an inherent concept that shouldn't take up additional redundant data to express.

This check seems to confirm that the request is redundant, and I don't think it would be a good idea to add a redundant (and potentially inconsistent) attribute at a more general level for convenience. Unless I am misunderstanding the intention of this bug, I suggest we reject it.

[datexii]

Comment 1888

Date: 2023-12-07 11:31:26 +0100 From: @iancornwellmottmac

(another case is wrong-way vehicle which inherently moves quickly)

[datexii]

Comment 1889

Date: 2023-12-07 11:33:49 +0100 From: @iancornwellmottmac

Use cases have different requirements. If you are publishing every 10 minutes, and you have a wrong-way vehicle, there is a suggestion that you should not publish a precise point location but a stretch. But on the other hand, if consumers understand that the publication is at a point-in-time with a period of 10 minutes, they can interpret a point accordingly. Either way, this may not change the data model.

[datexii]

Comment 1890

Date: 2023-12-07 11:54:10 +0100 From: @iancornwellmottmac

More suggestions on call: There is also a suggestion that such fast-changing data should be put into a different complementary publication. e.g. in slow moving roadworks, publish the situation with a stretch that is valid for a period, and for anybody who need the detail, another publication with a shorter period with a more specific stretch or point.

(That seems feasible for relatively slow moving events, but for wrong-way vehicle one stretch may not be enough for the period.)

Suggestion that the limitations of SituationPublication should be clearly expressed (that would be a first - we normally say here are the models, implying the use cases are up to you, use the models if they suit your use cases.)

Journalistic use case for SituationPublication is different to a use case that needs the precise positions of moving vehicles related to situations.