Changeset: 76231995
VBN Linie 681 Haltestellen und Linienführung ergänzt, nicht alle Alternativen erfasst
Closed by hybridOL
Tags
created_by | JOSM/1.5 (15390 de) |
---|---|
source | Bing;ZVBN |
Discussion
-
Comment from sundew
Hallo,
du hast jetzt den Briefkasten bei Holste-Paddewisch doppelt eingetragen. Bitte wieder entfernen!
Btw, warum löscht du die route_ref Tags an den Bushaltestellen? Die mögen dir vielleicht redundant vorkommen, da aber nie alle Buslinien in Routerelation erfasst werden, das sind sie das definitiv nicht.
LG -
Comment from hybridOL
Ist korrigiert, weiß auch nicht wie der doppelt da hin gekommen ist.
Die route_ref sind genau dann redundant, wenn ich an der Haltestelle alle dort genannten Routen auch eingetragen habe. Vorher lösche ich sie in der Regel auch nicht - es sei denn, ich weiß, das eine der dort genannten Linien die Haltestelle nicht mehr bedient. Linien an den Haltestellen zu taggen ist relativ problematisch, da bei der Überprüfung der Strecken in der Regel nicht alle Haltestellen noch einmal durchgeklickt werden. Insofern ist die route_ref nur in Bereichen sinnvoll, wo die Strecken noch nicht erfasst sind. -
Comment from sundew
Hallo und danke für die schnelle Antwort.
Bei den route_ref-Tags bin ich nicht deiner Meinung. Klar sind sie dazu da, bei der Ersterfassung/-ergänzung von Busstops den Istzustand der anfahrenden Linien zu dokumentieren. Zum anderen sind sie aber auch sinnvoll zur Qualitätssicherung der eingetragenen Daten. Es gibt nämlich recht oft Abweichungen zwischen den angeschriebenen Busfahrplänen und der Realität, bei vielen Busnetworks z.B. VBN/VNN zusätzlich auch noch zwischen veralteten Liniennummern am Haltenstellenschild und den angeklebten hoffentlich aktuellen Plänen. Da fehlen manchmal auch Werks- und Schulbusse, oft Bürgerbusse und Anrufsammeldienste oder Busse ohne Network, bzw. welche, die aus anderen Networks kommend in das Gebiet hineinfahren.
Auf der OSM-Seite kommt hinzu, dass nie alle Buslinien sinnvoll in Relation gepackt werden können, insbesondere dort, wo jede Fahrtinstanz des Tages ein Unikat ist. Außerdem, wie kannst du signalisieren: diese Bushaltestelle ist vollständig (!) durch Relationen erfasst, also auch in Bezug auf Linien, die das örtliche Network nicht kennt oder auflistet? Man bräuchte mindestens ein gepflegtes "check_date" plus ggf. Ergänzungsnotizen.
Ich bleibe dabei, nur durch eine redundante Erfassung (z.B. route_ref) können Fehler erkannt und vermieden werden, bzw. eine richtige Qualitätssicherung durchgeführt werden.
Das ist insbesondere sehr wichtig, weil es bei Buslinien immer wieder eine gewisse unabgesprochene Arbeitsteilung zu geben scheint. Zum einen sind da Mapper (wie ich), die Touren überallhin machen und sich u.a. die Haltestellen vor Ort ansehen. Zum anderen sind da viele Mapper (wie auch einige Kollegen vom OSM-Stammtisch), die überwiegend remote (Fahrplan/Luftbild) arbeitend Linienrelationen erstellen und pflegen, ohne sich alles wirklich vor Ort angeschaut zu haben.
Was die Änderungen an Plattformen versus Linienrelationen betrifft und ich spreche jetzt hauptsächlich aus meinen Beobachtungen aus dem HVV-Gesamtbereich (rundherum), und da sind es pro Fahrplanwechsel nur vereinzelte Linien, die eingestellt, neu erzeugt oder umbenannt werden. Dagegen sind Änderungen an den Fahrtverläufen erheblich öfter vorkommend. Gepflegt werden müssen die Daten also in jedem Fall. Das können dann ggf. auch die Couchmapper tun, falls niemand vor Ort vorbei kommt :-) Und sollten dabei Unterschiede zwischen Relationen und route_ref auffallen, wäre das ein Grund mehr zur Extrarecherche.
LG
sundew -
Comment from hybridOL
Ich arbeite mit den offiziellen Busplänen des Netzwerks. Da gibt es zwar auch Abweichungen zwischen Datenbestand und Realität, aber der ist minimal.
Wie gesagt vernichte ich auch keine Information, da ich die route_ref nur dann lösche, wenn alle noch existierenden Linien an der Haltestelle als Relationen erfasst wurden. Genau dann ist route_ref redundant und macht die Situation nur noch schlechter, nicht besser. Sofern danach nämlich nur an einer der Stellen geändert wird kommt es zu Diskrepanzen im Datenstand und es ist nicht klar, welche Information gepflegt wird. Sollte also, nachdem route_ref gelöscht wurde, sich eine Änderung ergeben, wäre neben dem Ändern der Relation einzig ein Hinweis- bzw. Fehlertag an der Haltestelle sinnvoll, um eine Bearbeitung durch Dritte zu triggern. Aufgrund der minimalen Verbreitung von route_ref (und der nicht vorhandenen Nutzungsempfehlung in der PTv2-Definition) bringt das einfach zu selten etwas.
check_date (was aber leider auch nicht standardisiert ist) bringt tatsächlich mehr. Ich werde das eventuell auch demnächst nutzen.
Ways (1-20 of 112)
- Landrat-Christian-Evers-Straße (10414911), v37
- Bahnhofstraße (24641250), v19
- Stedener Straße (24651118), v22
- Bahnhofstraße (24668551), v24
- Schulstraße (24670519), v18
- Büttel (24697123), v16
- Alt Ohlenstedt (24698436), v9
- 24698446, v10
- 24698479, v6
- Hinter dem Gartel (24704533), v19
- Wesermünder Straße (24715440), v18
- 24896665, v9
- Auf dem Großen Felde (25016558), v5
- Wohlthöfener Straße (25016559), v7
- Waldstraße (25016642), v7
- Bahnhofstraße (25016648), v24
- Schulstraße (25018026), v6
- Bahnhofstraße (25018320), v14
- Schwanhorstberg (25169606), v4
- Harrendorfer Straße (25170206), v8
Relations (1-20 of 64)
- Butenpad (28637), v41
- Quer nach Westerbeck (34359), v14
- Querverbindung Grüner Ring Region Bremen (34555), v410
- Quer nach Osterholz (34688), v30
- Bus 680: Bahnhof Burg => Bahnhof Osterholz-Scharmbeck (270834), v91
- Bus 680: Gröpelingen => Wallhöfen, Schule (270839), v137
- K 48 (CUX) (455337), v22
- L 128 (455459), v34
- Rund um den Kahlen Berg Route R20 (1677039), v36
- Bus 681: Osterholz-Scharmbeck => Steden (1736448), v44
- Bus 680: Am Mühlenberg => Gröpelingen (2559652), v63
- 3394289, v3
- Bus 680: Gröpelingen => Hambergen (3466463), v48
- K 5 (4152469), v11
- K 16 (4217676), v4
- K 22 (4246915), v2
- K 23 (4253219), v3
- K 24 (4264930), v2
- K 38 (4502213), v3
- K 40 (4505521), v3
Nodes (1-20 of 287)
- 88920580, v3
- 88920581, v5
- 267849624, v7
- 267887679, v3
- 267887680, v3
- 267951251, v4
- 267951861, v5
- 267951862, v3
- Ohlenstedt, Haslah (268460884), v4
- 268461148, v2
- 268461486, v3
- 268461488, v7
- 268635019, v3
- 268635020, v3
- 268638494, v3
- Lübberstedt, Schulstraße (268638496), v5
- 268639146, v4
- 268639307, v5
- 268639802, v2
- 268639803, v2
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |