!bm's Comments
| Changeset | When | Comment |
|---|---|---|
| 98602659 | almost 5 years ago | @PT-53:
Ich wiederum lese primär die englischsprachige Version, aus oben (insb "offtopic") genannten Gründen. Was gilt nun, deiner Auffassung nach? |
| 98602659 | almost 5 years ago | Nachtrag/Offtopic: Mir ist schon in anderen Fällen wiederholt aufgefalllen, dass das die DE-Versionenen des Wiki leider wirklich verkürzt/nachlässig übersetzt wurden. (Ein, zwei solche konnte ich auch schon möglichst originalgetreu neu übersetzen.) |
| 98602659 | almost 5 years ago | @PT-53
Es wird eben nicht explizit verboten oder davon abgeraten! Die entsprechenden Icons stellen Empfehlungen dar "sollte / sollte nicht" (siehe Mausüber-Effekt.) Also nein, wie schon geschrieben: Hier hinkt eher das Wiki der Entwicklung hinterher oder es ist einfach schlecht definiert. Meine Argumente: siehe oben! Bitte gerne inhaltlich dagegen argumentieren. |
| 98602659 | almost 5 years ago | Nein, tut es nicht. may be used on areas Nicht einmal die DE-Version untersagt es explizit und ich sehe auch keinen vernünftigen Grund, wieso ein flächiges Feature nur als Punkt gemappt werden dürfte. (Wenn es um die Taxirufsäule oder eine andere Kennzeichnung ginge, wäre das ein anderer Fall.) Wie oben schon ausgeführt: OSM entwickelt sich weiter. Da bedarf es wohl eher einer Anpassung/Akualisierung des Wikis als einer Verschlechterung der Datenqualität. |
| 98602659 | almost 5 years ago | Richtig, um sicher zu gehen, muss man ohnehin alle Typen inkludieren. Dann fällt auch auf, dass amenity=taxi neben nodes und der multipolygon-Relation auch bereits als drei einfache closed ways vorhanden sind.
Letztlich geht – so wie hier in Neukölln von Supaplex030 u.a. hinsichtlich Parkplätzen mit großem Eifer betrieben – der Trend zu einer höheren Auflösung / Genauigkeit in der Erfassung. Insofern ja, ist die konsequente Weiterentwicklung, die Taxistände als closed ways bzw multipolygone zu mappen. (Daraus lässt sich dann anhand der Größe evt auch eine Kapazität ableiten.) |
| 98602659 | almost 5 years ago | Das Argument bezüglich overpass und Einheitlichkeit kann ich nachvollziehen, aber es hier nunmal schon genauer gemappt. Löschen sollte man die Multipolygon-Relation so ohne Weiteres nicht, da ja noch andere Eigenschaften (der "Parkbucht") da getaggt sind. Ich habe mal den Ersteller der Relation, Supaplex030, informiert, sodass er sich evt dazu äußern kann. |
| 98597540 | almost 5 years ago | ftfy: changeset/98603080 |
| 98602659 | almost 5 years ago | Hallo taxi-adem, amenity=taxi ist hier bereits als Multipolyon relation/11973432 gemappt, somit ist eine weitere Hinzufügung als node überflüssig/unerwünscht. Siehe osm.wiki/DE:Ein_Objekt,_ein_OSM-Element Woher stammt der Name? (Woran) Ist dieser vor Ort ablesbar? (Verifizierbarkeit?) Bei den früheren Changesets 98600551,98599137 ging anscheinend auch beim Revert es schief, ich habe daher beide nochmal (hoffentlich) sauber revertiert: changeset/98602682 --besteGrüße!bm |
| 98427085 | almost 5 years ago | Hallo Rainero, eine mE vollkommen nutzlose Änderung, wie sie unterbleiben sollte. (Die PLZ ist hier nicht das Hauptproblem.) Bitte nicht einfach blind/automatisiert Dinge ändern, nur weil irgendein QA-Tool einen Fehler anzeigt! --besteGrüße!bm |
| 97905648 | almost 5 years ago | Hallo JoelLinn, du hast dich hier wohl zu sehr auf iD-Warnungen verlassen und etliche tram_level_crossing hinzugefügt, die mE keine (bzw nur für Linksabbieger) solchen sind – ich habe das Tagging daher in 7 Fällen entfernt. (Ausgenommen node/276566245, den du lediglich verändert hast – da kreuzt die Fahrbahn tatsächlich.)
Was ist mit node/1383533711 passiert, wurde dieses crossing=traffic_signals abgebaut? Aufhttps://www.mapillary.com/map/im/0vxp2UTmyewrRdFgdoIUsM ist es noch (wenn auch: Baustellenprovisorium) zu sehen. --besteGrüße!bm |
| 98530716 | almost 5 years ago | sourec+= Geoportal Berlin / ALKIS Berlin - Gebäude; Geoportal Berlin / Adressen Berlin; Geoportal Berlin / Berlin Zoom
|
| 97907654 | almost 5 years ago | Hallo whishainapou, du hast es in changeset/98159054 ja entsprechend geändert – allerdings dort auch keine source=* angegeben. Warst du vor Ort Da der User geozeisig es in changeset/98522020 nun wieder auf permanent maxspeed=30 zurückgeändert hat, frage ich nach: Was stimmt denn nun? Auf mapillary konnte ich keine ganz aktuellen Bilder, aber immerhin von 2019 in westliche Richtung finden. Demnach ist/war es als eine 30-er-Zone ausgeschildert. Wurde das vor kurzem geändert? Warst du vor Ort und hast Anfang/Ende geprüft? --besteGrüße!bm |
| 98444183 | almost 5 years ago | Hallo nikolaus95, zunächst willkommen zu OSM! Beachte bitte OSM-Grundlagen – ganz allgemein[1] und im konkreten Fall [2]. [1] osm.wiki/Good_practice
Fehler entsprechend korrigiert. Happy mapping! --besteGrüße!bm |
| 98334119 | almost 5 years ago | Hallo StefanHRT,
|
| 97986603 | almost 5 years ago | charge=* behoben und fixme=* betreffend KK gesetzt: https://osmcha.org/changesets/98317556
|
| 97986500 | almost 5 years ago | Angemerktes behoben und weiter verbessert in: https://osmcha.org/changesets/98316635
|
| 97969704 | almost 5 years ago | fixed: changeset/98313894
|
| 97378664 | almost 5 years ago | Da auf Cs-Kommentare bisher nicht reagiert und die Praxis unverändert (zB changeset/98306545 ) fortgesetzt wurde, habe ich die obige Aufforderung mal per PN wiederholt. |
| 98306545 | almost 5 years ago | s. Anm. zu / analog changeset/97378664 |
| 98117318 | almost 5 years ago | Vielen Dank für die zeitnahe Rückmeldung! Das mit der Übereinstimmung von brand=* und brand:wiki*... ist natürlich so eine Sache. (Ich bin auch kein besonderer Freund dieser Tags, aber es gibt sie nunmal und für gewisse Dinge wie Handelsketten haben sie durchaus ihre Berechtigung.) Da in diesem Artikel ausgerechnet jene Filiale beschrieben wird, wissen wir also gesichert, dass dort der neue Markenauftritt gilt. (Beachte hierzu die On-the-ground-rule. osm.wiki/Good_practice#Verifiability ) Also nein, ich würde jetzt nicht alle Filialen (automatisiert) umtaggen. ( osm.wiki/Automated_Edits_code_of_conduct ) Entsprechend korrigiert in: changeset/98306175
|