OSM-Geocoding mit Solr
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 71 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/14839 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
5
6
7
9
10
11
13
14
15
21
23
25
30
31
32
34
38
39
43
44
45
48
49
50
51
53
54
58
63
66
70
71
00:00
Stack (abstract data type)StreckeBerechnungiPhoneRun-time systemDatabaseRouter (computing)InformationCommodore VIC-20MAPPERSlide ruleRoutingAndroid (robot)IP addressCoordinate systemComputer animationLecture/Conference
04:06
BerechnungLecture/Conference
04:48
WordNumber theoryXMLComputer animation
05:46
Lecture/Conference
06:09
VorverarbeitungPositionLaptopContext awarenessInformationProcess (computing)Server (computing)Set (mathematics)BerechnungMobile WebXMLComputer animation
07:52
IP addressLösung <Mathematik>PositionOpen sourceServer (computing)Lecture/Conference
09:47
Open sourceLevel (video gaming)Web browserXMLUML
10:15
Web browserXMLProgram flowchart
10:49
Server (computing)WebsiteProxy serverComputer networkWind waveIP addressInternetTypHypermediaValue-added networkSuperLearnDataflowUniform resource nameComputer wormMoving averageSupercomputerLeadWorld Wide WebSupremumComputer animationLecture/Conference
12:33
DatabaseJSONXMLUML
13:10
Software developerPlug-in (computing)Lecture/Conference
13:37
DatabaseTypAPITechnical failurePlug-in (computing)Physical quantityWeb pageDrosselungFunktionalitätStructural loadDatabaseXMLComputer animation
15:23
APIInformationIP addressoutputLecture/ConferenceComputer animation
16:21
Mathematical structurePHON <Programm>GoogleIP addressLösung <Mathematik>Office <Programm>Web serviceData typeStandard deviationVersion <Informatik>Server (computing)Eigenvalues and eigenvectorsInflection pointLecture/Conference
20:57
Computer animation
Transcript: German(auto-generated)
00:07
Vielen Dank. Der Titel hat sich leider etwas verändert. Das hat damit zu tun, dass wir in der Zeit den Stack etwas geändert haben. Das Prinzip bleibt aber das Gleiche. Mein Name ist Christoph Link. Ich bin von Komod. Wir sind ein Berliner bzw. Potsdamer Startup.
00:25
Und thematisch gesehen schließe ich mich auch ein bisschen an den Vorredner an. Wir machen auch Fahrradrouting. Aber mein Talk wird es darum gehen, die OSM-Daten, die es so zahlreich gibt, durchsuchbar zu machen.
00:40
Zuallererst wollte ich noch kurz mal auf Komod eingehen. Das sind kurze Slides mit ein paar Screenshots. Was wir eben auch machen, ist Routing. Einerseits Fahrradrouting, aber auch spezielle für Mountainbike, für Wanderer oder auch für Rennradfahrer. Wenn jemand weiß, wo er hin möchte, von wo er aus starten möchte, von wo er hin möchte, kann er das bei uns planen.
01:01
Und er bekommt viele Informationen gezeigt, unter anderem wie lange es dauert, welche Untergründe er zu erwarten hat, ob es Asphalt ist, ob es Kiesel ist oder vielleicht ein Feldweg. Wir berechnen auch die Schwierigkeit, also wie technisch versiert man sein muss, wie sportlich man sein muss, um eine gewisse Strecke zu fahren.
01:20
Wir binden Fotos von Wikipedia, aber auch Panoramien ein. Und wenn jemand genau hinsieht, dann wird er hier auch eine OSM-Karte identifizieren können. Und auch die ganzen Daten, die wir extraieren, kommen großteils aus OpenStreetMap. Sie sind also da sehr stark auf OpenStreetMap angewiesen. Wir bieten auch für alle diejenigen, die nicht wissen, wo sie genau hinfahren möchten, die Möglichkeit an Orte zu entdecken,
01:46
wo sie ihren Ausflug hin planen möchten und geben dort Inspiration und auch zusätzliche Informationen. Wenn man mal auf dem Weg ist, bekommt man auch Unterstützung. Man kann das Handy gemütlich in die Hosentasche tun und sich den Stöpsel ins Ohr reinstecken und mit dem Fahrrad den geplanten Weg entlangfahren.
02:07
Und wir sagen dann zur richtigen Zeit an, ob man rechts, links, geradeaus den Weg folgen sollte. Zu guter Letzt, das kann man alles, seine Erlebnisse aufzeichnen per GPS und die dann mit seinem Profil abspeichern
02:20
und in unserer Outdoor-Community teilen und sich gegenseitig inspirieren lassen. Das war es auch soweit von Komode. Jetzt kommen wir zum eigentlichen Thema und das ist Geocoding mit OpenStreetMap-Data. Erstmal die Frage, wieso ist das Thema eigentlich wichtig für uns? Und ich habe mir so eine kleine Übersicht zusammengebastelt, dass meine Sicht der Dinge irgendwie widerspiegelt.
02:46
Wir haben auf der einen Seite ganz links die Mapper. Ich glaube, einige fühlen sich hier angesprochen. Und was wir tun, ist wir sammeln Daten ein und pflegen sie in eine große Datenbank ein, die dort als OpenData frei zur Verfügung steht.
03:00
Und für mich die zwei grundlegendsten Verwertungen, das ist einerseits eine Karte, andererseits ist Geocoding, also klar Karte, das ist ein Ausdruck auf dem Android oder iPhone, mit der ich mich orientieren kann, wo ich sehen kann, was in meiner Umgebung alles zu finden ist. Auf der anderen Seite stellen sich sehr häufig die Frage, wenn man eine Adresse hat
03:23
oder man hat eine Idee, wo man hinfahren möchte, beispielsweise die Mökelsee in Berlin, weiß aber nicht genau, wo das ist und dann versucht man das textlich zu suchen. Also und das ist eigentlich auch Geocoding, man gibt den Ort ein, für den man sich interessiert.
03:41
Das ist ein einheitliches Formular und was man zurückbekommt, ist eine Koordinat oder ein Punkt, eine weitere, also die Verordnung eigentlich des zu suchenden Textes. Genau und dann davon profitieren also ganz rechts diese Consumer. Und hier die Frage, was einen guten Geocoder ausmacht,
04:03
und das gibt es natürlich schon für OpenStreetMap. Sehr bekannt und ein sehr altes Projekt ist Nominatim und es hat sehr guten Dienst geleistet und sehr viele, ja, also das ist keine einfache Sache, so viele Daten zu prozessieren,
04:21
das sind aufwändige Berechnungen und Nominatim macht das alles für uns möglich. Und wir profitieren davon, wir bauen darauf auf und setzen noch ein Lehrjahr drauf und wollen das noch ein Level verbessern und es userfreundlicher zu machen und nützlicher für die ganze OpenStreetMap-Community.
04:42
Ich möchte kurz darauf eingehen, was so Features sind, an die wir denken, an die wir glauben, dass sie wichtig sind, nicht nur für uns, sondern auch für die ganze OpenStreetMap-Bewegung. Das ist einerseits Type Ahead Search, das heißt, wie man es auch von Google Maps kennt, die sind ein sehr gutes Beispiel dort. Wenn man schon Text eingibt, dann sollte auch schon Ergebnisse kommen
05:02
und nicht erst dann, wenn der letzte Buchstabe des zu suchenden Wortes komplettiert ist, dass man dann noch auf Enter drückt, sondern dass das System an sich responsiver ist, dass man sofort eine Rückmeldung bekommt, wie hier in dem Beispiel. Wir sind leider Menschen, oder Gott sei Dank, und machen kleine Fehler.
05:22
Nichtsdestotrotz sollte das System verstehen, nach was wir suchen und diese Toleranz gegenüber Rechtschreibfehler ist auch sehr wichtig und das passiert uns sehr häufig und dummerweise, man sieht auch solche kleine Fehler nicht und dann kommt aber nichts zurück. Man weiß aber nicht wieso und denkt sich dann, dass die Suche nicht funktioniert
05:44
bzw. die Daten nicht komplett sind. Also diese Sensibilität für Rechtschreibfehler ist essentiell. Und dann brauchen wir auch ein System, das sehr schnell reagiert. Es geht nicht um Sekunden, es geht um Millisekunden, weil das die ganze User Experience fördert
06:01
und das Ganze sehr viel sinnvoller macht. Und es geht auch nicht darum, dass wir eins zu eins das finden, was der User genau eingetippt hat, sondern auch etwas reflektiert, zumindest in primitiver Weise interpretiert wird,
06:21
was der User eigentlich wollte. Also in englischsprachigen Ländern ist es üblich, road als rd abzukürzen und klar, dieses rd steht so in der Form nicht in OpenStreetMap drin, sollte dennoch gefunden werden. Und eine Suche steht immer im Kontext, gerade in der Situation, in der man sich befindet.
06:42
Und einer der wichtigsten Kontexte ist die aktuelle Position. Und aufgrund der zunehmenden Häufigkeit mobiler Nutzung haben wir auch sehr häufig diese Information. Beispielsweise wenn ich hier jetzt in der Beuthochschule Hauptbahnhof suche, weil ich vielleicht jetzt mit der U-Bahn dorthin fahren möchte,
07:02
dann bin ich jetzt nicht so stark daran interessiert, den Hauptbahnhof in Hamburg zu finden oder Potsdam, sondern der hier in Berlin. Also den Bias gegenüber Ergebnissen in der Nähe meiner Position ist auch wichtig. Das sind jetzt bei OSM auch noch ganz spezifische Herausforderungen dabei, die es zu meistern gibt.
07:24
Also wir reden hier nicht über so kleine Datenmengen, die jetzt auf diesem Laptop vielleicht schneller prozessiert und evaluiert werden können. Das sind Prozesse, die häufig Stunden, vielleicht sogar mal Tage dauern, weil diese Menge so groß und so stark gewachsen und wird in Zukunft auch noch viel weiter wachsen.
07:46
Gleichzeitig sind diese Berechnungen, die notwendig sind, um die Daten zu analysieren, sehr komplex. Und da muss man schon einen vernünftigen Server aufsetzen, damit da irgendwas vorwärts geht.
08:00
Es gibt in OSM, das ist ganz typisch und auch verständlich und auch gut so, jeder kann mappen, wie er möchte. Das betrifft auch Adressen. Und da gibt es Associated Streets und das Karlsruher Schema. Und jeder hat da noch sein eigenes Tier und auch verschieden. Die einen mappen die kompletten Daten von Adresse,
08:22
die anderen lassen immer die Stadt und die Postleiter weg, weil die anderswo auch geteckt ist. Und so die verschiedenen Styles, die muss man einfach interpretieren und berücksichtigen. Und manchmal ist es auch so, die Daten sind nie komplett, wir sind am wachsen und wir werden immer größer.
08:41
Und zum Beispiel, wenn es eine Hausnummer gibt, also die Bahnhofsstraße 133, ist vielleicht diese einzelne Hausnummer nicht eingetragen, dennoch aber die Straße. Das heißt, wenn ich nach dieser Adresse suche, okay, dann kann ich die Hausnummer, diese genaue Position nicht zurückgeben, aber zumindest kann das System so clever sein,
09:03
zu sagen, okay, er kann die Hausnummer nicht finden, dann gibt er zumindest die Straße zurück und kein leeres Ergebnis. Ja, wie schon vorher auch erwähnt, die Verarbeitung, die ist nicht ganz trivial und dem muss Rechnung getragen werden.
09:22
Wir haben bei Komod uns nach Lösungen auf Basis von OSM umgesehen. Es gab einige Lösungen gesehen, aber nicht das gefunden, das wir wollten. Und haben uns dann auf den Weg gemacht, eine eigene Lösung zu machen. Und die wir dann auch als Open Source veröffentlichen und der Gemeinschaft zur Verfügung stellen möchten.
09:48
Das ist letzten Sommer passiert auf der State of the Map in Birmingham. Da hat sich jetzt auch ein bisschen was getan. Wir sind nicht untätig gewesen und das ist quasi ein Projekt.
10:02
Wir können auch gleich mal drauf gucken. Ich hoffe, das geht hier auf dem Rechner. Ich zeige Ihnen eine schöne Slide, gucken, ob das auch wirklich funktioniert. Kann mal jemand ... Ich kann es auch direkt in den Browser eingehen. Sonst wirst du mir das einfach auch glauben.
10:49
Jetzt zeige ich. Also unser Foto. Komod.de. Ich sehe das hier leider nicht. Jetzt haben wir es.
11:15
Das ist unsere Projektseite. Das erste, was man sieht, ist eine Karte.
11:21
Im Zentrum unser Büro hier in Potsdam. Ist recht schön dort. Und was wir sehen können, ich sehe es nicht. Also man muss das Wort nicht komplettieren. Man bekommt das Ergebnis sofort zurück. Wir können auch wieder zurück nach Potsdam.
11:44
Genau, die Funktionsweise ist wegen klar. Der Suchrequest ist auch extrem schnell. Die Sachen sind weltweit für Verfügung. Also wenn ich jetzt ... Picking. Jetzt muss ich es in Englisch eingeben.
12:07
Es ist diese verrückte Insel. Super. Es gibt auch sehr viele Herausforderungen solcher Art. Aber wir sehen, es funktioniert weltweit, es funktioniert schnell. Es ist eine Autocompletion dort.
12:21
Man kann die da selber auch gerne ausprobieren. Wir haben auch einen Location-Byes drin. Der kann auch für solche Ungereimtheiten manchmal sorgen. Jetzt gehe ich wieder zurück. Das kennen wir schon.
12:42
Noch kurz darauf auf die technische Zusammenstellung des Projekts. Also wir bauen auf den Datenstand von Nominatim auf. Das ist ganz unten diese Layer. Wir haben einen Exporter, der diese Daten rauszieht und ihnen eine für uns verwertbare Form bringt. Und zwar, so dass wir das in Elasticsearch einbauen können. Elasticsearch, das ist ein Aufsatz auf Apache-Lucine,
13:04
was im Prinzip eine Volltext-Suche ist. Das ist ein sehr, sehr mächtiges Toolset, das eigentlich ein Standardproblem löst. Nämlich der der Suche. Das ist auch ein Open-Source-Projekt.
13:21
Wunderschön dokumentiert. Extrem viele Plugins. Und auf dem wollen wir aufbauen, weil wir wissen, dass das ein Standardproblem ist. Und es gibt einfach sehr viele Tools und Plugins, die man da zusammenbündeln kann. Und allein, also auch ohne großartige Eigenentwicklungen, kann man eine sehr mächtige Suche bauen.
13:40
Ganz oben drüber ist noch ein ganz dünner Web-Layer in Flask. Also ein Micro-Framework für Python. Kurz zu den aktuellen Features. Wir haben also Type Ahead. Wir sind extrem schnell. Wir sind auch skalierbar. Das liegt in der Natur der Sache. Weil wir Technologien verwenden, die das eh schon unterstützen.
14:04
Das mit dem Rechtschreibfehler funktioniert noch nicht. Ist aber auch möglich. Auch durch Plugins von Elasticsearch. Was leider auch noch nicht geht. Wenn wir jetzt irgendwas Neues eintragen bei OSM, dann landet das hier nicht auf dieser Webseite
14:20
und dieser Suche. Das ist eine Funktionalität, die wir noch nicht unterstützen. Das soll aber bald kommen. Also falls jemand von euch Interesse hat, das zu nutzen, dann habt ihr einerseits die Möglichkeit, euch das Projekt auszuchecken, die Sachen selber zu installieren. Das ist auch alles gar nicht so wild.
14:41
Man muss nur auch dran denken, dass man Nominate installieren muss, weil das die Datenbasis ist. Und wie gesagt, das sind sehr viele Daten, große Daten. Das kann ein bisschen dauern. Wir haben gleichzeitig auch unter der vorher gezeigten Projektpage eine öffentliche API zur Verfügung gestellt.
15:01
Also wenn jemand von euch ein Projekt hat mit OSM-Daten und die Suche verwenden möchte, kann er das tun. Wir haben sehr laxe oder ja, wir wissen nicht so recht, wie viel Last das System aushält, um ehrlich zu sein. Aber wir haben eine leichte Drosselung drin.
15:22
Wer jemand, wenn jemand das nutzen möchte, kann das jetzt tun. Das funktioniert weltweit in Deutsch, Französisch, Englisch, Spanisch. Und das war's. Wir sind natürlich auch immer sehr happy, wenn jemand mitmachen möchte.
15:40
Allein durch die Nutzung und das Feedback, glaube ich, können wir auch schon sehr viele hilfreiche Informationen sammeln. Andererseits hatten wir das kürzlich in den Sprint. Wir werden es im nächsten machen, wahrscheinlich im April, Mai. Wir kommen auch von Sarah, von Nominatum, Unterstützung. Sie wird nach Berlin kommen, ebenfalls Johann Boniface,
16:01
eine Franzose, der auch in dem Umfeld sehr viel Erfahrung gesammelt hat. Also wenn jemand Lust hat, kann er mich gerne anschreiben, hier nochmal meine E-Mail-Adresse. Wir denken, das ist ein sehr wichtiges Thema für OpenStreetMail ganz allgemein und hoffen, dass wir da einen guten Input liefern können.
16:30
Vielen Dank, Christoph, auch für das Projekt. Er hat selber gesagt, ihr habt sehr laxe Beschränkungen, der Server darf ausgetestet werden. Vielleicht solltest du nachher nochmal gucken, ob der auch noch läuft.
16:43
Liebes Publikum, Fragen? Hier vorne sich eine Frage. Der Datenbestand ist ja sehr groß von OSM. Man hat ja auch bei der Suche gesehen, du hast da Berlin eingetippt, und dann kommt dann halt Kaffee Berlin in Wiesbaden, ich weiß nicht dabei, aber Berg Berlin.
17:02
Kann man die Suchefotonen so einschränken, dass man nur auf bestimmten Orten sucht? Also theoretisch fällt mir sofort eine technische Lösung ein. Wir bieten es nicht an, aber könnte man auf jeden Fall anbieten. Das ist aber auch an sich eine sehr gute Frage,
17:20
weil sie die Komplexität der Sache ein bisschen in den Vordergrund rückt. Klar, es sind nicht nur Orte in OpenStreetLab drin, wie Städte, wie Stadtviertel zum Beispiel, sondern auch ganz andere Typen, zum Beispiel ein C oder ein POI oder Adressen, und die untereinander irgendwie in ein Gleichgewicht zu bringen
17:41
und zu vermuten, was der User dann wirklich sucht, was er eigentlich wollte. Das ist dann nicht immer klar, und da liegt auch die Herausforderung. Darf ich sonst kurz? Hallo, vielen Dank für den Vortrag. Wenn ich jetzt ein Land suche, zum Beispiel Deutschland eingebe,
18:00
dann will ich ja auch quasi ein Zoom-Level zurückbekommen. Will ich so irgendwie sagen, ich will Deutschland anzeigen? Hallo, ist das eine Gruppe? Geht das? Ja. Okay. Wir haben jetzt gerade bei den Ergebnissen gesehen, dass man halt Potsdam eingegeben ist, aber direkt am Basernplatz rausgekommen, und den Rest von Potsdam sieht man nicht.
18:20
Unterstützt das System das auch, dass es einem irgendwie sagt, ja, das ist aber so und so groß, und man muss auf dem Zoom-Level anzeigen? Ja, also momentan nicht. Es gibt eine zweite, also das, was man hier gesehen hat, das ist das, was wir jetzt auf dem einen Test-Server haben, oder diesen Projekt-Server haben.
18:40
Bei Commode Eigens haben wir schon die nächste Version implementiert, und da passiert es schon, aber hier noch nicht, aber das ist nur eine Frage der Zeit. Also vor allem auch mit dem nächsten Sprint wird das dann auch erledigt sein. Aber es ist sehr, sehr wichtig, damit man den richtigen Kartenausschnitt sehen kann. Bitte, die nächste Frage. Wenn mal das mit diesen Rechtschreibfehlern kommt, wird es dann für den Benutzer auch eine Möglichkeit geben,
19:02
zu sagen, ich will aber exakt das suchen, was ich eingegeben habe? Das ist wieder so schwierig, ja. Oft ist die Entscheidung nicht klar, also das System muss irgendwie raten, ob es dann ein Schreibfehler war, oder ob er dann wirklich danach suchen möchte. Wird im Ergebnis zumindest angezeigt, wo eine Korrektur stattgefunden hat, und wo es wörtlich vorkommt?
19:20
Manchmal will man ja wissen, kommt diese Schreibweise vor, und sucht deswegen genau nach vielleicht einem falsch geschriebenen Wort. Also auch eine super Idee, also es ist eine Sache, an der man arbeiten muss. Es gibt ja bei Google selber auch irgendwie, die machen eine Autokorrektur, und fragen dann aber nach, ob ich denn nicht doch nach dem ursprünglichen Suchwort suchen möchte.
19:42
Hier oben wäre eine Frage, ich glaube, das machen wir auch zur letzten Frage. Hi, danke für den Vortrag. Kannst du uns sagen, inwieweit die API kompatibel zu deinem Nominatum ist, und was Versuchergebnisse zurückgegeben werden?
20:00
Also ich kenne so Sachen, dass wenn man die Postalzahlen nicht mit eingibt, dann findet er die und gibt die mit zurück. Also ist das kompatibel, oder habt ihr das neu designt? Also die Form der Rückgabe ist unterschiedlich. Wir liefern GeoJSON zurück, also ein kompatibles Standardformat.
20:26
Die Daten sind sehr ähnlich, aber du wolltest glaube ich auf den Punkt zurück, dass wir die Daten vervollständigen, das tun wir. Also wenn du nach Berlin oder nach einer Adresse suchst, bekommst du, auch wenn du nicht die Postalzahlen eingegeben hast, bekommst du die trotzdem zurück. Ja, bei den Nominatum, da kommen ja dann teilweise Bundesländer mit zurück
20:42
oder noch andere Unterstrukturen dann. Genau, die liefern wir aber auch mit. Okay, dann würde ich sagen, Christoph, nochmal vielen Dank für deinen Vortrag.