Massenedit "-website (DNS does not resolve)"

Ihr redet über vitalis-senioren.de? Jo, eine dämliche Form der Weiterleitung, die aber recht beliebt ist… Machen auch manche Shops und andere CMSe so: Man liefert bei Aufruf einer nicht vorhandenen Unterseite eine 404 und danach (also da wo in einer korrekt funktionierenden Seite eine hilfreiche Fehlermeldung kommt) die Startseite. Das soll Suchmaschinen und Crawler vom Aufruf der gelöschten Seite abhalten, ohne den Besucher mit Fehlermeldungen zu behelligen.

Die Senioren haben ihre Seite umgebaut, das Haus in Dresden findet man nicht mehr unter “Home - Vitalis Senioren-Zentren”, sondern unter dresden.vitalis-senioren.de

Hier übrigens als Beispiel für die Detektion durch Keepright eines der obengenannten Probleme mit einmal http zu viel: http://keepright.at/report_map.php?schema=4&error=27218941 Entdeckt von keepright (“The URL (http://http://www.schurk-markelsheim.de) cannot be opened (HTTP status code 504)”).

Gut, also? Weiteres Vorgehen? Ewig sollten wir mit einem möglichen Revert nicht warten – je eher desto problemloser. Spricht etwas dagegen? Andere Vorgehen? Ansonsten würde ich mich heute Abend vom aktuellsten zum ältesten Changeset per JOSM reverter durcharbeiten (nur Revertieren, keine Korrekturen).

Was mir eingefallen ist: der Fall mit “http://http://…” wäre evtl. auch eine passende Aufgabe für den Korrekturbot Wall·E.

IMHO sollte das erstmal revertet werden. Anschließend doppeltes Protokoll o.ä. von einem Bot korrigieren lassen. Alle anderen Fehler per Hand über KeepRight o.ä.

aseerel4c26,

nur zu, das Revert war ja von Anfang an Dein Wunsch, soll ja alles seine Ordnung haben. Dann sind die ganzen nicht funktionierenden URLs wieder drin. Wäre noch schön wenn die anderen Korrekturen die ich dabei gleich mit gemacht habe (sonst will JOSM nicht so gern hochladen) irgendwie nicht noch mal gemacht werden müssen.

Nachdem sich nun einige Erbsenzähler tatsächlich die Mühe gemacht haben die URLs durchzugucken, ob nicht doch welche dabei waren die man hätte retten können, wäre es nun ja auch gut die übrigen website-Tags anzugehen. Wie auch immer wir mit solchen Fällen umgehen - vielleicht sowas wie “fixme=website”, natürlich nur da wo noch kein Fixme steht. Aber das können wir ja erstmal hier diskutieren.

LG,

-moenk

Warum ein fixme Tag? Dafür gibt es Tools wie KeepRight. Und ansonsten behebt man es direkt.

Ja, die Sympathie empfinde ich ebenso. Es geht mir nicht um Ordnung (im übertriebenen Sinne), sondern um das bessere Ergebnis für unseren Datenbestand.

Die anderen Korrekturen beim Revert herauszufummeln halte ich für zu kompliziert und Fehleranfällig. Um es KISS zu halten übrigens auch das schrittweise Vorgehen: Revert, anschließend evtl. koordiniertes automatisches Verbessern und der Rest bleibt für keepright (wo das Problem ja schon bestens bearbeitbar ist).

Wenn du eine bessere Idee hast, dann lass sie uns wissen. Du kannst auch sehr gern selbst revertieren. Schade, dass du aber anscheinend immer noch nicht verstanden hast, dass deine Aktion kontraproduktiv war.

Achja, ich bitte, dass das Revertieren jemand anderes übernimmt. Das scheint mir ob der Uneinsichtigkeit von moenk und meiner Rolle als Quasi-Ankläger angebrachter.

done.

Gruss
walter

Danke Wambacher!

Verbesserungsvorschläge für’s nächste Mal:

  1. hier ankündigen, wenn du anfängst und dann anschließend einfach den Beitrag editieren und hinzufügen dass du fertig damit bist. Das vermeidet, dass jemand anderes zur gleichen Zeit damit auch anfängt.
  2. Im Änderungskommentar sollte nicht nur “dns-revert”, sondern auch diese Diskussion angegeben sein, damit jeder, der die Änderung sieht, sie nachvollziehen kann und weiß, dass diskutiert wurde.

