Willkommen zum dritten Vortrag von unserem Track zum Thema OpenStreetMap und Software. Bevor wir anfangen, wollte ich noch mal daran erinnern, dass heute Nachmittag ein Gruppenfoto ist,

zu dem alle eingeladen sind teilzunehmen. Fragen können gerne über die Webseite, über diese Online-Konferenzplattform gestellt werden, aber auch dann später noch im Auditorium. Dann hören wir jetzt einen Vortrag von Jochen Topf zum Thema OSM2PG SQL im Kontext von Generalisierung

und dann übergebe ich das Wort an den Redner und freue mich auf den Vortrag. Wir kennen alle OpenStreetMap-Daten hier jetzt mal so die Gegend, wo wir gerade sind. Und wie viele Details da sind, jeder einzelne Baum gemapped, irgendwie eine gigantische Menge an Daten

und das ist ja auch schön, das wollen wir auch haben. Und wenn man dann ein bisschen rauszoomt, dann wird es schon ein bisschen unübersichtlicher mit all diesen Daten. Und wenn man weiter rauszoomt, dann muss man irgendwie all diese einzelnen Bäume weglassen und also diesen Detailkram und muss gucken, wie man nur noch die Sachen darstellt, die in den kleinen Zoom-Levelen oder kleinen Maßstäben irgendwie wichtig sind.

Und das klappt nicht immer so ganz gut. Das ist hier ein Screenshot von OpenStreetMap.org, der Website, wo auf einem bestimmten Zoom-Level von Amerika aus New York, Washington, Los Angeles und Phoenix in Arizona besteht. Und das ist offensichtlich so ganz toll ist das nicht. Und das haben wir an ganz vielen Stellen. Wir wissen gar nicht so richtig, wie kriegen wir diese super detaillierten Daten,

die wir überall erfasst haben, wie kriegen wir die vernünftig auf die Karte in den kleineren Zoom-Levelen? Wie müssen wir die da prozessieren, dass wir das machen können? Und das ist das, was sich Generalisierung nennt, irgendwie die Daten auswählen, vereinfachen, zusammenfassen, sowas.

Und damit habe ich mich beschäftigt. Die Herausforderung bei der Generalisierung ist, ich sage mal, zweiteilig. Das eine ist, wir müssen einfach mit dieser riesengroßen Datenmenge umgehen, die wir für die ganzen Planeten haben. Wir können nicht nur eine Ecke uns raussuchen und die Daten rendern, sondern ich muss irgendwie die Daten von dem großen Raum irgendwie zusammen betrachten.

Dann haben wir die Änderungsrate bei OpenStreetMap, ändert sich ja alles ständig. Und die Prozessierung ist möglicherweise aufwendig für die Generalisierung. Und wir müssen danach kommen mit den Änderungen. Also müssen die Verarbeitungszeiten in der Prozesskette irgendwie in den Griff bekommen. Und damit eben auch eine Hardwareanforderung. Ich will nicht irgendein Tool schaffen, wo ich dann 100 Maschinen mir erst in der Amazon Cloud schießen muss oder sowas.

Und ich möchte gerne, dass solche Sachen auch auf einer kleinen Maschine noch laufen. Und dann haben wir die inhaltliche Herausforderung, wo wir uns überlegen müssen, was will ich denn überhaupt zeigen? Was will ich hervorheben? Was will ich weglassen? Was ist eigentlich das, was auf der Karte nachher erscheinen soll, wenn ich rauszoome? Und das ist natürlich sehr, sehr individuell.

Das ist nicht etwas, wo ich jetzt gerne möchte, dass Google das vorgibt oder dass BKG das vorgibt oder irgendwer. Sondern das will ich ja oder auch OpenStreetMap irgendwer das vorgibt. Sondern ich will vielleicht für meine Karte auch selber entscheiden können, wo das ist. Das heißt, wir brauchen auch eine konfigurierbare Lösung, die anpassbar ist. So wie ganz OSM eben anpassbar ist und die ganzen Tools Open Source sein sollen.

