Diskussion über Public Transport Version 3

Im Topic “Diskussion über Public Transport Version 2.1” haben wir bis etwa Beitrag 143 sowohl Modifikationen an PTv2 als auch größere Änderungen diskutiert. Die größeren Änderungen sollten ab sofort hier diskutiert werden.

Weide

Ich hab mal in http://wiki.openstreetmap.org/wiki/User:Weide#Vorschlag_P3 versucht, dass konkret zu machen.

Weide

Fortsetzung aus den Thread “Public-Transport V2 Platform als Area”

Mir auch nicht.

OSM-Daten werden zur Zeit experimentell in Auskunftssystemen benutzt:
http://efa.vrr.de/vrrstd/XSLT_TRIP_REQUEST2?language=de&itdLPxx_transpCompany=vrr

Dabei stammen aber die Start- und Zielpunkte des Fußgängerroutings aus den Datenbanken der Verkehrsunternehmen und von OSM werden nur die Fußwege aber nicht die Routen benutzt. Diese Start- und Zielpunkte müssen noch angepasst werden, denn ein Fehler von wenigen Metern kann den Passagier z.B. auf die andere Seite der Gleise versetzen und von dort aus hat man evtl. einen viel längeren Weg und es wird daher eine Verbindung über eine ganz andere Stadt vorgeschlagen.

Hier werden unsere Routen also nicht gebraucht…

Andererseits will man als Passagier natürlich gern sehen, wo man gerade auf der Strecke ist und ob man überhaupt auf der gewünschten Strecke ist. Die Anzeigen in den Bussen sind erstaunlich oft falsch und man kann ja auch mal unsicher sein, ob man überhaupt im richtigen Bus sitzt. Da wären unsere Routen praktisch, wenn man die Kopplung zu den Fahrplandaten hinbekommt.

Ohne die Routen kann man sowas wie in http://tracker.geops.ch/?z=12&s=1&x=772883.4251&y=6647631.0931&l=transport bekommen. Da kann man sehr schön sehen, wie der gesamte Fernverkehr zwischen Köln und Düsseldorf über die Hildener Güterzugstrecke läuft. In der Wirklichkeit fahren die Züge natürlich über die Strecke weiter westlich.

Wenn wir uns aber nur darauf beschränken wollen, Linienpläne graphisch darzustellen (mit Pfeilen, wo es nur eine Richtung gibt), dann sollten wir PTv2 einstampfen, kein PTv3 erfinden und PTv1 in seiner ursprünglichen Art benutzen: das war genau für diesen Zweck konstruiert und es ist einfach. Eine Relation für die gesamte Linie und unempfindlich gegen Editiervorgänge anderer Zwecke. PTv1 wurde erst durch die Vermischung mit PTv2 schlechter und ab da waren die OSM-Linienkarten mit den Pfeilen Geschichte.

Weide

Hallo,

die Fahrpläne in die Relationen einzupflegen ist gar nicht so schwierig.
Wenn gem. PTv2 alle Varianten einer Linie erfasst sind kann man an der Ralation, ähnlich den open_hours bei Geschäften, die Abfahrszeiten festmachen.
Beispiel: Mo-Fr 08:17,08:54,09:57; Sa 09:00,10:05
oder wenn die Linie im Zeitintervall fährt Mo-Sa 06:05-23:00+15

An den Einträge für die Haltestellen wird dann die Fahrzeit entweder von der vorherigen Haltestelle oder vom Startpunkt aus hinterlegt.
Von der vorherigen Haltestelle macht das Erfassen einfacher, da man im Fahrplan nur die Differenz ziehen muss.
Bei der Fahtzeit vom Startpunkt muss man immer die Differenz von Startzeit zu Abfahrtszeit ermitteln. Ist bestimmt fehleranfälliger.

Ich kenne das Datenbankmodell nicht, aber aus meiner Sicht wäre es auch über die heute vorhande Rolle machbar.
z.B. Rolle Fahrzeit:2 (Zeit in Minuten)
Die Abfahrtsstation bekommt dann Fahrtzeit:0

Über die Addition aller Fahrzeiten ergibt sich dann die Ankunftszeit.

Damit wäre auch ein Reiserouting möglich.

Sind natürlich nur erste Überlegungen. Da gibt es bestimmt noch Details zu berücksichtigen

Gruß
Gino