Gut, was hätten wir für Fehler, die evtl. vollautomatisch durch einen Bot behebbar sind?

jeweils nur am Anfang des Value-Strings zu ersetzen:

Ob das Anfügen von “http://” im Falle der Schreibweise ohne Protokoll sinnvoll ist, bezweifle ich. Es dürfte sehr viele solcher Values ohne Protokoll geben und man könnte auch meinen, dass http:// implizit ist, wenn es nicht angegeben ist. Das ist wohl nichts für eine automatische Korrektur. keepright beispielsweise scheint http:// automatisch anzufügen (hier scheint es aber zusätzlich ein Problem für keepright – nicht für Firefox – mit der Umleitung zu geben).

Optimal wäre es natürlich, wenn die Korrektur nur dann gemacht würde, wenn die Website mit dem alten Value nicht erreichbar war, sie es aber mit dem korrigierten Value ist. Vielleicht aber auch eine unnötige Absicherung.

Bei automatischen Korrekturen sollte man natürlich immer bedenken, dass ein Fehler auf eine gewisse Schlampigkeit des Fehlerproduzierers hinweist und man manuell so vielleicht noch mehr Fehler in anderen Tags oder Edits finden könnte. Das ist Abwägungssache, die genauso bei der Adresskorrektur besetzt.

Ich habe Obi-Wan mal gefragt, ob er sich hier melden kann. Der Bot Wall·E kann aber evtl. nicht die Websites checken, könnte ich mir vorstellen.

war mehrere Stunden nix passiert und dann auch spät genug. Ein “Ich mach das jetzt”-Locking erschien mir nicht unbedingt notwendig. Ich kenne meine Pappenheimer schon - entweder passiert sowas sofort oder garnicht :wink:

jo, hattu recht.

Gruss
walter

Doch, sowas geht selbstverständlich - wenn man den Aufwand treiben will. Es gibt für nahezu jede Programmiersprache Libraries, die http(s)-Zugriff auf Programmebene ermöglichen. Ich hab nicht in OLI-WAN’s Code reingeschaut, kenne aber einige ältere Bots, die genau so arbeiten.

Gruss
walter