Was die Generalisierung in der Open Source-Welt angeht, das Stand der Dinge ist so ein bisschen... Es gibt so eine Art Pseudo-Generalisierung bei der Abfrage der Daten. Man hat die Daten vielleicht ohne Datenmann geschrieben und dann sagt man, gib mir mal nur alle, die diesen Typ haben oder sowas raus.

Gib mir nur alle Orte, wo mehr als so und so viele Leute wohnen und die zeige ich auf der Karte. Und so entsteht dann sowas wie das, was wir gerade gesehen haben mit der Karte von Amerika. Das ist eigentlich keine Generalisierung, das ist nur so ein bisschen so eine kleine, simple Variante davon. Oder wir haben ein super aufwendiger SQL-Skripte. Da war gestern ja der Vortrag, die Demo-Session, wo man ein paar so Sachen gesehen hat,

wo man Seiten und Seiten und Seiten SQL-Skripte hat, um die Generalisierung zu machen und die dann aber auch nicht immer ganz funktionieren und super viele Corner-Cases haben und vor allen Dingen auch sehr lange brauchen, um durchzulaufen,

sodass wir dann zu tagelangen Vorberechnungen kommen, bis wir überhaupt auf der Karte was sehen. Und wir haben letztlich in der Open-Source-Welt nur sehr einfache Verfahren, die wir wirklich implementiert haben, die in der Praxis auch so nutzbar sind. Und da wollte ich halt ein bisschen mehr machen und ich habe dann Geld beantragt beim Prototype Fund. Letztlich kommt das Geld dann vom BNBF und die haben über diesen Prototype Fund mir bezahlt,

sechs Monate quasi mich bezahlt, dass ich da Entwicklung machen kann und da mal versuche, im Prinzip ist es ein Forschungsprojekt, zu schauen, wie weit ich komme, was ich einbauen kann. Die Ziel dabei war es, nicht neue Algorithmen zu entwickeln.

Ich bin jetzt nicht der große Kartograf oder Geoinformatiker oder irgendwas, der sich ganz neue, clevere Sachen ausdenkt. Wie man diese Generalisierung machen kann, sondern Verfahren, die schon existieren, versuchen praxisnah umzusetzen auf den OSM-Daten und es in bestehende Software so einbinden, dass es auch später für den normalen Nutzer nutzbar ist.

Ganz wichtig ist, ich arbeite auf OSM-Daten. OSM-Daten sind unvollständig. OSM-Daten sind inhomogen und häufig sehr, sehr komplex. Man hat eben verschiedene Objekte in OSM, die zusammenwirken und erst zusammen dann auch Kartenbilder geben und so weiter.

Das meisten von euch werden es kennen, wenn man versucht, mit den OSM-Daten umzugehen. Das ist eben nicht die sauberen Daten, die man so in so einem typischen akademischen Paper findet, wo beschrieben steht, wie man irgendeine Generalisierung machen kann vielleicht, sondern man muss irgendwie gucken, wie man damit umgeht, was da ist. OSM2PGS-Gel ist eine Software, die existiert seit 16 Jahren und wird ganz viel im OSM-Umfeld benutzt,

um eben OSM-Daten Richtung Karte zu bringen. Ich bin seit drei Jahren jetzt etwa in dem Projekt involviert. OSM2PGS-Gel ist nur ein Schritt in der Prozesskette. Wir fangen mit den OSM-Daten auf der einen Seite an,

benutzen OSM2PGS-Gel, um sie in den Postgres-Postgres-Datenbank zu laden und danach gibt es dann weitere Schritte mit dem Renderer-Software, zum Beispiel MEPNIC wurde im letzten Vortrag erwähnt oder so, um daraus die Karte zu generieren. Das kann aber auch ganz viele andere Varianten sein. Viele Leute machen da komplexe Analysen auch noch drauf dann auf den Daten

oder man kann Vector-Tiles draus machen und und und. Und weil OSM2PGS-Gel so flexibel ist und in ganz vielen Toolchains schon eingesetzt wird, ist es halt auch ein guter Punkt, um das da versuchen einzubauen. Ich habe dann verschiedene Verfahren ausgewählt, die ich mir gesagt habe, das will ich mal probieren, zu implementieren im Rahmen dieses Projektes. Ich kann nicht alle Probleme der Generalisierung in sechs Monaten lösen