Ich glaube, Netzwolf hatte mal Experimente zu der Idee gemacht. Ich kenne aber keine Resultate.

Wir brauchen aber eigentlich die Rollen als Rollen. Eine Rolle gibt ja eigentlich an, was dieses Element in der Relation soll. Typisches Beispiel ist Abbiegerestriktion: “Dieses Element ist drin, weil es die Richtung angibt aus der man kommt”. Entsprechendes haben wir bei PTv2 und in meinem Vorschlag … da ist dann eigentlich kein Platz mehr für Zusatzdaten. Jemand (Woodpeck?)hatte auch mal an Relationserweiterungen gedacht, so dass man jedem Element auch noch ganze Datensätze zuordnen kann. Ich hab aber etwas Angst vor so mächtigen Instrumenten…

Schöner wäre es aber, wenn wir von der Variante aus Verweise auf die Daten im Internet hätten. Dann bekommen wir auch Verspätungen und Ausfälle mit. Das müsste mit zwei Tags pro Variante machbar sein. So mal ins unreine:
timetable_proto=“VRR4711”
timetable_ref=“vrr:720O3: :H:j15”
Anhand der Protokollangabe könnte dann ein Kommunikationsplugin gewählt werden und dem wird das ref gegeben, damit er die Variante findet. Oder so ähnlich…

Weide

Dein Vorschlag berücksichtig dann aber nur grössere Städte. Ich glaube nicht, dass es für Buslinien auf dem Lande oder in Kleinstädten Onlinedaten gibt.

Ein Feld für Zusatzdaten bei einer Relationposition würde bestimmt nicht schaden.

Aber für die PTv2 Relation könnte man die Rolle trotzdem verwenden. Keine Ahnung für was stop oder plarform gebraucht wird. Diese Daten sind ja redundant zu dem verbundenen Node.

Zur Not könnte man ja stop:MIN eintragen.

Aber für das Alles muss es ja auch irgendwann mal ein Purposal geben.
Sehr wichtig und hilfreich wäre ja die Einführung der vorgeschlagenen Segmente.

Gruß
Gino

Zum Einen unterscheidet sich ein Fahrweg von einem Platformway nur durch die Rolle und zum Anderen haben nicht alle Haltestellen die zusätzlichen PTv2-Tags und diese sind auch ausdrücklich nicht erforderlich. Und dann gibt es ja auch noch Fehltaggings…

Bei PTv1 ging sowas. Da hatten wir dann aber bei den Versuchen im Vorfeld von PTv2 im Extremfall lustige Rollen wie “alternate:forward_stop:4:alternate:backward_stop:17” oder “alternate:backward:excursion”. Das sind eigentlich Datensätze und nicht Rollen. Nach meiner Erfahrung sind Datenstrukturen rachsüchtig: Wenn man irgendwas reinquetscht, was nicht da rein gehört, dann werden sie irgendwann bissig… :slight_smile:

Weide

Das kann ich zumindest für den Berliner Raum bestätigen. Lediglich das Auskuntssystem der DB AG nutzt eine eigene Karte. Die Auskunftssysteme der BVG, der S-Bahn Berlin GmbH (Tochter der DB AG) und des Verkehrsverbundes VBB nutzen für das Fußgängerrouting die Mapnik-Karte, bei den Standpunkten der jeweiligen Bahnhöfe und Haltestellen nutzen sie jedoch nicht die OSM-Daten.
Das ist für mich aber kein Grund, das Tagging nicht so zu verbssern, dass das Fußgängerrouting verbessert wird, wenn diese Auskunftssysteme irgendwann in der Zukunft vielleicht die vorhandenen OSM-Daten nutzen. Zumal die Wahrscheinlichkeit, dass sie sich zu diesem Schritt entscheiden, meiner Meinung nach entscheidend erhöht wird, wenn sie sehen, dass die OSM-Daten viel präziser auswertbar sind, als ihre eigene Datenbank.

Zu Ginos Vorschlag in # 4: Finde ich gut. Allerdings faällt mir auch gleich ein Detail ein, an dem man noch feilen müsste: Wie kennzeichnet man es, wenn der Zug/der Bus an einem Bahnhof/einer Haltestelle 5 Minuten (oder sonstwieviel) Aufenthalt hat?

Man könnte einfach einen Zeitraum in die Rolle schreiben. Das steht etwas ausführlicher in einem Entwurf / Notitzen.

