Address Review Plugin

[wisydb]

Hintergrund: Ich habe die Geocodierung umgebaut, dass sie 1. effizienter funktioniert (keine doppelten Geodcodierungsversuche); 2. "bessere" Adressen (Adresszusätze z.T. weg); 3. Mehr Adressen geocodierbar mit neuem, externen Dienst => erstmals seit langer Zeit vollständig geocodierter Adressbestand, aber natürlich nur die Adressen, die geocodierbar sind; 4. Mehr Error-Feedback.

Änderungen: Bessere Mapquest-Integration und mehr Adressen: https://github.com/wisydb/wisy/commit/88b70c5db7bcbe60a640ab9cf2b7930672573ace https://github.com/wisydb/wisy/commit/6769d47bd35246e2ff81f6f7d65cdedc5c29d661

Adress-Review-Plugin: https://github.com/wisydb/wisy/commit/70986341bfa3f1f773be0ad775a852a590fc0b66

Verbesserungsnotwendigkeit: 1.) Z.Z. läuft die Geocodierung sämtlicher Adressen auf dem Server über den HH-Account. Lediglich das Frontend greift für manuelle Anfragen durch nutzer in der Suchmaske auf die in den jeweiligen Portaleinstellungen hinterlegten Mapquesst-Accounts zu. Darum wären die Einstellungen zum Mapquest-Account a) in die Benutzergruppen-Einstellungen zu überführen, b) das Frontend müsste ermitteln, zu welcher Benutzergruppe ein Portal gehört und auf die Geoc.-Einstellungen dieser Benutzergruppe zugreifen (statt Portaleinstellung), c) in der zentralen Adress-Geocodierung (Sync-Renderer) müsste vor Geocodierung der jeweiligen Adresse ermittelt werden, welcher Benutzergruppe der Angebots-Datensatz dieser Adresse zugeordnet wurde und dann dieser Mapquest-Account verwendet werden. Ziel: eine tägliche / häufigere Geocodierung des Gesamtbestands ermöglichen (rund 5.000), dadurch, dass die kostenfreien Limits aller beteiligten verwendet werden (je 15.000/Monat). d) Anpassung des Geocodierungs-Caches entsprechend der Geocodierungsabstände.

2. ) Z.Z. wird eine Protokoll-Datei(!) erstellt, die später das erwähnte Review-Plugin im Redaktionssystem füttert zur manuellen. Die Ergebnisse der Geocodierung und insbesondere die Probleme mit den jeweiligen Adressen sollten lieber / zusätzlich in eine eigene Tabelle in der DB geschrieben werden. 3.) Wenn die problematischen Adressen in der Datenbank sind kann man eine echte Editierumgebung (wie die Feedback-Funktion usw.) schaffen, um die Adressen sinnvoller / strukturierter durchsuchen und darstellen zu können. 4.) Ideal wäre: falls eine Problematische Adresse editiert wird, sucht ein nächtlicher Cronjob nach editierten Adressen und spielt diese (in der Funktion analog zur Ortskorrektur) in alle Angebote aus, die diese Adresse enthalten, evtl. Benutzergruppen-bezogen

[debagel]

Ich fasse mal kurz zusammen was ich hier als Aufgaben sehe (und lasse weg was in #32) schon enthalten ist:

1. Geocoding-Fehler sammeln, anzeigen und bearbeiten:

• Neue Tabelle anlegen und Geocoding-Fehler darin sammeln statt wie bisher in Datei
• Neue Maske im Redaktionssystem anlegen die die Fehler aus obiger Tabelle auflistet
• Dabei u.a. automatische Verlinkung der fehlerhaften Adressen zu Google-Suche einbauen als Hilfestellung für Redaktion
• Felder zur Eingabe korrigierter Adressen bereitstellen

2. Adress-Korrekturen automatisch anwenden:

• Redaktionell korrigierte Adressen werden automatisch in alle betroffenen Durchführungen übernommen.
• Einerseits könnte direkt nach der Eingabe der Korrektur die mit diesem Fehler verknüpfte Durchführung korrigiert werden.
• Entweder / oder könnten nachts per Cronjob alle Vorkommnisse der fehlerhaften Adresse in Durchführungen korrigiert werden.