Das zweite Tool:
Mein
GeoCoderDa scheinen ja einige echt heiß drauf zu sein und damit jetzt hier nicht wild mit dem alten Müll geokodiert wird, habe ich mal eine aktuelle Fassung des verbesserten Tools erarbeitet.
Features:
- Nutzt die Google Maps API zum Geokodieren
- Unterstützt alle Länder, für die es auch Navikarten für Falk/Medion gibt...
- Interpretiert die Schreibweisen von Adressen für folgende Länder richtig: Deutschland, Österreich, Schweiz, Italien, Spanien, Frankreich, Großbritannien, Niederlande, Belgien (Gemeint ist die Schreibweise des Ergebnisses bei Google Maps, i.d.R. ist das die deutsche, also richtige, Schreibweise "Straße Hausnummer", Italien verwendet aber ein Komma zum Abtrennen - "Straße, Hausnummer" -, Frankreich das ganze dann auch noch verkehrt herum "Hausnummer, Straße" und Großbritannien nur verkehrt herum "Hausnummer Straße"), für noch nicht geprüfte Länder wird die gängigere, deutsche Variante angenommen.
- Erkennt Ort und Teilort, sofern von Google Maps zurückgemeldet, also z.B. nicht nur "Dresden", sondern "Dresden/Blasewitz".
- Führt einen vollständigen Abgleich zwischen gesuchter und tatsächlich gefundener Adresse mit nur minimaler Fuzzy-Logik durch, um Adressen vollautomatisch als Hausnummerngenau oder Straßengenau klassifizieren und in entsprechende, getrennte Listen speichern zu können.
- Funktioniert auch mit Quell-CSV, die keine PLZ enthalten (Nächsten Punkt beachten)
- Speichert für Adressen, die mittels automatischem Abgleich nicht verifiziert werden konnten, sowohl gesuchte als auch gefundene Adresse, letztere mit der angeblichen Genauigkeit, in zusätzliche Listen.
- Speichert für nicht gefundene Adressen die originale Adresse in eine weitere getrennte Liste.
- Als Eingangs- wie Ausgabeformat wird Extended EBA (Also die hier üblichen CSV mit den 14 für FN6/GoPal 3.x vorgesehenen Spalten, aufgestockt auf insgesamt 25 Spalten für zusätzliche Informationen) verwendet.
Benutzung:
- Wie üblich wird Perl benötigt, darauf gehe ich jetzt nicht nochmal ein.
- Man benötigt einen Lizenzschlüssel für die Google Maps API, diesen gibt es kostenlos bei Google Maps
- Der Google Map API Key muß in der Umgebungsvariable GOOGLE_MAP_API_KEY abgelegt sein. Dies kann erfolgen, indem in einem den Geokoder aufrufenden Batch die Anweisung
SET GOOGLE_MAP_API_KEY=<Dein Google Maps API Key>
eingetragen wird, oder o.g. Kommando vor dem Aufruf des Geokoders auf der Kommandozeile eingegeben wird, oder - bequemer - indem man den Key einfach dauerhaft als Umgebungsvariable anlegt.
Unter Windows geht das so:
Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen -> Neu (Entweder bei Benutzer oder systemweit, egal)
Name der Variablen: GOOGLE_MAP_API_KEY
Wert der Variablen: <Dein Google Maps API Key>
Achtung: Die neue Variable existiert danach noch nicht in vorher schon geöffneten Eingabeaufforderungen, man muß erst ein neues Kommandofenster aufmachen. - Wenn o.g. erledigt ist, erfolgt der Aufruf wie folgt:
GeoCodePro.pl <Pfad+Name der zu geokodierenden CSV-Datei>
z.B.
GeoCodePro.pl E-Lidl.csv - Nach erfolgreichem Durchlauf hat man im aktuellen Verzeichnis die folgenden CSV-Listen zusätzlich zur originalen:
<Originalname> Accurate.csv
<Originalname> Bad.csv
<Originalname> Check Accurate.csv
<Originalname> Check Road.csv
<Originalname> Road.csv
<Originalname> Wrong.csv
z.B.
E-Lidl Accurate.csv
E-Lidl Bad.csv
E-Lidl Check Accurate.csv
E-Lidl Check Road.csv
E-Lidl Road.csv
E-Lidl Wrong.csv
Erläuterung der verschiedenen Ausgabedateien:
XXX Accurate.csv:
Diese Liste enthält all jene Adressen aus der Eingangsliste, die mit an Sicherheit grenzender Wahrscheinlichkeit (Etwa 99,9999%) richtig hausnummerngenau geokodiert wurden.
D.h.:
1. PLZ und Ort stimmen überein. Einzig erlaubte Abweichungen sind Zahlendreher in der PLZ, also 52134 = 52143, aber nicht = 52133 und der Teilort muß nicht übereinstimmen (Sonst würden zu viele Ergebnisse verworfen, nur weil das Eingangs-CSV z.B. von "Dresden/Südliche Neustadt" und Google Maps von "Dresden/Südliche Vorstadt" spricht).
2. Der Straßenname stimmt zwischen original und Suchtreffer überein. Einzig erlaubte Abweichung: Der Vergleich wird ohne Bindestriche, Groß-/Kleinschreibung und Leerstellen durchgeführt. Damit ist Kurt-Schumacher-Damm = Kurt Schumacherdamm oder Münchenerstraße = Münchener Straße. Aber Münchener Straße wird nicht als identisch zu Münchener Str. anerkannt! D.h. je sauberer das Eingangs-CSV, desto weniger Nacharbeit in den Ergebnissen!
3. Die Hausnummern stimmen überein. Dabei werden Zusätze wie a,b,c - nicht berücksichtigt, also ist 6a = 6. Bei Hausnummerbereichen (7-11) im Quell-CSV gilt die erste (Google Maps kann keine Bereiche finden, sondern versucht eine der beiden Hausnummern zu finden, deshalb darf die gefundene Hausnummer auch um 2 höher oder niedriger sein).
Da die Maximalabweichung nur marginal ist, schlimmstenfalls:
53111,Bonn/Zentrum,Konrad Adenauer Allee,64 -> 53111,Bonn/Innenstadt,Konrad-Adenauer-Allee,62b
wird in der Ausgabedatei die Suchanfrage nicht mit gespeichert. Außerdem wird die gesuchte Hausnummer statt der gefundenen ins Ergebnis übernommen, damit z.B. Zusätze wie a,b,c oder Hausnummernbereiche nicht verloren gehen.
D.h. diese Ausgabedatei eignet sich direkt für die Konvertierung mittels POIConverter, oder, nach Entfernen der zusätzlichen Spalten, für die Erzeugung eines PSF.
XXX Road.csv:
Diese Liste enthält all jene Adressen aus der Eingangsliste, die mit an Sicherheit grenzender Wahrscheinlichkeit (Etwa 99,9999%) richtig straßengenau geokodiert wurden.
Die ÜBerprüfungen entsprechenen denen für hausnummerngenau gefundenen Adressen, lediglich der Hausnummernabgleich findet logischerweise nicht statt.
Die gesuchte Hausnummer wird ins Ergebnis übernommen, da das Ergebnis eh keine enthalten hat, um diese Informationen für spätere Wiederholungsversuche oder manuelle Plazierung erhalten bleiben.
D.h. auch diese Ausgabedatei eignet sich direkt für die Konvertierung mittels POIConverter, oder, nach Entfernen der zusätzlichen Spalten, für die Erzeugung eines PSF.
XXX Check Accurate.csv:
XXX Check Road.csv:
Diese Listen enthalten all jene Adressen aus der Eingangsliste, die laut Google hausnummerngenau bzw. straßengenau geokodiert wurden, für die Übereinstimmung mit der eigentlich gesuchten Adresse aber nicht automatisch bestätigt werden kann.
D.h.:
Mindestens einer der Tests, die für die Listen XXX Accurate.csv bzw. XXX Road.csv angegeben sind, ist fehlgeschlagen.
Dies kann bedeuten, daß lediglich
- ein gröberer Tippfehler gemacht wurde, wie z.B. daß die Münchener Straße in der Quell-CSV "Münchner Straße" geschrieben wurde oder bei der PLZ ist mehr als ein Zahlendreher drin, z.B. die Nachbartaste wurde gedrückt.
- die Eingangsadressen "unsauber" waren, z.B. "Roermonder Str." statt "Roermonder Straße"
es kann aber auch bedeuten, daß ein POI
- am
völlig falschen Ort gefunden wurde, z.B. in Stollberg im Erzgebirge statt in Stolberg im Rheinland, in Bergen auf Rügen statt Bergen an der Dumme, oder oder oder
- in die
falsche Straße gelegt wurde, z.B. in die Römerstraße statt den Römerplatz, die Beispielallee statt der Beispielstraße, usw. usf.
- beides
- bei vermeintlich hausnummerngenau geokodierten POI eine zu große Abweichung bei der Hausnummer, ggf. auch durch falsche Schreibweise eines Bereiches (7+9 oder 7/9 statt 7-11).
In der Ausgabedatei wird daher die original Suchanfrage gespeichert, gefolgt vom vollständigen Suchtreffer. Letzterem wird die Genauigkeit vorangestellt, Beispiel:
ESP;9800;Lidl;01012;Vitoria/Prox. Casco Viejo;Calle Domingo Beltrán 36-38;;;;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01012;Vitoria-Gasteiz;Calle de Domingo Beltrán de Otazu;36;-2.677105;42.852708;;0;;;;;;;;;;;;;;;
Dieses Ausgabe-CSV eignet sich nicht für die sofortige Verarbeitung zu einem PSF oder zum Erzeugen eines Google Earth/Maps Overlay, sondern es muß erst gesichtet und bearbeitet werden.
XXX Bad.csv:
Diese Liste enthält all jene Adressen aus der Eingangsliste, die schlechter als straßengenau geokodiert wurden.
Kommt in der Praxis eigentlich kaum vor, weil Google Maps eine solche Geokodierung nur in Ausnahmefällen vornimmt wenn man in der Anfrage auch eine Straße hat.
In der Ausgabedatei wird die original Suchanfrage gespeichert, gefolgt vom vervollständigten Suchtreffer. Letzterem wird die Genauigkeit vorangestellt. Vervollständigt heißt, daß alle Informationen, die im Suchergebnis nicht existieren können, weil die Genauigkeit zu gering ist, aus der Suchanfrage geholt werden.
XXX Wrong.csv:
Diese Liste enthält all jene Adressen aus der Eingangsliste, die gar nicht geokodiert wurden.
Da es kein Ergebnis gibt, sind diese Zeilen identisch mit denen aus der Eingangsdatei.
Wem das jetzt alles kompliziert vorkommt, ist es nicht:
1. Die Originaleinträge in den Listen Check, Bad und Wrong sind immer ggü. dem Original unverändert, wie der Name schon sagt.
2. Ist die Übereinstimmung von Suche und Ergebnis verifiziert, gibt es auch keinen Originaleintrag.
3. Bei den Ergebniseinträgen stammen all jene Werte aus dem Ergebnis, die im Ergebnis auch vorhanden sind.
Sie werden um die Bestandteile des Sucheintrags vervollständigt, die der Genauigkeit des Ergebnisses entsprechend garnicht aus diesem stammen
können, z.B. bei einer straßengenauen Geokodierung die Hausnummer, bei einer PLZ-genauen Straße und Hausnummer, bei einer ortsgenauen PLZ, Straße und Hausnummer und bei allem darunter (Kreis, Land, Staat) PLZ, Ort, Straße und Hausnummer.
4. Ausnahme zu 3. ist die Hausnummer bei bestätigter hausnummerngenauer Geokodierung, denn dann wurde sie ja bereits als nahezu identisch verifiziert. In diesem Fall hat die Bewahrung der Zusatzinformationen über Nummernbereiche bzw. Anhängsel wie a,b,c Vorrang davor, das Ergebnis meines Programms nochmals zu prüfen.
Wie man mit den (nicht direkt verwendbaren) Listen arbeitet:
Man öffnet diese in einem
Texteditor (Notepad, Notepad2, Notepad+) und sichtet Zeilenpaar für Zeilenpaar, z.B.:
ESP;9800;Lidl;01012;Vitoria/Prox. Casco Viejo;Calle Domingo Beltrán 36-38;;;;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01012;Vitoria-Gasteiz;Calle de Domingo Beltrán de Otazu;36;-2.677105;42.852708;;0;;;;;;;;;;;;;;;
ESP;9800;Lidl;01007;Vitoria/Armentia;Alto de Armentia U.A. 1;;;;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01007;Vitoria-Gasteiz;Alto de Armentia;1;-2.697406;42.837520;;0;;;;;;;;;;;;;;;
In diesen beiden Beispielen sieht man als Mensch recht schnell, daß die Ergebnisse tatsächlich mit der Suchanfrage übereinstimmen.
Also ergänzt man die Ergebnisse noch um ggf. zu rettenden Informationen, wie Hausnummernbereiche oder Ortsteile:
ESP;9800;Lidl;01012;Vitoria/Prox. Casco Viejo;Calle Domingo Beltrán 36-38;;;;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01012;Vitoria-Gasteiz/Prox. Casco Viejo;Calle de Domingo Beltrán de Otazu;36-38;-2.677105;42.852708;;0;;;;;;;;;;;;;;;
ESP;9800;Lidl;01007;Vitoria/Armentia;Alto de Armentia U.A. 1;;;;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01007;Vitoria-Gasteiz/Armentia;Alto de Armentia;1;-2.697406;42.837520;;0;;;;;;;;;;;;;;;
löscht dann die Originalzeilen:
8 - ESP;9800;Lidl;01012;Vitoria-Gasteiz/Prox. Casco Viejo;Calle de Domingo Beltrán de Otazu;36-38;-2.677105;42.852708;;0;;;;;;;;;;;;;;;
8 - ESP;9800;Lidl;01007;Vitoria-Gasteiz/Armentia;Alto de Armentia;1;-2.697406;42.837520;;0;;;;;;;;;;;;;;;
entfernt die Angaben zur Genauigkeit
ESP;9800;Lidl;01012;Vitoria-Gasteiz/Prox. Casco Viejo;Calle de Domingo Beltrán de Otazu;36-38;-2.677105;42.852708;;0;;;;;;;;;;;;;;;
ESP;9800;Lidl;01007;Vitoria-Gasteiz/Armentia;Alto de Armentia;1;-2.697406;42.837520;;0;;;;;;;;;;;;;;;
und verschiebt die Zeilen in die entsprechende Liste der bestätigten Adressen (in diesem Fall die hausnummerngenauen), indem man sie in der einen Textdatei ausschneidet und in der anderen einfügt.
Ich empfehle, erst einige Adressen zu kontrollieren und dann einen ganzen Block zu verschubsen, um sich nicht dumm und dusselig zu cut'n'pasten.
Man wird aber auch auf solche Ergebnisse stoßen:
DEU;9800;Lidl;06571;Roßleben;Friedensstraße;7;;;;0;;;;;;;;;;;;;;;
8 - DEU;9800;Lidl;06268;Querfurt/Ziegelroda;Friedensstraße;7;11.463515;51.332772;;0;;;;;;;;;;;;;;;
Hier sieht man auch sofort, daß das Ergebnis wirklich nicht stimmen kann, weder PLZ noch Ort stimmen auch nur annähernd.
Dann löscht man entsprechend das Ergebnis:
DEU;9800;Lidl;06571;Roßleben;Friedensstraße;7;;;;0;;;;;;;;;;;;;;;
und verschiebt die Originalzeile in die Datei mit den falschen Ergebnissen (XXX Wrong.csv).
Wenn man damit fertig ist, hat man hoffentlich die meisten Suchanfragen in XXX Accurate.csv und in XXX Road.csv
Je nachdem, wie wichtig die POI sind, kann man jetzt diese sofort nutzen, um ein PSF zu erzeugen, oder man macht sich an die Einträge in Bad und Wrong.
Diese beiden sind in diesem Stadium eigentlich gleich zu behandeln. I.d.R. liegt - in zivilisiertem Gebiet - ein Fehler oder eine Ungenauigkeit in der Schreibweise der Adressen vor oder wir haben eine Kreuzung bzw. ein Gebäude als Adresse.
Beispiele für ersteres:
C.-Goerdeler-Straße -> Carl-Goerdeler-Straße
Prof.-F.-Porsche-Ring -> Professor-Ferdinand-Porsche-Ring
Bonnhoefferstraße -> Bonhoefferstraße
St. Augustin -> Sankt Augustin
Beispiele für zweiteres:
EKZ Neuer Markt -> Neuer Markt (Das "EKZ" ggf. in einem freien Feld des CSV zwischenspeichern)
Hauptstr./Bachstr. 1 -> Bachstraße 1 (Die "Hauptstraße ggf. in einem freien Feld des CSV zwischenspeichern)
Manchmal sind auch längst nicht mehr existente Dörfer als Ort angegeben, so daß man den Ortsnamen durch den korrekten Ort ersetzen muß.
Beispiel:
52134;Streiffeld -> 52134;Herzogernrath/Merkstein
Zumindest in Frankreich kann man Google das Leben auch wesentlich erleichtern, indem man das überflüssige Gekrüschel aus Orts- und Straßennamen entfernt:
Níçè; Rúè dê lá çòndòm -> Nice,Rue de la condom
oder indem man Ortsnamen durch die Schreibweise der Besatzer
ersetzt:
Straßburg -> Strasbourg
Hat man die Listen so überarbeitet, kann man sie nochmal durch den Geokoder jagen.
Aber Achtung: Entweder ihr geokodiert direkt die XXX Bad.csv bzw. XXX Wrong.csv, damit die Dateinamen der Ergebnislisten lauten
XXX Bad Check Accurate.csv
XXX Bad Accurate.csv
XXX Bad Check Road.csv
XXX Bad Road.csv
XXX Bad Bad.csv
XXX Bad Wrong.csv
oder ihr sichert Euch die schon vorhandenen Ergebnisse, denn der Geokoder überschreibt existierende Dateien beim Abspeichern gnadenlos!
Würdet Ihr also eine Liste E-Lidl.csv geokodieren, danach die E-Lidl Wrong.csv nachbearbeiten, diese in E-Lidl.csv umbenennen und erneut geokodieren, dann überschreibt der Geokoder am Ende die Ergebnisse des ersten Durchlaufes!
Etwas Hintergrund, muß man nicht unbedingt lesen, dient nur dem Verständnis:
Zur Motiviation dieser Vorgehensweise:
Manche werden sich fragen, warum das so umständlich sein muß, wo doch die ersten Geokoder direkt nur fertige Listen ausgespuckt haben und manche kommerzielle das auch tun.
Berechtigte Frage. Dennoch ist auch diese Vorgehensweise berechtigt.
Wer schon länger dabei ist, wird sich erinnern können, daß beim Apothekenoverlay zuerst Apotheken aus Meckenheim (Pfalz) auf einen Acker zwischen Meckenheim (Rheinland) und Rheinbach geokodiert wurden. Das ist ein Problem, das durchaus mehrfach auftritt, umso stärker, je unbedeutender der tatsächlich gesuchte Ort ist.
Zur Abhilfe habe ich den Geokoder so verändert, daß er die PLZ von Suche und Ergebnis abgeglichen hat. Das funktioniert aber nur, wenn man in der Suche überhaupt eine PLZ hat und diese auch richtig ist.
Im Gegenzug gab es dementsprechend oft POI, die als falsch deklassiert wurden, weil es z.B. Zahlendreher in der PLZ gab.
Deshalb habe ich dann einen Geokoder geschrieben, der grundsätzlich Suche und Ergebnis zusammen abgespeichert hat, so daß der Benutzer Pärchen für Pärchen vergleichen mußte.
Zuerst habe ich diesen nur für die POI benutzt, die der Geokoder mit PLZ-Abgleich als Falsch klassifiziert hat.
Es stellte sich dann aber heraus, daß Google Maps auch bei den Straßennamen sehr "tolerant" sein kann und auch schonmal aus einem Platz eine Straße macht oder aus einem Weg eine Allee oder oder oder.
Außerdem war es - bei aller Arbeit für's Ausmisten - sehr angenehm, sauber geschriebene Adressen zurückzuerhalten, wenn man den Geocoder mit Gegenkontrolle verwendete.
Seitdem ist der Geocoder mit Gegenkontrolle bei mir der Standard, da man sicher sein kann, nur richtige Ergebnisse zu erhalten (Es sei denn, es sind Kartendigitalisierungsfehler in Google Maps, dagegen kann man aber nichts tun, außer Sichtkodieren) und diese auch richtig geschrieben sind.
Mein Gedanke war es nun, wie man sich die Arbeit wenigstens etwas erleichtern kann. Ein Vergleich von Suche und Ergebnis mit Fuzzy Logik kam nicht in Frage, da diese ja bei der Suche erst zu den Fehlern führt.
Ein 1:1-Vergleich von Suche und Ergebnis wiederum hätte nahezu gar kein Ergebnis als korrekt akzeptiert.
Daher die Entscheidung, bei Straßennamen nur Abweichungen bei den Füllzeichen (Bindestriche, Leerstellen) und der Groß- und Kleinschreibung zuzulassen, ansonsten müssen diese aber Buchstabe für Buchstabe übereinstimmen.
Entsprechend wird eine Übereinstimmung des Ortes, aber nicht des Teilortes verlangt. PLZ+Ort+Straße ergeben eine eindeutige Zuordnung, wohingegen über Teilorte meist keine Einigkeit besteht. Ureinwohner benutzen gerne noch Teilorte, die es seit der Völkerschlacht bei Leipzig eigentlich nicht mehr gibt, z.B. Teilorte des Ortes, der inzwischen längst selber ein Teilort eines anderen Ortes geworden ist. Ein Beispiel ist o.g. Streiffeld, welches zuletzt zu napoleonischer Zeit ein Teilort des Ortes Merkstein war, welcher aber inzwischen selber in Herzogenrath aufgegangen ist. Die Deutsche Post AG ist zwar in der Lage, nach Merkstein/Streiffeld adressierten Kram zuzustellen, amtlich ist aber Herzogenrath ausreichend, höchstens noch Herzogenrath/Merkstein und die Zustellung funktioniert bei Fehladressierungen nur, weil die PLZ stimmt.
Außerdem heißt es mal Zentrum, mal Innenstadt.
Damit ist es nun möglich, einen Großteil der Ergebnisse direkt als richtig zu bestätigen, sofern das Quell-CSV fehlerfrei geschrieben ist, bei gleichzeitiger Möglichkeit, größere Abweichungen weiterhin manuell als korrekt zu klassifizieren.
Es fehlen somit nur noch zwei Tools, um mit dem geringstmöglichen Aufwand präzise Geokodierungen durchzuführen und dennoch für möglichst viele POI überhaupt eine Geopositionierung zu erzielen (Um diese dann manuell zu korrigieren):
- Ein CSV-Cleanup. Dieses wird alle Einträge eines CSV durchgehen und die Adressen ins "Normformat" bringen, also ausgeschriebene Straßennamen, korrekt abgetrennte Teilorte (Durch / und nicht durch -, der Bindestrich verbindet nämlich Wortbestandteile und Orte einer Samtgemeinde (Lüchow-Dannenberg, Übach-Palenberg, usw.), usw.
Damit sind dann mehr Adressen automatisch verifizierbar.
- Ein Geokodiertool, das es von vornherein nur auf PLZ-/Ortsgenaue Geokodierung anlegt. Dies dient dann dazu, überhaupt eine Ortsmarke zu haben wenn eine Geokodierung mit Straße nur Mist ergibt oder garnicht gelingt, denn ohne eine solche läßt sich ein POI nicht Google Earth sichten und verschieben.
Legende:
Die Genauigkeiten von Google Maps werden numerisch entsprechend folgender Liste ausgedrückt (In Klammern, wie ich diese Genauigkeit nenne):
0 (Falsch/Wrong) Unknown location. (Since 2.59)
1 (Staat/Bad) Country level accuracy. (Since 2.59)
2 (Land/Bad) Region (state, province, prefecture, etc.) level accuracy. (Since 2.59)
3 (Kreis o.ä./Bad) Sub-region (county, municipality, etc.) level accuracy. (Since 2.59)
4 (Stadt/Bad) Town (city, village) level accuracy. (Since 2.59)
5 (PLZ/Bad) Post code (zip code) level accuracy. (Since 2.59)
6 (Straße/Road) Street level accuracy. (Since 2.59)
7 (Kreuzung/Accurate) Intersection level accuracy. (Since 2.59)
8 (Hausnummer/Accurate) Address level accuracy. (Since 2.59)
9 (Gebäude/Accurate) Premise (building name, property name, shopping center, etc.) level accuracy. (Since 2.105)
Diese Zahl findet Ihr in den zu prüfenden Ausgabedateien, wenn ich davon spreche, daß die Genauigkeit eingefügt habe. Die Genauigkeit kann auch um 10 höher sein, dann hat Google Maps mehr als einen Treffer gefunden (In dem Fall kann es sich lohnen, die Suche von Hand durchzuführen und sich die alternativen Treffer anzusehen).
Versionshistorie:2008-05-11 - Erste Version
2008-05-12 - Verbesserter automatischer Abgleich (Suche <-> Ergebnis) italienischer Adressen: Gefundene Orte können alternativ zur PLZ auch über die Unterverwaltungseinheit als identisch mit dem gesuchten verifiziert werden.
2008-05-12 - Fehler korrigiert: Die PLZ wurde immer als identisch gewertet
Anmelden
Registrieren
FAQ
Downloads
Mitgliederkarte
Suche
