Keine Sorge, ist längst korrigiert. Liebe Grüsse

Wurde seltsamerweise erst vor wenigen Tagen neu eingetragen. "Alt" kann es allerdings nicht sein, da man Gleis 1 erst kürzlich entfernt hat. Ohne aktualisierte Luftbilder oder AV-Daten wird's schwierig.

Bitte beachte, dass bei Schweizer ÖV-Linien die korrekte Schweizer Schreibweise gilt – insbesondere bei Haltestellen in der Schweiz. Völlig egal, was da irgendwelche Validatoren in JOSM, iD oder anderen Tools vorschlagen. Bitte nicht wieder zurückändern. Danke.

Ein Wort zum DiDok: dieses erfasst gar nicht die Transportunternehmen, die die Haltestellen anfahren, sondern "Haltestellenverwalter". Und das DiDok (respektive das BAV) akzeptiert nur einen einzigen Verwalter pro Haltestellenanlage. Bei der Eisenbahn ist dies immer der Infrastruktureigentümer. Bei Bushaltestellen ist der Eigentümer jeweils die Standortgemeinde, was wiederum das BAV nicht interessiert – deswegen stehen dort meist der grösste Linienbetreiber drin und ist gegenüber dem BAV meldepflichtig.

Im Kanton Zürich hat man aufgeräumt, hier ist es inzwischen pro Gemeinde das jeweils zuständige MVU (VBZ, SBW, PAZ, VZO, VBG, SZU Auto), das die Haltestellenverwaltung übernimmt, auch wenn es die Haltestelle gar nicht selber bedient.

Jedenfalls: das DiDok lässt grundsätzlich keine unterschiedlichen Haltestellen- und Kantenreferenznummern zu. Was aber nicht bedeutet, dass nicht vereinzelte Fehler geben kann. In Studen widersprechen sich am Wydenplatz die Kantenangaben zwischen DiDok und GTFS. Ist jetzt aber über das halbe Mittelland gesehen der erste Fall den ich gefunden habe.

Liebe Grüsse und guten Wochenstart,
Dani

Das hat nichts mit einem "Schweizer Tagging-Schema" zu tun, sondern einzig mit der Tatsache, dass in PTv1 Zugshalte schon immer separat als Stationsnode (ref = Haltestellenreferenz) und Eisenbahnperrons (ref = Perronbezeichnung [bei uns Gleisnummer]) getaggt wurden. Bushaltestellen werden dagegen klassisch als einzelner node (hw=bus_stop) getaggt und ref ist hier zwingend die Haltestellenreferenz, und local_ref ist die Kantenkurzbezeichnung.[1] Randbemerkung: Der eigentliche Schweizer Alleingang sind uic_ref und uic_name, die zwingend Open Data voraussetzen und nicht on-the-ground feststellbar sind – und dass wir das ref leer lassen (weil zu uic_ref teilredundant) ist die eigentliche Schweizer Eigenheit.

Zurück zum Thema: das Problem, dass du zu sehen glaubst, ist einzig durch PTv2 entstanden. Bei Zugsperrons ist es logisch, dass pt=platform auf dasselbe Element wie rw=platform kommt. Auch bei hw=platform geht dies problemlos. Da aber rund die Hälfte der OSM-Community der Meinung ist, dass pt=platform auf das Element hw=bus_stop geklatscht gehört (und iD dies offenbar immer vorschlägt), hat man sich nun selber ein Problem geschaffen, welches es vorher gar nicht gab.

Im Prinzip ist es einfach, du darfst nicht Dinge gleich behandeln, bloss weil sie für dich gleich aussehen. Was im "ref" steht hängt schlicht nicht von pt=platform ab, sondern von den zugrundeliegenden PTv1-tags. Oder nochmals anders formuliert: ist das pt=platform-Element ein node, ist local_ref zu verwenden, ist das Element ein way, kann ref verwendet werden. Entsprechend verwende ich auf pt=stop_position (zwingend ein node) immer local_ref, weil ich im ref eine Haltestellenreferenz erwarte.

[1] highway=bus_stop

Hoi Raphael,
nun die kurze Antwort wäre, weil wir dies schon immer so gemacht haben (und die spezialisierten transport maps local_ref darstellen).

Aber natürlich gibt es auch eine längere Erklärung: im ZVV ist ref=* durch die ZVV-eigene vierstellige Haltestellenreferenznummer belegt (weicht von uic_ref ab, nicht nur wenn man das Landespräfix 85 streicht). Die individuelle Kantenbezechnung geht daher über das spezifischere local_ref.

Neu dazu kommt, dass das BAV seit drei(?) Jahren von den TU verlangt, dass sie die einzelnen Haltepunkte ausweisen. Dies wird in der Didok-Erweiterung Verkehrspunktelemente publiziert und wäre der nächste Anwendungsfall von ref=*. Problem: die betrieblichen Bezeichnungen lauten oftmals 1, 2 etc. während für die Kundenkommunikation jeweils Buchstaben verwendet werden (und Zahlen den Gleisen vorbehalten sind). Hierbei hat der ZVV wiederum ein eigenes System (0er für Tramkanten, 10er für Trolleybuskanten, 20er für Stadtbuskanten, 50er für Nachtbuskanten/Überlandbuskanten, 80er für Ersatzbuskanten), und PAG ebenso (SCHEZEL1, SCHEZEL2, SCHEZEL3 steht beispielsweise für die Haltepunkte Zellfeld, in Schenkon).

