OpenStreetMap

(This note has been re-created from old note #996361)
--------------------------
derstefan on 2017-05-14 20:27:51 UTC:
Allgemein sollten alle S-Bahn-Halte als railway=halt kartiert werden, außer es handelt sich um richtige Bahnhöfe (railway=station).
In Nürnberg sind viele Halte/Stationen falsch getaggt! Dieser Punkt bezieht sich deshalb nicht auf den Hauptbahnhof Nürnberg, sondern auf das gesamte S-Bahn-Netz.

Leider ist das Tagging nicht ganz intuitiv und etwas eigenartig:

Bahnhöfe: railway=station
Bahn-/S-Bahn-Halte: railway=halt
U-Bahn-Halt: railway=station & station=subway.
--------------------------
pyram on 2017-05-14 21:09:34 UTC:
Um das nachhaltig in den Griff zu bekommen, müsste mann es schaffen, die Firma Mentz von ihrem Tun abzuhalten (siehe auch die irre Wegeführung hier im Bahnhof) - oder man einigt sich auf einen gemeinsamen Nenner. So wird das ein Ping-Pong-Spiel :-(.
--------------------------
derstefan on 2017-05-14 21:41:31 UTC:
Was genau tut denn diese Firma Mentz? Wenn es ein größeres Problem ("Edit-War") gibt, könnten wir die OSM-Community einschalten. Eigentlich ist die Eisenbahn-Community doch äußerst engagiert bei der Sache, selbst Geschwindigkeiten, Weichen und Signale werden erfasst. Aber Bahnhöfe und Halte werden nur schlecht unterschieden...
--------------------------
(anonymous comment removed)
--------------------------
gsperb on 2017-07-03 19:18:26 UTC:
"Weltstaat" definiert auch jede Haltestelle an einen Gehsteig mit "platform" mit willkürlicher Ausdehnung und killt die Haltestellenzeichen. "platform" taugt bei einem Bahnhof oder bei einem Busbahnhof wo tatsächlich eine "platform" vorhanden ist.
Ich war auch mal in Wien aber ob ich dort ein Busliniennetz pflegen könnte?
Vielleicht verwendet Mentz die OSM daten aber der Programmierer ist zu doof korrekte Einträge bzw. deren Varianten auszuwerten?
--------------------------
hsimpson on 2017-08-19 16:21:42 UTC:
Sowas würde ich persönlich konsequent revertieren... (natürlich nach vorherigem Kommentar im CS). Das sind für mich ganz offensichtlich fern-Edits, die schon was automatisiertes an sich haben. Da dreht sich bei mir so einiges, wenn ich sowas sehe...
Auch bei Menz bin ich der Meinung, dass die sich nur dann den gängigen Standarts fügen werden, wenn sie merken, dass alles andere eine sinnlose Verbratung von Arbeitsstunden ist, weil solche Änderungen hier nicht überleben.
Von daher bitte keine falsche Scheu, und wenn man sich unsicher ist, im Forum nach Hilfe fragen.
--------------------------
hsimpson on 2017-08-19 16:26:55 UTC:
Und bezüglich des ursprünglichen Problems bin ich da ganz beim OP.

Ich hab etwa bei den Ausbauarbeiten bei Erlangen festgestellt, dass das gesamte S-Bahn-Netz doch sehr chaotisch ist. Die Relation der S1 war etwa das Chaos pur :)
Von daher würde ich fast sagen, dass man hier keine Flickschusterei betreiben sollte, sondern das Netz als ganzes korrigieren, ordnen und auf ein einheitliches Taggingschema bringen sollte.
Etwas ähnliches habe ich vor einiger Zeit mit dem Kölner Stadtbahnnetz gemacht, von daher kann ich hier gerne beratend mitwirken, allerdings felt mir für ein solches Großprojekt derzeit die Zeit, um tatsächlich mitzuwirken.
Viele Grüße
--------------------------
gsperb on 2017-08-20 07:23:22 UTC:
Mentz ist ganz offiziell von der DB beauftragt in Bayern das IFOPT Projekt abzuwickeln.
Hierbei bekommt jede Haltestelle eines öffentlichen Verkehrsmittels (unter Anderem) eine eindeutige Nummer. Die Nummer ist Voraussetzung um Haltestellen und Verbindungen miteinander verknüpfen zu können UND Aussagen in Echtzeit zu bringen.
Das ist in M schon ziemlich weit und an vielen Haltestellen kommt schon der Hinweis, dass z.B. der Bus in 2 Minuten eintreffen wird.
Weiter wird möglich sein im Bus anzuzeigen, dass zum Umsteigen in die S-Bahn nur noch 1 Minute zur Vervügung steht (weil er 2 Minuten Verspätung hat) oder der ICE bereits weg ist und man sich nicht beeilen muss.
Voraussetzung ist eine bundesweit übergreifende Datenbank oder zumindest verknüpfte Datenbanken mit gleichartigem Inhalt und Aufbau.
Weshalb die in OSM derartig geschäftig sind weiss ich nicht, doch natürlich könnte man das Kartenmaterial auch verwenden um einheitliche Linienpläne zu erstellen.
--------------------------
hsimpson on 2017-08-20 09:52:45 UTC:
Nun ja, OSM bietet sich für sowas nunmal an. Wenn es bei sowas nur bei den Nummern bleibt, finde ich das auch nicht allzu tragisch. Die Frage ist nur, welche Nummer man dafür nimmt.
Jeder Bahnhof hat ja ohnehin eine eigene Nummer und jeder Verkehrsverbund hat auch seinen Haltestellen in der Regel eindeutige Nummern zugewiesen, schon alleine, um die internen Abläufe organisiseren zu können. Solche Nummern sind natürlich auch in OSM zu finden, zu allererst natürlich an den Bahnhöfen. Aber auch in Köln wurden z.B. im Rahmen eines Daten-Imports vor einigen jahren die dazugehörigen VRS:ref mit erfasst und sind seitdem an fast jeder Haltestelle eingetragen.
Liniennetzpläne aus OSM zu erstellen ist übrigens auch nicht mehr ungewöhnlich, das betreibt z.B. die Rheinbahn in Düsseldorf auch seint einiger Zeit (ich glaube, da ist Menz auch wieder im Spiel, das weiß ich allerdings nicht so genau).
Grüße
--------------------------
gsperb on 2017-08-20 17:45:50 UTC:

Im Rahmen von DEFAS FGI BAYERN (Durchgängiges Elektronisches Fahrplanauskunfts- und AnschlusssicherungsSystem“ auf Basis von Echtzeitdaten)
wird ein zentrales Haltestellenkataster für alle Haltestellen in Bayern erstellt. Hierfür wird jeder Haltestelle, jedem Bereich und jedem Haltemast (Haltepunkt, Steig) eine eindeutige Kennung gemäß dem CEN IFOPT Standard zugewiesen. Dazu gehört auch die bereits verwendete europaweit eindeutige CEN-Nummer.
Da müsste also nicht mehr jeder Verkehrsbetrieb seie eigene Datenstruktur erfinden. Gängiges Verfahren ist, dass man den Aufwand für Neues/eine Umstellung scheut, intern mit eigenem Kram weitermacht und nach Extern die Daten wie gewünscht liefert.
Dazwischen zig dauernd klemmende Schnittstellen.
Ein Bisschen etwas Allgemeinverständliches steht hier (Seiten 21ff)

http://plan-mobil.de/wordpress/wp-content/uploads/Anlage_5_2_VGN_Vorgaben_Fahrplandaten_DEFAS_Anhang.pdf
Sicherlich ist es sogar wünschenswert wenn OSM verwendet wird.
Das Risiko des gewerblichen Anwenders ist jedoch, dass „jeder“ darin herummurksen kann und u.U. Daten zerschossen werden. Dagegen hilft, zumindest für einen bestimmten Stand, ein Download.
Was nicht im Sinne der Erfinder sein kann ist, wenn irgendwer sich Daten so hinbiegt, dass es für ihn „hübsch“ ist bzw. eben exakt seine Anforderungen erfüllt sind und zwar egal ob das im Standard OSM-Vorgehen vorgesehen ist oder nicht.
Blöd ist eben auch, dass man mit entsprechender manpower einfach Fakten schaffen kann.

--------------------------
(anonymous comment removed)
--------------------------
hsimpson on 2017-09-02 14:06:02 UTC:
Hi, eine Zusammenfassung dazu gibt es hier: https://www.openstreetmap.org/changeset/51033842#map=19/49.41295/11.14398&layers=N
Der User hat bisher auf keine Nachricht von mir geantwortet...
Es wäre nicht schlecht, würdet ihr euch weitere seine Änderungen anschauen und auf Unstimmigkeiten überprüfen, ich habe dazu hier nämlich zu wenig Ortskenntnis.
Viele Grüße
--------------------------
hsimpson on 2017-09-09 13:27:09 UTC:
Hi, ich habe das Thema der Datenimports inzwischen ins Forum gebracht, wo derzeit ein Revert der entsprechenden Changesets erwogen wird: https://forum.openstreetmap.org/viewtopic.php?pid=663009
-
In dem Zusammenhang wäre es hilfreich, wenn sich die Mapper mit Ortskenntnis dort in die Diskussion einbringen würden, insbesondere bei der Frage, ob der Mapper Marsuna alleine für den imort verantwortlich ist, oder ob es weitere Akteure gibt, die diesbezüglich aktiv waren und ähnliche Fehler produziert haben könnten.
-
Viele Grüße!
--------------------------
(anonymous comment removed)