User:RailML Coord Governance

From railML 2 Wiki
Revision as of 19:37, 15 December 2022 by RailML Coord Documentation (talk | contribs) (Ferri Leberl moved page User:Vasco Paul Kolmorgen to User:RailML Coord Governance: Automatically moved page while merging the account "Vasco Paul Kolmorgen" to "RailML Coord Governance")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Vasco Paul Kolmorgen

railML-Koordinator

Tel. +49 351 46676939

01069 Dresden

Germany / Deutschland /

Netter Kerl, aber manchmal auch ein wenig frech.

Vorlage für railML® 3 use cases im timetable-Schema

Use case / Anwendungsfall / :

An expressive name in English; Ein aussagekräftiger Name in Deutsch;

Description / Beschreibung /

What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

Which data flows (from/to the use case application) exist? Which data and process interfaces exist?

References to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten /

Please note here which references to other data models come with that use case. Such references (also described as key expressions) may be one single attribute or a combination of several attributes of the respective <element>. Typical examples are

  • <designator>s for a national register of stations (<ocp>s),
  • <line> and/or <track> numbers, names, codes, possibly with UIC numbers,
  • codes of infrastructure or interlocking elements like signals, switches, signal boxes, level crossings, interlocking routes,
  • types, classes, codes of <vehicle>s,
  • names or codes of <categories>,
  • train numbers, codes or names,
  • names of circulation plans.

Please do also think about more indirect references to the world outside of software like possibly the names of companies such as infrastructure managers.

You do normally not need to specify references which lead into the already predefined XML world such as dates (of Gregorian calendar), times (of 24 hour clock), or coordinates including heights (of a pre-defined world coordinate system) except if there are special assumptions by the use case.

Please note which references are

  • mandantory
  • optional, typical
  • optional, seldom

for that use case or even, if applicable, which shall be avoided or explicitly not assumed.

Please note which attributes or sets of attributes must be unique within the railML® file defined by the use case (so in spite of they do not need to be unique by the railML® schema).

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen /

  • infrastructure
  • rolling stock
  • interlocking
  • other ..............

Please note which references are

  • mandantory
  • optional, typical
  • optional, seldom

for that use case, from-to which <element>s the references exist (at least, typically) and if there are any references which do not use the default id-ref system of railML®.

Characterising Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • static (not changing)
  • yearly
  • regular changes
  • monthly
  • weekly
  • daily
  • realtime (seconds)

How big are the data fragments to be exchanged (complexity)?

  • tiny (attribute)
  • very small (element)
  • small (single train run)
  • big (line)
  • huge (region)
  • whole data set (detailed operational concept network)

Which views are represented by the data (focus)?

  • Long term planning (eg. for infrastructure dimensioning)
  • Mid term planning (eg. for yearly timetable disposition)
  • Short term planning (eg. for trackworks)
  • Real term planning (eg. for dispatching)
  • Statistics
  • Fare collection
  • Passenger information
  • ...

Which specific timetable data do you expect to receive/send (elements)?

Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.
Please describe also structures which should be modeled in another way (so called "refactoring") in railML 3.
Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.