Vielleicht nimmt er einfach alles mit public_transport=stop_position und alles mit highway=bus_stop. In dem Fall wäre einfach das Verfahren falsch. Deine Routen sehen jedenfalls richtig aus.
Ein kleines Problem sehe ich nur in der Benennung, da haben mehrere denselben Namen und der Master ist auf eine seiner Varianten bezogen. Nach dem Vorschlag im PTv2 wäre das anders. Z.B.
Sieht so aus. Ich habe bei der Linie 15 mal Versuchsweise bei einer Haltestelle von zwei Nodes mit hw=bus_stop und und pt=paltform das pt=platform auf eine um den Node herum neu gezeichnete Platform (Als Fläche) verlegt (+ Relation angepasst), und siehe da (Vorher, Nachher), der Halte wird nur noch einmal dargestellt. Wo geht es zum Bug Report?
Ok, ändere ich.
Gibt es noch Ideen, was mit Linie 1 los sein könnte?
Oh, ja. So eine kenne ich bei mir auch (Line Diagram). Erwartet habe ich eigentlich soetwas in der Art (Bild1 bzw. Bild2). Die Linie ist aber zugegebener Maßen auch etwas schwierig, da sie sowohl unterschiedliche Starts, als auch Ziele hat, je nach Uhrzeit und Wochentag.
Dann werde ich mal vorsichtig bei den Developern nachfragen. Vieleicht lässt sich da ja noch was machen.
Bei der Linie 15 sind die langen Zwischenräume Fehlstellen, die durch Einbindung der doppelten nodes entstehen.
node1 auf der Strecke stop_position und bus_stop
node2 neben der Strecke die platform
Lösung: platform-node aus der route raus oder platform als way anlegen (wie es sich gehört).
Ich habe die funktionierenden Kombinationen mal unter http://wiki.openstreetmap.org/wiki/User:Axelr/Bushalte aufgelistet
Es ist nicht nur völlig OK, zwei Nodes für einen Halt in der Route zu haben, es soll auch nur dann einer weggelassen werden, wenn er nicht existiert:
“Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.”
Das finde ich auch sehr sinnvoll, denn nur dann kann man aus den Mitgliedschaften der Haltestellenobjekte auf die dort haltenden Linien schließen.
An einer Punkt-Platform, kann nur eine Person stehen. Die meisten Haltestellen bieten aber Platz für mehrere Wartende. Da ist der way oder das area die angesagte Form.
Die Geometrie des Haltebereichs sollte aber für die Auswertung / Erstellung eines Liniendiagramms keine Rolle spielen. Die dafür notwendige Information steckt komplett in den Rollen der Relationsmember und deren Tags. Wenn die Overpass-API hier irgendwelche anderen Informationen heranzieht, die für ein Liniendiagramm gar keine Rolle spielen, ist das nach wie vor ein Fehler in der Auswertung, und dieser besteht unabhängig davon, wie die Geometrie erfasst ist. Mal ganz davon abgesehen gibt es auch Haltestellen, bei denen gar kein Wartebereich als solcher ausgezeichnet ist, z.B. wenn diese Haltestellen sich nur durch ein Haltestellenschild auszeichnet, das irgendwo neben der Straße steht. Gemäß der On-the-ground-rule kann man dann eben nur die Position dieses Schildes erfassen, und das ist eben ein Node.
Adressen werden für Häuser vergeben. Ein Punkthaus …?
Zum Thema
Bei der Linie 1 liegt das Problem an der doppelten Haltestelle Steintor IHK.
sketch-line wäre wohl in Ordnung, wenn man eine Haltestelle mit einem Namenszusatz versieht.
Ach ja? Ich glaube es gibt zivilisierte Gegenden in Deutschland wo deine Aussage nicht zu trifft! Dort werden Adressen für Grundstücke vergeben! Aber kein Mensch würde auf die Absurde Idee kommen jetzt Grundstücksgrenzen für Adressen einzutragen. Oder?
Und Platform für Haltestellen ist meiner Meinung nach bei den meisten Bushaltestellen Schwachsinn. Sie unterscheiden sich nämlich durch rein gar nichts von dem Fußweg davor und dahinter! Also macht man aus nichts irgendwas! Und dann versucht man noch damit zu argumentieren, dass das andere viel zu klein wäre. Fahrgäste warten in der Regel auch nicht in einer Reihe welches deine Linie suggerieren würde.
Platform als Node: Dort wo es geht, weil ein Bussteig vorhanden bzw. auf dem Sat-Bild erkennbar ist, trage ich die als Area ein. Allerdings unterscheiden sich die Haltestellen dort nach einer Vor-Ort-Besichtigung überhaupt nicht vom Gehweg (Als Beispiel sei diese Haltestelle der Buslinie 15 gegeben, leider mit einem Finger von mir im Bild). Wären dort kein Schild und Wartehäuschen, könnte man die Haltestelle nicht vom Gehweg unterschieden. Daher ist es m.M.n dort nur möglich die Platform als Node einzutragen, wie es aus der entsprechenden Wikiseite auch eindeutig hervorgeht.
Umbenennen der Haltestelle: Was die Vermutung mit der Benennung der Haltestelle “Steintor IHK” der Straßenbahnlinie 1 angeht, so hatte ich zuerst auch vermutet, dass ein Umbenennen der Halte das Linie Diagramm wieder “vernünftig” darstellen lassen würde. Es ist auch anders, aber immer noch nicht Richtig (Bild). Außerdem alle drei Haltestelle leider gleich, in sofern kann ich nicht mit gutem Gewissen begründen, warum man die nun anders benennen sollte.
Ich denke mal, die einfachste Lösung wäre, wenn man das Line Diagramm für Linien nach dem PTv2 aller Mitglieder der Rolle “platform” ignorieren würde. Ist das machbar, oder übersehe ich da gerade etwas. Ansonsten schlage ich das mal bei GitHub vor.
Ich hätte nichts dagegen wenn Overpass-API weitere Fälle abdecken würde.
Das Thema war aber “wo dran liegt das”.
Ich muß wohl richtig stellen: Mit Fehlstelle meinte ich den langen Zwischenraum im Liniendiagramm, dieser entsteht nicht zufällig, sondern ist ein Anomalie im Liniendiagramm.
Man kann diese vermeiden, wenn man Haltestellen mit einschränkenden Regeln anlegt oder
darauf wartet bis das Auswerteprogramm erweitert wurde.
Bei public_transport warten wir schon ziemlich lange auf eine Umsetzung, so dass ich für mich einen Weg gefunden habe, im Istzustand alles unter einen Hut zu kriegen. Dabei ist der Doppel-node zu vermeiden.
Hier stimmen wir voll überein. Die bauliche Platform ist Teil des Gehwegs oder sogar gar nicht vorhanden.
Meine Folgerung: highway=platform gehört in die Mottenkiste.
Anderst verhält es sich mit public_transport=platform "The platform is the place where passengers are waiting for the vehicles. ". Kommt der Bus sind Wartende da , ist der Bus weg sind sie nicht mehr On-the-ground.
Ich wäre machmal froh, so viel Haltestelle wie auf deinem Bild zu sehen.
Nachdenklich macht einen der Haltstellenmast im Grünstreifen ohne befestigte Fläche ohne Fußweg.
Aber auch dort warten Personen auf den Bus.
Falls du mit wiki-Seite das proposel meinst, hebst du den Nebensatz ohne Hauptaussage hervor.
Sinngemäß steht dort:
Es ist üblich way oder area zu nehmen, wenn man sich gar nicht mehr anders zu helfen weiß, kann man auch mal den node verwenden.
Was ist denn an deinem Bild noch nicht richtig ?
Zu Namensvarianten:
Da hat 2009 Oxomoa eben dieses Problem erkannt und in seinen Beispielen eingesetzt.
Bei genauer Betrachtung erkennt man: Die erste Haltestelle heißt “Zentralplatz (Langgasse)” die zweite “Zentralplatz (Hauptstraße)”.
(Die zusätzlichen, abweichenden Namen an der Platform sind nach meiner Meinung mal durch direction=* abgelöst worden.)
Vielleicht erleichtert das dein Gewissen
Gruß Axel
Bevor ich die "platform"en zu den Relationen hinzugefügt habe, so das Line Diagram so aus. Daran sollte das Hinzufügen der "platform"en eigentlich ja nichts ändern.
(Wenn ich das Richig mitbekommen habe, ist das PTv2 nicht identisch mit dem Oxomoa-Schema.)
Bezüglich der “name” heißt es hier: “The name by which the platform is known, e.g.: C or 3. The name of the station/stop_area is given in the relation.” Das hatte ich da tatsächlich falsch im Kopf. Mal sehen ob die Änderungen irgendwelche Auswirkung auf das Line Diagram hat.
Interssantes Bild, hatte ich so noch nicht mit dem verstzten führenden Linienstück.
Du hast zwischen den Bildern den Linienweg umgedreht.
Nach meinen Versuchen wird als Hinweg der mit der kleinsten Relation-Nummer genommen.
Richtig, das Oxomoa-Schema war nur Vorüberlegung für PTv2.
(Das beschlossene Schema PTv2 ist von Weide auf seiner Seite referenziert.)
Ich bezog mich auf die aktuelle Seite PTv2 http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
Die von dir bezogene Seite sollte ein korrektes Vorgehen darstellen, sie ist aber recht unpräzise.
