| Re: [railML 3.1] level crossing parameters [message #1729 is a reply to message #1714] |
Mon, 19 March 2018 09:51   |
Tobias Bregulla
Messages: 20
Registered: June 2017
|
Junior Member |
|
|
Dear Christian, dear railML community,
Some thoughts from the point of view of video-based infrastructure data
measurement on level crossings. First of all: Our modelling concepts are
far from being comprehensive and sufficient for an expert in the field
of level crossings and mainly reflect the situation in Germany and Austria.
We would therefore be very pleased to receive information from other
countries and to have a specialist discussion.
Please note the suggestions and questions under your individual points:
Am 08.03.2018 um 17:20 schrieb Christian Rahmig:> @protectionType
> ... describes the technical protection of the level crossing
> (doubleHalfBarrier, fullBarrier, halfBarrier, lights, none)
* singleFullBarrier [de: Vollschranke; DB Netz: LzV or mVS]
* doubleHalfBarrier [de: doppelte Halbschranke; DB Netz: LzHH]
* singleHalfBarrier [de: einfache Halbschranke]
* lightsOnly [de: Lichtzeichen; Lz]
* noBarrier (Saltire/Crossbuck only) [de: nichttechnisch
gesichert/ntg, nur Andreaskreuz]
* none (rarely, only in industrial plants or locomotive workshops)
[de: ohne Andreaskreuz (selten, nur in Industriegebieten oder Bahnwerken)]
Question 1: However, a distinction between level crossings “With
barriers AND lights [de-DB Netz: LzV = Lichtzeichen+Vollschranke]” and
“With barriers but WITHOUT lights [de-DB Netz: mVS = mechanische
Vollschranke]” does not seem possible; perhaps a different detailing
would be more useful?
Question 2: What about "gates" as level crossing protection? Such gates
(which sometimes blocking the railways tracks too, when not used) are
common in Scotland and Ireland IMHO (see
https://www.youtube.com/watch?v=Xh8Xl6t7Oqg for an example). Shall they
included into the barriers in the Middle Europeas sense or should a
distinction be modelled?
> @activation
> ... describes how the level crossing is being activated (automatic (by
> train), local (by staff), remote (by staff))
* infrastructureRoute (IM will care for closing, but level crossing
will activated by setting the train route under normal conditions) [de:
Hp-abhängig]
* infrastructureManual (IM will care for closing, by station master or
signal box/CTC operator or level-crossing attendant)
* trainAutomatic (RU will 'care' for closing [de: zugbediente
Einschaltung Fü/Lo]
* none (default value for @protectionType:nonTechnicallySecured and
@protectionType:none; rarely for the others, when level crossing is
available but closed forever)
> @obstacleDetection [bool]
> ... states whether the level crossing is equipped with technical system
> for object detection (radar, camera)
This causes the question of a missing (optional) attribute, therefore I
suggest to avoid such a optional boolean value.
In addition, a distinction should be made or a clear description given
between monitoring the functionality of the level crossing and
obstacle-free detection of the intersection area.
> @opensOnDemand [bool]
> ... states whether the level crossing is by default closed for road
> transport and the barriers are opened only on demand
This causes the question of a missing (optional) attribute too. For us
the use case of this attribute is not very clear in the railML 3 domain.
Best regards,
Tobias Bregulla and the whole Bahnkonzept team
|
|
|
|
Members
Search
Help
Login
Home
