Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • railML 3 railML 3
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare revisions
  • Issues 70
    • Issues 70
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • railML.orgrailML.org
  • railML 3railML 3
  • Issues
  • #23
Closed
Open
Issue created Oct 07, 2009 by Deleted User@deleted-user

Flatten 'trainDetector' and 'trainProtectionElement'

Leightweighting elements trainDetector and trainProtectionElement

What to do?

Some common attributes are repeated inside every element instance. They could be sourced out into a "definition element" and used as reference.

Attributes of element trainDetector for outsourcing:

  • detectionObject
  • medium
  • model
  • axleCounting

Attributes of element trainProtectionElement for outsourcing:

  • medium
  • system
  • model

(Contribution by Thomas Albrecht at 16th meeting in Brunswick, October 6th, 2009)

How to do?

Define new container element inside infrastructure for "trackEquipment".

Define new container element inside this for "trainDetectionSystems" and "trainProtectionSystems".

Define new elements inside these containers for "trainDetectionSystem" and "trainProtectionSystem" based on tElementWithIdAndName for attributes id, name, description and anyAttribute.

Change current definitions of trainDetector and trainProtectionElement to use ref attribute for references.

Harmonize definition and references with rollingstock and timetable.

Library

railML could provide a library with "typical European train detection and train protection systems".

Their definition could be used with xi:include in XML instance files.

Contribution by users is needed.

This list should be extended with other systems, if required by railML users.

Proposed solution railML 3.1

railML 3.1 provides both infrastructure components: and .

A can refer to the train protection system using the attribute @trainProtectionSystem that shall link to the codelist TrainProtectionSystems.xml, section trainProtectionSystemsAtTrack. Only if this list does not contain the specific train protection system to be modelled, it shall be described in its functionality using attributes @medium and @monitoring.

A can be specified via its attribute @type (e.g. "axleCounter" or "insulatedRailJoint" or "trackCircuit"). If the train detection element/system is not included in the list of @type, the specific installation can be described using attributes @detectedObject, @detectorMedium and @layout. If you want to define these parameters only once, do this for a "basic" train detection element and make use of the attribute @basedOnTemplate referencing to this train detection element from other (specific) train detection elements.

Proposed solution railML 3.x

The railML 3.1 implementation shall be reviewed considering best practices and specific use case requirements.

Assignee
Assign to
Time tracking

railML.org e.V. (Registry of Associations: VR 5750) Phone: +49 351 47582911 Altplauen 19h; 01187 Dresden; Germany