und wollte aber beispielhaft mal so verschiedene Verfahren, die verschiedene Problemansätze und so weiter zeigen können, versuchen. Ich gehe da im Detail noch mal ein bisschen drauf ein. Basisarbeiten, OSM2PGS-Gel gibt es schon seit Langem. Ich arbeite seit 2020 da an dem Flex-Output, der es erlaubt.

Für die Leute, die OSM2PGS-Gel schon vor 16 Jahren eingesetzt haben, OSM2PGS-Gel heute ist ganz anders und kann viel viel mehr und ist wesentlich flexibler geworden. Ich kann genau sagen, welche Daten in welche Tabellen, in welche Spalten und welchen Typ sein sollen, wie die Konvertierung der OSM-Daten in Attribute in der Datenbank erfolgen soll und so weiter. Das ist schon gemacht. Ich habe jetzt im Rahmen dieses Projektes auch flexiblere Indexes und Expire-Outputs gemacht.

Das heißt, man kann genau auch sagen, ich möchte so eine Art von Index auf den Daten generieren und OSM2PGS-Gel kümmert sich darum, das zu machen. Und wenn Daten sich ändern, dann kann man über die Expire-Outputs genau sagen, wenn da eine Änderung erfolgt, dann schreibt bitte in die Tabelle einen Hinweis rein, dass da was sich geändert hat und damit es weiter verarbeitet werden kann.

Und ich habe jetzt ein Framework geschaffen, ein neues Tool. Der OSM2PGS-Gel-Scan heißt, das ist Teil jetzt der OSM2PGS-Gel-Programm geworden. Also es ist im gleichen Depository mit drin. Es ist ein getrenntes Binary. Wollen wir vielleicht mal später integrieren.

Es benutzt auch das gleiche Config-File. Aber weil es noch sehr experimentell ist, haben wir gesagt, wir machen es erstmal nochmal als getrenntes Binary. Aber es geht über die gleiche Lua-Konfiguration, lasst Sie es machen. Jetzt gehe ich mal ein bisschen drauf ein über die verschiedenen Strategien, die ich mir so angeschaut habe und überlegt habe, was man machen kann und was man implementiert. Das erste ganz simple, auch im vorigen Vortrag wurde es mir wieder erwähnt,

irgendeine Software kann nur einen Centroid berechnen. Aber der Centroid ist ein guter repräsentativer Punkt für einen Polygon, weil er häufig außerhalb des Polygons liegt. Es gibt verschiedene Verfahren, wie man einen Punkt finden kann in einem Polygon, wo man zum Beispiel ein Label hinschreiben kann. Oder wenn ich das Polygon irgendwann umso weiter raussuche

und das Polygon irgendwann verschwindet, dann will ich wenigstens noch diesen Punkt erhalten und wissen, da ist irgendwas. Und da gibt es verschiedene Möglichkeiten. Eine Sache ist dieser Pole of Inaccessibility oder das Zentrum, das Maximum Ascribed Circle. Das ist also der Punkt, der am weitesten vom Rand des Polygons entfernt ist.

Das ist manchmal ein ganz guter Punkt. Da gibt es in PostGIS auch eine Funktion, um den zu berechnen. Und das kann jetzt auch OZMTP GSG direct beim Import machen. Das heißt, ich muss auch nicht mehr ein riesengroßes Polygon importieren in die Datenbank und dann den Punkt berechnen und das Polygon wegschmeißen. Und ich kann es beim Import machen und spar mir ein bisschen Arbeit.

Und das sieht man in diesem Bild hier. Das ist glaube ich der Pole of Inaccessibility. Das ist der Punkt, den PostGIS berechnet. Point in Polygon, wie das heißt. Da gibt es auch eine Funktion. Point on Surface ist die Funktion. Und der würde diesen hier berechnen.

