Guten Morgen, auch im nächsten Vortrag geht es hier im Saal wieder um OpenStreetMap und den Referenten, den wir haben, das ist Sven Gegos, und der optimiert schon seit auch über einem Jahrzehnt den Foskes Server unter der

Domain OpenStreetMap.de und nicht nur den Server, sondern auch den deutschen Stil, den unterstützt er schon fast im Alleingang jetzt über zehn Jahre. Von daher ist er also schon sehr erfahren hier und

in dem nächsten Vortrag würde er uns zeigen, wie man Points of Interest ganz einfach in eine Karte reinpackt. Und das Ding hat den umständlichen Namen OpenStreetMap Point of Interest Database und mit dem Instrument will er uns zeigen,

wie man diese Karten ganz leicht einmal aufsetzt. Ich wünsche viel Unterhaltung, gute Unterhaltung mit dem Vortrag von Sven Gegos. Hallo zusammen von mir auch nochmal. Wir kommen auf so ein sperriges Thema. Das ist ganz einfach. Eigentlich sind ja sowieso POI-Darstellungen, Point of Interest-Dinger so mit, was man so liest und

hört, die häufigste Anwendung von OpenStreetMap, wenn man von Routing und Karten-Darstellung mal absieht. Komisch eigentlich, dass es da nichts Fertiges gibt. Und genau das wollte ich eigentlich machen, mal schnell eine Webkarte mit ein paar POIs darzustellen

und dann so, was nimmt man da jetzt serverseitig? Dann habe ich da ein bisschen mit Overpass angefangen und das ist irgendwie so ein bisschen zu langsam für einen beschriebenen Anwendungsfall. Also habe ich mir halt mal ein Backend selber gebastelt und dankenswerterweise gibt es so die ganzen Tools aus dem OpenSource-Gistbereich, die man da einfach

einsetzen kann und wenn man die richtig zusammensteckt und das ist das, was ich jetzt hier mache, dann ist es eigentlich auch relativ einfach und mit wenig Aufwand zu machen. Vorausgesetzt, man kennt sich ein bisschen aus und weiß sowas, die Tools so können. Also was hatte ich dann für Anforderungen ans Backend?

Und das war nämlich genau das Problem. Ich wollte halt mal so eine Webkarte machen, wo ich die POIs darstelle und wenn ich da hin und her zoome, dann sollen die halt schnell nachgeladen werden in meiner Bounding-Box da, die ich entsprechend darstelle und das soll nicht ewig dauern. Das ist was, das man mit Overpass so nicht darstellen kann.

Overpass ist dafür ja eigentlich auch nicht gedacht. Und was ich halt auch immer gern hätte, wenn ich OpenStreetMap-Daten verwende, ich will da nicht groß drüber nachdenken, dass ich da irgendwann die Datenpack aktualisieren muss, sondern das sollte möglichst automatisch gehen, dass das immer möglichst einen aktuellen Stand darstellt.

Sagen wir mal maximal einen Tag alt oder so, wäre was, wo ich noch akzeptieren würde. Also was habe ich gemacht? Was man eigentlich typischerweise macht, man nimmt eine PostGIS, das ist ja

Standard-Methode und PostGIS kann eigentlich echt alles, was man da braucht, schon. Da gibt es eben so eine Funktion, die kann direkt GeoJSON rauswerfen. Das kann ein Client verarbeiten mit Leaflet oder OpenLayers und dann ist man eigentlich schon fertig.

Man kann sogar ein Client, auf Client-Seite das UMap verwenden. Dann braucht man auf Client-Seite nicht mal was programmieren, aber man braucht halt irgendwie eine Quelle für GeoJSON und das kann meine OSM-PoE-DB. Also ich habe das auch schon mal getestet, also es funktioniert problemlos, da

auch UMap als Frontend dran zu hängen und dann die PoEs halt mit UMap darzustellen. Was man auch braucht, ist eben zusätzlich zur Datenbank kleine Abfrageskripten, die CGI-Skripten, ich habe sie mit WSGI, das ist das Python-Interface

