Hallo OpenStreetBoy!

Das ist nicht ganz richtig, was du schreibst. Und über das PTV2-Schema wurde schon sicher ein Jahrzehnt lang heftigst diskutiert. Ein Kompromiss findet sich im wiki.
osm.wiki/DE:Key:public_transport

* Dort steht für die virtuelle Stopposition: Angabe empfohlen wenn keine public_transport=stop_area Relation existiert, sonst optional ..
Es gibt jetzt bei "Kirchlinteln-Lehringen, Winkelmann" aber eine Haltestellenrelation.

* Das Tag bus=yes ist für public_transport=stop_position gedacht, um z.B. bei gemeinsamer Nutzung von Haltepunkten von Bus und Tram eine Zweckbestimmung zu setzen.
An public_transport=platform war das früher verboten und ist auch heute allgemein nicht gern gesehen, auch wenn hier irgendwelche Editoren wie ID sich darüber hinwegsetzen und eine eigene Agenda verfolgen und es somit im wiki als optional hinzugefügt wurde.

* Was die von dir angestrebte Aufteilung von "name" und "ref_name" als Kurz- und Langname betrifft, ist auch das nicht richtig.
In "name" kommt das, was an dem Haltestellenaushang am Schild steht. Dies müsste überall, wo ich im VBN-Bereich einen Blick darauf warf, inzwischen die Komplettschreibweise tragen. Manchmal steht natürlich am Halteschild verblichen noch zusätzlich die früher übliche Kurzschreibweise - z.B. "Ortsmitte" - die ist dann durch den Haltestellenaushang aber obsolet. Man könnte jetzt natürlich diskutieren, ob man die auf den Haltestellenaushängen verwendeten Abkürzungen, wie "Kirchl.", als "Kirchlinteln" umsetzen darf, weil ja in OSM gern alles ausgeschrieben wird, aber darum geht es nicht.
Nun zum optionalen "ref_name". Das ist NICHT für den Langnamen gedacht, der am Haltestellenschild steht, sondern für die in der HAFAS-Onlineauskunft stehende Schreibweise. Und die beinhaltet zuerst den Haltestellenname und erst dahinter den Ort, also z.B. "Steintor, Hannover".
osm.wiki/DE:Key:ref_name
Dieses Tag gehörte ursprünglich auch nur in die Haltestellenrelation und die Wiki widerspricht sich da. Also wie immer, macht jeder hier was er/sie will...

Im Übrigen solltest du bitte nicht ungeprüft einfach alles im Umkreis per App auf VBN setzen. Gerade im betrachteten Gebiet ist die Grenze zum Nachbarverbund sehr eng und einige deiner Edits waren nicht korrekt. Habe ich, wo ich vorbeikam, korrigiert.
Eine Buslinie kann durchaus die Haltestellen mehrerer Verbünde durchfahren, die Haltestellen gehören trotzdem zum jeweiligen Verkehrsverbund. Der Operator der Haltestellen ist manchmal in größeren Orten die Ortschaft selbst im Auftrag des Verbund und nicht der in der Teilregion alleinig fahrende Busbetreiber. Aber das steht nicht an der Haltestelle dran und lässt sich nicht sicher herausfinden.

Dann weiter frohes Mapping ..

Hi highflyer74!

Mit der PLZ scheinst du aktuell Recht zu haben. Habe diesmal vor Ort nur die ref-Nummer sowie technische Eigenschaften gecheckt. Aber da mir das jetzt keine Ruhe lässt: In der alten Wegpunkt-Notiz meiner ersten Prüfung vor zwei Jahren steht sie aber auch genauso als 28195 drin. Das ist die PLZ von Bremen-Mitte/Altstadt, dort war ich bisher noch nie unterwegs. Warum soll ich sie mir falsch notiert haben? Wahrscheinlich stand sie damals tatsächlich noch falsch dran. (Das wäre für mich auch nicht das erste Mal, dass eine Packstation eine PLZ gewechselt..)

