Wenn dort addr:place angegeben wird, bin ich nicht sicher, dass der rote Kreis verschwindet.
Zumindest habe ich Stellen, wo ein Fehler gemeldet wird, z.B. https://www.openstreetmap.org/way/228431419.
Liegt das vielleicht daran, dass in der Nähe ein place=isolated_dwelling mit anderem Namen eingetragen ist?
Nicht notwendig hat ein Hof als Adresse seinen Namen, sondern oft den Flurnamen.
Da gibt es allerdings ein ziemliches Durcheinander Gemeinde/Post mit Namen mit/ohne “G(e)wand(t)”. Das sorgt dann für etliche (gerechtfertigte?) rote Punkte.
Zur Updatefrequenz: Ich erinnere mich an einen Hausnummernvalidator http://gulp21.bplaced.net/osm/housenumbervalidator/# (letzte gemeldete Aktualisierung: 2015-04-01), der gefühlt monatlich aktualisiert wurde.
Da ist ein Tagesrhythmus Gold dagegen und man sieht eher mal nach, was man die letzten Tage “verbrochen” hat.
Wird als “Fehler” angemeckert, weil addr:place = Sulzrain. Einen Place (Node, Way) mit “Sulzrain” finde ich jetzt nicht in der Umgebung (vielleicht kannst du einen Link schicken?), wohl aber einen Place isolated_dwelling “Tannenhof”: https://www.openstreetmap.org/way/34012025#map=18/48.45354/9.19434
Ist das “Anmeckern” jetzt korrekt oder nicht? IMHO kann man das nur mit Vorort-Kenntnissen genau festlegen.
Bei diesen ganzen “Gewann”-addr:places drumherum bin ich mir nicht sicher, ich kenne persönlich keine Adresse, die so lautet. Zumal diese Gewanne meist gar nicht in OSM existieren oder Nominatim diese nicht findet oder ich zu doof zum Suchen bin: “Gewand Äußere Hintere Röt” oder “Äußere Hintere Röt” > 0 Ergebnisse.
Den place=Sulzrain gibt es nicht, da bisher niemand hier in der Gegend den Ehrgeiz hatte, alle Flurnamen als place einzutragen.
Das kann man machen (siehe anderen Thread), sollte aber nicht Anlass sein, dass ein addr:place ohne Eintrag in der Umgebung angemeckert wird.
Das liefe auf folgendes hinaus:
Ein addr:place ohne einen Eintrag in der Nähe wird nicht angemeckert.
Ein addr:place mit Einträgen in der Nähe (Straße, place-Tag), die nicht übereinstimmen, von mir aus ja, wenn Mapper ohne Ortskenntnis davon die Finger lassen und nur offensichtliche Tippfehler korrigieren.
Gäbe es vielleicht die Möglichkeit, ähnlich wie bei Keepright ein “false positive” rückzumelden?
Ich finde schon, dass das korrekt ist. Es wird in dem Fall ja ein Hinweis gegeben (eben durch den “roten Punkt”), dass da u.U. etwas nicht übereinstimmt. Entweder ist kein place dieses Namens innerhalb eine gewissen Radius, oder addr:place ist falsch. Beides sind “Fehler” in OSM, denen man nachgehen sollte.
Wenn ich das entsprechend umstelle, wird man nicht mehr mitbekommen, dass da eventuell ein place fehlt, den man aber gerne in OSM hätte. Das kann man gerne ausdisktutieren, in dem Fall füge ich mich der Mehrheit
Wegen “false positive”-Rückmeldung - wie soll das aussehen?
Was ich mir vorstellen kann:
Der Benutzer kann private false-positive im eigenen Browser (per local storage) nur für sich selbst festlegen, die dann beim Laden bzw. Anzeigen der Vektor-Tiles ausgeblendet werden. Da weiß ich nicht, wie das mit dem Speicherbedarf und dem Laufzeitverhalten im Browser aussieht. Wenn false-positive, dann wäre das mein bevorzugter Weg.
Eine “globale”, für alle Benutzer sichbare false-positiv-Liste möchte ich eigentlich nicht führen:
Wenn 1 Person das Objekt als korrekt kennzeichnet, nicht mehr anzeigen? Was ist, wenn diese Person durch welche Umstände auch immer “falsch” entscheidet? Das fehlerhafte Objekt bleibt versteckt.
Keine Ahnung, wie Keepright das intern handhabt? Lokal scheint ausser dem Cookie nichts gespeichert zu werden. Wenn ich da einen Fehler mit “ignore” speichere, wird der Bug dann nur für mich oder auch für andere “unsichtbar”?
Ich sehe das leidenschaftslos, war ja nur ein Vorschlag.
So wie ich mich kenne, führt das halt dazu, dass ich nach dem fünften “war doch wieder nur false positive” was anderes mache. OSM wird’s überleben
Wie Keepright das macht, weiß ich nicht - ich habe es nicht implementiert. Ich will da keinen Aufwand generieren, war ja nur eine Frage. In der Nachbarschaft weiß ich schon, wo die Pappenheimer sind und das muss dann reichen (s.o.).
Jetzt komm ich doch mal wieder mit meiner addr:place-Spezialität aus der Deckung…
Hier im Spreewald, speziell in Dorf Lehde (Ortsteil von Lübbenau) gibt es Adressen, die defakto nicht mit dem Auto zu erreichen sind. addr:street fällt da aus. Da bleibt nur addr:place.
Diverse Grundstücke sind auch nur per Kahn erreichbar.
Ich werde die Tage mal testen, wie das vom Handling her ist, wenn man für sich selbst eine Ignore-Liste führt. Wenn das einigermaßen erträglich ist von der Verarbeitungsgeschwindigkeit, ok. Ich selbst hätte es ja auch gerne, weil ich in meiner Homezone auch immer wieder die gleichen Objekte anfasse, die ich nicht bearbeiten kann.
Und darum ist Vorsicht angesagt. Und noch aus einem zweiten Grund, wenn es konkret um eine ph/f-Verwechselung o.Ä. geht: Rudolph mit -ph- wäre die seltenere, ungewöhnlichere Schreibweise (die lectio difficilior, wie die Philologen sagen), Rudolf mit -f dagegen die gewöhnliche. Daher, so eine Faustregel der Textkritik, ist es zwar recht wahrscheinlich, dass jemand Rudolf statt Rudolph schreibt (weil er unbewusst die ungewohnte durch die gewöhnliche Schreibweise ersetzt), aber eher unwahrscheinlich, dass es umgekehrt geschieht. Daher sollte man im Zweifelsfalls gerade solche „schwierigen“ Namensschreibweisen nicht einfach korrigieren: ihre Ungewohntheit spricht für ihre Echtheit, d.h. dafür, dass sie tatsächlich vom Straßenschild übernommen sein könnten.
Aber noch einmal generell zu dooleys neuem Tool OSMsuspects!. Es ist wirklich sehr nützlich, ich habe gerade eine Reihe von Schlampereien im Landkreis HN damit gefunden und behoben (ich weiß, dass auch in diesem Landkreis noch mehr zu tun ist ;)!).
Charmant finde ich insbesondere, dass das neue Tool nicht so überladen ist wie keepright und (erst recht) http://osmose.openstreetmap.fr/ – letzteres verwende ich, ehrlich gesagt, kaum, obwohl es fantastische Fähigkeiten hat, einfach weil es so mächtig und überladen ist und an jedem Kleinkram rummeckert ….
Daher meine Bitte: feilt OSMsuspects! noch ein bisschen aus, aber baut nicht zuviel ein, damit es ein übersichtliches, klares Werkzeug zur Adress-Fehlersuche bleibt. Gerade durch diese Übersichtlichkeit und die klare Zielrichtung (Adressdaten) hebt sich OSMsuspects! für mich wohltuend von keepright und Osmose ab, die Benutzung macht dadurch IMHO mehr Spaß und das dient der Sache sehr.
Sind verschiedene Schreibweisen bei Eigennamen echt erlaubt, zählt es nicht so, wie es in Geburtsurkunde steht?!
Photo=Foto…hier hat man die Rechtschreibung angepasst, klar. Aber bei Namen?
Wenn ich irgednwo mal einen Index von Wikipedia finde, werde ich mal einen Ablgeich versuchen.
Dummerweise hab ich noch Nichts gefunden und alles aus der XML Gesamtdatei rausackern ist mir im Moment noch zu doof.
Es muss doch irgendwo ein Stichwortverzeichnis geben…
Natürlich wirds unfassbar viele nicht gefundene Begriffe geben, aber eventuell kann ich es so machen, dass ich phonetisch ähnliches Suche und Abweichungen innerhalb von OSM zeige
Oder zwei Großbuchstaben hintereinander.:
Way WY183169434 Werner-von-SIemens-Str
Wenn man eigetnlich ausschließen kann, dass das korrekt ist, kann man auch nach sowas suchen.
Oder am Anfang Kleinbuchstabe+Kleinbuchstabe (also nicht: “´s Wegle”)…
Nehmen wir mal
LAgerhausstr.; Way 257334467
Hier findet sich ein ungewöhnlicher Anfang, der zugehörige Highway(=Straße) selbst korrekt geschrieben und andere Adressen ebenfalls korrekt geschrieben.
Sowas könnte man schon automatisiert raussuchen, oder?
Vorsicht: Platz- und Straßennamen weichen durchaus häufiger von der Schreibweise des namengebenden Ortes ab, siehe z.B. die Benennungsgeschichte der Joachimst(h)aler Straße nahe dem Berliner Zoo oder den Platz samt U-Bhf. Kottbusser Tor in Berlin Kreuzberg und den davon abgehenden Kottbusser Damm. Eigentlich ein Fehler, könnte ein Ausstehender denken, der nur die Stadt Cottbus kennt.
Ab sofort kann man für sich selbst (in dem benutzten Browser) festlegen, ob die Daten gefiltert oder nicht gefiltert angezeigt werden. Auf der Karte > Der Button mit dem Filtersymbol: sehr hellgrau > Filterung aus, dunkelgrau > Filterung ein.
Wie wird gefiltert: Im Popup der Marker gibt einen neuen “Link”: “Diese xxx ignorieren” > Klick und der Marker wird zukünftig nicht mehr auf der Karte erscheinen (wenn die Filterung eingeschaltet ist natürlich). Die Filterung geht immer auf den entsprechenden Bug, d.h wenn ein Marker mehrere Bugs anzeigt, muß dieses Objekt ggf. mehrfach ignoriert werden.
Die Ignore-Liste wird im localStorage des Browsers lokal vorgehalten, wenn man einen anderen Browser benutzt, ist die Liste dort nicht vorhanden.
Zum Entfernen eines Objekts auf der Ignore-Liste ist mir ehrlich gesagt noch nichts eingefallen - vorläufig kann man die Liste manuell bearbeiten, wenn man die Browser-Konsole aufmacht (meist F12) und dort unter “Speicher- Local Storage” o.ä. den String für den Key “ignoreList” bearbeitet. Oder mit Kontext-Menü (Linksklick) gleich ganz löscht.
Wenn was nicht funktionieren sollte, bitte kurze Rückmeldung.
Das alles geht natürlich nur, wenn der Browser localStorage unterstützt (was alle neueren Browser aber können sollten).
Beim Umherstreifen am Bodensee ist mir aufgefallen, dass es da richtige Weiß-Kreis-Seen (unklare addr:city) gibt.
Bei Ueberlingen ist das einsichtig, bei Radolfzell aber nicht.
Grund dürfte sein, dass es zwar einen place-node mit name=Radolfzell gibt, in der boundary-relation aber “Radolfzell am Bodensee” steht.
Statt an jede Hundehütte das “am Bodensee” dranzuhängen oder gar Hunderte von weißen Kreisen per Klick zu ignorieren, tendiere ich dazu, das bei der boundary mit
name=Radolfzell + name:suffix=am Bodensee
zu lösen, ein name:prefix=Stadt gibt es ja schon.
Ein “addr:city=Radolfzell am Bodensee” würde ich tolerieren, im Konsens sogar ein “Stadt Radolfzell am Bodensee”.
Das ließe sich auch bei der Suche viel leichter realisieren als auf Teilstrings zu vergleichen.
Ich weiß nicht, wie die Nachbarschaftssuche bei addr:city abläuft, das Namensproblem mit den offiziellen bis halboffiziellen Zusätzen gibt es ja häufig. Wir sollten uns nur einig sein, was bei addr:city stehen darf (ein “Ort - Ortsteil” z.B. nicht).
Schwieriges Thema, das. Der offizielle Stadtname lautet “Radolfzell am Bodensee” (als einzige Stadt am Bodensee mit diesem Zusatz lt. Wikipedia). In der VG250-Datenbank ist es auch so drin, in den Admingrenzen von OSM auch. Lt. https://www.postdirekt.de/plzserver/ wäre das auch korrekt (also der Langname).
Ich halte es eher für ungünstig, nur wegen dieser einen Auswertung den Boundarynamen anzupassen, da kommen sicherlich andere Auswertetools ins Stolpern - und es wäre IMHO inkorrekt.
Ich tendiere eher dazu, die Adressen entsprechend zu korrigieren, wobei man bei diesen Mengen eventuell schon an einen zuvor diskutierten mechanical edit denken kann. Niemand wird die über 3000 Adressen in “Ueberlingen” manuell korrigieren.
addr:city prüfe ich übrigens nicht spatial, sondern ausschließlich auf Namensgleichheit gegen die VG250 und die Namen, die in den notes der OSM-PLZ-Boundaries hinterlegt sind. Das ist sicher nicht optimal und wird bei Gelegenheit (und entsprechenden Hinweisen, wie man es besser machen kann) geändert werden müssen.