Etwas in die Rolle zu kodieren, ist zwar für die Auswertung nicht besonders praktisch, aber für den Mapper einfach. Zudem wären solche OSM-Daten relativ gut mit dem JOSM-Relationseditor überblickbar.

Darüber hinausgehende Fahrtdaten (Ausfälle, Fahrtgeschwindigkeiten, Tarife, Zugteilungen, …) gehören meiner Meinung nach nicht in OSM weil diese Daten kaum noch Geobezug haben und das Datenmodell von OSM dafür nicht geeignet ist. Hier müssen in OSM eher Referenzen geschaffen werden damit Dritte den Bezug von OSM-Daten und verfügbaren Fachdaten herstellen können (vorstellbar wäre die stop_id aus GTFS in OSM zu pflegen, wenn wir mal annehmen, dass die verwendete stop_id allgemeingültig ist wäre).

??

Zumindest in der DB-Auskunft bekomme ich den Busfahrplan bis ins letzte Kuhdorf.

Ich halte aber überhaupt nichts davon, Fahrplandaten in OSM integrieren zu wollen (oder habe ich da was missverstanden?).

  1. sind Fahrplandaten keine Geodaten, sondern Zeittabellen
  2. wird die Datenbank sinnbefreit aufgebläht
  3. werden die Daten kaum jemals vollständig sein
  4. veralten die Daten viel schneller als man sie erfassen kann
  5. sind die Fahrpläne häufig viel zu kompliziert, mit Zeitintervallen ist es nicht getan

Viel sinnvoller ist es, die bereits vorhandenen Online-Daten mit der OSM-DB in Auswertungen zu verbinden.

Extrem wichtig finde ich es, zu Liniensegmenten zu kommen. Dann besteht eine Linie nur noch aus einem Hinweg und einem Rückweg, die jeweils alle Liniensegmente aller Alternativen der jeweiligen Richtung zusammenfassen.

Die Liniensegmente stelle ich mir als Liste der ways vor, die von den Verkehrsmitteln, z.B. Bus, benutzt werden, im Prinzip wie heute die Linie, aber nur als Teilestücke daraus.

Der Nutzen liegt darin, dass die Segmente viel kürzer sind als jetzt die ganzen Linien und von allen Linien referenziert werden können. Dann hat man auch im Zentrum der Großstadt nur noch ein bis drei Liniensegmente (geradeaus, links/rechts abbiegen) am Way und nicht wie heute 20 und mehr. Das erleichtert das Bearbeiten der Straßen ganz erheblich. Auch das Bearbeiten der Segmente wird viel einfacher als jetzt die Linien. Man braucht auch dann, wenn der Bus von der Bundesstraße nach A-Dorf und wieder zurück fährt, keine doppelten Wege mehr, sondern benutzt einfach 2 Segmente, die dann für Hin- und Rückweg referenzierbar sind. Die Bearbeitung in JOSM wird wesentllich einfacher, die Relation kann sortiert werden und es ist sofort ersichtlich, ob das Segment eine geschlossene Linie abbildet oder irgendwo unterbrochen ist. Außerdem erschlägt man mit dem Erstellen eines Segments gleich alle Buslinien, die den Weg benutzen.

Ich finde es auch sinnbefreit, bei OSM alle Fahrtvarianten abbliden zu wollen. Es reicht völlig, jeden befahrenen Weg durch Segmente zu erfassen und alle Segmente in einer Hin- bzw Rückwegrelation zu referenzieren. Welchen Weg welcher Bus wann fährt, ergibt sich aus den Fahrplandaten, und die zu erfassen ist meiner Meinunng nach Unsinn, s.o.

Wolfgang

Von Hin- und Rückweg kann man aus Sicht der Passagiere nicht in allen Fällen reden.

Beispiel: Wenn die Busse folgenden Varianten fahren:

  1. ABCDB (eine große Schleife durch den Zielort)
  2. ABDCB (genauso, nur anders rum)
  3. BCDBA (Umkehrung von 3. aus Sicht des Fahrers)
  4. BDCBA (Umkehrung von 1 aus Sicht des Fahrers)

Für manche Verbindungen ist es so wie für den Fahrer. Aber für die Leute, die nur die Schleife am Zielort benutzen, sind 2. und 4. die Umkehrungen von 1. und 3.

