| Re: Alternative Stationsnamen (ocp, additionalName) [message #318 is a reply to message #284] |
Wed, 27 June 2012 22:02   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hallo Dirk,
entschuldige bitte das späte Antworten, wir (Christian und ich) haben
uns mal wieder über das Gruppieren von 'ocps' unterhalten und daraus
den Vorschlag im Posting "Grouping of elements in an" [1] erarbeitet.
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> So ist auch in derzeitigen deutschen Anwendungen unklar, ob unter
> ‚name’ der verkehrliche Name anzugeben und der betriebliche unter
> ‚additionalName’, type=trafficName aufzuführen ist oder umgekehrt der
> verkehrliche als ‚name’ und der betriebliche unter ‚additionalName’,
> type=operationalName. (Der Unterschied zwischen betrieblichem und
> verkehrlichen Namen ist z. B. „Bft. Dresden-Neustadt Pbf.“ und
> „Dresden-Neustadt“.
Üblicherweise wird vermutlich der verkehrliche Name angegeben, so wie er
in der Fahrplanauskunft erscheint. Allerdings wäre das Attribut 'type'
vom Typen 'tOcpNameType' für die Unterscheidung in 'betrieblich',
'verkehrlich' und 'local' an dieser Stelle sehr sinnvoll und sollte noch
ergänzt werden.
-> Bei Zustimmung: in Trac Ticket für Version 2.2 aufnehmen
> Der Unterschied ist unvermeidbar spätestens bei
> solchen Bahnhöfen, wo zwei oder mehr betriebliche Bahnhöfe als ein
> verkehrlicher vermarktet werden, wie z. B. „Berlin Lehrter Bf oben“
> [BHBF], „Berlin Lehrter Bf S-Bahn“ [BLS] und „Berlin Lehrter Bf unten“
> [BL] gemeinsam als „Berlin Hbf - Lehrter Bahnhof“.)
Dafür könnte das neue Element <ocpGroup> aushelfen. Ich packe das
Berlin-Beispiel mal in die angedachte Struktur (BHBF wurde in der
Web-Variante der RL100 nicht gefunden):
<operationControlPoints>
<ocp id="o_1" name="Berlin Hauptbahnhof-Lehrter Bf (Stadtb)"
code="BLS" type="operationalName"/>
<ocp id="o_2" name="Berlin Hauptbahnhof - Lehrter Bahnhof"
code="BL" type="operationalName"/>
</operationControlPoints>
<ocpGroups>
<ocpGroup id="og_1" name="Berlin Hauptbahnhof - Lehrter Bahnhof"
code="BL" type="trafficName">
<ocpRef ref="o_1"/>
<ocpRef ref="o_2"/>
</ocpGroup>
</ocpGroups>
In diesem Beispiel ist die neue Struktur für unterschiedliche "codes"
nicht enthalten. Das Thema soll in einem anderen Thread abgehandelt
werden. [2]
Alternativ könnte dieses Thema auch mit der bisherigen Struktur (inkl.
'type'-Attribut) abgebildet werden:
<operationControlPoints>
<ocp id="o_1" name="Berlin Hauptbahnhof-Lehrter Bf (Stadtb)"
code="BLS" type="operationalName">
<additionalName name="Berlin Hauptbahnhof - Lehrter Bahnhof"
type="trafficName"/>
</ocp>
<ocp id="o_2" name="Berlin Hauptbahnhof - Lehrter Bahnhof"
code="BL" type="operationalName">
<additionalName name="Berlin Hauptbahnhof - Lehrter Bahnhof"
type="trafficName"/>
</ocp>
</operationControlPoints>
Die zweite Variante hat den Nachteil, dass nicht definiert ist, dass der
ocp 'o_1' auch unter dem "code='BL'" auffindbar ist.
Die Einführung der "ocpGroups" hätte recht weitreichende Folgen. Es wäre
wünschenswert einige Meinungen darüber zu erfahren.
> Im Falle von Piräus und Athen habe ich deren griechische verkehrliche
> Namen sowohl als ‚name’ angegeben als auch bei ‚additionalName’
> wiederholt, um deren Zugehörigkeit zur Sprache deutlich zu machen, was
> in diesem Beispiel für Mitteleuropäer nicht trivial ist. Hier wird
> deutlich, dass ‚xml:lang’ eigentlich bei ‚ocp’ noch fehlt.
Das Attribut "xml:lang" ist seit Version 2.1 im Element 'ocp'
enthalten. Was habe ich übersehen?
Grüße in die Runde...
Susanne
[1] http://www.railml.org/forum/ro/index.php?group=1&id=135
[2] https://trac.assembla.com/railML/ticket/112
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
