Neuling legt Buslinien an

Hallo zusammen,

ich habe vor wenigen Tagen angefangen, richtig bei OSM mitzuarbeiten. Wege und Gebäude zu bearbeiten klappt ganz. Ich habe bereits zwei Buslinien angelegt, die Linie 30 der Havag (Halle/Saale) (5867555) und die Linie 358 der Omnibusbetriebe Saalekreis (5868452). Ich bin jedoch nicht dahintergestiegen, wie ich Bushaltestellen korrekt anlege. Es scheint wohl möglich zu sein, den Bushalt direkt auf die Straße zu legen oder aber neben die Straße. Auch weiß ich nicht, wie ich die Bushalte der Linie zuordne. Geht das mit Potlach2 überhaupt?

Auch über sonstige Anmerkungen zu meinen Änderungen bin ich natürlich dankbar, vor allem, falls ich irgendwo Fehler gemacht habe.

Das
https://wiki.openstreetmap.org/wiki/DE:Relation:route

und das

http://ra.osmsurround.org/analyzeRelation?relationId=5867555&_noCache=on

kennst du?

Ich bin auch noch nicht richtig “dahintergestiegen” und lasse “ÖPVN” außen vor.

Hallo Saint-Louis,

willkommen bei OSM und im Forum.

Ich bin nicht der Fachmann für ÖPNV und mein letzter Besuch in Halle liegt auch schon ein paar Jahre zurück.
Aber über deine Ergebnisse bin ich begeistert :slight_smile:
http://www.osm.org/relation/5867555
http://www.osm.org/relation/5868452

Kennst du die folgenden Seiten im Wiki schon?
http://wiki.osm.org/wiki/DE:Public_transport
http://wiki.osm.org/wiki/DE:Busse

http://wiki.osm.org/wiki/DE:Potlatch_2

Es gibt das “alte” Schema und das neuere für die Erfassung von ÖPNV.
http://wiki.osm.org/wiki/DE:Tag:highway=bus_stop
http://wiki.osm.org/wiki/DE:Tag:public_transport=stop_position

Das neue Schema ist detailierter und bittet zusätzlich um Erfassung z.B. des Wartebereichs:
http://wiki.openstreetmap.org/wiki/DE:Tag:public_transport=platform

Mit Potlatch2 kann man die benötigten Relationen erstellen (Ich arbeite auch mit P2).
Es wird aber viele erfahrene User geben, die dir den Umstieg auf JOSM empfehlen werden.
Die Entscheidung liegt bei dir. Alle Produkte haben ihre Vor-+Nachteile.

Das sieht doch ganz gut aus. Was Du da benutzt ist das alte Schema (PTv1). Schreib das am Besten auch in die Relation (public_transport:version=1). Haltestellen gehen bei diesem Schema nur als Punkte mit highway=bus_stop, Du kannst also keine Haltestellen als Linien oder Flächen aufnehmen. Die Haltestellen kommen mit in die Relation und Du kannst ihnen die Rolle “stop” geben. Die Reihenfolge ist egal für die Bedeutung. Die Haltetellennodes können auf den Fahrweg oder daneben. Wenn sie daneben sind, dann ist nur eine Richtung gemeint. Auf dem Fahrweg ist es für beide Richtungen gedacht.

Die Rollen “forward” und “backward” scheinen nicht so ganz zu stimmen. Z.B. ist der Weg 5867555 “Riebeckplatz” mit “backward” angegeben. Da es auch noch ein “oneway=yes” hat, fährt der Bus also immer nur gegen die Einbahnrichtung. Das hast Du vermutlich nicht gemeint. “forward” und “backward” sind sowas wie oneway=yes bzw. oneway=-1 nur für diese Buslinie.

Mit dem alten Schema kann man sehr schön alles angeben, was man für einen Linienplan mit Pfeilen braucht. Sobald man was komplizierteres machen will muss man auf das jetzt aktuelle PTv2 umsteigen. Da kann man dann auch angeben, dass die Buslinie Varianten hat und dass z.B. der Bus über die X-Straße in A-Dorf später in B- Dorf immer den Schlenker über die y-Schule macht und sowas.

frohes Mappen
Weide

Vielen Dank für die Informationen und das positive Feedback. Ich denke, ich bleibe erstmal beim alten Schema, da es weniger kompliziert zu sein scheint und ich momentan auch wenig Interesse daran habe, alle Varianten der Linien einzupflegen. Ich mappe also den Normalfall und lasse Sondervarianten im Schülerverkehr, o.ä. außen vor. OSM kann schließlich eine Fahrplanauskunft nicht ersetzen.

Das ist völlig OK.

Das mit dem “weniger kompliziert” ist längerfristig nicht ganz so eindeutig:

Solche Relationen ändern sich durch andere Editiervorgänge wie lane-Mapping und dem Eintragen von Geschwindigkeitsbegrenzungen. Beim alten Schema ist es ziemlich mühsam, die ganzen “forward” und “backward” und “” immer wieder einzeln zu prüfen und fehlende Stücke zu finden ist manchmal auch nicht ganz einfach.

Beim neuen Schema würde man jede Richtung als eigene Relation anlegen und die wären beide sehr viel einfacher: eine durchgezogene Linie ohne den “forward”- und “backward”-Kram … da reicht die Reihenfolge der Angaben und alles ist eindeutig.

