Kleinigkeit Hamburg-Rothenburgsort

[gizmo]

Moin,

wollte nur mal schnell loswerden, dass der Stadtteil "Rothenburgsort" und nicht "Rotenburgsort" heisst. Vielleicht lässt sich das fehlende "h" ja noch an den diversen Stellen nachtragen.

Grüsse
gizmo

[DragonGuard]

Arbeitsaufwand:

• Stellwerk Rotenburgsort überarbeiten
  Stellwerke Wilhelmsburg, Hamburg Hbf, S-Bahn Hauptbahnhof, Poppenbüttel, Hamburg Eidelstedt, Bad Oldesloe (unsichtbar) und Bergedorf überprüfen und anpassen
  Alle Züge, die einen Durchfahrpunkt in einem der anderen Stellwerke haben (und das sind mind. alle Züge aus Eidelstedt und Bergedorf) anpassen und freigeben
  - und das alles für 2006 und 2010?

Bei 2006 steht der Aufwand in keinem Verhältnis zum Nutzen. Für 2010 kann man dies dann anpacken.

Es gibt übrigens spätestens dann auch ein neues Format für Rothenburgsort, übersichtlicher und breiter

[gizmo]

...
Bei 2006 steht der Aufwand in keinem Verhältnis zum Nutzen. Für 2010 kann man dies dann anpacken.

Es gibt übrigens spätestens dann auch ein neues Format für Rothenburgsort, übersichtlicher und breiter

2010 reicht ja auch dick. So unübersichtlich finde ich das Stellwerk im jetzigen Zustand übrigens gar nicht, ist ja nicht soooo viel los

[DragonGuard]

Aber total vollgestopft. Aber ist schon schöner, wenn man ein Stellwerk hat, in dem es keine Sprünge mehr gibt

[DLichti]

Wurde das 'h' schon eingefügt? In dem Fall wurde eines in Harburg in der Bezeichnung des Ein-/Ausfahrtgleises von/nach Rothenburgsort. Sowohl in der Gleisliste als auch in den (einigen) Fahrplänen steht Rotenburgsort.

David

[DragonGuard]

Ich setz es auf meine Liste der zu prüfenden Dinge, die ich bei Zeit (haha -.-) mal erledigen werde.

Bad Oldesloe: vollständig angepasst
Hbf: vollständig angepasst
Büchen: vollständig angepasst
Harburg: Beschreibung angepasst, Gleisbild noch offen
Poppenbüttel: Beschreibung angepasst, Gleisbild noch offen
S-Bahn Hbf: Beschreibung angepasst, Gleisbild noch offen
Eidelstedt: Beschreibung angepasst, Gleisbild noch offen

Die Anpassung von Poppenbüttel ist kein Problem, da hier keine Züge verkehren kann ich die Durchfahrpunkte einfach ändern.
Die Anpassung vom S-Bahn Hbf ist auch kein Problem, da hier nur die E/A sowie Texte geändert werden müssen, für die Züge ändert sich im Fahrplan nichts.
Die Probleme habe ich bei der Anpassung für die Stellwerke Eidelstedt und Harburg: Hier muss ich die Durchfahrpunkte für die Züge ins Stellwerk Rothenburgsort ändern. Das bedeutet, dass auch die Züge geändert und freigegeben werden müssen. Dazu müsste ich die Anlagen entweder unsichtbar setzen, während ich die Änderungen vornehme oder 2x den Admins ein Update zumuten, was auch blöd ist. Außerdem muss die QS einen ganzen Haufen Templates prüfen, was die zu erwartende Downtime verlängert.
Außerdem müssen die Templates selbst angepasst werden, was auch Zeit erfordert.

Über die Feiertage werde ich da so oder so nichts machen, aber es steht irgendwo auf meiner Liste der zu erledigen Sachen.

Gruß DragonGuard

[DLichti]

Hier muss ich die Durchfahrpunkte für die Züge ins Stellwerk Rothenburgsort ändern.

