Automatisiertes beheben toter Links

Communities Deutschland (Germany)
,
21

Ich muss zugeben, dass ich keinen Beleg für die Existenz ein automatisches Erzeugungsverbot für Notes auf die Schnelle vorzeigen kann. Da müsste ich mal die alten Diskussionen zu der Frage finden und lesen. Gegen eine automatische Erzeugung spricht jedoch, dass es zu einer Note-Schwemme führen würde, die manche Mapper zu recht kritisieren. Notes sind als Mittel dazu gedacht, dass Menschen Fehler melden. Für Fehlermeldungen durch Maschinen gibt es Qualitätssicherungs-Websites wie Osmose, den OSM Inspector oder KeepRight, wo Maschinen ihre Ergebnisse publizieren können.

3 Likes
22

Danke dafür… Da sieht man mal, was da so alles drin steht…

…sowas ähnliches kannte ich mal von Internetseiten des Landes Brandenburg: bei jeder Änderung der Seite wurde die Zahl in der URL hochgezählt, man konnte keinen Perma-Link setzen; ist da inzwischen geändert. Ich würde vermuten, daß bei sowas die Angabe der *.php nicht viel bringen wird, da die sich jederzeit wieder ändern kann.

Ich glaube, ein automatischer oder Semi-Automantischer Prozess zur Fehlerbehebung könnte da kontraproduktiv sein.

Sven

2 Likes
23

Das ist z.B. im Wiki so dokumentiert: DE:Notes

Mal ein neuer Vorschlag: wie wäre es mit einer MapRoulette-Challenge nur für Objekte mit toten Links und einem check_date in der jüngeren Vergangenheit? Die sind neulich überprüft worden, das heißt, sie werden wohl noch existieren und es sind wohl eher Tippfehler in der URL oder die URL hat sich geändert. Die neue URL findet man dann schnell raus und kann das vom Sessel erledigen, anders als wenn der POI nicht mehr existiert.

3 Likes
24

Danke:-)

Die englische Version ist im Abschnitt Don’t s etwas ausführlicher - und bereits am 25.04.2013, einen Tag nach Einführung der Notes, stand im Abschnitt API der Satz:

Das klingt nach einer guten Idee. Möglicherweise in Regionen aufgeteilt, so dass Fortschritte besser zu sehen sind und somit motivieren - im Vergleich zu den 50.000 Objekten der verlinkten Challenge.
Wobei ich persönlich recht viele website-Tags aktualisieren konnte.

1 Like
25

Ich wäre gespannt zu wissen, wie viele Objekte das betrifft und ich vermute: Wahrscheinlich wird es davon gar nicht so viele Objekte geben, dass es sich lohnt in Regionen aufzuteilen.

26

Stimmt! Leider bin ich nicht in der Lage, zig tausende Links zu korrigieren. Darum schlage ich vor, genau einen solchen Hinweis einzufügen.

Noch nicht, das ließe sich aber einfach ändern, Beispiel.

Den Kommentar empfinde ich als herablassend. Können wir uns darauf einigen, dass wir beide die OSM noch besser und korrekter machen wollen?

Das stimmt! Auch die Geographie-Daten veralten ständig, und dennoch werden sie ständig aktualisiert und verbessert. Darum will ich an dem Katz-und-Maus-Spiel teilnehmen, um OSM zuverlässiger und aktueller zu machen.

Das eigentliche Problem ist, dass OSM falsche, veraltete Daten anzeigt. Das Problem wird durch beide Ansätze (“Umstellen auf disused:website” und “Löschen des Tags”) gelöst.

Ich schlage ja disused:website gerade deshalb vor, weil es sehr einfach auszuwerten ist, und z.B. durch overpass, mapquest, StreetComplete, etc. sehr einfach findbar ist. Ich kann gerne eine SC Quest implementieren.

Verstehe ich dich richtig, dass du vorschlägst, dass der Bot automatisierte Notes erstellen soll? Ich bin dagegen, der Moderator anscheinend auch.

Ungefähr 20.000 tote Domains, betrifft grob ca. 21.000 OSM-Einträge.

Ich habe vor, nur unerreichbare Domains die 6+ Monate denselben Fehler zeigen zu editieren. Das müsste all deine Bedenken beantworten.

Stimmt, das wäre schlecht, darum habe ich das auch garnicht vor. Ich will immernoch disused:website verwenden. Dadurch ist der POI klar markiert und findbar.

4 Likes
27

Richtig coole Idee!

