Reverted for blatant vandalism with changeset/176293655 (changeset/176293655)

Ich schreibe schnörkelfrei, das ist nicht aggressiv, sondern effizient.

Kein einziges Kundenparkhaus in der Stadt schreibt explizit hin, dass es nicht für die Öffentlichkeit ist. Umgekehrt geht nur, wenn man eine städtische Bewilligung hat (z.B. Globus). Das ist in letzter Zeit so ein OSM-Ding geworden, dass defaults und nicht-Eigenschaften (*=no) gemappt werden.

Gemäss Signalisation wiederhergestellt. LG

Als Mapper solltest du das Wort 'survey' verstehen, sonst hilft DeepL. Das Parkhaus ist seit einigen Jahren nicht mehr öffentlich, auch wenn kein bewaffneter Wächter nach einer Coop-Quittung fragt.

Hallo MappSurfer, du wurdest mehrfach im Namen der Data Working Group durch Frederik Ramm aufgefordert das Mappen inexistenter Objekte wie längst abgebauter Gleise zu unterlassen. Dies ist wiederholt ein Changeset in dem du diese klare Ansage ignorierst und noch dutzendfach Multipolygone an solche Elemente bastelst, oder bestehende Polygone in MP umwandelst, was sinnfrei und unerwünscht ist.

Anhand deines Verhaltens gehe ich davon aus, dass jegliche weitere Diskussion reine Zeitverschwendung ist, genauso wie die Versuche sinnvoll aufzuräumen. Entsprechend habe ich mit changeset/157203270 die Änderungen zurückgesetzt. Im Wiederholungsfall werde ich um eine Sperre bitten.

Schönes Wochenende.

Bitte nicht mit Beta-Tools irgendwelche Kreisverkehre splitten. Wir splitten Kreisverkehre grundsätzlich nicht, ausser es gibt physische Gründe dafür, z.B. wenn die Anzahl Fahrspuren im Kreisverkehr ändert.

Zudem splittet das Tool unsauber (mehr Segmente als notwendig), berücksichtigt keine nicht-ÖV-Relationen (Hauptstrassen, Wanderwege) und macht das erstellen neuer Relationen grausam qualvoll.

Dies nur als grösster Punkt, was das Tool nicht ansatzweise beherrscht. Zudem habe ich in den letzten Monaten sämtliche ÖV-Relationen in 19 Kantonen bereinigt, entsprechend lang erscheint mir die Liste an Dingen, die das Tool _nicht_ beherrscht.

LG, Dani

Bitte keine korrekt eingetragenen Treppen und Fusswege löschen. Strassen und Wege gehören auch nicht mit irgendwelchen Hausecken verbunden.

Mit changeset/155455443 auf vorherigen Zustand revertiert.

Es gibt hierfür leider keine Lösung, ausser den "Click-Button-Jockeys" beidseits der Grenze den Validator zu entziehen. Im Raum Basel (respektive in fast allen CH-Grenzgebieten) existiert dasselbe Problem – dort dann eher umgekehrt.

Warum allerdings ein langjähriger OSM-ler den Kopf ausschaltet, nur "um die Warnung weg zu machen" kann ich nicht nachvollziehen.

Die Antwort auf 'Züri wie neu' erklärt wohl, warum auch am Uetliberg die seit 1999 gültigen, bereinigten Strassenbezeichnungen, bis heute – also 25 Jahre später – bestenfalls unvollständig bzw. gar nicht umgesetzt wurden...

Baustellen bitte recherchieren:
https://www.freienbach.ch/freienbach/aktuelles/news/2186110

Eine Neueintragung in der Woche der Fertigstellung ist kontraproduktiv, hab die Strasse daher wieder als befahrbar eingetragen. Grüessli

Bitte beachte, dass baulich nicht abgetrennte Radstreifen nicht als eigenständiges highway-Element gemappt werden, sondern mittels lane tagging (z.B. cycleway=lane) auf dem entsprechenden Strassenelement, wie es bereits korrekt erfasst war. Ich habe die duplizierten Eigenschaften daher wieder entfernt.

Danke für die Korrektur des Kreisverkehrs.

Splitte keine Strassen an einfachen Fussgängerinseln repektive Leitinseln. Zum Mappen gehört das abstrahieren von Eigenschaften, nicht das ein-zu-eins abzeichnen irgendwelcher Flächen. Danke.

