NaviJoy

Spitzen-Tool und Klasse Anleitung, SpaceRat. Nach anfänglichen Formatierungsproblemen und einem kurzen Abgleich mit Deinem HowTo (war halt das 1. Mal für mich ) hat's dann hervorragend geklappt. Tolle Arbeit.

In dem Zusammenhang: Wenn Ihr POI in anderen Länder als den namentlich erwähnten geokodieren wollt, schickt mir doch mal ein paar Beispieleinträge, besonders solche, bei denen Ihr wißt, daß sie sich hausnummerngenau geokodieren lassen.

Ich brauche das in vielerlei Hinsicht:

1. um zu überprüfen, ob die Hausnummer auch durch mein Script von Google Maps ausgelesen werden kann
2. um nationale Besonderheiten berücksichtigen zu können. Z.B. meldet Google Maps die Buchstabenfolge bei NL Adressen nicht mit zurück. Beim Abgleich, ob die gesuchte PLZ gleich der gefundenen ist, nutze ich daher bei NL Adressen nur die Ziffern, nicht die Buchstaben.
3. um das Cleanup-Script soweit erweitern zu können, daß ich die gesuchten Adressen "normieren" kann, damit möglichst wenige Ergebnisse nachbearbeitet werden müssen.

Was mein Script derzeit noch nicht "weiß" ist, daß in Italien die Unterverwaltungseinheit dem Ort in Klammern beigefügt werden kann. Google Maps meldet die Orte ohne diese Angabe zurück, in einem extra Feld ist sie aber enthalten. Im geokodierten CSV sollte sie auch nicht drin sein, da die Orte in den Navikarten ohne diese gespeichert sind, sie würden also die Suche an einem bestimmten Ort unmöglich machen. Deshalb werde ich das wohl nicht in das CleanUp-Tool nehmen, sondern in den Abgleich im Script, insbesondere wenn es in den Quellen keine PLZ gibt.

mir ist aufgefallen, das bei dem geocode-script meistens ein Schwung Adressen geocodiert wird und danach meist ein Block von 10-20 failed Adressen kommt.

Also hab ich in das das Script mal mit meinem laienhaften Wissen ein sleep(1) an den Anfang der Geocode-Subroutine gemacht (bedeutet nach jeder geocodierten Adresse wartet das script eine Sekunde bevor die nächste geocodiert wird). Klar das das Script nun wesentlich langsamer läuft, allerdings ist die Fehlerrate der geocodierten Adressen nun auch wesentlich geringer, sprich man braucht nicht mehr so viele Durchläufe um das Maximum an Geocodierungen zu erhalten.
Viele Fehler resultieren jedenfalls nicht aus falschen Adressangaben sondern weil Google nicht oder nicht rechtzeitig antwortet.

Vielleicht könnte man das Script auch dahin gehend optimieren das bei failed Adressen noch 2-3 mal versucht wird diese failed zu geocodieren bevor sie dann wirklich als failed markiert werden. Wäre natürlich eleganter als stumpf nach jeder Adresse eine Sekunde zu warten, aber dafür fehlen mir die Programmierkenntnisse.

Richtig. Das GeoCode-Script ist, was die programmiertechnische Sauberkeit angeht, eine Beleidigung für's Auge.
Aber: Wo fängt man an und wo hört man auf?
Ich habe übrigens festgestellt, daß die hier gepostete Fassung nach meinem Wechsel von Congster zu T-Online Adressen teilweise in auswärts (ausländisch) zurückliefert, z.B. Amburgo statt Hamburg.
Das ist besonders lustig, weil Congster auch nur eine T-Com-Tochter ist. Außerdem klappt das Abtrennen der Hausnummern nach wie vor nicht 100%ig.


Ist aber relativ viel Gefummel, weil ich den Fehler erst provozieren muß, um zu sehen, was ich in dem Fall zurückbekomme.
Die Frage ist auch, ob es sich lohnt. Man erhält ja keine falschen Ergebnisse, nur eben gar keines. Da in fast jeder Liste auch immer wieder Schwachsinnsadressen sind, die man nacharbeiten muß, kommt man um mehrere Durchläufe sowieso selten rum.