Wegen der anderen Anfrage - bitte per PM falls da wirklich Diskussionsinteresse ist.

LG

Ist leider die Changeset-Beschreibung vom vorherigen Changeset .. Es ist natürlich das Innenstadtgebiet von Harsefeld gemeint ..

zu große Fläche - da haben sich leider zwei kleinere Changesets vermischt ..

Hallo Mateusz and a happy new year ..

I know app_operated=yes + display_operated=no from the new parcel locker mapping scheme 2-3 years ago and I used it very many times now. I do it manually at my long mapping tours around Hamburg + 150km. But after my opinion such a "new scheme" must be fix at publishing and should not be adapted again and again and again.

Bye bye, sundew
(sorry my English is horrible)

Korrektur:
Tour 20241003 .. Dutzow, Kneese-Dorf, Bernstorf, Stintenburger Hütte (Vor-Ort-Prüfung Postkästen, Busstops, etc.)

Hallo Langlaeufer!

Danke für die Rückmeldung. Naja, beim Tag smoothness=* hieß es in den letzten Jahren immer, dass eine objektive Einordnung - z.B. nach Bodenfreiheiten von Fahrzeugen - nicht möglich ist. Vielmehr ist es eine subjektive Beschreibung und die ist natürlich auch abhängig von der Art der Fortbewegung. Wenn ich einen breiten versandeten grade2-Track habe, wird ein Fahrrad- oder Normalauto-Nutzer fluchenderweise smoothness=very_bad oder schlimmer vergeben, während ein Wanderer oder Reiter sich nicht weiter daran stört. Habe ich einen vom Zahn der Zeit zerfressenen ehemaligen Asphaltweg oder concrete-lanes, wo es bei jedem Riss und an jedem Plattenübergang heftig holpert, ist man mit dem Fahrrad auch erheblich schlimmer dran, als mit dem Automobil. Beim Mountainbike hilft da auch die Federung kaum, genausowenig wie auf naturbelassenem Kopfsteinpflaster. Ein grasbewachsener grade4-Track ist mir da deutlich lieber.
Dass überhaupt feste Werte excellent/bad/very_bad/horrible existieren, dient wohl viel mehr der Vermeidung von Wildwuchs bei den Tagwerten, als einer objektiven Bewertung.
In dem konkreten Fall habe ich den hauptsächlich als Fuß-/Fahrradweg genutzten Serviveweg so getaggt, wie ich es damals vor Ort mir notiert habe. Wenn du inhaltlich anderer Meinung bist, bitte ändere es.

LG
sundew

Hallo Niiepce!
Nach meiner Kenntnis steht es für eine Tafel mit Amtlichen Bekanntmachungen, zu finden in praktisch jedem Dorf. Das wurde mir wurde vor Jahren so empfohlen, weil board_type=notice eher für Veranstaltungstermine u. örtliche Werbung passt. Inzwischen ist board_type=information zwar im wiki als deprecated markiert, aber eine sinnvolle Alternative finde ich nicht.
LG

Hallo Johnny,

ja du hast Recht. Dort stand neulich nur eine einzige Telefonleiche. Ja mein Fehler, ich hatte mich schon gewundert, warum ich bei meiner ersten Tour durch Stendal zwar das Telefon dort geprüft hatte, aber dann bei der Vorbereitungsfilterung (check_date) für die zweite Tour zwei Wochen später es immer noch ungecheckt vorfand, also nochmals dran vorbei fahren musste. Ich glaube mich zu erinnern, es gab wohl damals einen Uploadkonflikt in JOSM, weil der Node an der zu dem Zeitpunkt ungeladenen Wiese dran hing.
Ich lösche den versehentlich doppelt eingetragenen Node nun.

LG & frohes Mappen!

Tour 20240330 ..

Tour 20240330 ..

Hallo Roger,