dazu von dort gemacht, die sind aber relativ kurz jeweils eine halbe Seite oder so. Also da geht es im Prinzip bloß darum, die Eingaben zu verarbeiten und dann halt eine SQL-Abfrage zu machen und das Ergebnis dann an den Client zu

liefern. Also eine relativ schnelle Geschichte. Der Fokus ist jetzt hier ein bisschen auf, wie kriege ich die PoE-Daten aus Open Street mehr raus und tue sie in eine Datenbank rein, weil da muss man so ein paar Sachen beachten.

Das erste ist, ich habe gesagt, ich hätte gerne kontinuierliche Aktualisierung und da scheiden schon halt leider dummerweise viele Tools aus, die das typischerweise können, also zum Beispiel kann Osmium sowas, dass die Sachen in PostGIS importieren.

Es kann auch OGR, wie man gestern in dem Vortrag, ich weiß nicht, was drin war, gesehen hat auch, OGR kann die Sachen auch direkt in PostGIS rein tun. Nachteil hier immer ist, die können alle keine kontinuierlichen Updates, sondern die nehmen halt einmal einen kompletten Planet, hauen den rein.

Die beiden Tools, die das können, sind ImpOsm und OSM2PG SQL. Ich habe mit OSM2PG SQL angefangen, weil ich das besser kenne eigentlich, um dann festzustellen, okay, das was du da machen willst, das geht ja gar nicht. So und das ist falsch. Seit Anfang 2020, seit Anfang dieses Jahres hat der Jochen Topf dankenswerterweise

das OSM2PG SQL erheblich erweitert und hätte ich es jetzt erst angefangen und etwa vor knapp einem Jahr hätte ich vermutlich OSM2PG SQL verwendet. Stattdessen habe ich ImpOsm verwendet, weil es damals eigentlich so das einzige Tool war, dass dieses flexible Ausgabeformat konnte, wo man halt festlegen

konnte, welche Tabellen hätten wir gerne und wie sollen die aussehen. Und das war bei OSM2PG SQL bisher sehr statisch. So, Besonderheiten von POI in Open Street Map. Es wäre ja zu schön, wenn in Open Street Map so ein POI einfach nur ein Point

wäre, Point of Interest, wie man denken könnte. Nee, Points of Interest sind in Open Street Map natürlich auch mal als Fläche erfasst, kann man ja noch halbwegs nachvollziehen, aber nein, es kommen sogar Linien vor und weil so eine Pike-Bank halt in Open Street Map von

manchen Leuten selbst als Linie, naja, als Linie mit einer Länge von, was weiß ich, zwei Meter erfasst wird und Fun Fact, es gibt 15.000 davon in der Open Street Map Datenbank weltweit als Linie erfasste Pike-Bänke.

Also, das macht ja nichts, aber man muss mit solchen Sachen rechnen. Ja, und also die Polygone, das ist dann eher wieder so eine Sache. Natürlich, die meisten Points of Interest sind in der Realität keine

Punkte, sondern sind halt eher Flächen, ja, also man sagt, ein Spielplatz ist ein Point of Interest, aber natürlich hat ein Spielplatz eine räumliche Ausdehnung, in OSM wird er typischerweise halt als, wenn er

bei meiner POI-Datenbank dazu, dass ich halt tatsächlich Linien, Polygone und Punkte berücksichtigen muss. Und dann habe ich eine weitere Besonderheit und die ist eigentlich aufwendiger. So, polygonförmige POIs können halt weitere POIs enthalten

und in den meisten Fällen ist das dann eigentlich, naja, wenn man so darstellt, eigentlich eine Eigenschaft von dem übergeordneten POI. Beispiel jetzt hier, mein Campingplatz, auf meinem Campingplatz gibt es eine Toilette. Dann will ich eigentlich wissen, wenn ich einen Campingplatz

darstelle, hat der eine Toilette oder hat er keine? Und das will ich mir nicht auf der Fläche raussuchen, da sind da noch Toiletten-POIs drauf. Das heißt, ich muss da sowas machen, das nennt Post-GIS Spatial Join. Da kann ich im Prinzip gucken, überlappen sich, überschneiden sich

