Danke, dass du dich zurückgemeldet hast.
Es mag sein, dass du NUR dir bekannte Parkplätze anpassen wolltest und es mag auch sein, dass du zumindest diese teilweise selbst kennst. Allerdings hat dein Editor mit deiner Hilfe in genau den selben Changesets jede Menge anderer Objekte verändert, die du NIE persönlich geprüft haben kannst.
Wenn dein ID-Editor dir andere Korrekturen vorschlägt, bedeutet es noch lange nicht, dass du sie auch durchführen musst und schon gar nicht im Umkreis von mehr als ein paar Metern. Du bist dafür verantwortlich, nicht Editor oder App.
Alle deine Changesets mit dem Namen "Fehlerkorrekturen gemäß Vorschlägen, Verfeinerungen" sind großflächige automatische Änderungen. Du kannst sie jetzt selbst revertieren oder sie werden revertiert.
Du solltest jetzt das auch sein lassen, weitere dieser Edits durchzuführen, um nicht noch mehr unnötige Hin- und Rückänderungen zu veranlassen.
Mit der Bitte um kurzfristige Meldung.
Danke & LG,
sundew

Hi MRGBoss,

kannst du bitte erläutern, was du mit deinen großflächigen Changesets in und rund um Hamburg machst! Z.B. in den changeset/120172244, 120172881, 120205490 und etlichen anderen.

Das sieht mir sehr nach unerlaubten mechanischen Edits aus, wenn du nicht ALLE Objekte selbst vor Ort geprüft hast. Kannst du Belege liefern, dass du alles selbst geprüft hast, z.B. GPS-Tracks oder Fotos von allen Objekten?
Einfach einem Editor oder einer App zu sagen, biege alle gerade, was nicht dem Schema der App entspricht, verstößt klar gegen die Regeln bei OpenStreetMap.
Insbesondere deshalb, weil es nicht in jedem Fall einen Konsens zum Mappingschema gibt, z.B. bei den Wiki-Tags, kannst du nicht einfach großflächig alles glatt ziehen.

Wenn ich von dir nicht kurzfristig eine zufrieden stellende Erklärung erfahre, werde ich die Changesets teilweise oder komplett revertieren.

LG,
sundew

Hallo Puma515,

danke für die umfangreichen Erläuterungen.
Sicher hast du Recht, dass man nicht jeden Editor gleich pauschal verteufeln sollte, aber wie wir gesehen haben, arbeiten sie eben nicht in jeder Hinsicht korrekt. Und was schlimmer ist: sie erlauben oder verführen ggf. sogar den/die Anwender(in), Dinge zu editieren, ohne Kenntnis der dahin liegenden Datenstrukturen. Das ist natürlich für die Gewinnung neuer Mitstreiter förderlich, bringt aber auch das eine oder andere Problem mit sich. ...
Schauen wir mal, wie es sich entwickelt.

Weiterhin frohes Schaffen & LG,
sundew

Hallo Puma515,

danke für deine ausführlichen Antworten und Aktivitäten. Vielleicht wäre eine Rückfrage von mir vor dem Revert möglich und sinnvoll gewesen. Allerdings war das Gesamtbild ähnlich dem, wie ich es jetzt schon ein paar mal an anderen Stellen, die ich regelmäßig kontrolliere, erlebt habe: Irgendein(e) Mapper(in) lässt im Umkreis von einem oder mehreren Kilometern durch eine App viele POIs etc. automatisch umpatchen, ohne alles selbst vor Ort kontrolliert zu haben. Etliche Male habe ich schon erlebt, wenn ich dann direkt danach eine meiner Touren gemacht habe, dass diese POIs inzwischen vor Ort abgebaut wurden oder sich wichtige Werte geändert haben, z.B. Leerungszeiten. Beklagte ich mich daraufhin per Message, kam nie eine Antwort.
Es ging mir also in erster Linie darum, dass solche Massenedits nicht in Ordnung sind. Klar gibt es dagegen Dinge, die man auch ohne Vor-Ort-Prüfung anpassen kann, z.B. Buslinien mittels Fahrplan. (Bei neu erfassten Busstops prüfe ich gern auch mal beides, weil vor Ort häufig veraltete Angaben weiter existieren.)