ich habe jetzt den fehlenden Briefkasten im Ortsteil Kolonie Hünzingen gesucht und eingetragen. Und tatsächlich hat auch dieser ein vertauschtes Briefkastenschild "Forellenhof, 29699 Hünzingen-Dorf". Nun haben wir allerdings das Problem zu wissen, dass beide Briefkästen nicht nur vertauschte, sondern auch noch veraltete Schilder tragen. Das entspricht zwar der OTG-Regel, ist aber nicht mehr korrekt. Denn mittlerweile haben die meisten Briefkästen der gesamten Region Walsrode statt dem jeweiligen Dorfnamen den Ortsbezeichner "Walsrode" und ich gehe davon, dass dies auch hier zutreffen müsste.
Naja egal, nicht zu ändern, ich habe den ursprünglichen Briefkasten auch angepasst und kommentiert.

LG und einen guten Rutsch,
sundew

Hallo Roger,

prinzipiell hast du vollkommen Recht mit OTG. Allerdings erlebe ich es ständig, dass Briefkastenschilder zwischen benachbarten Orten vertauscht sind, die ref-Adresse existiert nicht im Ort, dafür im Nachbarort und umgekehrt (oder mehrere Briefkästen reihum). Es gab sogar mal jahrelang an der Straße nördlich von Bendestorf drei Postkästen mit identischem Schild/identischer ref-Adresse. Somit ist mein Vertrauen zur Richtigkeit erstmal per se eingeschränkt. Wenn ein solcher Fehler also offentsichtlich ist, korrigiere ich die Vertauschung und vermerke das im note-Tag. Ich glaube, das erfüllt die OTG-Regel trotzdem, weil ja aus anderen OTG-erfassten Daten abgeleitet.
In dem jetzt hier besprochenen Fall hatte ich erfahren, dass wohl noch ein Briefkasten irgendwo dort in der Gegend um den Ortsteil "Kolonie Hünzingen" fehlen soll, also werde ich diesen auf meiner zeitnah nächsten Tour durch diese Orte suchen. Und genau auf diesen fehlenden Kasten würde die vermeintlich falsche ref-Adresse nun besser passen.
Da ich mir - wie geschrieben - baustellenbedingt auf Distanz eingebildet hatte, eine andere ref-Adresse gelesen zu haben und selbst der Erfasser dieses Tags bzw. zuvor letzte Änderer war, sowie der Meinung war, dass nun alles richtig sei, sah ich hier keine Notwendigkeit für einen note, sondern hab es einfach nach bestem Gewissen angepasst ..

LG
sundew

Nein, ich glaube, die ref = "Kolonie Hünzingen" gehört an einen anderen Briefkasten, nicht an diesen. Ich werde diesen bisher nicht in OSM eingetragenen Briefkasten suchen fahren und dann hier ggf. nochmal nachbessern.

(Also habe ich wohl auf Distanz, Bauabsperrungen davor, was falsches abgelesen/notiert was aber evtl. am Ende doch inhaltlich richtig ist. Schaun wir mal ..)

Normalerweise wenn ein Briefkastenschild vertauscht ist, was an manchen Regionen krass oft vorkommt, schreibe ich das richtige ref dran, falls irgendwie erschließbar, und die falsche ref-Adresse in einen note=* ..

LG, sundew

Hallo Roger,
dort war am Briefkasten wohl bei meiner vorherigen 2022-Kontrolle noch ein vertauschtes Briefkastenschild dran. Diesmal war alles am Forellenhof Baustelle und ich kam nur auf zwei/drei Meter an den Kasten ran, sah aber vage die neue Ref-Adresse, hab sie jedoch vor Eintragung nochmal mit der Hausadresse verglichen. Die vorherige falsche ref-Adresse gehört wohl zu einem anderen Briefkasten in der Kolonie Hünzingen, den ich noch zu suchen mir zeitnah vorgenommen habe.
LG und frohes Mappen,
sundew

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