die Flächen und kann dann quasi meinem POI quasi diese anderen Dinge als Eigenschaften zuordnen. Das ist was, wo ich halt auch brauche, wenn mein Ausgabepunkt irgendwo,

naja, sinnvoll nutzbar sein soll im Frontend. Dummerweise sind diese Spatial Joints, ach ja, genau, das habe ich da wie

man die behandelt, dummerweise sind diese Spatial Joints eine teure Geschichte und deshalb nehme ich mir eine Materialized View, das heißt, eine Materialized View in Postgres ist so eine Art, ich mache mir eine

neue Tabelle, aber speicher auch noch ab, wie du die neue Tabelle generiert hast, dann kann ich nämlich über einen einfachen Update, kann er die dann neu generieren. Das ist relativ neu, aber das ist für diesen Zweck ganz praktisch, weil dann muss er diese Spatial Joints halt nur einmal machen,

immer nach dem Aktualisieren der Datenbank und muss die nicht bei jeder Abfrage machen, weil das wird es wieder langsam machen. Die andere Geschichte, POIs als Linien und Polygone, dafür gibt es dankenswerterweise diese ganz einfache Funktion ST-Centroid und

dann bin ich fertig, dann kriege ich halt das Zentrum von meiner Linie oder von meinem Polygon und kann da meinen Punkt darstellen, also mein GeoJSON, das ich typischerweise im Client bekomme, ist einfach immer nur ein Punkt, also ich nehme diesen Punkt, da ist dieser Point of Interest und er hat die und die Eigenschaften.

Und das ist auch das, was ich mache typischerweise, ich habe das halt so aufgebaut, könnte man sich ja auch in einer Tabelle speichern, ich habe jetzt drei Tabellen genommen, eine für Linienpunkte und Polygone und dann fasse ich die zusammen mit einer Union-Abfrage

und rufe halt bei den Linien und bei den Polygonen noch ST-Centroid auf, damit ich letztendlich den Mittelpunkt bekomme und dann bin ich beim Point of Interest im Wortsinn und nicht mehr, wie sie halt roh in der Open-Street-Map-Datenbank drin sind.

So ein paar Facts dann noch zur Datenbank selber, weil typischerweise ist eine OSM2PG SQL-Datenbank, wenn man da nicht groß was macht, ziemlich riesig inzwischen, also man ist da so bei,

ich weiß es nicht, das waren glaube ich irgendwie so 500 Gig oder so was, was man so für alles in allem braucht. Also meine PIOI-Datenbank ist relativ klein, das hat ganz einfach Gründe, wenn man sich da mal die meine Texte anguckt, die ich zurzeit drin habe,

da ist Building-Net drin, ganz wichtig, da ist Highway-Net drin, ganz wichtig und dann hat man eigentlich schon die großen Net drinnen und da ist kein Land-Use drin, wie man auch noch sieht und dann dampft das ganz gewaltig ein.

Also meine Datenbank ist mit allen PIOIs, mit den genannten Tags 20 Gigabyte groß und für die Aktualisierung, die IMPOSM da noch datenspeichert, brauche ich nochmal 70 Gig. Also das ist noch darstellbar für einen kompletten Planeten. Na ja, im Prinzip auch noch auf einem Laptop, das ist eigentlich, wenn man mal nicht so riesig

und der komplette Neuimport ist auch nicht so teuer. Der dauert je nachdem, wenn man eine schnelle SSD hat, etwa eine Stunde, wenn man ein bisschen langsamerer Platten hat, dann vielleicht zwei. Also damit kann man ein bisschen spielen und so einen Neuimport. Also das habe ich auch zwei, drei Mal gemacht.

Oh, ich habe doch noch einen Tag vergessen. Deshalb habe ich das alle da durchgestrichen. Ich habe eigentlich gedacht, ich hätte alle. Nee, aber ich habe jetzt auch festgestellt, man hätte vielleicht noch gerne Natural, weil ich hätte gern letztens eine Karte gemacht mit irgendwie Berggipfeln ab so und so viele Metern oder so was.

