Hallo Roger,

danke für deine wohlgemeinte Anmerkung. Leider kann ich dir da nicht komplett zustimmen.
Jeder Mapper/jede Mapperin ist für seine/ihre Edits ausschließlich selbst verantwortlich und darf auch nur vor Ort erfasste Dinge oder Informationen aus zulässigen Quellen nutzen (z.B. für OSM freigegebene Luftbilder/Videoaufzeichnungen, Fahrplanaushänge, sowie wenige Webseiten, die das explizit genehmigen). Ein sich auf einen anderen Mapper bezogenes "Nacharbeiten" sollte nur im wirklichen Fehlerfall geschehen. Ein Fehler liegt hier bei diesen optionalen Tags aber NICHT vor, auch wenn Nutzer gewisser Apps dies gern mit belanglosen Kommentaren wie "resolve id errors" suggerieren, dabei aber nie andere Eigenschaften inhaltlich überprüft haben, wie schon hunderte Male selbst erlebt, praktisch bei jeder Mappingtour in Norddeutschland ..

Außerdem gilt die On-the-ground-Regel, wonach nur vor Ort einsehbare Dinge erfasst werden sollten.
Wenn ich also vor Ort einen POI prüfe, steht nirgendwo eine wikidata-Nummer angeschrieben, ich muss sie also entfernen, weil nicht prüfbar, genauso wie ich am Briefkasten nicht oder nicht mehr angeschriebene zusätzliche Leerungszeiten (z.B. Frühleerungen) entferne, die evtl. veraltet sind oder aus unzulässigen Quellen (z.B. DHL-Webseite) stammen.
Btw, ein Entfernen unnötig / ggf. per Massenedit meist durch eine App gesetztes Tag ist keine "Arbeit anderer Nutzer", wie Discustu36 schreibt, weil es für mich keinerlei Schöpfungshöhe besitzt ..

Dein inhaltliches Argument, eine wikidata-Nummer sei eindeutiger, mag theoretisch stimmen. Sie ist aber genauso fehlerbehaftet (Zahlendreher) und vor allem nicht "sprechend", also direkt vergleichbar. Für einen sprechenden Operatorstring kann ich dagegen leicht eine RegEx-Suche erzeugen, die die meisten aller gängigen Falschschreibungen trotzdem findet. Und vor allem: soll ich bei Mappen alle dieser wiki-Nummern im Kopf haben, wenn ich klassisch OSM-Daten bearbeite? Ich sage nein ..

Naja, bei diesem Thema werden wir im Vergleich zu früheren Diskussionen wohl nicht einig. Aber ich wünsche dir in jedem Fall schöne Feiertage und uns allen, dass es wieder etwas trockener wird, um dieses Jahr draußen noch viel zu "schaffen" :-)
LG und frohes Mappen,
sundew

Hallo Fandarel!
"Bundesstraße 22, 24878 Jagel" ist nunmal die Referenzadresse des Briefkastens. In vielen Fällen, die ich schon irgendwo vor Ort geprüft habe, sind da merkwürdige Eintragungen dran. Oft stammen die auch noch von früheren Straßennamen, z.B. "Dorfstraße 30, 12345 Altland". Heute heißt die Straße nach entsprechenden Namensreformen dann real z.B. "Altländer Dorfstraße" oder total anders. Die Referenzadresse bleibt aber meist die Alte. Ähnlich bei den Hausnummern: Wird der Briefkasten hunderte Meter an der Straße versetzt, bleibt die alte Ref.Adresse oft erhalten. Das ist aber letztlich auch egal. Viel schlimmer sind die vielen zwischen Dörfern vertauschten Briefkastenschilder in manchen Regionen.
LG

Korrektur: Tour 20231105 .. Satrup und Bahnhof Flensburg (Vor-Ort-Prüfung Postkästen, POIs, etc. ... )

Sorry, viel zu großes Gebiet, weil ein Changeset leider offen blieb und zwei Changesets vermischt ..