Hm, sieht so aus als ob ihr euch viel Arbeit sparen könntet, wenn ihr die Darstellung von der Struktur entkoppeln würdet. Der Name eines Objekts sollte eigentlich nichts mit seiner ID zu tun haben außer, dass er in irgendeiner Tabelle damit verknüpft ist.

David

[DragonGuard]

Die Durchfahrpunkte sind Haltepunktelemente in der Anlage, an denen ein Fahrplaneintrag generiert wird.

Daher sind hier die Anlagenelemente mit den Zügen verknüpft.

Gruß

[DevonFrosch]

Hm, sieht so aus als ob ihr euch viel Arbeit sparen könntet, wenn ihr die Darstellung von der Struktur entkoppeln würdet. Der Name eines Objekts sollte eigentlich nichts mit seiner ID zu tun haben außer, dass er in irgendeiner Tabelle damit verknüpft ist.

Die Haltepunktnamen sind selbst die ID Und da darauf z.B. die Nachbarbahnsteigsuche beruht (Haltepunkteelemente mit gleichem Namen werden als eine Einheit betrachet, wie ist das mit IDs?), wird sich das wohl nicht so einfach ändern lassen, ohne das System erheblich komplizierter zu machen... So ist das halt, man kann nicht alle Normalisierungsstufen auf alle Datenbanken sinnvoll anwenden

Gruß,
DevonFrosch

[DLichti]

Das verhindert aber nicht, dass die Darstellung von der Struktur entkoppelt wird. Wenn der Name die ID ist und mehrere Elemente den gleichen Namen haben, dann identifiziert die ID nicht mehr und ist nur noch eingeschränkt nützlich. Dann kann man auch gleich die selbe ID für verschiedene benachbarte Elemente wählen (was de facto ja schon gemacht wird) und den Namen entkoppeln.

Und die Nachbarsuche hat auch so ihre Macken. Einige davon würden von selbst verschwinden wenn man zur Nachbarsuche eine oder zwei zusätzliche Spalten für Bahnsteig und Bahnhof verwenden würde statt den Namen so zu überladen. Das würde beim Bauen jedenfalls weniger Auswand machen als jetzt wegen einem kleinen 'h' alles nochmal durch die QS zu schicken. Und ob man die eine Spalte oder die andere vergleicht macht auch keinen Unterschied.

David

[hinz]

Was hat die Nachbarbahnsteigsuche mit falschen Bahnsteignamen zu tun? Bei der Suche nach Nachbarbahnsteigen wäre es völlig egal ob da eine ID oder der Name als primärer Schlüssel steht. Beides erfüllt den gleichen Zweck. Derzeit haben die Bahnsteige oder Haltepunkte eben keine Elementnummer. Ich sehe auch nicht wo die Nachbarbahnsteigsuche wirkliche Macken hätte, zumindest keine die durch Verwendung von IDs plötzlich verschwinden würden. Man würde allerdings dem Erbauer keinen Gefallen tun, wenn er seinen Fahrplan auf Basis von IDs aufbauen muss. Also müsste vom Namen wieder zurück auf den Primärschlüssel referenziert werden. Das macht's code-technisch wieder schwieriger und zeitaufwendiger (wir sprechen ja nicht nur von ein paar Bahnsteigen, die von einer Handvoll Fahrplänen referenziert werden). Ich kenne das System ja auch nicht "von innen", aber ich denke diese Struktur ändern zu wollen dürfte eine langwierige Suche im Code bedeuten, ob es überhaupt möglich wäre wird wohl nur JS überhaupt beantworten können. Unter Umständen ist das halt einfach so "historisch gewachsen" - macht es nicht besser, ich weiß.