Vermutlich durch gar nichts; die Beschränkung wurde vor siebeneinhalb Jahren in changeset/44870704 eingetragen und vor sechs Monaten 'dank' Maproulette-Quest in changeset/145602460 einfach blind übertragen. Weil dabei wieder mal sämtliche Relationen zerschossen wurden, habe ich in diesem CS den Kreisel neu komplett aufgespalten, konnte aber die Signalisation nicht vor Ort überprüfen.

Hoi Roman, gern geschehen. Mit der Mapping-Genauigkeit und Strassengeometrien, sind wir im Mittelland recht gut unterwegs, da komme ich auch relativ zügig voran. Aber der ehemalige OAK-Busbetrieb ist schon eine Nummer, alleine bei Linie 51 gibt es 33 Varianten, die ich jetzt auf 14 "relevante" Fahrwege reduziert habe. Uff... Liebe Grüsse, Dani

Was bitte spielt das für eine Rolle? Die physischen Gebäudeeigenschaften ändern sich dadurch schon mal sicher nicht.

Hallo, nochmals. Lösche keine tags, die du nicht kennst. Dazu gehören auch korrekt gemappte Gebäudeteile, wo sich jemand die Mühe gemacht hat die einzelnen Dachformen und -farben zu erfassen. Danke.

Bitte lies die tags richtig, das ist mit 'building=construction' eingetragen und bereits der neue Gebäudegrundriss.

Hallo Moritz. OSM ist leider gelegentlich eine Sammlung von halbgaren Ideen. ;-)

stop_area war einzig dazu gedacht, PTv2-Elemente (stop_position und platform) zusammenfassen, welche dieselben Referenzwerte (ref, uic_ref, uic_name, name) besitzen. Dies als wundervolles 'high-concept', um Redundanzen zu minimieren. Leider im Alltag unbrauchbar, da ich zumindest beim Editieren auf Klarnamen angewiesen bin und mit der OSM-ID der Objekte selber nichts anfangen kann. Und auch QA-Tools wie PTNA holen sich aus den ÖV-Relationen die Angaben von den Objekten und nicht von allfälligen Elternrelationen.

Inzwischen werden daher (wenig beachtet) auch 'Kraut & Rüben' erfasst, und Relationen wie wikipedia-Kategorien verwendet, obwohl dies dies als 'do-not' [2] deklariert ist.

platform_edge ist ein railway-Element (und als solches nie automatisch ein PT-Element), und erfüllt als eigenständiges Objekt keinen Zweck, sondern dient dazu ein platform-Objekt besser zu beschreiben. Grade im Beispiel hier, wo die platform bereits ein multipolygon ist, hättest du dir etwas Arbeit sparen und den Umriss an den Eckpunkten auftrennen können, dann hättest du automatisch zwei Kanten erhalten. platform_edge ist dann auch logisch korrekt Teil des Perron-Multipolygons, der wiederum Teil der stop_area ist (sofern er im Personenverkehr verwendet wird). Reiner Güterverkehr ist nie public_transport – wenn man dies erfassen möchte, dann müsste man korrekterweise mit einer (railway-)site-Relation arbeiten. Das Problem ist, dass "schlaue" Editoren wie iD, solche Unterscheidungen nicht beherrschen, überall dieselben tag-Vorschläge machen und auf diese Weise fehlerhaftes Tagging salonfähig machen.

Ich hoffe, dass meine Erklärung die Zusammenhänge klarer macht.

Liebe Grüsse, Dani

[2] osm.wiki/DE:Relationen/Relationen_sind_keine_Kategorien

@Fijord: Das ist im Grunde so, dass wir die "technischen Adressen" mit Dezimalpunkt und ähnlichem in OSM _nicht_ erfassen – zumindest solange es erkennbar technische Adressen sind. Was man in jedem Fall vermeiden sollte, ist dann daraus noch eine "postalische Adresse" mit PLZ und Ort zu basteln, die es schlicht nicht gibt.

Hallo Mischa, danke für die Quelle. In dieser ist abzulesen, dass Velo und Bus weiterhin in Gegenrichtung fahren dürfen, was ich in changeset/152244334 ergänzt habe.

Ich nehme an die Pestalozzistrasse ist ebenfalls wie abgebildet nur auf dem Abschnitt Schiller–Hadwig 'oneway' und nicht auf voller Länge?