Und dann so, okay, habe ich nicht drin. Vielleicht soll ich Natural auch noch mal dazu nehmen. Das wächst halt so, aber so ein Neuimport ist ja auch nicht teuer. Ja, genau, jetzt noch so als Zusammenfassung, was ich noch gern hätte.

Und dann zeige ich noch mal kurz in der Praxis, wie das aussieht. Also was hätten wir noch gern? Momentan habe ich ein Abfrageskript, ein eigenes Abfrageskript für jeden Typ von POI. Momentan wird diese Datenbank, die Datenbank läuft momentan

auf einem der OpenStreetMap.de und ist auch für Projekte offen. Also wenn jemand da freie Projekte mit machen will und braucht eine POI-Backend, kann er das hier einfach mitbenutzen. Dann brauchen wir nichts Neues aufsetzen, das gibt es ja schon. Und ich habe aber immer für jeden Typ von POI einen kleinen Abfrageskript gebaut,

der dann die eigentlichen SQL-Abfragen macht. Das ist einfach aus Sicherheitsgründen Bedenken so gemacht, weil, na ja, will man so in den Query-String eine SQL-Ware-Clause reinschreiben, dann macht mir jemand SQL-Injection und so.

Lassen wir mal lieber, sind wir auf der sicheren Seite. Da hätte ich gern was universelleres, was trotzdem sicher ist. Vielleicht auch eine Wunschvorstellung. Ja, und dann fehlt Postgres eigentlich eine HTTP-Schnittstelle. Postgres müsste eigentlich direkt aus Jason liefern können

in anderen Browser, aber dass man da immer noch irgendwie so ein so ein Dings dazwischen braucht, das ist genau. Und Ebenbosom ist auch nicht ganz perfekt. Das bräuchte noch einen Skripthook, das nach jeder Ausführung halt meine eigenen Skripte triggern kann. Momentan verwende ich da einen etwas unschönen Workaround.

Ja, jetzt, Quellcode gibt es da. Das ist in den Folien so. Jetzt wollte ich noch ein bisschen was in der Praxis zeigen. Na, wo ist jetzt der Browser?

Äh, ach, hier gibt es ja eine echte Maus. Also das ist die Open Camping Map. Das ist für das, die wollte ich eigentlich mal schnell machen. Und für die habe ich das Backup gebaut.

Das Backend gebaut. Und wenn man da jetzt sieht, wenn man halt ein Pen oder ein Zoom macht, dann kann er die Sachen schnell nachladen. Und das ist das, was ich so gewünscht habe. Das soll nicht ewig dauern. Man sieht, es dauert einen Moment, aber es ist akzeptabel. Wenn man weniger nachlädt, dann ist es auch noch ein Ticken schneller.

Und wie ich das gesagt habe, wenn ich so einen POI anklick, wenn ich so einen POI anklick, dann habe ich halt da oben die Icons. Und das sind halt, was weiß ich, es gibt eine Toilette, es gibt eine Dusche. Und das ist über den Spatial Join zusammengezogen,

weil das ist halt als eigener POI auf dem Platz gemapt. Wir können auch da mal reinzoomen. Das war, glaube ich, einer, der besonders gut erfasst war da. Ja, genau, der hat noch Platznummern und so ein Zeug.

Ja, das ist ganz praktisch, wenn man Platz sucht. Also wenn er gut erfunden auf dem Handy und dann so ha, dann muss ich jetzt dahin laufen. Also so ein bisschen Micromapping. Ja, und wie sieht so eine wie sieht so eine wie sieht jetzt dieses dieses Abfrageskript aus?

Das kann ich auch noch so nicht. Ich zeige vielleicht besser die Datenbank. So viel Zeit habe ich jetzt auch nicht mehr. Wie sieht die POI-Datenbank aus? Die sieht als einfach so aus. Ich habe jetzt hier meine. Oh, jetzt ist es weg.