Hallo Jannik,
danke für die Rückmeldung. Zu deinen Fragen: Ja, ich fahre jährlich bzw. weiter draußen zweijährlich Dörfer und Städte rund um Hamburg plus 100km auf Biketouren ab und prüfe/ergänze verschiedene POIs.
Nun zu deiner eigentlichen Frage zu wiki***-Tags. Die sind optional und meiner Meinung nach komplett unnötig für massenweise vorkommende POIs. Welchen Mehrwert haben sie da? Briefkästen z.B. sind für Massenabfragen via Overpass eindeutig mittels amenity, operator und/oder brand findbar. wikidata-Tags sind dagegen durchaus sinnvoll bei Einzel-POIs, wie z.B. Denkmäler, Sehenswürdigkeiten, speziellen Einzelgeschäften, die mit einer Webseite zu verbinden sind. Wir müssen nicht alles unnötig mit Datenmüll belegen, nur weil wir es können.
Zum anderen sieht die Realität zumindest hier im Norden so aus, dass immer mehr Coachmapper einfach irgendwo automatisiert alles mit solchen wiki-Tags vollspammen und dabei mit unaussagekräftigen Kommentaren suggerieren, sie hätten die Objekte vor Ort geprüft, die Fortexistenz des POIs oder Korrektheit anderer Tags wurde aber dabei nie geprüft, wie inzwischen in hunderten Fällen gesehen. Da ich schwer davon ausgehe, dass du tatsächlich vor Ort unterwegs bist, schlage ich vor, immer die check_dates mit zu aktualisieren.
Dann mal frohes Mappen und LG,
sundew

Hi GrindersKeeper,

ich habe nicht von Vor-Ort-Kenntnis geschrieben, die ist bei den meisten sowieso nur vorgeschoben, sondern in Frage gestellt, dass du die Objekte großflächig vor Ort kontrolliert hast. Und solange du keine Belege (gps-Tracks, Fotos, etc.) lieferst, sehe ich keinen Unterschied zu Couchmappern, die einfach ändern, ohne dort gewesen zu sein.

Eine Entfernung der check_date-Einträge ist falsch, selbst wenn du sie nicht für nötig hältst. Wie sollen sonst andere Mapper wissen, wann ein Objekt das letzte Mal wirklich geprüft wurde? Das Änderungsdatum ist dafür ungeeignet. Genau dafür wurde check_date vor etwa 7-8 Jahren vereinheitlicht. Außerdem: Hättest du die check_date Einträge ausgewertet, wäre dir auch aufgefallen, dass ich mir alle diese Objekte bereits wenige Monate zuvor angesehen habe und hättest dir die vorgebliche Mühe sparen können.
Also: wenn du es nicht selbst tust, werde ich die Werte zurücksetzen.

LG
sundew

Hi,
warum hast du die Packstationen im Großraum Celle blind und anscheinend ohne Vor-Ort-Kontrolle umgepatcht?
Derartiges ist in OpenStreetmap generell unerwünscht.
Zudem hast du die vorherigen check_date-Einträge entfernt, sodass eine Aktualitätsprüfung nun nicht mehr möglich ist.
Wenn du die check_date-Werte nicht sofort restaurierst und mir belegst (Fotos, gps-Tracks), dass du alle (!) Objekte tatsächlich kontrolliert hast, werde ich deine Changesets zurücksetzen.
LG,
sundew

Hallo Wolfgang,

das was du machst, geht überhaupt nicht: Das großflächige automatische Ändern von Tags an Objekten z.B. mittels einer App, ohne sie einzeln vor Ort geprüft zu haben, ist in OpenStreetMap unerwünscht. Auch die Übernahme von Vorschlägen dieser Apps zur automatischen Änderung, ist nicht zulässig.
Inhaltlich gibt es unter der Mapperschaft keinen Konsenz zur Verwendung bestimmter optionaler Tags. Einige von dir gemachte Änderung sind auch schlichtweg falsch. Außerdem: wie kannst du sicher sein, dass die betreffenden POIs noch existieren oder alle bisherigen Tags noch richtig sind???

Also lass dies bitte in Zukunft. Das kostet uns alle unnötige Arbeit.

