Currente Implementation of the model give a chance to define a situaton record that remain valid for some time using the Overall Period adding information for Valid Period and Invalid Period in which the situation record is not currently valid. 

Once having specified the Overall Period ( in which the situation record is supposed to be valid implicitely ) the  usage of Valid Period could lead to some misunderstandig: in case for the same days or period of time both an invalidPeriod and also a validPeriod is defined.

The modelling of a mobile VMS (component name: VMS) could benefit from the following new attributes:

• remainingAccuCapacity (Minutes)
• qualityOfGpsSignal (Percent)

As there is no datatype for minutes right now, this is also a proposal to add a datatype 'Minutes'.

The component SpeedManagement (instance of SituationRecord) seems to be useful, especially to model a geographical independet region where some speed management action takes place.

But I can imagine several operator actions, where a reduced speed limit goes along with the origin action (par example roadwork, lane mangement, ...). In these cases, creating an extra situation record seems oversized to me.

My proposal is to add the existing attribute 'temporarySpeedLimit' to the OperatorAction component, of course classified as optional.

The DirectionEnum contains - amongst others - the literal 'opposite', but there's no literal to express the original direction.

I suppose to add some literal like 'straight', but maybe native speakers have some better expression.

Background: A roadClosure can be bothWays, opposite or straight.

I have seen several times the need to say just "road blocked" or "exit slip road blocked". This is not possible today in DATEX because road blocked is underneath the Impact class, trafficConstrictionType attribute. Which means you have to have a situationRecord. Normally this would be the source but, if you don't know the source yet?
For road closed, which is similar, this is not a problem becuase there you can create a NetworkManagement class. 
If it is a bug or not I am not sure. 

for RWIS-systems, the following new attributes can be useful:

• Wind: maximumWindDirectionBearing
• PointByCoordinates: altitude
• MeasurementSpecificCharacteristics: altitude (for single measurements)

There are even more specific enumerations (new ones and extending existing ones). It can be discussed whether to insert them into level A or not:

• precipitationIntensityGrading: {noPhenomena, light, moderate, heavy, violent, severe}
• precipitationType - see picture

The current definition of the aggregations "headway" (package "TrafficHeadway") is ambiguous. One needs to add this measure is measured from the head of one vehicle to the head of the continuous vehicle.

Following the preparation of the draft of CEN TS 16157-5 about Measured and elaborated data, some types of data are still missing.
One can mention:
- minimum speed
- maximum speed
as possible new relationships between the classes "TrafficSpeed" and "SpeedValue".

During the preparation of CEN TS 16157-5, several elements can be considered missing in Weather data package;
- pressure (in hPa);
- friction rate (in %);
- subsurface temperature (in °C) with the corresponding measurement depth;
- ice layer thickness;
- ice percentage.
Some metadata are also missing (see RWIS project).

Systems that calculate travel times delays without knowledge of traveltime, e.g. from congestion length. Add an association that allows coding that.