eben - du erhältst gar kein Ergebnis. Könnte man für eine Geocode-Anfrage im Script die kein Ergebnis liefert, nicht nochmal die gleiche Geocode-Subroutine durchlaufen lassen, mit einem Zähler versehen das spätestens nach 3-4 ohne Resultat aufgegeben wird ? Nur so als Idee... (ich hab übrigens auch mal programmieren gelernt, allerdings schon ca 100 Jahre her, Cobol und ähnliches ).
Aber ok, wenns zu kompliziert wird, notfalls gehts ja auch ganz gut mit der Sekunde Wartezeit wenn man nicht gerade 50000 POI's zum geocodieren haben. Bei knapp 1000 ist die Wartezeit jedenfalls erträglich und man hat hinterher deutlich weniger Arbeit.

Ja, könnte man. Es gibt aber auch kein Ergebnis, wenn der Input Mist war.
GIGO nennt man das - Garbage In - Garbage Out.


Ich werde mal sehen, was sich machen läßt. Allerdings kann ich das mit der Mehrarbeit so nicht bestätigen. Adressen ohne Ergebnis werden ja ganz normal in einer Datei mit den Adressen, die falsche Ergebnisse geliefert haben, gespeichert.
Über diese Datei schaue ich grob drüber, ob mir Müllangaben in den Feldern auffallen und dann jage ich sie neu durch.
Die Wahrscheinlichkeit ist gering, daß ein und dieselbe Adresse nicht in irgendeinem Durchlauf mit geokodiert wird, ist äußerst gering.
Ich kann auch Deine Angaben zur Häufigkeit nicht nachvollziehen. Ich habe auf 7000 Adressen vielleicht 5-6, die "einfach so" nicht geokodiert wurden. Da ich dabei aber über Tausend mit fehlerhaften Orts-/Straßenangaben hatte, die nachgearbeitet werden mussten, wurden diese 5-6 eigentlich intakten halt im 2. oder 3. Durchlauf mitgenommen.

Eine Sekunde Verzögerung je Abfrage hätte den 1. Durchlauf hingegen um fast 2h verlängert...
Das ist also keine Lösung.

dann schau dir mal die Dateianhänge an - es ist jeweils enthalten die Original-CSV (Test1 bzw. Test2) sowie das jeweilige Script ohne und mit Pause und das Ergebnis nach Ausführung dessen, alle Resultate von heute abend. Beispiel-Daten waren die ca 800 COOP's aus Italien. Den Unterschied zwischen den Wrongs bzw. Check Accurate finde ich doch signifikant.
Was seltsam ist, dass man inzwischen überhaupt keine Accurate mehr bekommt, als ich die COOP-Daten letztes Jahr im Mai/Juni mit dem gleichen Script (ohne Pause) durchgejagt habe, gab es noch welche die 100% Accurate waren. Aber da hat sich vermutlich auf Google-Seite etwas geändert...

Kann ich so nicht nachvollziehen.


In Zahlen:
856 Zeilen total

Ohne Pause (Bei Dir):
Accurate: 0
Road: 0
Check Accurate: 317
Check Road: 258
Wrong: 281
Bad: 0

Mit Pause:
Accurate: 0
Road: 0
Check Accurate: 385
Check Road: 326
Wrong: 145
Bad: 0

Also 136 weniger Wrong, die sich dann auf Accurate und Road verteilen...

Aber hier mal zum Vergleich mein neuer Geocoder:

GeoCoder2:
Accurate: 110
Road: 121
Check Accurate: 274
Check Road: 202
Wrong: 149
Bad: 0


Du hast es erfaßt. Man kriegt die adminarea nicht mehr in einem separaten Feld mitgeteilt. Ich habe den Parser jetzt so geändert, daß er sie aus der Adresse zieht.

Noch ein Ergebnis des neuen GeoCoders:

3208 Adressen, die mit dem alten GeoCoder alle in einer "Check Accurate" waren mit dem neuen GeoCoder kodiert:

1907 Accurate
1186 Check Accurate
2 Road
0 Check Road
8 Bad
105 Wrong

D.h. aus 3208 zu sichtenden POI wurden "nur" noch 1299, d.h. 60% weniger Arbeit!

na das klingt doch schon alles sehr vielversprechend - war die letzten Tage leider mit ganz anderen Dingen beschäftigt als mir deine Programmierkunst zu Gemüte zu führen. Wird aber ab morgen gleich mal alles ausprobiert....