Ich werde alle betreffenden verdächtigen Changesets (z.B. "Angaben ergänzt") hier im Großraum Hamburg reverten.

LG und weiter frohes echtes Vor-Ort-Mappen,
sundew

.. eher Bauchentscheidung, dort ist die Landschaftsgestaltung des Viertels noch nicht fertig..
Aber du darfst es gern anpassen, wenn es dir das wichtig ist. Mir selbst liegen eher physische Eigenschaften wie Bauart, Breite oder Surface hoeher in der Prioritaet ...

LG,
sundew

Das kann ich leider nicht exakt sagen. Ich war auf einer langen Ganztagestour zufaellig auf dem angrenzenden "Hollenkamp" unterwegs, habe mir nur eine Notiz gemacht und das & anderes nun mittels Luftbild (bing) etwas angepasst.
Das ist alles noch dreiviertel fertiges Baugebiet und war noch nicht komplett erfasst.
LG

Hallo dkf!

.. emotional? Naja, ein bisschen schon, aber bitte nicht persoenlich nehmen. Aber ich bin ein etwas angenervt, weil es inzwischen an vielen Orten aehnlich ist, wo auch immer ich jaehrlich auf jeder meiner Mappingbiketouren herumkomme. Da werden hier und dort automatisch irgendwelche POIs umgepatcht, ohne dass der/die Verursacher/in da nachweislich jemals vor Ort ein Auge draufgeworfen hat. Ein Grundprinzip von OSM wird da verletzt. Da wird an in der Realitaet laengst verschwundenen Objekten (z.B. Telefone, abmontierte Briefkaesten) fleissig geaendert und damit der Eindruck impliziert, die Objekte sind gerade geprueft worden. Eine Diskussion darueber ist oft nutzlos, weil man sich meist gar nicht des Problems bewusst ist.

Jede(r) kann selbstverstaendlich an Hand von zugelassenen Luftbildern Geometrien von Haeusern, Wegen, Landschaften per Couchmapping eintragen und korrigieren, das ist in Ordnung. Du kannst Buslinien verbessern, usw..
Ich erwarte aber, dass POIs, die nicht in brandaktuellen Luftbildern erkennbar sind, grundsaetzlich nur vor Ort geprueft werden oder alternativ auschliesslich nur mit erlaubten Quellen. Und die Webseite eines Postunternehmens ist definitiv KEINE erlaubte Quelle. Erlaubte Alternativen waeren z.B. aufgezeichnete Kamerabilder wie von OpenStreetView etc., womit man natuerlich bestenfalls die Fortexistenz/Position eines POIs belegen kann ..

Deine Changesets tragen leider nur den recht mageren Changesetkommentar "#maproulette". Daraus ist nichts zu erlesen, was du wie getan hast. Ich gehe einmal davon aus, dass dieses Spiel die User ebenso motiviert, sich die POIs vor Ort anzusehen und sie nicht unerlaubt blind umzuaendern. Sonst wuerden die Macher das einfacher gleich selbst vollziehen koennen.

Dann mal weiter ein frohes echtes Mappen!
LG, sundew

Hallo dfk,

zu deiner Anfrage nach meiner Vor-Ort-Ueberpruefung:

Zum einen sehen mir deine Aenderungen nach einem in Haeppchen geschnittenen Massenedit/mechanical edit aus - sprich: veraendere alle Objekte in Umkreis, ohne sie selbst ueberprueft zu haben. Dafuer sprechen neben fehlenden weiteren Anpassungen die veraenderten Leerungszeiten weiter oestlich in Unterluess, die du natuerlich NICHT korrigiert hast. Dass Massenedits unerwuenscht sind, wurde in der Vergangenheit hinreichend diskutiert und dargelegt. Wenn du auf diese Weise etwas modifizierst, wie kannst du sicher sein, dass das Objekt noch an der Position vorhanden ist bzw. seine wesentlichen Eigenschaften beibehielt?
Der Sinn einer Mitarbeit bei OpenStreetMap besteht darin, Dinge vor Ort zu erfassen/zu pruefen und nicht automatisiert mit irgendwelchen Spielen die Daten zu editieren.