Der schwarze ist der Centroid. Da sieht man, der liegt in diesem Fall außerhalb. Also ich habe mir verschiedene Punkte angeguckt und dann den implementiert. Das nächste, was ein bisschen interessanter ist, sind Polygone zusammenfassen und vereinfachen. Also ganz typischer Use-Case ist, ich habe ganz viele Wälder

und die sind sehr, sehr kleinteilig gemapt bei OZM. Sehr kleine Stücke und häufig geht da auch vielleicht mal eine Straße durch oder eine Schneise oder so durch den Wald. Und wenn ich jetzt rauszoome, dann will ich natürlich, dass alle diese Details verschwinden. Und das heißt, ich habe die hier in grün dargestellt, die Originaldaten sozusagen. Aber was ich dann für die anderen Zoom-Level brauche,

ist das, was diese schwarze Umrandung darstellen soll. Nur eine grobe Form dieser Wälder, wo kleinere Features zu größeren teilweise zusammenfallen und so was. Und da gibt es ein Standardverfahren eigentlich, sage ich mal, wie man das implementieren kann. Ich nehme die Vektordaten, dann buffer ich die. Einmal mache ich es ein bisschen größer mit dem Buffer,

dann nehme ich nochmal den Buffer, mache sie wieder kleiner, mache es wieder größer und das macht dann die verschiedenen Ecken und Kanten, macht dieses Verfahren weg. Das ist eigentlich Standard-Ding, was jeder so benutzt, der diese Art von Sachen macht. Und das kann man auch in Postgres mit SQL implementieren. Es hat aber einen großen Nachteil, es ist super langsam.

Und man kann das Ganze aber auch im Raster-Space machen. Das heißt, ich nehme die Vektoren und raster sie in ein Bild. Also ich render sie quasi in ein Bild. Und dann kommt da so eine morphologische Operation Open-Close drauf, was letztlich genau das gleiche ist, wie der Buffer macht. Nur ich mache es mit Rasterpixeln. Und da mache ich aus dem Raster wieder Vektor.

Und obwohl das jetzt irgendwie aufwendiger klingt, funktioniert das sehr gut und ist viel, viel schneller. Weil diese Rasteroperation ist quasi kein Aufwand, für einen Rechner sowas zu machen. Und damit kann ich das dann verarbeiten. Ich habe das jetzt einfach mal als Beispiel.

Das sind jetzt hier in Neuseeland alle Wälder. Ich habe es im Moment laufen. Wer es mal ausprobieren will, auf test.osm2pgs.org läuft ein Vektor-Tile-Server. Da sind die aktuellen Open-Street-Map-Daten drauf. Nur für diese Wälder. Also das, was wir hier sehen sozusagen.

Nur die Wälder. Wenn man ganz reinzoomen, kriegt man die Originaldaten. Und dann gibt es drei vorverarbeitete Levels von Vereinfachungen. Und da wird nichts gekascht oder irgendwas. Das kommt jetzt so direkt aus der Datenbank, wenn man das ausprobiert. Und es sind minütlich aktualisierte Daten. Ich tue also die Open-Street-Map-Daten da einmal pro Minute reinfüttern,

die ich kriege. Und tue die kachelweise, die Sachen neu berechnen, die sich geändert haben. Das geht in ein paar Sekunden. Also das ist ein Ansatz, wo wir doch eine deutliche Verbesserung haben gegenüber dem, was man jetzt im SQL oder so etwas machen könnte. Einfach von der Geschwindigkeit her. Hier mal so ein Beispiel einfach, wie diese Konfiguration dann aussieht.

Ich muss in meinen Lua, also Open-Street-Map, osm2pgs.org wird über Lua-Skripte konfiguriert. Und da schreibe ich dann so was rein. Da gibt es diese Process-Scan-Funktion. Die wird osm2pgs.org im richtigen Moment aufrufen. Und dann kann ich dort meine Sachen reintun,

die dann bei der Generalisierung ausgeführt werden sollen. Ich sage jetzt, ich möchte die Generalisierung vom Typ Raster-Union laufen lassen. Der soll also den Forest-Table, alles, was da drin ist, nehmen und soll es generalisieren, den Forest-Scan reinschreiben. Und dann gibt es halt ein paar Parameter, die sagen, wie er das genau machen soll. Und so ähnlich werden all diese verschiedenen