Wir brauchen für dieses Konzept aber keine Unterscheidung von Hin- und Rückweg. Wenn wir die Varianten nicht unterscheiden, müssen wir Hin- und Rückweg auch nicht unterscheiden. Da es dann auch nur noch eine Relation pro Buslinie gibt, ist der Bedarf nach Segmenten auch entfallen. Man anderen Worten: PTv1.

Weide

Die Unterscheidung von Hin- und Rückweg kann je nach Einzelfall tatsächlich entfallen, wenn bei kleineren Straßen dieselben ways benutzt werden.

Dagegen halte ich die Segmente für extrem wichtig.

Vorteil 1: Die Konsistenz eines geschlossenen Weges kann im Segment gut kontrolliert werden, Fehler sind sofort offensichtlich. Ob die Segmente aneinander anschließen, muss extra geprüft werden, aber auch dafür kann man eine Funktion schreiben.

Vorteil 2: Die Segmente können von verschiedenen Buslinien, die abschnittsweise die gleiche Straße befahren, referenziert werden. Damit habe ich dann nur noch eine Segment-Relation am way und nicht 20 Routen, wie es in manchen Innenstädten der Fall ist.

Vorteil 3: Die Segmente sind wesentlich kürzer und können leichter bearbeitet werden.

Die Arbeit für den Mapper, der den way als solches anfassen muss, wird damit entscheidend vereinfacht und die Einstiegshürde für OSM wird etwas gesenkt.

Also gerade nicht PTv1, das ist mit den zerrissenen Wegen, dem ständigen forward/backward und der Vielzahl der Routen am way ein einziger Alptraum, ebenso wie die Vielzahl der Routen am way in PTv2.

Wolfgang

Zur Klarstellung: Reden wir von Segmenten als zusätzliches Daten-Grundelement (das es bis Oktober 2007 schon mal gab). Oder verstehen wir unter Segmenten (normale) Relationen, die Teilstücke des Fahrweges beschreiben?

Wenn es ein zusätzliches Daten-Grundelement sein soll: Wie wahrscheinlich ist es, dass das eingeführt wird? Gibt es andere Anwendungsfälle, in denen Segmente “vermisst” werden?

Unabhängig davon: Gäbe es Sinn, dass mal “face to face” zu diskutieren, am besten auch mit Vertretern derjenigen, die diese OSM-Datenstruktur nutzen wollen (Fa. Mentz und andere). Zum Beispiel auf dem kommenden FOSSGIS Hacking Event.

Ich kann mir nicht vorstellen, dass die Routen mit solchen Minisegmenten dann noch lesbar und pflegbar sind.

Ich denke, man kann unabhängig von der Anzahl der Relationen dafür sorgen, dass im Normalfall gar keine Arbeit mit den Relationen entsteht. Das hab ich jedenfalls in meinem Vorschlag zu erreichen versucht.

Wenn wir in einer Gesamtrelation auch noch das “‘’/forward/backward” streichen, dann kann man nicht einmal mehr eine Linienkarte mit Pfeilen erstellen. Dann kann man die Routen besser ganz streichen.

Bist Du Dir sicher, dass Du PTv1 wirklich meinst? In PTv1 hat man eine einzige Route für die gesamte Buslinie und jeder Weg kommt da nur einmal vor! Das ist nichts im Vergleich zu PTv2. (Es gibt allerdings viele fehlerhaft gemappte)

Weide

Die meine ich.

Die Verkehrsunternehmen und Mentz DV haben zur Zeit und m.W. auch in Zukunft mit den OSM-Routen nichts vor. Die Mitarbeiter bei Mentz DV editieren Routen nur deshalb, weil sie beim Editieren der Haltestellen angepasst werden müssen.

Weide

Und wer könnte denn mal was mit Routen vorhaben?

Ich bin sehr pragmatisch eingestellt und schätze es, wenn mein Aufwand einem gefühlten Nutzen gegenübersteht. Routen wären für mich gefühlt die Kür. Innerstädtische Haltestellen (also überwiegend Bus- oder Straßenbahnhaltestellen) einheitlich zu mappen und die diversen Schemata abzulösen scheint mir demgegenüber das naheliegende Pflichtprogramm zu sein - und vom Aufwand her schon gigantisch genug.

Moin,

