| Re: Extensions to railML for passenger information at stations [message #2190 is a reply to message #2182] |
Wed, 08 May 2019 16:51  |
Tobias Bregulla
Messages: 20
Registered: June 2017
|
Junior Member |
|
|
[English text below]
Guten Tag,
wir stellen auch eine Vielzahl von Infrastrukturdaten für
Fahrgastinformationssysteme bereit. Daher halten wir diese Erweiterung
auch für sinnvoll, würden dazu bereits jetzt folgende (erste)
Anmerkungen aus Infrastruktursicht machen:
- Der Ansage-Zeitpunkt (Trigger) wird bei vielen Systemen nicht nur
alleine über die Zeit vor einem Ereignis bestimmt, sondern auch über die
Entfernung (Weg); weitere Trigger (wie Uhrzeit) sind denkbar.
Von daher sollte bei der Modellierung die Aufzählung des Attributes
@event um folgende Trigger erweitert werden:
- Strecke & Kilometer (z.B. beim Erreichen von km 71,880 ansagen "Wir
erreichen Disentis")
- Betriebsstelle (z.B. beim Erreichen von von Disentis ansagen "10
Minuten Aufenthalt zum Lokwechsel")
- Geokoordinate und Fangradius
- ggf. auch reine Uhrzeiten (z.B. Ansage "Ab jetzt Happy Hour im
Speisewagen; 3 Bier zum Preis von 2!")
- Die Modellierung der Triggerpunkte sollte vielleicht etwas
strukturiert und klarer beschrieben werden (z.B. Unterschied "Arrival"
und "ScheduledArrival"? Ist das in der Schweiz nicht immer identisch?
;-)). Da kommen bestimmt noch weitere Trigger dazu im Laufe der Zeit.
- Fehlt dem @periodic nicht noch ein Intervall und eine Beschreibung,
was mit dem Rest nach dem letzten Intervall (mathematischer Rest des
Bruchs) passieren soll?
- Für die Ansagen sollten Prioritäten vergeben werden können, wenn
mehrere Ereignisse gleichzeitig stattfinden. Irgendwie muss das Systeme
ja entscheiden können, welcher Ansage dann der Vorrang gegeben wird.
Beste Grüße,
--
Tobias Bregulla
Bahnkonzept Dresden/Germany
Dear all,
we also provide a variety of infrastructure data for passenger
information systems. Therefore, we consider this extension to be useful
and would like to make the following (first) comments from an
infrastructure point of view:
- In many systems, the announcement time (trigger) is not only
determined by the time before an event alone, but also by the distance
(distance); further triggers (such as time) are conceivable.
For this reason, the enumeration of the @event attribute should be
extended by the following triggers during modelling:
- Distance & Mileage (e.g. when reaching km 71,880 announce "We reach
Disentis")
- Service station (e.g. when reaching Disentis announce "10 minutes
stop at this station to change locomotive")
- Geocoordinate and snap radius
- if necessary also pure times (e.g. announcement "From now on Happy
Hour in the dining car; 3 beers for the price of 2!")
- The modelling of the trigger points should perhaps be more structured
and clearly described (e.g. difference between "Arrival" and
"ScheduledArrival"? Isn't this always the same in Switzerland? ;-)).
There will certainly be more triggers in the course of time.
- Doesn't @periodic still lack an interval and a description of what
should happen to the rest after the last interval (mathematical
remainder of the fraction)?
- It should be possible to assign priorities to the announcements if
several events take place simultaneously. Somehow the system must be
able to decide which announcement is given priority.
Best regards,
--
Tobias Bregulla
Bahnkonzept Dresden/Germany
|
|
|
|
Members
Search
Help
Login
Home