Generalisierungsverfahren konfiguriert. Das ist jetzt ein ähnliches Beispiel. Siedlungsgebiete, wenn ich rauskriegen will, also typischer Fall ist, ich will ungefähr so sehen, hier ist das Ruhrgebiet und so weiter, dass man so ein bisschen sehen kann, wo sind die bebauten Gebiete in den Karten.

Da könnte man jetzt einfach sagen, ich nehme von Open-Street-Map die Polygone, die sagen, okay, hier ist Land-Use-Residential, Land-Use-Commercial und so weiter. Aber das ist nicht überall in der Welt gemapt. Da sieht man, wir müssen mit den schlechten Daten umgehen oder mit den unvollständigen Daten umgehen. Und in Europa funktioniert das recht gut, wenn man nur von diesen Polygonen ausgeht.

Aber wenn ich jetzt in Afrika gucke oder in Amerika, da ist es ganz viel, fehlen diese Land-Use-Polygone. Aber sind vielleicht Gebäude gemapt. Oder ich sehe einfach, da ist ein dichtes Straßennetz. Und das kann ich ja auch erkennen. Diese Generalisierung, die benutzt, wo es geht, diese Land-Cover-Polygone. Aber wo nicht, tue ich letztlich aus den Gebäuden

und da, wo viele Gebäude sind, bzw. dieses Straßennetz, letztlich gleiche Verfahren anwenden und kann dann die Siedlungsgebiete ableiten. Das ist jetzt mal ein Beispiel hier in Quito, der Hauptstadt von Ecuador. Da kann man also sehen, das helle Gebiet ist das, wo er jetzt erkannt hat, dass das Siedlungsgebiete hat.

Und kann man nicht so gut jetzt hier sehen. Aber das ist eben da, wo Gebäude sind oder wo enge Straßennetze sind. Und wenn man dann rauszoomt, dann ergibt sich da ein ganz gutes Bild. Das letzte, was ich probiert habe, sind Schlussnetzwerke. Da bin ich so ein bisschen abgewichen von meiner Idee,

andere nur zu implementieren, was andere Leute schon sich ausgedacht haben und haben selber mir was ausgedacht. Und das hat dann auch nicht so ganz funktioniert. Aber ich will mal sagen, was ich probiert habe, Flüsse werden in Open Street Map sowohl als Linien, als auch, wenn sie breit genug sind, als Polygona erfasst. Also hier haben wir mal ein Stück der Elbe, die hier langfließt und irgendeinen Zufluss.

Und die Flächen außenrum sind hier straffiert dargestellt. Und ich muss als erstes wissen, wenn ich wissen will, welche Flüsse ich zeichnen möchte, wenn ich weiter rauszoome, dann sind es ja die, die breiter sind. Sag ich mal in erster Linie. Das heißt, ich gucke, wie breit sind diese Flächen. Das geht wieder mit dem Maximum Inscribed Circle.

Und dann kann ich diese Information auf die Linien übertragen. Und dann muss ich gucken, dass ich die Breite der Flüsse sollten nach unten immer nur zunehmen, weil sonst habe ich Flüsse, die irgendwo erscheinen und dann im Nichts verschwinden, weil sie mal kurz dünner werden, weil sie irgendwie durchs enge Rheintal fließen oder sowas.

Und dann kann ich das zusammensetzen. Und das ist das Ergebnis. Man sieht, man braucht noch ein bisschen Arbeit an einigen Stellen. Funktioniert ganz gut. Also blau sind die Ursprungsdaten. Rot sind die Flüsse, die ich da rausgezogen habe, als die wichtigeren. An einigen Stellen kann man also den Rhein, kann man zum Beispiel recht gut erkennen, bis er dann da unten im großen Kuddelmodel verschwindet.

Und über die Po-Ebene da unten, da reden wir gar nicht. Also, da ist noch ein bisschen was zu machen. Aber ja, wäre ja langweilig, wenn alles schon gehen würde. Und das Verfahren habe ich auch noch implementiert. Das Create Isolation, da gibt es einen Vortrag von Matthias Gröber auf der letzten FOSGIS, wer die Details haben will.