Sorry und bitte nicht falsch verstehen: Ich weiss, dass du bisher überwiegend "echt" mappst, allerdings hatten wir letztes Jahr schon das Thema mit den von ID inflationär vergebenen bus=yes an public_transport=platform diskutiert, aber das ist Schnee von gestern ..

Nun mal zum Inhaltlichen:
Dass ich diese Tags als überflüssig sehe, ist eine andere/meine Sache. Das wäre im Kleinen hier und da auch kein Grund, etwas zu reverten, sondern ggf. etwas für die nächste Überprüfungstour ein Jahr später.

Die von dir erwähnte Wiki-Seite listet übrigens auch nur als eventuelle Option wikidata-Tags, aber keine wikipedia-Tags (jene sollten in den Wikidata selbst weiter verlinkt sein). Mein Vorschlag zur Lösung des Dilemmas wäre prinzipiell, dass man ein Objekttyp-spezifisches brand-Tag verwendet, also brand="Deutsche Post Briefkasten" plus ein brand-Wikidata, so wie bei brand="DHL Packstation", aber leider ist bereits brand="Deutsche Post" vordefiniert. Wie unterscheidet man damit Briefkästen und Briefmarkenautomaten mit dem selben brand? Egal ..

Dass auf einer OSM-Wiki-Seite keine Pro & Contra zu finden sind, ist klar. Da wird ein aktueller (aber scheinbar nicht verbindlicher) Stand zum Mappingschema gezeigt, oft nicht einheitlich zwischen englischer und deutscher Wiki, den der letzte Änderer so eingetragen hat .. solange bis halt der nächste daherkommt und es wieder modifiziert. Oft erlebt ..
Im Forum sah ich da auch schon einige unvollendete Diskussionen, finde das aber jetzt auch nicht wieder.

Nett fand ich deine Aussage, dass ja nur Deutsche-Post-Briefkästen inkludiert seien. Hier im Norden sind das eher 99 Prozent. Die Handvoll Nordbrief-, Citypost- und Lünepost-Kästen kann man eher vernachlässigen. In anderen Gebieten mag das etwas anders sein, z.B. auf Reisen in Bayern und Sachsen sah ich auch in den kleinsten Dörfern alternative Anbieter, aber hier im Norden suchen die sich wohl nur größere Orte heraus, wo es sich lohnt. Und ich habe auch schon mehrfach erlebt, dass sie schnell wieder verschwanden.
Bei Nakaner-Revert ging es im Übrigen auch um alle Briefkästen.

Zur beschriebenen Taginfo: Hast du mal versucht herauszufinden, mit welchen Editoren die Tags erstellt worden? Ich kann mir an Hand meiner Beobachtungen der letzten Monate sehr gut vorstellen, dass die meisten Änderungen durch solche Flächenänderungen von ID und Osmose stammen. Die haben halt eine gewisse Verbreitung bzw. quasi Macht, ihre eigenen Schemata durchzusetzen, insbesondere ID ist bekannt dafür, sich nicht an die bestehenden Regeln zu halten. Und die OSM-DataWorkingGroup zuckt mit den Schultern und macht praktisch nichts dagegen. Statt ID & co den Zugang zu versperren.
Super tolles Projekt OpenStreetMap ..

Aber danke nochmal für deine Antwort!
LG und trotz schlechten Wetters ein frohes Mappen,
sundew

Hallo Puma515!