Es sind dann aber drei Relationen: Hinweg-Relation, Rückweg-Relation und die Master-Relation, die nur eine Liste der Varianten ist. Wenn dann jemand z.B. die Schultour um 6:42 hinzufügt, dann wird nicht alles unübersichtlich sondern es ist einfach nur eine zusätzliche Variante.

Hat alles so seine Vor- und Nachteile. Ein Gegenüberstellung der beiden Schemata hab ich auf http://wiki.openstreetmap.org/wiki/User:Weide liegen.

frohes Mappen
Weide

Da ich auch nicht so richtig bei ÖPVN durchblicke, aber festgestellt habe das Router public_transport=platform nicht mögen, sollte dort unbedingt highway=footway dran.

highway=platform und public_transport=platform gemeinsam zu verwenden halte ich für falsch.

Das sehe ich nicht ein.

Ist es denn in Ordnung, wenn Router Bus- oder Bahnsteige als nicht für Fußgänger geeignet betrachten wenn das public_transport=platform fehlt?

Jeder normale Bahnsteig oder Bussteig ist für Fußgänger gedacht und es ist daher eindeutig ein Routerfehler, wenn das nicht drin ist. Wenn Router highway=tertiary nicht mehr als für Autos geeignet betrachten, dann besteht die Lösung doch auch nicht darin, sie alle als highway=road umzutaggen.

Weide

Hallo - sicher Missverständnis:

Wenn public_transport=platform getaggt ist, warum muss dann noch (die vorhergehende Version) highway=platform bestehen bleiben?

zweimal der gleicher “Wert” an verschiedenen Schlüsseln?

Dann kann doch highway=footweg “durchgängig” genutzt werden - die public_transport=platform muss doch an einen Fußweg angeschlossen sein.

(Oder ist es weil sonst public_transport=platform nicht auf OSM als eigener Weg erkennbar ist, da highway=platform anders gerendert wurde?)

Ja, das kann gut sein. Ich bin einfach von der Frage ausgegangen “Was bedeutet highway=platform?” Da komme ich zum Ergebnis, dass die Router fehlerhaft sind, wenn sie da keine Fußgänger zulassen. Das ist deshalb für mich ein Routerproblem. Als Programmierer stufe ich das Problem dann auch noch als relativ leicht lösbar ein. Deshalb denke ich dabei nicht über Möglichkeiten nach, wie man das Problem mit zusätzlichen Regeln für highway=platform umschiffen kann.

Ganz anders ist das z.B. beim Flächenrouting. Das ist ein massives Problem für die Routerprogrammierung. Da muss man ernsthaft überlegen, wie man vorläufig klar kommt und man muss evtl. Kompromisse in der Sauberkeit der Datenbank machen.

Weide

Zu der Bahnsteigfrage: Man kann nicht davon ausgehen, dass Bahnsteige für die Allgemeinheit zugänglich sind. Bei uns ist das zwar so, in anderen Ländern darf oder kann man einen Bahnsteig jedoch nur mit gültiger Fahrkarte betreten. (Pariser oder Londoner U-Bahn beispielsweise).

Das gibt es auch in Deutschland: http://www.shz.de/lokales/pinneberger-tageblatt/verwirrung-um-die-bahnsteigkarte-waren-die-bussgelder-berechtigt-id9429921.html

Ja, aber der Bahnsteig ist trotzdem zum Begehen gedacht. Das ist nur eine Zugangsbeschränkung wie z.B. bei Mautstraßen für Autos.

Weide

Warum gibt es highway=platform überhaupt (noch)? Als Programmierer ist es doch sicher einfach sich einen “Wert” in mehrere Schlüssel aufzuteilen.

Router sollen sich ändern! - Renderer brauchen es nicht?

(Ich bin kein Programmierer und am Ende)

Ja, die Router sollen sich ändern.

Das mit den Renderern ist ne berechtigte Frage. Die sollten eigentlich auch den PTv2-Kram anzeigen.

Das PTv2 hat uns da aber ein Ei ins Nest gelegt, das schwer auszubrüten ist. Wir haben sowohl stop_positions als auch platforms und jeder der beiden darf weggelassen werden. Wir wollen Haltestellen aber darstellen und wir wollen sie nicht doppelt darstellen. Wir können also nicht einfach sagen “stop_positions sollen dargestellt werden, platforms aber nicht”. Umgekehrt geht es aber auch nicht. Wir müssen also die Pärchen finden. Das ist schon normalerweise nur durch Untersuchen der Routen möglich, denn da müssen alle existierenden Teile genannt werden. (Das wissen viele nicht: man muss die Sachen nicht mappen. Aber gemappte müssen in der PTv2-Route stehen) Aber die Pärchenbildung ist nicht eindeutig, d.h es kann auch mal eine stop_position zu zwei Platforms gehören und auch eine Platform zu zwei stop_positions. Wie stellt man da noch fest, ob eine fehlt? Ich habe keine immer funktionierende Lösung gefunden.

Da das alte Haltestellentagging aber voll und ganz PTv2-kompatibel ist und die Darstellung für die schon eingebaut ist und PTv2 ganz ausdrücklich die alten Haltestellentags nicht ablösen will, bietet sich das Rendern der alten Sachen an.

Eine schöne Lösung ist das natürlich nicht. Aber ist geht.

Weide