Da geht es letztlich darum, dass ich eben entscheide, welche Städte will ich denn jetzt auf der Karte erscheinen lassen. Und ich möchte einerseits nicht total leere Gebiete haben, aber andererseits möchte ich auch nicht, dass irgendwo da, wo ganz viele Sachen auf dem Haufen sind, ganz viele Städte, kann ich nicht irgendwie 17 Punkte und Labels unterbringen.

Da muss ich die wichtigen rausziehen. Und das versucht, dieses Verfahren zu machen. Und wenn man das jetzt zum Beispiel auf Amerika anwendet, dann sieht es schon ein bisschen besser aus. Ich weiß aber nicht, warum Lubbock da drauf ist. Von dem habe ich jetzt noch nie gehört. Wobei das benutzt hier jetzt auch nicht nur die Population Numbers,

sondern benutzt, ich ziehe oder ist schon vorbereitet, die Nominate, denen habe ich die Idee geklaut aus der Wikipedia, die Informationen raus, wie wichtig es ist, Seiten, auf die viele Links zeigen, sind wichtiger.

Und dadurch habe ich eine Wichtigkeitsmetrik, die nicht nur an der Anzahl der Personen hängt, die da in dem Ort vielleicht wohnen, sondern auch vielleicht ein touristischer Ort, der vielleicht auf der Karte erscheinen soll, wo vielleicht nicht viele Leute, aber ist sehr bekannt, dann soll der vielleicht eh auf die Karte. Aber das sind so Sachen, der kann dann eben jeder sich so konfigurieren, wie er haben möchte.

Wenn ich die Sachen, die ich jetzt mal so gezeigt habe, zusammentue, dann kommt jetzt zum Beispiel mal so eine Karte raus. Also hier mit den Flächen, verschiedene Flächennutzungen vereinfacht dargestellt, die Siedlungsgebiete und die Städte. Also Performance ist bei den teilbasierten Verfahren, also insbesondere diese Lentius-Vereinfachung ist sehr gut.

Ich kann sehr schnell über diese Raster-Processing arbeiten. Und es skaliert auch mit der Anzahl der CPUs. Das geht nur deswegen so schnell in wenigen Sekunden, weil ich 24 CPUs auf der Maschine habe und auch 24 CPUs ausnutzen kann an der Stelle. Die Discrete Isolation lasse ich einfach im ganzen Planeten laufen, dauert irgendwie 20 Minuten, glaube ich, oder so was, wenn ich das mit allem was mache, was als Play City getaggt ist.

Das ist also auch völlig im Rahmen. Genau, Stand der Dinge ist, in der aktuell veröffentlichten Version, von ein paar Wochen veröffentlichten Version 181, ist dieser Pull-of-Inaccessibility-Algorithmus bereits drin. Diese flexible Index-Konfiguration ist im OSM2PKS-Geld drin, kann man auch für viele andere Sachen gut brauchen und viele kleine Vorarbeiten habe ich da auch schon drin.

Und in der nächsten Version wird es eben diese noch als experimentell gekennzeichnete, aber wird es diese Generalisierung geben. Also man kann jetzt den Master Branch sich einfach runterladen und kann damit schon mal rumspielen. Und es wäre auch schön, wenn einige Leute das tun würden, mir da Feedback geben. Das ist alles erst ein Anfang. Es gibt noch ganz viele Probleme, die wir lösen müssen.

Wir müssen Gebäudeumrisse vereinfachen, Grenzen, Straßennetzwerke und so weiter. Da gibt es ganz viele Sachen, die man angehen möchte. Ich konnte jetzt nur eine gewisse Menge an Verfahren mal ausprobieren, aber ich muss mal irgendwo anfangen und sehen und Erfahrungen sammeln. Und ich hoffe auch, das Wissen von verschiedenen Leuten dann bündeln,

weil jeder hat da so seine Tipps und Tricks und Ideen, wo ja Generalisierung bei seinen Karten schon so macht. Genau, deswegen bin ich da auf eure Erfahrungen auch angewiesen und würde gerne hören, was ihr so alles gemacht habt und was wie auch OSM2P, GSKL vielleicht bei euch funktioniert. Vielen Dank an den Proletarbefund und an das BMWF,