Ich schalte das vielleicht mal. Das ist schön, dass unter Linux jeder Winter Manager anders ist. So, also ich habe meine, kann man sehen, ja. Also ich habe meine Tabellen, Point, Polygon und Line.

Und ich habe eine Materialized View momentan für die Campsite und für die Playgrounds, weil es gibt ein Projekt, das heißt Babykarte und das benutzt neuerdings auch mein Backend. Und die wollen wissen, was gibt es auf dem Spielplatz für Spielgeräte, Sandkasten und solche Sachen. Und das ist auch wieder Point in Polygon.

Und dann brauchen wir auch noch mal so ein Materialized View. Da können wir jetzt noch mal ein Describe machen auf den auf meine Campsites. Und da sieht man jetzt eben, ich habe die Tags, meine OSM-ID, meine Geometry.

Die Geometry ist ein Punkt. Und dann habe ich noch so eine ganze Menge an Bullions. Und das sind quasi diese Dinger, die ich mit Point in Polygon über den Spatial Join rausziehe. Und das ist halt true, wenn es das irgendwo auf dem Platz gibt. Und irgendwo hatte ich noch ein Select. Und das Schöne ist halt, dass Postgist das Zeug

direkt so in Jason raushauen kann. Da muss man gar nicht groß drüber nachdenken. Und das macht die Abfrageskripten so klein. Ja, das wäre es mal von meiner Seite, wenn es noch Fragen gibt.

Wunderbar, das war eine Punktlandung. Vielen Dank, Sven. So, und ich sehe schon eine Wortmeldung. Ja, vielen Dank für den Vortrag.

Gibt es auch Duplikate, die entstehen können, wenn man jetzt in Polygon, in Centroid verwandelt. Und das noch als POI, als Not, auch kartiert ist. Also dass es dann zwei Punkte existieren. Von einem Shop oder von einem, ja. Ja gut, also in Open Street Map hat man ja auch in dem Vortrag von der Sara gesehen

manchmal so ein bisschen Müll drin. Und da bin ich natürlich auch nicht gefeit vor. Also was mir bei den Campingplätzen mehrfach aufgefallen ist, nach dem Motto, viel hilft viel, gibt es irgendwelche Mapper, die machen dann einen Polygon, sagen, oh, das ist die Campsite irgendwie. Und dann basteln sie noch einen Not mitten rein

und setzen auf den Not noch mal den gleichen Namen drauf. Das sieht tatsächlich momentan in der Karte halt übel aus. Und das ist was, wo ich dann halt typischerweise in den Daten fixe. Also es gibt keine Abstandstoleranz, dass die dann rausgefiltert werden. Ja, das könnte man machen, aber das ist ja dann heuristisch, weil, doch, weil es wäre,

also gerade bei den Campingplätzen war es auch so, dass da derselbe Name dran klebt. Dann hat man schon Glück gehabt. Manchmal kleben sie an eines den Name dran und das andere nicht. Und dann, womöglich sind sogar zwei verschiedene Mapper. Der eine tragt den Punkt ein und der andere tackt es an das Polygon noch mal ran. Also ich glaube, man repariert besser die Daten.

Ja, dann sei mal froh, dass das nicht noch in die Relations reinpackt. Weitere Fragen? Da hinten bitte. Vielleicht eine dumme Bemerkung. Wenn ich im Rollstuhl sitze,

sind für mich die Points of Interest zum Beispiel auch irgendwie Treppenstufen. Lässt sich deine Geschichte auch irgendwie sozusagen duplizieren? Es gibt ja so Open-Wheel-Map. Also ich habe mit Rollstuhl zum Glück noch nichts zu tun.

Ja gut, ich habe im Moment kein Highway drin, habe ich gesagt. Highway equals steps. Könnte man machen, ob ich jetzt eine Preukarte haben will mit allen Treppen. Ja, sage niemals nie. Es gibt sicherlich Leute, aber klar. Momentan ist es so,

