Home » railML newsgroups » railML.infrastructure » Alternative Stationsnamen (ocp, additionalName)
| Alternative Stationsnamen (ocp, additionalName) [message #284] |
Mon, 26 March 2012 10:57  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Allerseits,
was mir beim Schreiben eines Beispiels zu alternativen Stationsnamen
(http://www.irfp.de/download/railml_doku_beispiele.pdf, Seite 3)
aufgefallen ist: Ein Umstand ist hier derzeit m. E. noch ungünstig. Wir
können zwar den alternativen Namen mitgeben, ob es sich um
(inner)betriebliche oder verkehrliche Namen handelt und welcher Sprache
sie angehören, es bleibt aber unklar, welcher Kategorie und Sprache der
„eigentliche“, im Element ocp, Attribut name genannte Name angehört.
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“. 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“.)
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.
Wir haben aus meiner Sicht folgende Möglichkeiten:
a) Wir schreiben klar und deutlich vor, dass ‚name’ bei ocp immer der
(inner)betriebliche Name sein muss und eventuell abweichende verkehrliche
Namen immer als additionalName anzugeben sind. Dann brauchen wir die
Ausprägung ‚type=operationalName’ eigentlich nicht mehr, und wir gingen
dann davon aus, dass es immer nur einen betrieblichen Namen geben kann
(was ich für vernünftig hielte).
b) Wir erlauben weiterhin, dass alles möglich ist, fügen aber bei ocp die
optionalen Felder ‚type’ und ‚xml:lang’ hinzu, damit man eben deutlich
machen kann, für welche Wahl sich das schreibende Programm entschieden hat.
Ich wäre eigentlich für Lösung (a), weil Klarheit es den lesenden
Programmen leichter macht. Bei Lösung (b) muss ein lesendes Programm ja
quasi alles können. Ich fürchte aber, nur Lösung (b) ist so richtig
abwärtskompatibel.
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
| 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
|
|
|
|
| Re: Alternative Stationsnamen (ocp, additionalName) [message #324 is a reply to message #318] |
Fri, 29 June 2012 21:57 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Susanne,
> 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.
Kein Problem, keine Notwendigkeit zur Entschuldigung.
>> 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.
Siehst Du, da haben wir den Salat: Das sieht nämlich bisher eher umgekehrt
aus. Weil nicht alle OCPs in der Fahrplanauskunft erscheinen, haben auch
nicht alle einen verkehrlichen Namen, so dass eher der betriebliche (der
bisher immer vorhanden ist) im Attribut ‚name’ angegeben wird. Sonst würde
die Regel ja lauten: „‚Name’ enthält den verkehrlichen Namen, falls die
Betriebsstelle in der Fahrplanauskunft erscheint, ansonsten den
betrieblichen Namen. Falls der verkehrliche angegeben ist, steht der
betriebliche unter additionalName. Ob eine Betriebsstelle in der
Fahrplanauskunft erscheint, erkennt man indirekt daran, ob unter
additionalName ein betrieblicher Name angegeben ist...“
> 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.
Da sind wir uns sehr einig, also volle Zustimmung von meiner Seite.
> -> Bei Zustimmung: in Trac Ticket für Version 2.2 aufnehmen
---
> Dafür könnte das neue Element <ocpGroup> aushelfen.
Ok, zu <ocpGroups> läuft die Diskussion an anderer Stelle. In diesem
Zusammenhang sind wir uns einig, dass <ocpGroups> hier eine Hilfe wären.
> BHBF wurde in der Web-Variante der RL100 nicht gefunden
Sollte es aber, denn es ist in den offiziellen Schienennutzungsbedingungen
und Stammdaten der DB enthalten (geprüft für Jahresfahplan 2013). Es ist
insofern auch richtig, in Berlin Hauptbahnhof - Lehrter Bahnhof oben zwei
Betriebsstellen zu unterscheiden, als dass es auf der S-Bahn-Strecke nur
ein Haltepunkt ist, auf der Fernbahn aber ein Bahnhof. (Es müsste dann
wohl auch korrekt heißen: „Berlin Haupthaltepunkt (S-Bahn)“. ;-) )
---
> Das Attribut "xml:lang" ist seit Version 2.1 im Element 'ocp'
> enthalten. Was habe ich übersehen?
Dass sich mein Beispiel auf 2.0 bezog... Nein, im Ernst: Du hast nichts
übersehen. Ich hätte die Frage gar nicht zu stellen brauchen, wenn ich
nicht übersehen hätte, dass es in 2.1 enthalten ist. Daher schreibe ich
jetzt: Ich bitte um Entschuldigung!
Viele Grüße,
Dirk.
|
|
|
|
| Re: Alternative Stationsnamen (ocp, additionalName) [message #350 is a reply to message #318] |
Sat, 08 September 2012 10:01 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello everyone,
>> 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“.
>
> [...] 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.
The new optional attribute "type" of type "tOcpNameType" has been
implemented within the complex type "tAdditionalOcpName" in SVN commit
427. The enumeration "tOcpNameType" contains the values
'operationalName', 'trafficName' and 'localName' in order to distinguish
between different names for an ocp, e.g. a station like Berlin's central
station:
>> 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“.)
>
> [...] 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.
Considering the concept for grouping ocps as described and implemented
in trac ticket [1], this disadvantage does not exist anymore. An ocp may
contain an "additionalName" as well as it's parent ocp referenced by the
attribute "parentOcpRef".
[1] https://trac.assembla.com/railML/ticket/153
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| Re: Alternative Stationsnamen (ocp, additionalName) [message #436 is a reply to message #324] |
Mon, 12 November 2012 11:39 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
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.
>
> Siehst Du, da haben wir den Salat: Das sieht nämlich bisher eher
> umgekehrt aus. Weil nicht alle OCPs in der Fahrplanauskunft
> erscheinen, haben auch nicht alle einen verkehrlichen Namen, so dass
> eher der betriebliche (der bisher immer vorhanden ist) im Attribut
> ‚name’ angegeben wird.
>> 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.
>
> Da sind wir uns sehr einig, also volle Zustimmung von meiner Seite.
I filed a Trac ticket for this issue:
http://trac.assembla.com/railML/ticket/191
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Goto Forum:
Current Time: Tue Apr 16 13:48:44 CEST 2024
|
Members
Search
Help
Login
Home