dass sie das gefördert haben. Und ja, kann ich nur noch sagen, vielen Dank. Und heute um 17 Uhr gibt es eine BOV-Session zur Generalisierung. Das ist dann irgendwo da oben im zweiten Stock. 17 bis 18 Uhr, wer da Lust hat, noch da dazuzukommen. Da kann man einfach noch mal ein paar Ideen austauschen

oder Fragen beantworten oder Wünsche äußern und so weiter. Vielen Dank. So, vielen Dank, Jochen, für den spannenden Einblick, den du uns da gegeben hast. Online sind schon Fragen eingetrudelt. Und zwar die erste ist, es gibt es auch Ansätze,

bei denen nicht nur einzelne Objektarten generalisiert werden, sondern der gesamte Kontext mit unterschiedlichen Objekten. Wie ich es verstanden habe, war das ja mit Land use so. Ich weiß nicht, gibt es da noch andere Beispiele? Nein, also beim Land use ist es so, dass man sagen kann, ich habe hier eine Tabelle und da sind 17 Arten von Land use drin.

Und dann werden die alle für sich allerdings generalisiert und dann wieder in die Tagetabelle reingeschrieben. Also so weit geht es. Aber wir sind noch weit entfernt davon, dass wir sagen können, so was wie die Verdrängung, die alle Leute haben wollen, dass man sagen kann, okay, hier ist ein Fluss und da ist eine Straße daneben und daneben steht ein Baum.

Und wenn ich jetzt irgendwie die Straße breiter zeichne, dann muss ich den Fluss ein bisschen verschieben und dann muss ich den Baum versetzen, damit er immer noch auf der richtigen Seite von der Straße steht. Da sind wir noch ein ganzes Stück von entfernt. Das ist so nicht machbar, da brauchen wir noch viel mehr. Und das ist so mal nicht leistbar. Das ist ein richtig großes Projekt.

Da brauchen wir ein bisschen andere Ressourcen für uns. Okay, aber vielleicht sind die Grundstrukturen schon geschaffen, dass man das dann noch irgendwann einbauen kann. Dann eine weitere Frage ist, wie generalisiere ich einen verteilten Standort, z.B. die HU in Mitte und den Atlashof?

Wie generalisiere ich? Das kommt drauf an. Das kommt drauf an. Naja, man muss halt wissen, was man will, wenn man sagt, wenn man weit genug rauszoomt, dann ist es eh wieder alles das Gleiche. Dann sagt man, der Punkt ist einfach auf Berlin. Kann man so generell nicht sagen.

Okay, dann eine weitere Frage mit Kommentaren. Zunächst danke an Jochen, dass er dieses 12 Jahre als Problem angeht, bei dem OSM verglichen mit den properitären Diensten stark abfällt und die räumliche Orientierung in unbekannten Gebieten sehr erschwert. Ist auch eine konfigurierbare Priorität bei der Beschriftung wie beispielsweise auf Kommunen, Landkreise, Staaten, Straßen oder Flüsse denkbar?

Denkbar ist alles. Da ist mir erst nicht ganz klar, worauf die Frage jetzt abzielt. Ja, weiß ich nicht. Soll mich mal so ansprechen. Okay, dann gibt es Fragen aus dem Publikum.

Verliert die Aktualität der Karte nicht stark an Bedeutung bei einer größeren Generalisierung? Also New York wird ja nicht unbedingt verschwinden. Das heißt, wenn man das ein halbes Jahr rechnet,

wird das schon noch okay sein? Das ist natürlich richtig. Also bei manchen Generalisierungsverfahren, wie jetzt zum Beispiel bei den Städten. Es ist jetzt sehr unwahrscheinlich, dass eine Stadt innerhalb von einer Woche plötzlich doppelt so viele Einwohner hat und deswegen irgendwie höher auf der Liste erscheinen soll. Das ist richtig. Andererseits ist es natürlich aber auch so, dass die Open-Street-Map-Daten vielleicht jetzt nicht irgendwie in Deutschland,