Um zu testen ob diese Idee auch praktikabel ist, habe ich mal alle Links die mir jemals einen Verbindungsfehler beim crawlen gaben rausgesucht, und alle dazugehören Items in OSM exportiert: Das sind 39446. (Bedenke, da sing unweigerlich einige false-positives dabei, ich behaupte nicht dass alle 39k Items tatsächlich tote Links haben, aber die Zahl “20k” von vorhin ist wohl etwas zu niedrig.)

Von diesen 39 TAUSEND Items enthalten nur 436 Items das Wort “last”. (Davon 216 lastcheck, 42 last_check, der Rest sind false-positives wie “Kopfsteinpflaster”, “Pflasterbau”, “Altlastenfreistellung”, “Asienpalast”, “plastische Chirurgie”, “craft=plasterer”, “Lilastern”, “plastic_bottles”, “Lasthaus”, etc. Sagen wir mal 300 true positives.)

Es haben also weniger als 1% überhaupt ein last_check Tag, und noch viel weniger davon sind in der jungen Vergangenheit: Nämlich 23. Hier ist die gesamte Liste: n905189886 n1421236232 n1545948647 n1546889233 n1567004849 n1567004851 n2000958132 n2049437344 n2830955760 n2933800514 n3208553484 n3276184285 n3811152602 n3874137810 n3874138531 n4076224604 n4404210176 n7107977842 w48817847 w95143726 w299650257 w830159755 w885533919

Dafür mache ich keine Challenge auf, da ich die anderen ca. 20k-39k toten Links auch beheben will.

28

Danke! Der Key heißt aber check_date :slight_smile: Könntest du vielleicht einmal gucken, wie viele Objekte den haben?

Der Key wird unter anderem von StreetComplete und Every Door gesetzt (auf den Tag, an dem das Objekt zuletzt überprüft wurde).

Wenn check_date fehlt, kann man natürlich auch nach dem letzten Bearbeitungsdatum gehen. Der ist aber unter Umständen von Massenedits und Maproulette-Challenges verfälscht, bei denen das Objekt gar nicht konkret überprüft worden ist.

1 Like
29

Oh Mist! Ja, da habe ich mich total verlesen, danke! :smiley:

check_date kommt in 2877 von 39446 vor, davon lediglich 1620 nach 2020-01-01. (Und checkdate gibt es 0 Mal.)

Wie gesagt: Gute Idee! Leider nicht praktikabel, da es nur zu wenige Objekte abgdeckt.

Ich kann dir gerne einen Dump per PM zukommen lassen, mit dem Caveat dass ich nicht garantiere dass die Domains wirklich tot sind.

30

Ich finde den ganzen Ansatz eher sinnfrei. Nur weil es möglich ist, genau dieses eine kleine Problem maschinell zu erkennen, ist es doch noch lange nicht nötig, dafür einen besonderen Aufwand zu betreiben. Wenn ich die Webseite von Bauer xyz zu irgendeinem Hofladen eintrage, dann prüfe ich meist, ob die auch erreichbar ist, aber was interessiert mich das, wenn sie nach zwei Jahren nicht mehr erreichbar ist? Viel interessanter ist doch, ob der Hofladen oder was auch immer noch existiert.
Das eine URL nicht erreichbar ist erkennt ja auch jeder, der es versucht.
Man kann also so eine maschinelle Auswertung verwenden, um mal bei Gelegenheit dort vorbei zu schauen, aber “Automatisiertes beheben toter Links” wäre aus meiner Sicht genau falsch, weil dann eben der Eindruck erweckt würde, dass jemand das Objekt selbst überprüft und für korrekt befunden hat und nur die URL nicht mehr stimmt.

4 Likes
31

Muss es denn immer diese drastische Wortwahl sein? Dennst Du wirklich, dass es wirklich ohne jeglichen Sinn ist, wenn jemand sich darum kümmert, dass Datenbankeinträge aktuell sind und keine falschen Daten in der Datenbank stehen?

3 Likes
32

Ich schrieb “eher sinnfrei”, was doch klar macht, dass ich es nicht für völlig unnötig halte, aber im Weiteren erläutere ich ja auch, warum.

33

Naja, wurde aber ganz oben schon angeführt: Wenn der Link tot ist, dann ist manchmal/oft/was-auch-immer auch der POI tot, und mit Link-Tot markieren ist es also nicht getan, sondern der POI gehört geprüft.

Meine Meinung: Link-Tot markieren ist OK :slight_smile:

34