Zudem erwarte ich, dass wenn du tatsaechlich vor Ort etwas ueberprueft haettest, du das zugehoerige check_date=* aktualisierst, sofern es vorhanden ist, so wie es ueblich ist und vor Jahren beschlossen wurde. Anderenfalls sehe ich die POIs als nicht geprueft an.

Zum anderen gibt es inhaltlich in der Mapperschaft keinen Konsens zur Verwendung beschriebener wiki-Tags. Das OSM-Wiki listet sie bestenfalls in der englischen Variante als moegliche Option, nicht jedoch als obligatorisch. Ich persoenlich halte nichts davon, Objekte, die massenweise vorkommen, mit wiki-Tags vollzuspammen. Welchen Mehrwert hat dies, allen POIs vom Typ x und Operator y die selbe Nummer mitzugeben? Das muss anders geloest werdeen. Eine Verwendung ergaebe einzig Sinn bei Unikaten, um z.B. von einer Ortsmarke einen Link zu den wikidata-Eintraegen zum Ort zu ermoeglichen oder z.B. bei Sehenswuerdigkeiten etc..

Wenn ich POIs vor Ort regelmaessig (!) pruefe, werde ich selbst entscheiden, ob ich solchen optionalen Unfug behalte oder nicht.

Dann weiter ein frohes echtes Mappen!
LG, sundew

Hi Anisa,
thanks for your info. But you should know how old were these changes and how horrible was the air imaginery at this time. In this time I travelled moretimes there (before facebook came) wide areas here were unmapped.
My best wishes to you ..

Korrektur:
Tour 20221120 .. Schiffdorf, Friedheim, Apeler (Prüfung Postkästen, Geometrien, u.a.)

Hallo nochmal!

Keine Ahnung, wo das steht. Aber es muss auch nicht geschrieben stehen, es reicht wenn es in der letzten zehn Jahren in den Mapperstammtischen in Diskussionen mit den Altvorderen und im OSM-Forum in etlichen Situationen so gelebt bzw. empfohlen wurde. Und nein: ich habe jetzt keine Link für dich.
Außerdem ist das, was im Wiki an möglichen Tags beschrieben ist, auch nur eine kleine Auswahl dessen, was in der Praxis an Tags vorkommt.

Sicher hast du Recht, kann man auch separate bicycle_parking-Nodes mittels Haltestellenrelation anbinden. Allerdings ist dann die Auswertung mit Overpass genauso kompliziert, wie eine near-Umkreisabfrage, bzw. wohl unmöglich, wenn man eine lineare Ergebnismenge haben möchte (also nur eine einfache xml-Liste aus u.a. vielen Busstop-Nodes mit zusätzlich angehefteten bicycle_parking-yes/no-Properties von den zugehörigen Separatnodes).

Vorausgesetzt übrigens auch, die Haltestellenrelation existiert, und das ist nicht überall der Fall. Ich würde sie auch nicht anlegen wollen, wenn ich nicht beidseitig die Platformen komplett erfasst/geprüft habe (dafür gäbe es genug Situationen).

Aber spätestens, wenn ich die relative geometrische Position zur Bushaltestelle angebe, muss ich sie auch bei späteren Überprüfungen mit kontrollieren, genau wie Art, Stellplatzzahl, etc.. Ich will der Bushaltestelle(!) einfach nur die Eigenschaft geben, hier kann temporär ein Fahrrad geparkt werden, mehr nicht.

Dass du bisher kaum bicycle_parking=yes gesehen hast, liegt vielleicht auch daran, dass
1. Fahrradstellplätze an Busstops erst in den letzten ein/zwei/drei Jahren dazu kamen, insbesondere auf dem Land,
2. weit weit draußen sowieso nur wenige Mapper flächendeckend unterwegs sind,
3. heute viele Landbushaltestellen von Couchmappern aus spartanischen Uralteinträgen, Fahrplänen und Luftbildern mal besser, mal schlechter aktualisiert werden,
4. dass die heutigen App-Kiddies bisher dieses Feature noch nicht zur Auswahl haben -> schlag dies ID vor und du hast in Kuerze halb automatisiert das ganze Land mit bicycle_parking=no vollgespam't :-)