Was das ref=* an Zugsperrons betrifft, entspricht dies eigentlich nicht der Schweizer Realität, dass wir die Gleise neben dem Perron bezeichnen, und nicht das Perron selber. Immerhin gibt es keine Widersprüche zur ref-Angabe in den Verkehrspunktelementen.

Die Frage ist also _nicht_, welcher tag weiter verbreitet ist, sondern welcher logisch Sinn macht. Und das ist in diesem Fall local_ref, da dieser nicht mit einer anderen ref dieses Objekts kollidiert.

Grüsse, Dani

Deine Behauptung ist falsch, es gibt zwei korrekte Wege ein platform-Element zu erfassen: entweder als Knoten (mit highway=bus_stop) oder als Weg (mit highway=platform und highway=bus_stop auf dem stop_position-Element).[1]

Nach endlosen Diskussionen mit usern datendelphin und Nzara ist es explizit _nicht_ erwünscht, korrekt gemappte platform-Knoten durch, platform-Wege zu ersetzen. Das wird grundsätzlich den lokalen Mappern überlassen.

Was aber ganz sicher nicht geht, ist korrekte platform-Elemente einfach aus sämtlichen Relationen rauszulöschen. Entweder man macht es sauber und ersetzt die Elemente in den Relationen wieder an der richtigen Stelle, oder man lässt es bleiben.

Auffällig ist zudem, wie Neo-Mapper wiederholt mit dem Satzfragment "meine Arbeit" ihre komplette Ignoranz bezüglich der Arbeit dutzender anderer beteiligter Mapper demonstrieren, die ebenfalls viel ihrer Lebenszeit in OSM investiert haben. Es ist grundsätzlich jedem selber überlassen, wie er seine Zeit in OSM investiert, man ist aber gut beraten sich mit lokalen und regionalen Gepflogenheiten vertraut zu machen, bevor man anderen Mitarbeitenden einfach auf Füsse tritt.

[1] osm.wiki/Public_transport

Same here. All turn restrictions added are incorrect. They don't exist as such, neither signed, nor as unsigned (implicit) default. Please don't add things that don't exist into OSM. Thank you.

Hi. Never split roads just to add U-turn restrictions on each and every segment. This is incorrect, and a central example for bad mapping.

See also: osm.wiki/FR:Relation:restriction

Don't fix, what isn't broken, just because Maproulette suggests something. This is a clear false positive, and anyone can go from north (rte de Chailly) to west (rte de la Saussaz) without entering the roundabout, which is by design, and NOT by mapping error.

Spannend, seit Jahren sind es immer wieder die angefressenen Bahnmapper, die historisches wiederholt von Null auf mappen. Früher fand ich es schade, dass dies gelöscht wurde, aber mittlerweile muss ich zugeben, dass ich ganz froh bin, kommen solche Sachen weg, bevor iD oder StreetComplete vorschlagen, dass man dort doch sicher wieder irgendwas umtaggen könnte...

Bei alten ÖV-Relationen (mit LC-prefix 'disused' oder 'was') kommt glaub iD immer mit einem Korrekturvorschlag. :-/ Seither gilt für mich: in JOSM speichern und löschen, da bei gewissen Nutzern das Leseverständnis nicht mit deren Klickfreude korreliert...

Aber eigentlich wollte ich was völlig anderes anmerken: Steg an der Thunstrasse 96, links vom Burgernziel, dürfte aufgrund Insolvenz wohl 'disused' sein... :-?

Vom Sofa aus "einfach irgendwas machen", ist kein qualitativ gutes Mapping. Und 'upon request' ist auch keine Quelle, denn es ist nicht ersichtlich warum hier etwas geändert wird, was der amtlichen Dienststellendokumentation widerspricht.

OSM erfordert, dass man sich mindestens mal im Wiki einliest, bevor man irgendwelche Dinge einträgt, die für das betreffende Element völlig ungeeignet sind.

Beginne mit Änderungen bitte zuerst an deinem Wohnort, wo du vor Ort, vor deiner Türe abklären kannst, wo es wirklich eine Haltestelle gibt, oder wo der Bus gegebenenfalls seit Jahrzehnten nach Gewohnheitsrecht anhält. Das sind gehaltvolle Angaben, die nicht von allen Verkehrsunternehmen in guter Qualität zur Verfügung gestellt werden.

Das Verschieben von Haltekante 54 auf 53, ohne vor-Ort-Abklärung ist dagegen keine Verbesserung, sondern Glaskugellesen, zumal die Eigenschaften von 54 nicht zwingend auf 53 zutreffen.

Wenn man mit den Widersprüchen im wiki nicht klar kommt, kann man auch das OSM-Forum bemühen. Aber einfach irgendwelche tags vervielfältigen und Elemente doppeln ist nicht zielführend.