Wenn man website löscht und ein fixme hinzufügt, dann würde ich das immerhin in Osmand sehen, wo man die fixme Anzeige aktivieren kann.

Ok, für fixme gilt das gleiche wie für Notes: :frowning_face:
https://wiki.openstreetmap.org/wiki/Key:fixme#This_is_not_a_tag_for_robots_nor_for_any_automated_edits

35

Meiner Meinung nach wäre dies die beste Lösung. Es sieht gar nicht so schwer aus, den Datensatz in Osmose zu bekommen.

  • Du müsstest den Auswertungs-Datensatz unter einer konstanten URL bereit stellen. Z.B. als CSV-Datei id, url.
  • Im osmose-backend gibt es die “Analysers”, die auch externe Daten laden können. Die analyser_merge_*.py unter /analysers können als Beispiel dienen.
  • Beim Abgleich mit den aktuellen OSM-Daten sollte man noch einmal prüfen, ob die tote URL noch in den aktuellen Tags erscheint.

Die Vorteile aus meiner Sicht sind:

  • Du brauchst nur die Auswertung zu machen und als Datei bereit zu stellen.
  • Die Frontend-Anwendung z.B. mit Markieren der Fehler als erledigt oder falsch-positiv gibt’s geschenkt.
  • Integration in eines der Standard-QA-Tools, wo hoffentlich mehr Mapper drauf schauen als ein spezialisiertes Einzel-Tool.
  • Man kann von Osmose aus als GPX oder KML exportieren und in mobile Apps laden. SCEE integriert schon Osmose – allerdings nur im Expertenmodus und nur ausgewählte Fehlertypen.
5 Likes
36

Es kommt darauf an, oder? Mit der Zeit werden es schon einige werden, würde ich meinen. Man muss nicht alles auf einmal beheben.

Ist dies ein Henne-Ei Problem? Kommt die Quest erst wenn sie x Objekte betrifft oder ginge das auch so schon?

Ja, können wir. Entschuldigung, so war das nicht gemeint. Es war so gemeint, dass es im Internet keine Website gibt, auf die man sich verlassen kann, dass die Daten alle korrekt sind. Und (nicht nur bei) bei OSM ist es “ein ewiges Katz-und-Maus-Spiel”, weil man denkt, dass man nun alle Websites an den Objekten im Griff hat und dann gehen halt die nächsten offline.

Ich finde, das ist nicht das eigentliche Hauptproblem. Das Problem sind veraltete POIs. Es sind ja nicht nur die Webseiten, die dann falsch sind, sondern auch die Feature-Tags, Öffnungszeiten, Name etc. Das ist nur nicht so sichtbar, weil man kein curl darauf loslassen kann und disused:opening_hours setzen kann. Dass die Website falsch ist, ist mMn nur ein Teilproblem von dem Problem “POI veraltet”.

Nein. Das sollte ein Mensch machen. Wenn jemand Rückmeldung zu dem Hinweis gibt, soll Mensch darauf eingehen können und auch den Fehlerhinweis bearbeiten können. Es soll nach einer Rückmeldung zum Hinweis, dieser eben nicht vor sich hin schmoren.

So pauschal würde ich dem nicht zustimmen. Auch nach 6+ Monaten kommt vielleicht auch eine Website wieder.

Um mich noch einmal zu wiederholen, aber anders: Es gab mal einen automatisierten Edit, deutschlandweit alle getaggten Telefonnummern in ein bestimmtes Format zu bringen. Dadurch, dass da nur das Telefonnummerformat geändert wurde, wurde der POI aber vor Ort gar nicht angesehen. Man hat mit der Aktion von dem Objekt aber eine neue Version erzeugt. (Und der Revert von dem undiskutierten Edit noch eine Version.) Wenn ich nicht genau in die Historie des Objektes schaue, was die letzte Änderung war und das sehe, denkt man, der POI ist schon ok, wurde ja erst kürzlich aktualisiert. Genau das ist nicht schön, wenn man nur auf disused:website setzt. Der POI wird aktualisiert ohne ihn vor Ort betrachtet zu haben.
Verschiedene Tools schauen darauf, wann ein Objekt zuletzt geändert wurde, u.a. auch StreetComplete solange es kein check_date gibt (Quest, die fragt ob XY noch existiert). Das funktioniert nicht mehr, wenn eine neue Version mit disused:website erzeugt wird.

+1
Wenn das irgendwie gehen könnte, wäre das eine sehr coole Lösung.

edit: ein weiteres Beispiel, wo nach nach der letzten Änderungen eines Objektes geschaut wird: RestoBot