aber wenn man auch an andere Länder denkt, doch teilweise sehr unvollständig sind und Sachen einfach irgendwie total fehlen oder manchmal auch vielleicht ganz falsch eingetragen sind. Und dann ist man eben froh, wenn man doch ergänzt, dass die dann schneller da sind. Die Geschwindigkeit, mit der diese Generalisierung passiert, ist jetzt nicht für jeden Fall wichtig.

Das Interessante ist ja aber auch, es geht ja nicht nur um eine Generalisierung, sondern es geht ja um ganz, ganz viele verschiedene Layer und Themen, die man irgendwie generalisieren will. Und wenn jetzt schon ein Layer super langsam ist und einen Tag braucht, dann brauchen halt alle zusammen irgendwie ein paar Wochen. Und worum es mir hier geht, wenn ich einen in ein paar Minuten rechnen kann,

dann kann ich halt alle zusammen da und dann immer vielleicht noch einen Tag. Also man muss mal schauen, wie es in der Praxis sich entwickelt. Ich denke, einige Generalisierungen wird man immer machen wollen und möglichst zeitnah machen wollen, damit Daten, die sich eben vielleicht doch mal ändern.

Also nehmen wir mal an, vor ein paar Jahren war es die Brücke da in Italien eingestürzt oder sowas. Da ist dann plötzlich ein Loch im Netz, möchte man vielleicht schnell darstellen können oder sowas. Weiß ich nicht. Müssen wir ausprobieren, aber es ist ja auch völlig in Ordnung,

wenn man sagt, ich lasse es nur einmal pro Woche laufen oder so. Die Schnelligkeit hat auch was damit zu tun, nicht nur, wie schnell es geht, sondern eben auch, wie wenig Ressourcen ich brauche. Das heißt eben, ich kann es auf dem Laptop vielleicht auch noch laufen lassen, dann dauert es da vielleicht ein bisschen länger, aber ich kann es wenigstens überhaupt.

Ja, ich finde es super cool. Ich bin einer von diesen Menschen, die früher USM2 PGA-Scale benutzt haben und damit sehr kämpfen mussten und freue mich heute total, dass so viele Dinge offenbar passiert sind. Und die Frage ist eigentlich, bist du bei der nächsten Runde vom Prototype Fund auch dabei oder hat sich der Prototyp damit sozusagen erschöpft? Also ich bin jetzt konkret bei der nächsten Runde nicht dabei

und wer weiß, vielleicht mache ich das ja mal wieder oder vielleicht ergeben sich irgendwelche anderen Möglichkeiten der Finanzierung oder Sachen auszuprobieren und so weiter. Im Moment bin ich jetzt mal ganz froh, dass sich das jetzt auch mal ein bisschen setzen kann, weil man kann nicht immer voll speed an irgendwas arbeiten, sondern ab und zu braucht man es auch mal ein bisschen Zeit,

dass es sich setzt und dass Leute es auch ausprobieren. Also ich glaube, dass es jetzt der wichtigste nächste Schritt ist, dass andere Leute es ausprobieren, weil man selbst natürlich auch betriebsblind wird nach einer Weile, wenn man immer nur das baut, was man denkt, was man selber braucht und nicht sieht, dass andere Leute vielleicht ein bisschen andere Ideen haben und andere Wünsche und so. Das heißt, im Moment geht es jetzt erstmal so auf kleinerer Flamme weiter

aber vielleicht gibt es ja auch andere Leute, die Interesse haben, das weiter zu führen und da sich in die Entwicklung mit einzubringen und sich fanden zu lassen oder so. Ja, mal schauen. Ok, gibt es noch weitere Fragen?

Offenbar nicht. Offenbar nicht, die Leute wollen alles Mittag essen. Das glaube ich auch, ja. Dann vielen Dank nochmal Jochen für den spannenden Vortrag. Dann weitere Fragen können dann auch noch später geklärt werden und ich erinnere noch mal an das Gruppenfoto, das heute Nachmittag stattfindet und wünsche eine schöne Mittagspause.