bevor wir Details neuer Datenstrukturen entwerfen, sollten wir überlegen, was das Ziel der Public Transport Daten in OSM ist.
Insbesondere bei den Buslinien liegt vieles im Argen:

  • die Daten sind unvollständig; in manchen Kleinstädten ist keine Buslinie erfasst, weder lokal, noch regional, noch Fernbus
  • die Daten sind als PTv1 oder PTv2 oder in undokumentierten Mischformen erfasst
  • die vorhandenen Daten werden selten gepflegt, es gibt zum Teil Lücken, zum Teil Datenfehler
  • Linien mit vielen Varianten können nicht praktikabel erfasst werden
  • nur wenige Mapper sind bei Buslinien aktiv
  • Straßen mit vielen Buslinien können von vielen Mappern nicht editiert werden ohne die Buslinien kaputt zu machen

Der einzig erkennbare Nutzen ist bislang eine sehr unvollständige und teilweise fehlerhafte Linienkarte.

Ein sinnvolles Fußgänger-ÖPNV Routing würde die vollständigen Fahrplandaten in allen Linienvarianten erfordern.
Das ist mit unseren Mitten nicht möglich, wie schon Osmonav geschrieben hat.
Mittelfristig werden sich ohnehin Onlinedienste zu diesem Zweck durchsetzen, da sich mobile Datenverbindungen verbreiten und
Onlinedienste auch kurzfristige Fahrplanänderungen und teilweise aktuelle Verspätungen berücksichtigen können.

Eine Ausnahme der Betrachtungen zu Fahrplandaten sind Fähren, die zwischen zwei Anlegern pendeln.
Dort sind Fahrzeit, Takt und Betriebszeiten recht leicht zu erfassen und stellen eine Hilfe für das Routing dar.

Die von Weide vorgeschlagene Linienerfassung über Segmente würde es vereinfachen, Straßen zu editieren, da nur eine Relation angepasst werden muss.
Andererseits würde eine weitere Abstraktionsebene (Linie - Variante - Segment - Way) den Einstieg in das Thema erschweren.
Wenn diese Variante zusätzlich zu den bestehenden Schemata eingeführt wird, müssten Mapper und Datennutzer noch mehr Regeln lernen.
Eine Verbesserung würde dieser Vorschlag nur ergeben, wenn er die alten Varianten ersetzt. Aber ist das realistisch?

Mehr aktive Mapper und somit bessere Daten kann man m.E. nur gewinnen, wenn man die Datenstrukturen einfach hält.
Eine Linienerfassung als geordnete Liste der Haltestellen ohne Streckenelemente wäre einfach und für jeden verständlich.
Defekte Relationen wären fast ausgeschlossen. Mapper, die Straßen bearbeiten, müssen sich nicht mehr mit Buslinien beschäftigen.
Eine Linienkarte müsste man dann allerdings mit Hilfe eines Routers erstellen. An wenigen, mehrdeutigen Streckenabschnitten wären Zusatzdaten nötig.

Eine radikale Vereinfachung wäre der Verzicht auf Buslinien in OSM.
Man könnte dann zu jeder Haltestelle die Liniennummern (mit Angabe des Verkehrverbunds) erfassen und dies als Schnittstelle zu anderen Diensten nutzen.
Linienkarte wären dann allerdings nur mit Daten Dritter zu erstellen.

Oder gar nicht mehr. Denn das Routing über OSM netze ist auch nicht ganz trivial.

Ich denke es gibt nicht umsonst Liniennetzpläne. Damit kann man sich wunderbar orientieren. Warum sollten wir in OSM darauf verzichten. Und weil wir die Daten erfassen, können wir noch mehr als einen Liniennetzplan anbieten. Nämlich die Information welche Haltestelle mit welcher ohne Umsteigen verbunden ist.

Das sehe ich als lösbare Aufgabe für die Editoren, vor allem Josm. Wenn ich in der Routenrelation ein Segment anklicke, sollte es möglich sein, die zu dem Segment gehörigen Ways zu highlighten. Im Gegenteil, kleinere Segmente sind wesentlich übersichtlicher. Das einzige Problem liegt in den Schnittstellen der Segmente. Aber auch das ist anhand der Nodes an den Schnittstellen, die in beiden Segmenten gleich vorhanden sein müssen, lösbar.

Dann hast du noch nie in einer Großstadt eine Straße angefasst. Stichwort z.B. bauliche Trennung, Kreisverkehr etc. Wenn du da 20 Relationen anfassen musst (in jeder Relation muss erst einmal die Stelle gesucht werden, an der geändert wird), nur weil du einen Weg auftrennen musstest (auftrennen im Sinne von Gegenverkehr, z.B. wegen Mittelstreifen - aber auch das Gegenteil, Gegenverkehrswege zusammenfassen, weil jede bauliche Trennung fehlt), wirst du schnell den Vorteil einer einzigen Relation kennenlernen.

