| Aspects of timetable 3.0 [message #1269] |
Thu, 16 October 2014 19:26  |
Burkhard Franke
Messages: 5
Registered: October 2014
|
Junior Member |
|
|
some reminder of the discussion at the railML-conference in Paris:
getting rid of optional elements.
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 ;-)
The use-cases can also be applied to other elements, for instance it
could ease the discussion on vehicle data in the timetable (uc0 - no
vehicle information; uc1 - only sample vehicles; uc2 - detailed
technical data ;...)
This approach (maybe the term "use-case" is not the best) will limit
flexibility or rather guides the flexibility in an orderly manner. This
is meant to help create a better structured railML-timetable in a 3.x
version.
Comments welcome
|
|
|
|
| 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