in Java sieht das z.B. dann so aus:


      String Url = "http://api.openstreetmap.org/api/0.6/changeset/"+id;

      DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
      Document doc;

      try {

         doc = db.parse(Url);  // get changeset
         String temp;

         NodeList ChangeSets = doc.getElementsByTagName("changeset");
         Node ChangeSet = ChangeSets.item(0); 
         Element ChangeSetElement = (Element) ChangeSet;
 
         // get details

         this.id                = id;
         this.user_name		= ChangeSetElement.getAttribute("user");
         this.uid		= Integer.parseInt(ChangeSetElement.getAttribute("uid"));
	 this.created_at	= ChangeSetElement.getAttribute("created_at");
	 this.closed_at		= ChangeSetElement.getAttribute("closed_at");
         ...

Vielleicht macht es auch Sinn, einen richtig üblen Regex bestehend aus Information vom RFC für URLs und einer Liste von TLDs der ICANN zu basteln.

vermisse ich da den Ironie-Flag oder verstehe ich dich einfach nicht?

Grübel Grübel
walter

Also wenn die Übersetzung lautet: “Vielleicht macht es auch Sinn, die vorhandenen website-Tags mittels eines Musterabgleichs gegen den Standard für URLs auf Gültigkeit zu überprüfen.” sehe ich keine Notwendigkeit für Ironie-Flags :wink:

Inhaltlich nicht zusammengehörende Datenänderungen (z.B. URL Änderungen und Neuerfassung von Daten) sollten auch in getrennten Changesets hochgeladen werden. Einerseits erleichtert dies im Notfall das Reverten und andererseits dient es auch der Nachvollziehbarkeit (sonst wird der Kommantar am Changeset auch so lang wenn man dort alle enthaltenen Änderungen aufzählt…).

Aha, also den URL auf formale Richtigkeit zu überprüfen - das kann man auch einfacher schreiben (wie du es ja auch gemacht hast):

Nö, zuviel Aufwand: es gibt in den APIs genug Funktionen, die Validität eines URLs zu überprüfen, da brauch ich nicht selber was zu konstruieren.

Soll sich aber derjenige mit rumschlagen, der sowas machen will - ich bin es jedenfalls nicht.

Gruß
walter

Ich meinte damit, dass ich mir denken kann, dass Wall·E zur Zeit noch keine solche Funktion hat.

ok, damit kann ich leben :wink:

Gruss
walter

Ich habe alle von moenk gelöschten und daraufhin von wambacher wiederhergestellten Löschungen in meiner Region überprüft.

Hier eine kleine Auswertung:

Insgesamt überprüft: 71
existieren oder ließen sich einfach korrigieren: 35
existieren nicht: 32
existieren, aber antworten nicht richtig: 4

D.h. etwa 50% (35 von 71) der Internetseiten waren erreichbar oder konnten von mir einfach verbessert werden (meist offensichtliche Fehler).

Viele Grüße,
whb

Ich hatte den Faden bereits verfolgt, hätte aber von mir aus keinen Fall für Wall·E daraus gemacht. Zuerst die Kurzfassung der Antwort: vorstellbar, aber auf kurze bis mittlere Sicht für mich kein Thema.

Zur Langfassung: Der eine oder andere wird bereits bemerkt haben, daß Wall·E im Moment eher auf Sparflamme läuft. Grund ist zum einen das Ende des Wikimedia Toolserver, der Wall·E zuvor eine Heimat geboten hatte. Da mir derzeit keine andere Hosting-Lösung zur Verfügung steht und ich zuhause auch gerade weder schnelles Internet noch einen geeigneten Rechner habe, führe ich die Tools nur sporadisch per ssh auf einem verwaisten Uni-Rechner aus (wo ich aber keine cronjobs einrichten kann). Zum anderen haben nach einem Jobwechsel mit weiterem Umzug im Moment andere Dinge außerhalb von OSM Vorrang (was auch der Grund für das fehlende schnelle Internet ist, denn man will ja nicht gleich in seinen ersten Wochen bloß wegen des Telefonmanns Urlaub nehmen). Von daher kann ich Ideen wie website=* mal vormerken, aber auf kurze Sicht werde ich mich nicht damit befassen.

Außerdem haben auch bei der Entwicklung von Wall·E andere Dinge Priorität: erstens, wenn sich irgendwann eine neue Hosting-Lösung auftut, ein flexibleres Scheduling; zweitens, nachdem sich kürzlich jemand an mich gewandt hat, der mit der Umbenennung einer “Strasse” nicht einverstanden war, eine automatische Sperrung von Objekten auf Basis des letzten Bearbeiters.

Aber wie ich bereits in den diversen Wall·E-Fäden immer mal wieder fallengelassen habe, wäre ich keineswegs unglücklich, wenn mir jemand eine solche Aufgabe “wegschnappen” und sich somit das Knowhow zu Reparaturbots in DE auf mehr Schultern verteilen würde. Gerade website=* halte ich für einen überschaubaren Fall, an dem man ausprobieren, lernen und sich allmählich das Vertrauen der anderen Mapper erarbeiten kann. aseerel4c26 hat ja schon einige Fälle skizziert, wo eine automatische Korrektur ggf. möglich wäre. Insbesondere würde auch ich ein komplett fehlendes http:// nicht anfügen wollen. Es gehört zwar eigentlich dort hin, aber jedes Programm, das website=* nutzt, sollte zu dieser Ergänzung imstande sein.

Die Frage ist allerdings noch, ob sich der Aufwand einer automatischen Korrektur wirklich lohnt. Ich überblicke nicht, wie viele kaputte website=* es (etwa in DE) gibt und welchen Anteil davon man tatsächlich sinnvoll automatisch reparieren und ob man die Mapper, die den Rest manuell korrigieren (wie es beispielsweise whb gerade vorgemacht hat), spürbar entlasten kann. Dumpfes Löschen ist sicher die schlechteste Lösung.

Sollte ich irgendwann eine derartige Korrektur implementieren, dann nur mit einer solchen Absicherung, um nicht flasch in aflsch zu ändern.

Richtig. Das würde ich ihm aber auch nicht beibringen, sondern auf Daten von keep right! zurückgreifen, und nur die Korrektur selbst (mit der obigen Absicherung und Hilfsfunktionen) implementieren. (Es ist mir zwar noch nie gelungen, Fehler von keep right! als Rohdaten zu beziehen, aber irgendwie soll das ja möglich sein.)