Es tut mir Leid, dir da in die Quere zu kommen. Ich habe deinen Changeset revertiert, weil das undiskutierte großflächige Umpatchen von Objekten in OpenStreetMap unzulässig ist, sofern man sie nicht alle (!) selbst geprüft hat, alternativ gemein nutzbare Daten eingetragen werden (z.B. an Hand von Fahrplänen oder Luftbildern) oder offenkundige Fehler vorliegen. Ein Vollspammen mit redundanten Tags, die noch dazu - wie in diesem Fall - keinen Konsens in der Mapperschaft erfahren oder vor Ort nicht ersichtlich sind, fällt NICHT unter Fehlerkorrektur. -Viel- ist nicht unbedingt -mehr- ..
Du solltest doch an dem bundesweiten Revert ähnlicher Änderungen durch die DataWorkingGroup (Nakaner-repair), z.B. changeset/115022436, gesehen haben, dass derartige Aktionen nicht gewollt sind.

Einfach nur einer App zu sagen, korrigiere alles um Umkreis x, geht definitiv nicht und dies hat auch nichts mit dem OSM-Grundgedanken zu tun, on-the-ground Objekte zu prüfen/zu erfassen.

Und: Operator-Wiki-Tags sind kein Mehrwert, wofür auch? Nur damit ein Prüfprogramm keine falsche Fehlermeldung mehr ausgibt?

LG und weiter fröhliches echtes Mappen,
sundew

Hallo G4rden3r,

ich habe Teile deines Changesets 118320770 revertiert, weil das undiskutierte großflächige Umpatchen von Objekten in OpenStreetMap unzulässig ist, sofern man sie nicht alle selbst geprüft hat, gemein nutzbare Daten eingetragen werden (z.B. an Hand von Fahrplänen oder Luftbildern) oder offenkundige Fehler vorliegen. Ein Vollspammen mit redundaten Tags, die noch dazu keinen Konsens in der Mapperschaft erfahren oder nicht vor Ort ersichtlich sind, fällt NICHT unter Fehlerkorrektur. -Viel- ist nicht unbedingt -mehr- ..

Einfach nur einer App zu sagen, korrigiere alles um Umkreis x, ist definitiv ungewünscht, und dies hat auch nichts mit dem OSM-Grundgedanken zu tun, on-the-ground Objekte zu prüfen/zu erfassen.

LG und weiter fröhliches echtes Mappen,
sundew

Hallo Garstedter,

kannst du bitte erläutern, was dein changeset/115229260 soll? Das sieht mir sehr nach mechanischen Edits aus, d.h. ich habe den Verdacht, du hast dir die Objekte NICHT vor Ort angesehen. Du hast scheinbar mit einem Tool oder einer App einfach alle Objekte in einem großen Bereich umgepatcht / mit sinnlosen Tags vollgespammt. Und sowas ist ein undiskutierter, nicht erlaubter mechanischer Edit.
Bitte belege, dass DU die Objekte vor Ort geprüft hast (z.B. GPS-Tracks, Objektfotos vom Änderungszeitpunkt, etc.). Außerdem wäre es dann hilfreich, wenn du dann das check_date entsprechend beachten und pflegen würdest.

Danke,
LG,
sundew

Hallo Martin!
Ganz einfach: ich halte diese von dir so genannten Zusatztags beim Operator für redundant und überflüssig. Es braucht keinen Direktlink vom Operator ins Wiki. Das sollte vielmehr über einen auf den Objekttyp bezogenes brand (z.B. brand=Deutsche Post-Briefkasten oder brand=Nordbrief-Briefkasten) plus ggf. brand:wikidata=* erfolgen. Ähnlich wie bei Parcel-Locker z.B. brand=Amazon-Locker. Mehr nicht! In den Wikidata selbst steht dann die Weiterverlinkung auf die Operator-Wikiseite...
Aber unabhängig vom Taggingschema halte ich es für bedenklich, dass derzeit etliche Leute mit ihren Apps unterwegs sind und einfach Objekte - ohne sie wirklich zu kontrollieren - mit Tags vollspammen. Es wird kein check_date gesetzt/aktualisiert, es werden an vielen Stellen keinerlei Korrekturen an Leerungszeiten, Referenzadressen etc. vorgenommen. So geht das einfach nicht.
Bei Objekten, die ich seit vielen Jahren regelmäßig vor Ort prüfe, gestatte ich mir somit, bei der jeweils nächsten Kontrolle unnötigen Wildwuchs zu beseitigen. Ähnliches hast du ja in der Vergangenheit auch mit Bushaltestellen getan, richtig?
LG M.