HTH, und happy mapping.

Ziehe nicht irgendwelche Papierfahrpläne zu Rate, sondern die freien GTFS-Datensätze, die uns von der SKI via opentransportdata.swiss zur Verfügung gestellt werden. Die 403 fährt sonntags nach Attinghausen und wechselt auf die 402 nach Brügg. Würde man auch merken, würde man die Fahrplanfelder studieren.

Unterlasse es bitte, korrekt eingetragene Strassen innerhalb von Parkplätzen, Fusswege, Bushaltestellen etc. zu löschen. Auch die Gebäudegrundrisse stammen im Kanton Solothurn aus dem kantonalen GIS und bedürfen keiner Verschlimmbesserung aus Luftbildern. Danke für die Kenntnisnahme und viel Erfolg beim Mappen.

Nein, absolut nicht. Belagsrosetten sind keine Kreisverkehre und dürfen (auch mit Pfeiler drauf!) links umfahren werden, wenn man links abbiegt. Genau aufgrund des ständigen Fehlverhaltens von Autofahrern, die von einem Kreisverkehr ausgehen, werden die Dinger seit einigen Jahren bei Belagserneuerungen systematisch rückgebaut respektive in einen Vertikalversatz (table) geändert. Also bitte jetzt nicht anfangen ein aus der Zeit gefallenes Verkehrsberuhigungselement, zu etwas "zurechtzubasteln" bloss damit die Validatoren Ruhe geben.

Ich weiss nicht ob du StreetComplete falsch bedienst, aber es wäre nett wenn du aufhörst (wiederholt) Haltestellen zu löschen. Danke schön.

Hi johsin18,

Zu einem conditional gehört zwingend ein Interval (Anfang-Ende). Wenn das Basler Tiefbauamt erklärt, das Einrichtungsregime bleibt bis Sommer 2026[1], dann werde ich das nicht in Zweifel ziehen. Zweieinhalb Jahre sind mehr als genug Zeit, um den Endtermin gegebenenfalls anzupassen. Und stur auf 'oneway=yes' setzten (und vergessen) ginge natürlich auch – halte ich für eine unsaubere Lösung, da erfahrungsgemäss oft irgendwelche Segmente vergessen gehen.

Das Velorouting habe ich auf den drei Abschnitten beim Zoll tatsächlich vergessen – entweder 'bicycle=yes' auf die 'highway=construction'-Abschnitte oder 'oneway:bicycle=no' auf die drei Abschnitte daneben – oder den Abschnitt einfach krude mit 'highway=cycleway' überbrücken.

Ersteres dürfte am ehesten "man kann sich durchschlängeln" entsprechen, zweiteres ist aufgrund des provisorischen Charakters ebenfalls nicht falsch und für Router wohl eindeutiger. Hab jetzt zweiteres genommen, Ende April 2024 ist ohnehin die nächste Verkehrsphase absehbar, wenn der Verkehr wieder durch (respektive um) den Zoll via Kreisverkehr in die Neuhausstrasse geleitet wird.

Die Anpassungen sind im changeset/146399306[2] enthalten. Kommentar willkommen. ;-)

Grüsse,
d_berger

[1] https://www.tiefbauamt.bs.ch/baustellen-und-projekte/aktuelle-grossprojekte/Freiburgerstrasse.html

[2] changeset/146399306

Würdest du dir freundlicherweise die Zeit nehmen, das wiki zu lesen, bevor du einfach irgendwas zusammenklickst und Fehler am laufenden Band produzierst?

iD ist kein geeignetes Werkzeug um, ÖV-Routen zu warten, das geht nur mit JOSM sauber.

Die Haltstellenelemente werden nicht in einer stop_area_group zusammengefasst, sondern in einer stop_area.

Die korrekte Rolle für eine stop_position lautet 'stop' und nicht 'stop_position'.

Das Auftrennen von Kreisverkehren ist weder produktiv, noch erwünscht, sofern keine zwingenden Gründe vorliegen (z.B. wechselnde Anzahl Spuren im Kreisel).

HTH

Hi. Bitte die Änderungen im CS-Kommentar zusammenfassen.

Und wieso "layer=1"? Strassen auf der Oberfläche sollten _nie_ eine layer-Angabe tragen. Bei iD ist dies meist ein Zeichen, dass ein ahnungsloser Mapper einen (allfälligen) Fehler maskiert. Ich sehe den Grund dafür nicht, und der Validator in JOSM auch nicht...

Jetzt reicht es langsam. Ich habe dich bereits aufgefordert nicht mit veralteten Datensätzen und veralteten Luftbildern zu mappen, sondern deinen Hintern hoch zu kriegen und die Angaben vor Ort zu überprüfen. Jetzt trägst du wiederholt denselben Datenmüll ein, den ich bereits gelöscht habe, da es ihn vor Ort nicht mehr gibt.

Ich werde dies in Zukunft kommentarlos entfernen. Insbesondere auch aus den aktuellen Baustellen im Quartier. Vielleicht hilft es, dann man mal den Kopf einschaltet und etwas mitdenkt, bevor man einfach irgendwelchen Datenmüll "importiert."

Beste Grüsse