Hi, ich möchte mein aktuelles Projekt am Highgit vorstellen, dem Heidelberger Institut für Geoinformationstechnologie. Den ORS hat Julian ja schon vorgestellt, ich bin ein bisschen ein Kollegen. Und wie jedes gute Projekt startete meins mit einem Problem und das

Problem war der Klassiker, irgendwas ist zu langsam. Niemand hat ein Problem mit dem Open-Route-Service bis dann die Disaster-Mappers kamen, in Heidelberg falls das jemand schon mal gehört hat und das Humanitarian Open-Street-Map-Team unten in Open-Route-Service für Disaster-Management machen wollte und da war das Problem, dass das Grafen-Update

sehr langsam war, dauerte nämlich genau sieben Tage, das heißt die Daten sind immer sieben Tage alt und der rechnet auch sieben Tage durch dabei. Eine Lösung für das Problem, das wir dann verfolgt haben, war pro Region eine ORS-Instanz laufen zu lassen, pro Disaster-Region, dadurch ist die Datenbasis viel kleiner und die

Grafen-Updates gehen viel schneller. Jetzt aber noch das Problem, dass wir aktuelle Daten haben wollen und hier kam mein Projekt ans Spiel. Das sieht so aus, es ist ein Web-Server, der quasi Tasks verwaltet und jede Task ist dazu da einen Extrakt zur Verfügung zu stellen. Man kann damit ganz individuell über Polygone eigene

Regionen definieren und eigene Update-Intervalle definieren, die dann automatisch von dem Web-Server aktuell gehalten werden und natürlich auch bereitgestellt werden. Hier sieht man das Ganze schon in Aktionen beim Open-Route-Service für Disaster-Management und in rechts kann man schön sehen, dass man die Regionen einzeln auswählen kann,

der springt dann auf die jeweilige Instanz um. Technisch ist das Ganze auf dem Node.js-Server aufgebaut, der verwaltet die Update-Tasks in einer SQLite-Ratenbank und hält die Daten alle aktuell, stellt aber auch eine API bereit, mit der jeder ganz einfach Tasks hinzufügen und entfernen kann und natürlich gibt es auch noch das Webfrontend, das wir gerade gesehen haben, mit dem man ganz intuitiv die Daten verwalten kann. So, die Updates laufen wie folgt ab, das ist bestimmt der

interessante Teil für viele. Der Server versucht den kleinsten möglichen Geofabrikextrakt zu finden für die gewünschte Region, schneidet die dann zu auf das Wunschgebiet und hält die dann fortlaufend up-to-date mit osm-update. Ich kann das mal kurz demonstrieren, wir haben nämlich eine Instanz

geschaltet für die Foskis. So sieht das Ganze aus. Man hat hier die Karte, kann hier Tasks hinzufügen, wo immer man auch will und hier oben sehen Sie die URL, Sie können auch gerne drauf zugreifen, der wird

ungefähr bis Sonntag online sein, der Server, aber bitte nicht zu große Tasks reinladen, das Ding hat nur zwei Gigabyte RAM und wenn man jetzt beispielsweise HIT hinzufügen will, kann man hier noch ein Expire-Datum angeben und Update-Intervall und die Tasks submitten. Okay, die Zeit läuft,

anscheinend ist die Internetverbindung gerade schlecht, unabhängig davon kann man hier unten dann alle Tasks, auch noch per Adjacent, sich ausgeben lassen und sich alle Daten zur Verfügung stellen lassen und wir sind damit auch

sehr zufrieden bislang. Es gibt aber noch ein, zwei Limits und zwar haben wir ein Problem, wenn das Wunschgebiet größer ist als der größtmögliche Geofabrikextrakt, dann wird kein Geofabrikextrakt gefunden logischerweise und die Tasks kann nicht zur Verfügung gestellt werden. Was wir uns dann überlegt haben ist, man könnte einen Planetfile vorhalten oder ein Osmosis-Datenbank, allerdings war das Ziel für unser

Projekt ja, dass es sehr benutzerfreundlich sein soll und jeder sich das runterladen können soll und dann ist es ungünstig, wenn man ganzes Planetfile vorhalten muss. Die zweite Option war Overpass abzufragen, aber die ist momentan dafür noch zu langsam. Wenn da jemand noch eine Idee hat, würden wir uns sehr freuen. In Zukunft werden wir die

Planetfile-Variante noch implementieren, aber bislang basiert das Ganze auf den Geofabrikextrakten. Vielen Dank und wenn Sie eine Frage haben, können Sie immer zu mir kommen oder mir eine Mail schreiben.