.. ein Node in Prepow ungewollt mit in den Changeset gerutscht ..

okay, ist jetzt besser so, danke ..

Hallo Puma,
danke, dass du dich zurückgemeldet hast. Genauer gesagt gehört ID an den Pranger. Die waren von Anfang an beratungsresistent und halten sich nicht vollständig an die geltenden Mappingregeln - es gibt viele andere Beispiele. Noch schlimmer: sie nutzen ihre Verbreitung aus, um die Nutzer mittels irgendwelcher "Überprüfungen" zu halbautomatischen falschen Änderungen zu verleiten. Und wenn am Ende ein Großteil im ID-Stil gemappt ist, können sie einfach das Wiki anpassen.
Das perfide ist, dass die Programmentwicklung und Wartung auch noch aus irgendeinem Topf bei OSM bezahlt wird, weil man ja einen schicken Klicki-bunti-Editor haben wollte, egal was damit kaputt gemacht wird ...
Weiterhin ein frohes Mappen,
LG sundew

Hi,
das ist sicher kein echtes öffentliches Telefon. Also verwende bitte nicht amenity=telephone .. !
Danke!
VG

Hi,
warum reaktivierst du den als entfernt gekennzeichneten Briefmarkenautomaten (node/1957237679)? Hast du das vor Ort geprüft?
VG

Hallo nochmal, ich habe die Werte an dem Node jetzt wieder teilweise zurückgesetzt.
LG

Hi,
warum hast du in Sottrum bei der Packstation das check_date entfernt. Du weißt, dass das der Qualitätssicherung dient. Wieso entfernst du einfach website=* ? Außerdem solltest du doch wissen, dass beschreibende Namen nichts im name=* zu suchen haben, da gehören nur wirkliche Namen hinein (z.B. bei Bushaltestellen oder Shops). Ebenso gilt dies für alt_name, short_name -> also fort damit.
LG

Tour 20211006 .. jetzt ist's richtig

Tour 20211106 ..

Hallo Johnny,

ja, prinziell schon. Aber wir wissen ja, wie schnell undiskutiert neue Tagwerte ins Wiki geschrieben werden, auch wenn sie nirgendwo in den Daten verwendet, nur weil irgendwer einen kleinen Unterschied etwas deutlicher herausarbeiten wollte. (Da sind im OSM-Telefon-Wiki auch noch einige andere Subtags gelistet, die mir noch nirgendwo unterkamen, und ich bin da eher auf der Hut vor Eintagsfliegen). Ich benutze payment:telephone_cards seit Jahren bei allen verbliebenen Basistelefonen hier im Norden, weil das ueberall anders scheinbar auch so gemacht wird.
Genausowenig kann ich prüfen, ob payment:credit_cards=yes überhaupt noch funktioniert, weil ich sowas noch nie probierte.
Spitzfindigerweise müsste dann payment:calling_cards an alle Telefonarten angeheftet werden, weil die auf den Basistelefonen mit der 'T'-Taste gewählte 08003300222 auch von jedem öffentlichen Telefon wählbar ist. Hab ich auch schon gemacht, als der Telefonkartenleser defekt war.
Sorry, es tut mir Leid, ich sehe da momentan keinen Handlungsbedarf.

GLG,
sundew

Hallo Johnny,
auf Telefonkarten kann man eine 16-stellige Pin freirubbeln und damit mit Basistelefonen telefonieren. Das wird dann vom Kartenbetrag abgebucht, den man online damit auch wieder aufladen kann. Beides praktiziere ich hin&wieder. (Vorteil: wenn man seine Pin kennt, braucht man keine physische Telefonkarte mehr.)
Ob das dann noch payment:telephone_cards=yes darstellt oder ein anderes Tag, ist Ansichtssache.
LG
sundew

Hallo Roger,
danke für die Information.
LG
sundew