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 (n1957237679)? 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

Hallo Roger,

danke für die netten Worte. Leider kann ich dir da nicht zustimmen, was das von dir erwähnte Tag type betrifft. Es mag ja so sein, dass jetzt (!) auf der Wikiseite ein anderes Tag steht (wenn auch etwas unglücklich formuliert). Allerdings war das nicht immer so und type=Schrank ist die seit ewig benutzte Variante, wenn auch unglücklicherweise nicht-englisch, weil ursprünglich nur hierzulande verwendet.
Sie wird nachwievor überwiegend benutzt. Irgendwann hat eine der überflüssigen Mapping-Apps angefangen, eigene englische Tags zu erfinden, und jemand hat das undiskutiert (!) auf der Wikiseite geändert - ebenso ohne an die Folgen zu denken.
Und nun haben wir jetzt den Salat, dass nachwievor tausende Packstationen deutschlandweit mit type=Schrank besetzt sind und nur vielleicht 15% (Stand Juli) mit der englischsprachigen Variante. Zwei Werte für ein und dasselbe, das sollte definitiv nicht so sein.
Ein Massenedit um das glattzuziehen, ist normalerweise unzulässig, obwohl das vor etwa zwei Jahren auch mit den https vs. http-Adressen bei website=* gemacht wurde.
Zudem müsste jede Packstation vorher mindestens auf Fortexistenz und Stellort vor Ort geprüft werden, denn andere Quellen sind unzulässig. Eine flächendeckende Mapperaktion, quasi als "Wochenaufgabe", würde auch nur in Großstädten halbwegs funktionieren und bestenfalls das Verhältnis der beiden Varianten verschieben, nicht jedoch das Problem lösen.
Falls es eine solche klassische Aktion gibt, die bundesweit wirklich ALLE Stationen korrigiert, würde ich mich hier natürlich daran beteiligen, aber sowas ist nicht in Sicht. Akteure bitte voran!
In einer Diskussion zum Thema beim monatlichen Hamburger Mappertreffen (derzeit virtuell) haben wir dort beschlossen, diese Umtaggung derzeit(!) NICHT zu unterstützen und die bisherigen meistgenutzten Varianten (type=Schrank bzw. type=Paketbox) weiter zu nutzen! Und da ich auf meinen Biketouren Hamburg plus 100km Umkreis abfahre, halte ich mich vorerst daran.

LG,
sundew

Hallo DaN0mic!

Packstationen von Amazon werden nicht wie bei DHL über eine Nummer identifiziert, sondern über einen mehrheitlich exotischen Namen. Ob dieser weltweit eineindeutig ist, wäre interessant zu wissen. Bei DHL-Packstationen sind die dreistelligen Nummern dagegen nur im jeweiligen Postgroßbereich eindeutig, d.h. hier muss eine Postleitzahl vorhanden sein. Das ref-Tag wird auch bei anderen Objekten alphanumerisch belegt, z.B. zur Referenzierung einzelner Bahn/Bussteige innerhalb eines Verkehrsknotens. "kunigunde" stand an der Packstation angeschrieben.

Was das von dir erwähnte Tag type betrifft, so ist type=Schrank die seit ewig benutzte Variante, wenn auch unglücklicherweise nicht-englisch, die nachwievor überwiegend benutzt wird. Irgendwann hat eine der überflüssigen Apps angefangen, ein eigenes englisches Tag zu erfinden, und jemand hat das undiskutiert auf der Wikiseite ergänzt - ebenso ohne an die Folgen zu denken. Und nun haben wir jetzt den Salat, dass tausende Packstationen deutschlandweit mit type=Schrank besetzt sind und nur vielleicht 15% mit der englischen Variante. Zwei Werte für ein und dasselbe, das sollte nicht so sein. Ein Massenedit um das glattzuziehen ist unzulässig, zumal jede Packstation vorher mindestens auf Fortexistenz und Stellort geprüft werden müsste. Eine flächendeckende Mapperaktion, quasi als "Wochenaufgabe" würde auch nur in Großstädten halbwegs funktionieren und bestenfalls das Verhältnis der beiden Varianten verschieben, nicht jedoch das Problem lösen. In einer Diskussion beim monatlichen Hamburger Mappertreffen (derzeit virtuell) haben wir dort letztes Jahr beschlossen, diese Umtaggung derzeit(!) nicht zu unterstützen und die bisherige Variante weiter zu nutzen!

Wenn wir schonmal dabei sind: ich würde dich bitten, beim Prüfen von Objekten, die ggf. wieder verschwinden können (Packstation, Briefkästen, Telefone), auch das check_date=* zu aktualisieren, weil das die einzig saubere Methode ist, beim Mappen zu filtern, welche Objekte andere Mapper zuletzt noch nicht begutachtet haben. Danke!

LG

.. eigentlich waren zwei Changesets gedacht, die aber nun leider zusammengemengt wurden ..

Hi, warum hast du den Briefkasten Otto-Hahn-Str. 3 (3705762367) kommentarlos gelöscht? Ich habe ihn jetzt wiederhergestellt, weil er ja noch da ist. Bitte pass ein wenig mehr auf, sowas darf nicht passieren!
LG

Danke für die Korrektur & LG ..

Hallo, warum zeichnest du an der Stelle einen weiteren Briefkasten ein? Der befand sich doch schon um die Ecke am Neddernbrook Haus 8 - vor ein paar Monaten geprüft. Ist der unter Beibehaltung der Referenzadresse umgezogen? Falls ja, dann bitte den Vorhandenen verschieben und nicht noch einen zweiten dazu eintragen. Danke!