| Re: Aspects of timetable 3.0 [message #1270 is a reply to message #1269] |
Wed, 12 November 2014 18:57   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Burkhard,
Am 16.10.2014 19:26, schrieb Burkhard Franke:
> [...]
>
> Problem: the railML standard features a lot of flexibility, as it covers
> a wide range of use-cases. That´s basically fine, but it makes it hard
> to write import interfaces and to validate files as you never know what
> to expect...
> The idea to ease this problem is to predefine "use-cases".
>
> Favourite example of my collegue Bernhard are the timetable and
> operating periods. It is required to have them, everything else is
> optional...
>
> The "use-case"-approach defines several sets of mandatory and optional
> data:
> use-case 0: no information on an operating period (for
> schematic/long-term planning)
> use-case 1: startDate and bitmask mandatory, bitmask covers seven days
> to specify a sample week (to define operating patterns in a schematic
> timetable), no holidays, deviances or offsets
> use-case 2: real timetable: start date, bitmask, holidays, ... and all
> the complex stuff with deviances, specialServices ...
> use-case n: user-defined descrition of a timetable/operating period
> based on the klingon calendar ;-)
thank you very much for your suggestion of the "use case approach",
which perfectly fits to the ongoing development in the infrastructure
schema:
Following the definition of the UIC RailTopoModel, which will be the
basis for the new railML 3 infrastructure schema (cf. [1]), we are
currently collecting use cases for infrastructure data exchange with
railML. The aim is to get an overview about all applications using (or
generating) railway infrastructure data and their resulting requirements
on the content and the structure of the data and the connected
processes. Therefore, your examples like "long-term TT planning" and
"real-time TT" fit very good into this use case concept.
In order to collect the different infrastructure data use cases, we
designed a short questionaire to be filled by the relevant users. The
form includes
* a short description of the application,
* a list of relevant data flows and interfaces,
* a statement about the interference with other railML schemes, and
* a characterization of the data regarding certain aspects (update,
complexity, focus and elements).
I suggest to start such a survey also among the TT users and collect
their (timetable data) use cases. The idea behind this survey is to
identify the use cases that shall be considered with priority in the
process of developing the new railML 3 schema.
Any comments and questions appreciated...
[1] http://railml.org//index.php/railml3-development.html
Best regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