Dass man den Bahnsteignamen im Nachhinein ändern muss, kommt ja nicht oft vor. Der Aufwand liegt dann halt auf Erbauerseite, weil er da halt alle Templates durchforsten muss. Meines Erachtens ist der Aufwand für die QS eh klein, evtl. geht das sogar als Trivialfreigabe durch das System, wenn vorher sonst nichts geändert ist. Nur die Masse an Templates und die Synchronisation zw. Stellwerk und Templates macht das dann zeitaufwendig.

Servus
Heinz

[DLichti]

Nicht durch die Verwendung von IDs, aber durch die Entkopplung. Wenn man nach dem Grundsatz "Ein Datum, eine Verwendung" ein paar mehr Spalten in die Datenbank einfügen würde, dann könnte man erstens ein 'h' in den Anzeigenamen einfügen ohne sich Gedanken machen zu müssen, ob die Züge ihr Gleis noch finden. Und andererseits müsste man sich nicht so verrenken mit einer Nachbarschaftssuche, die 3 Felder horizontal und vertikal nach Nachbarn sucht und die strukturelle Nachbarschaft aus der Darstellung auf dem Stelltisch abzuleiten versucht.
Jedenfalls fallen mir auf Anhieb zwei simple SELECTs ein, mit denen das Gleiswechselsystem, vorrausgesetzt, die Daten sind vorhanden, so abgebildet werden kann wie bisher nur ohne die zwei genannten Einschränkungen.

Ich kann mir gut vorstellen, dass das ganze System nach und nach so gewachsen ist. Aber bei immer mehr Problemen, von denen es heißt, sie seien technisch nicht lösbar, hab ich den Eindruck, dass sie letztendlich durch ein aufgräumtes Datenbankbackend leicht zu beheben wären. Sowohl das System als auch der Datenbestand würden robuster, flexibler und besser erweiterbar.

David

[hinz]

Aus technischer Sicht was das Datenbankbackend angeht stimme ich Dir auch voll zu. Bitte misinterpretiere aber den Begriff technisch nicht lösbar nicht, meist heißt das für uns alle es ist im Moment nicht umsetzbar. Ob es technisch tatsächlich überhaupt nicht möglich ist, kann Dir immer nur der Entwickler sagen. Das ist halt ein Problem der Kommunikation über ein Forum. Geantwortet wird in der Regel aus einer persönlichen Sicht.

Als Erbauer finde ich es aber so wie es jetzt ist einfacher. Denn bei den Nachbarbahnsteigen muss die Kopplung zwischen Stelltisch und Bahnsteigdaten zwangsläufig hergestellt werden. Im Moment macht das der Editor vollkommen automatisch und ich würde mal sagen in min. 95% der Fälle passt das und ich muss nur noch in speziellen Fällen eine falsche Zuordnung ausschließen. Andersherum muss ich doch für jeden Bahnsteig die Elementnummer zumindest korrigieren, um diese Zuordnung herzustellen. Das sind deutlich mehr Fälle zum Nachkorrigieren, als bei der automatischen Erkennung. Jetzt bleibt noch ein verschwindend geringer Anteil an Fällen, in denen ich noch tricksen muss, um ans Ziel zu kommen. Mit den paar Spezialfällen (die in aller Regel lösbar sind) hol' ich keinen Entwickler hinterm Ofen vor.

Es ist eh alles Spekulation, weder Du noch ich wissen wie das DB-Backend tatsächlich abgebildet ist. Wir schließen nur aufgrund des Frontends, wie es aussehen könnte. Und die Vergangenheit hat auch gezeigt, dass JS und Co. durchaus auch bereit sind tiefgehende strukturelle Änderungen anzugehen, um dann hinterher zu einem besseren System zu kommen. Leider wird dann auch gerne gemeckert, dass dann halt zunächst keinerlei Weiterentwicklung möglich ist, weil die Kräfte gebunden sind. Von daher vertraue ich auf die Einschätzung derer, die's programmieren was sinnvoll geht und was nicht. Jedenfalls mehr als unserer Spekuliererei was evtl. vielleicht anders besser sein könnte.

Servus
Heinz