2.2 Version
In the validty model, the class "TimePeriodOfDay" is an aggregation to the "Period" class.
The only possibility is to specialise this class by "TimePeriodOfDay", there are no other links or attributes.
I'm wondering, if this class cannot be removed to introduce a direct aggregation between "Period" and "TimePeriodByHour".
The Temperature class can be used in MeasureDataPublication to measure airTemperature, dewPointTemperature, maximumTemperature and minimumTemperature.
Currently, the data dictionary can be created out of the XMI-input file. All elements included in this file will be part of the dictionary (anyway, there is a possibility to [de]select packages). But there is no correspondence between the dictionary and the profile selection you might perform on this input file.
The linear by coordinates extension allows to specify linear locations by a number of points
represented by coordinates. There must be a start and an end point together with an arbitrary
umber of intermediate points.
AlbrechtConsult is a consulting company specialised on planning, realisation and operation of systems related to traffic engineering. Within the last 10 years it has developed to become the leading independent IT and organisation consultant in the segment of road traffic systems, traffic management and telematics.
The enumeration "MeasuredOrDerivedDataTypeEnum" has - among others - two literals:
But there are no classes to represent these type of data like it is for all other literals (i.e. there is no component "RadiationInformation" and no component "PressureInformation").
Constraints like "One of these three clases must be used." are written in form of comments in the UML model right now.
There is no possibility to tranfer these constriction into the schema (and to check this constriction within an resulting XML).
This would be nice to have, probably with using something like OCL.
This is an updated version of the previous 1.3 version. This version mainly upgrades to version 2.2 of DATEX II and should be compliant with OpenLR version 1.5 and forward, now also supporting Areas!
This is an draft level B extension for OpenLR.
OpenLR is an open, compact and royalty-free dynamic location referencing method which enables reliable data exchange and cross-referencing using digital maps of different vendors and versions. OpenLR helps to enhance existing applications and generates opportunities for new services. It facilitates new business opportunities in various areas of Intelligent Transport Systems (ITS) such as traffic information services, map content exchange and Cooperative Systems where precise and compact dynamic location information is needed.
Dynamic location referencing is a requirement for many ITS and LBS (location based systems) systems and services. The use of various location reference methods will limit the interoperability of systems. A universal standard across a variety of applications will enable system integration and open the market for LBS.
DATEX II was designed for being able to be extended with user specific needs, national requirements and upcoming new specifications and standards. Swedish Transport Administration and the Dutch National Datawarehouse for Traffic information have jointly and together with TomTom developed an extension for OpenLR in DATEX II.
OpenLR has been designed for the use case of transferring traffic information from a centre to in-vehicle systems, built-in or used as an add-on (PND, Smart Phone). The information transferred can consist of the current traffic situation at a certain location, a traffic forecast or special alerts. The corresponding locations are roads or a list of connected roads. Additionally OpenLR supports point locations which are zero-dimensional elements in a map that specify a geometric location. Use cases for point locations are e.g. point of interests (POIs), petrol stations and speed cameras.
Compared to the existing RDS-TMC method every location in a map can be transferred using OpenLR. Besides the XML format a binary format for compact and bandwidth efficient transmission is supported. The goal of OpenLR is the wide-scale adoption by the industry at large. OpenLR is therefore proposed as an open standard in an Open Source framework.
The OpenLR extension for DATEX II makes it possible to use DATEX II with an extended location referencing model containing OpenLR. This makes it possible e.g. to deliver on the fly referencing in OpenLR format from the source of the information e.g. a Traffic Information Centre.
The full EA Model file and XML Schema which incorporate OpenLR into the Level A model are downloadable below. Also the separate xmi export file just containing the Extension package is made available for download.
More information about OpenLR can be found at www.openlr.org
The Swedish Transport Administration is responsible for long-term planning of the transport system for road, rail, maritime and air traffic in Sweden.
TomTom is a digital mapping and routing company that focuses on car navigation.
The Dutch National dataWarehouse for Traffic information is the central point for distribution Traffic and Travelinformation from joint road operators in The Netherlands
Normal
0
false
false
false
SV
X-NONE
An openLR linear does not comply with the definition of a Linear in DII. Linear has the definition: A linear section along a single road with optional directionality defined between two points on the same road. The issue is that an openLR linear can be on more than one road
This would then be an itinerary with openLR linear. But then we get another issue:
I cannot find any rule for the definition of units in DATEX, neither in the methodology nor in the extension guide.
The assumption of using only base units of the International System of Units seems not to be valid, as there are things defined in DATEX Level A like 'Tonnes' (but not: 'Kilograms') and 'KilometresPerHour' as well as 'MetresPerSecond'.
So is there any rule for defining units?