2.1

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.

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).

When the new feature to deselect enumeration litterals was introduced, the feature to generate schema from DD profile was not updated. So litterals was ignored.

Fixed, will be in next release.

Software that automatically generates a XML schema from a UML model. Requires Windows and Microsoft .Net framework 2.0.

This is version 2.1 (build 4563)

In 2.1 we introduced to read the schema name from configuration, to be abel to produce same name as in 2.0. However we discovered, in last minute, that this was wrong. The schema name shoudl be DATEXIISchema_[model base version]_[tool major version]_[tool minor version].xsd

The last minute change did not revert back to the old rules, instead we just changed to configuration file. That will create a wrong schema name if you use a 2.0 model or if you use a future version. So the best is to revert back to old rules.

In the DATEX-Tool, it is not possible to restrict the multiplicity of an attribute, which is mandatory (at least I suppose this is the point).

Example:
'accidentType' has multiplicity 1:*. It is not possible to change it to 1:1, which should be possible according to the rules. The Tool does not accept the value 1 - it does block any further action in this case, until the 1 is deleted again.

Note: This problem differs from the one described just before.

In the current version of the DATEX Tool, multiplicities and enumeration literals can be modified according to the rules of DATEX II 2.1, but these changes don't have any effect on the resulting schema (i.e. all literals are present, multiplicities are unchanged).