Ich gehe mal davon aus, du meinst mit der “Linienkarte mit Pfeilen” kein Linienschema, sondern die Landkarte mit eingezeichneten Buslinien. Du selbst hast geschrieben, dass man auf die Unterscheidung Hin/Rückweg verzichten kann, wenn der Bus denselben Weg zweimal benutzt, etwa um von der B xx nach A-Dorf und zurück zu fahren. Eine “Linienkarte ohne Pfeile” ist auf jeden Fall machbar. Ob wir unbedingt eine Karte “mit Pfeilen” aus nur unseren Daten erstellen können wollen, müssen wir überlegen. Möglicherweise könnte die forward/backward/both-Rule ja auch in der Routenrelation an das Member-Segment gesetzt werden. Das Segment zählt die betreffenden ways in der befahrenen Reihenfolge auf, bzw. in der Gegenrichtung, wenn es mit der Role “backward” eingetragen würde. Damit ergibt sich die Richtung, in der der way befahren wird, aus der Reihenfolge im Segment. Zugegeben etwas mehr Aufwand bei der Auswertung, aber viel einfacher für den Mapper. Die Richtung der einzelnen ways spielt dann keine Rolle mehr.

Es ist richtig, dass in PTv1 jeder Weg nur einmal in der Route drin ist. Aber weil die ways für die Fahrtrichtungen teilweise aufgesplittet sind und teilweise nicht, ist es nicht mehr möglich, den Weg zu überblicken, ganz abgesehen von Sonderwegen für einzelne Fahrten. In Segmenten könnte man die JOSM-Sortierfunktion benutzen, danach müssen alle Wege im Segment eine zusammenhängende Kette bilden. Was fehlt, ist die Kontrolle, ob die Śegmente selbst zusammenhängen, s.o. Ich empfehle hier als Beispiele die Buslinien 31 oder 39 in Hamburg. Das ist in PTv1 einfach nur gruselig.

Auf jeden Fall “normale” Relationen, die Teilstücke der Fahrwege aller hier verkehrenden Buslinien beschreiben.

Die Routen werden zumindest in den sich mit ÖPNV befassenden Karten dargestellt. Einzelne Fahrtvarianten darzustellen, wäre eine Aufgabe, die zusätzlich die Daten der Fahrpläne auswerten müsste.

Eine ausschließliche Erfassung der Haltestellen, wie Seawolf sie vorschlägt, wäre zwar denkbar, aber es wäre schade, wenn die bedienten Straßenabschnitte nicht mehr eindeutig darstellbar wären. Sicher haben wir im Moment noch Lücken und kommen mit der Aktualisierung den ständigen Linienänderungen kaum noch nach. Das liegt aber vor allem an den unhandlichen Relationen in PTv1 und PTv2.

Den Vorschlag von Sven Wacker, einmal “face to face” zu diskutieren, halte ich für sehr sinnvoll.

Wolfgang

Ich würde hier aber eine “Vereinfachung” für unbedarfte Mapper vorschlagen:

Eine Haltestelle ist für jeden zu erkennen. Damit der Name, die Linie und der Operator. Wenn man diesen Node neben die Fahrbahn an die richtige Stelle platziert ist auch die Fahrtrichtung ablesbar. Weitere Angaben Bank, Schutz, Papierkorb kann auch einfach erfolgen. Man könnte sogar ein Bild verlinken.

Nun müsste ein “Relationserfahrener” nur noch eine Relation erstellen und die Straßenabschnitte dazwischen einfügen - eventuell über den Fahrplan.

So können einfache Dinge mit Erweiterungen zu nützlichen Sachen werden. (Ich selbst tue mich auch mit den ÖPVN schwer:

  • nimmt mann das alte oder das neue?
  • warum meckert JOSM wenn die Haltestelle neben einem hw liegt?
  • muss ein Bahnsteig in den Fußweg eingebunden, darübergelegt oder nur verbunden werden?

Um Dresden hat mal jemand einige notes zu fehlenden Bushaltestellen oder Linien gesetzt. Ich ändere so etwas nur, wenn ich vor Ort bin, nach meinem Wissen.