momentan hatte ich ja in der Liste drin die Keys, die ich verwende. Aber man kann in Imbossen auch sagen, Key equals value will man importieren und nur die. Also in dem Fall Highway equals step. Und die ganzen anderen Highways lassen wir weg. Nein, ich meinte, das nochmal anzulegen

für die Wheelmap, dein System zu duplizieren mal. Als ferne Vision. Alles, was POIs sind, kann man damit abdecken, das ist kein Thema. Meine Idee war tatsächlich, ich mache etwas, wo ich möglichst alle POIs mit abdecken kann. Und nicht für jede Spezial-POI-Anwendung

nochmal eine Spezial-Datenbank. Das wollte ich explizit nicht. Noch einmal eine kurze Frage zum Wording. Du spreist eben ein paar Mal davon zu teuer. Was meinst du damit? Zu teuer ist, wenn eine Abfrage eine Stunde dauert

und aber in 10 Sekunden durch sein sollte oder so. Was ja logisch. Die Aktualisierung von Eintagesakzeptabel, ist das sportlicher Ehrgeiz? Oder was hat es damit für Bewandtnis auf sich? Nein, das ist auch tatsächlich so.

Ich habe ja die Open-Camping-Map tatsächlich auch dafür gemacht, dass Leute jetzt zum Beispiel, wenn man hier sieht, da sind Ausrufezeichen. Okay, dann kann ich jetzt das Tagging von diesem Campingplatz, der hat zum Beispiel nur einen Namen, sonst nix. Dann kann ich hier auf den Bug klicken und kann mir die ID rausholen. Kann in JOSM oder ID editieren, kann das reparieren.

Und für den Mapper ist immer so, er will sehen, ob es auch funktioniert hat, ob es jetzt gut aussieht. Und dann soll es halbwegs zeitnah wieder aktuell sein. Also das ist der Hintergrund dabei. Momentan ist es so, es wird alle Stunden aktualisiert.

Und schneller geht es aber auch nicht, weil die Materialized Views zu erzeugen, das dauert einen Moment, also zu minütlichen Updates, das würde mit der Technik so nicht gehen. Wenn man jetzt die POIs abhaken will, gibt es da Endpunkte, also eine Rest-API oder so, dass ich sage, ich filter jetzt aus dem Backend die und die POIs?

Ja, das ist ja das, was ich vielleicht gerne hätte. Es gibt solche Sachen wie PG Rest und so weiter. Da denke ich drüber nach, habe ich im Moment nicht. Momentan habe ich einfach ein kleines Python-Skript für jeden Typ von Point, wo einfach die SQL-Abfrage fest drin steht.

Das ist halt auch nicht gefährlich. Also müsste man nicht immer fragen, wenn es noch etwas dazugeben sollte, ob das dann reingeschaltet wird im Backend? Ich muss im Endeffekt nur ein weiteres CGI-Skript reinkippen, weil das Backend gibt es her. Das sind die CGI-Skripten, die sind da auch auf meiner GitHub-Seite.

Dann kann man sich eine als Beispiel hernehmen. Eine einfache war dann irgendwie, das war ein älteres Projekt von mir. Wo mir dann aufgefallen ist, das kann ich auch besser mit dem neuen Backend machen.

Das ist so eine Brauereikarte, natürlich auch weltweit. Das nimmt einfach dasselbe Backend. Das kann jetzt wesentlich weniger als das Camping-Ding.

Das kann jetzt einfach nur vier, drei Typen von Brauereien darstellen. Kann ich da anklicken, dann sehe ich da halt, wie die heißen und so weiter. Das passiert auf dem selben Backend. Das 1 zu 1 ist hinten raus. Das sind einfache Poys, die brauchen doch nicht mal die Views. Weil da gibt es keinen Poin-Poi bei dem Zeug.

Das ist einfacher. Wir haben noch drei Minuten bis zur Pause. Noch Zeitfragen aus dem Auditorium. Sind da noch welche? Das ist nicht mehr der Fall. Dann noch mal herzlichen Dank für deine Antwort, Sven.