1 Like
37

Danke dir, besonders für die Links! Ja, das klingt nach einem sehr sinnvollen Ansatz, den werde ich wohl nehmen

Danke dir :slight_smile:

Das stimmt, aber irgendwo muss man die Grenze ziehen. Ich halte 6 Monate für eine ganz “okaye” Grenze, besonders da es dann “nur” zu einer Warnung in Osmose kommt. Sobald mein Crawler Daten über einen viel längeren Zeitraum hat, können wir uns gerne nochmal darüber unterhalten.

Das ist in meinen Augen ein Problem der Tools bzw. des Formats. Es gibt ja genügend Gründe ein Objekt anzufassen ohne dass es vor Ort mit den eigenen Augen angeschaut wurde (z.B. Imaging-Offset, Umbenennung, Entfernen von illegalen Daten, Vandalismus, etc.). Aber ja, ich sehe auch dass man das Problem nicht unnötig schlimmer machen muss.

Ich fasse kurz das Ergebnis zusammen:

  • Ja, wir wollen alte/kaputte Links irgendwie behandeln
  • Nein, nicht automatisiert behandeln, weil Uneinigkeit darüber besteht wie genau (und ein Tag zu hinterlassen kann paradoxerweise als sign of activity gesehen werden)
  • Osmose müsste ein guter Weg sein, siehe Hermanns Anleitung
4 Likes
38

Die bisher noch ungeklärte Frage ist für mich eigentlich:

Sind in der Mehrzahl der Fälle nur die Links tot, weil z.B. falsch oder veraltet, aber der POI existiert noch, oder sind in der Mehrzahl der Fälle die POIs tot?

In einem Fall macht das Entfernen der Links Sinn bzw. es sollte möglich sein, den neuen Link zu finden.

Im anderen Fall wäre das Entfernen eher kontraproduktiv.

Wenn du das machst, gucke ich mir das mal an. Falls es tatsächlich so ist, dass sich bei den meisten Objekten mit check_date oder Bearbeitungsdatum in der jüngeren Vergangenheit schnell online der richtige Link finden lässt, würde sich eine Zweiteilung des Datensatzes anbieten:

Vor kurzem bearbeitete Objekte in Maproulette (gut und schnell vom Schreibtisch aus zu erledigen), ältere in Osmose (braucht wahrscheinlich einen Besuch vor Ort oder zumindest Ortskenntnis).

39

Interessante Frage, aber um sie zu beantworten müsste man mehrere Wochen quer durch Deutschland touren.

Ich schicke dir per PM einen Dump von den 1870 Objekten mit den Eigenschaften:

  • Mein Crawler hatte mal einen Verbindungsfehler (was nicht heißt dass die Webseite definitiv down ist, sondern nur dass sie wahrscheinlich down ist – oder mein ISP einfach nur Schluckauf hatte, oder kosmische Strahlen)
  • und es gibt ein check_date von 2023 (1826 Objekte) oder 2024 (45 Objekte).
  • “Aber Ben, 1826 plus 45 ergibt nicht 1870!” höre ich dich sagen. Das liegt an n2887805874, welches die Tags check_date=2023-08-30,check_date:opening_hours=2024-01-06 hat, und ich deswegen gerade doppelt gezählt habe.

Bitte nimm das nicht als ultimative Liste der Wahrheit – diese Objekte hatten nur ein bis drei Verbindungsfehler, das ist noch nicht lange genug um eine Domain wirklich als tot zu bezeichnen.

sha256: d754011d9bf57fcb9dc476663c314915d5f52b2f9c78cbd2e33f409e2ddfaa5a

40

Danke. Ich bin mal 20 durchgegangen.
Es gibt die unterschiedlichsten Situationen:

  • URL falsch (z.B. Tippfehler), richtige URL schnell zu ergoogeln: 6
  • Finde keine URL auf die Schnelle, nur Einträge in gelben Seiten, Lieferando o.Ä.: 4
  • Finde keine URL aber Instagram oder Ähnliches: 3
  • HTTPS in URL, aber Link nur unter HTTP erreichbar (z.B. weil falsches Zertifikat): 3
  • URL funktioniert noch: 3
  • Objekt bereits als disused:amenity getaggt: 1

Im allgemeinen Schreibtisch-Fleißarbeit, die keinen Besuch vor Ort erfordert, sowas würde sich gut für Maproulette eignen. Dafür müssen wir die Daten nur ins richtige Format bringen, dann kann es losgehen.

1 Like