So lass uns mal das nichtige Thema abschließen. Für sowas habe ich leider vielzuviel anderes zu tun, sorry.
LG
sundew

Hallo, danke für das Feedback..

In dem Fall habe ich wohl den schon eingetragenen bicycle_parking-Node übersehen (es wurde einfach nicht gerendert). Zwei Gedanken dazu:
1. Generell gilt aber in OSM die Regel, dass amenity=xyz-Objekte auch mit xyz=yes an bestehende Tags angeheftet werden können, wenn man eine Untereigenschaft beschreiben will, die zum Hauptobjekt gehört, z.B. amenity=bench als alleinstehender Node oder bench=yes als Subeigenschaft bei Bushaltestellen ohne weiter Details. Würde man hier einen alleinstehenden Zusatznode eintragen, wäre eine einfache Overpassabfrage, z.B. filtere mir alle Bushaltestellen mit Bench entlang meiner Route, nur noch mit tiefgreifenden Overpasskenntnissen oder halt mit nachgestellter auswertender Programmierung möglich.
2. Mein Ansinnen ist, bei Bushaltestellen nur die ja/nein-Eigenschaft bicycle_parking zu beschreiben, nicht jedoch ständig bei meinen Überprüfungstouren auch noch (recht oft vorkommende) bauliche Änderungen zu kontrollieren. Meine Touren sind schon lang genug und ich hänge mit der Abarbeitung am PC in der Hochsaison oft Wochen hinterher. Keine Chance, sorry.

Bei den Haltestellennamen schaue ich meist vor Eintragung auch nochmal in den offiziellen Fahrplan, um Tippfehler oder Verwechselungen zu vermeiden. Recht oft erlebe ich vor Ort total veraltete Haltestellenschilder mit Uraltnamen oder veralteten Schreibweisen. Im Zweifelsfall gilt dann der Name aus dem Fahrplan.

LG und frohes Mappen,
sundew

Tippfehler im Kommentar -> Tour 20221016 ..

Hallo Lukas,

wenn du dir dessen sicher bist, werde ich gern das Kreditkartentag in Zukunft entfernen. Inzwischen ist bei mindestens einigen dieser Telefone auch der Telefonkartenschlitz verriegelt und es funktioniert neben Muenzen nur noch die als "Telefonkarte Komfort" verkaufte Nachfolgevariante mit 16-stelliger Nummerneingabe. Aber das ist eine andere Baustelle ..

Btw, ich wollte dir ja letztes Jahr nochmal intensiver auf deine Basistelefonanfrage antworten, weil ich die regelmaessig pruefe. Leider sind seitdem von den wenigen verbliebenen die meisten ganz entfernt worden. Sehr schade ..

LG
sundew

Anmerkung: ein Node von der selben Tour in Quisdorf ist versehentlich mit in diesen Changeset gerutscht .. Deshalb diese flächenmäßige Ausdehnung ..

Hi !MRGBoss,
danke für die positive Rückmeldung. Deine Änderungen waren zu umfangreich, um von draußen zu sehen, was genau du als eigenen Beitrag geleistet hast und was nicht. Ich habe mindestens 28 Changesets gefunden, die hier im Raum Hamburg hauptsächlich oder nebenbei unter anderen Changeset-Kommentaren irgendwas quasi automatisiert geändert haben. Da ich das nicht beurteilen kann, werde ich in den nächsten Tagen wohl nur hier in Hamburg und Umgebung die POIs oder POI-Typen teilreverten, die ich auch selbst einmal im Jahr vor Ort prüfe. Was andere Mapper in den anderen Städten machen, kann ich nicht sagen.
Ich hoffe, dass du in Zukunft vorsichtiger mit deinem Editor agierst, insbesondere was irgendwelche automatischen Änderungsvorschläge von ID auch beim ganz normalen Bearbeiten betrifft.
LG und frohes echtes Mappen!
sundew

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