Pipelinebasierte Erzeugung von Karten
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 95 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/36137 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
00:00
Hidden-Markov-ModellStochastische ErzeugungWeb logErzeugendePhysikalische GrößeChipkarteDatensatzp-BlockVorlesung/Konferenz
00:30
Stochastische ErzeugungIterationChipkarteSoftwareVektor <Datentyp>HypermediaComputeranimationVorlesung/Konferenz
01:20
ChipkarteErzeugendeComputeranimation
01:45
DatenbankVolumenvisualisierungGruppoidPostgreSQLJSONFlussdiagramm
02:24
Atomarität <Informatik>SQLPostgreSQLSpeicherbedarfLesen <Datenverarbeitung>SpeicherkarteDateiTreiber <Programm>Shape <Informatik>DatenbankPostgreSQLErzeugendeGeodätische LinieKettenregelDatenformatRichtungSpeicherbedarfUNIXChipkarteKennzahlStruktur <Mathematik>Tabellep-BlockVektor <Datentyp>RollbewegungNabel <Mathematik>Inverser LimesGrundraumComputeranimation
07:03
Inverser LimesSQLiteFaktorisierungNetzadresseDatensatzDateiformatUpdateNullSQLitePhysikalische GrößeComputeranimation
08:54
BinärdatenSQLiteSQLiteDatenformatp-BlockNabel <Mathematik>Computeranimation
09:29
Ein-AusgabeBetafunktionDateiformatEin-AusgabeZahlenbereichSoftwaretestVersion <Informatik>DatenformatMagnetbandlaufwerkRegistrierung <Bildverarbeitung>BenchmarkComputeranimation
11:10
MARKUS <Unternehmensspiel>p-BlockDienst <Informatik>DatenformatMagnetbandlaufwerkComputeranimation
12:21
RechenwerkPhysikalische GrößeMeterQuelle <Physik>Computeranimation
12:52
CW-KomplexSIMPL <Programmiersprache>ParametersystemDateiKlasse <Mathematik>AuswahlverfahrenComputeranimation
14:50
ProgrammHardwareMARKUS <Unternehmensspiel>DatenformatGruppoidVersion <Informatik>StandardabweichungPostgreSQLHardwareVorlesung/Konferenz
16:41
DatenformatÄhnlichkeitsgeometrieElementargeometrieVolumenvisualisierungDatenbankHardwareFestplatteUnterprogrammSchnittstelleFilter <Informatik>RAMProzess <Physik>DatenstrukturRechenwerkMomentenproblemProgrammiergerätGeometrieDatenmodellSenderVorlesung/Konferenz
21:54
p-BlockNichtflüchtiger SpeicherDynamikLinieDateiformatIndexCASDatenbankVolumenvisualisierungRichtungLesen <Datenverarbeitung>Attributierte GrammatikPayPalMatroidEin-AusgabePhysikalische GrößeSchnittstelleKonferenz Europäischer StatistikerVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:08
Ja, dann herzlich willkommen zurück zum dritten Vortrag unseres Blogs. Diesmal wird uns Thomas Einblicke in die pipeline-basierte Erzeugung von Karten geben, mit denen es möglich ist, auch mit wenig Ressourcen große Datensätze zu verarbeiten.
00:27
Vielen Dank. Dankeschön. Genau, ich möchte da so ein bisschen an ein paar Themen anknüpfen, die im letzten Jahr ungefähr entstanden sind, so ein paar Gedanken, die da mehrere iterationen durchlebt haben.
00:42
Ich habe vergangenes Jahr auf der Foskis-Konferenz einen Überblick über Rendering-Techniken und Software gehalten. Muss man nicht gesehen haben, um das jetzt hier zu verstehen, aber falls jemand verstehen möchte, was alle Möglichkeiten sind, um zu rendern, also so eben dieses Bitmap-Vector-Hybrid
01:02
und Vektor mit Client-Site-Rendering, wie das so aussieht, der soll noch mal in media.ccc.de ins Archiv schauen. Da gibt es noch mal den kompletten Talk. Ansonsten möchte ich direkt einsteigen, denn was ist denn der Status Quo, wenn wir eben Karten erzeugen wollen?
01:21
Natürlich gibt es die ganzen manuellen Ansatzweisen, die Christoph im vorangegangenen Vortrag auch erklärt hat, wie man eben von Hand dabei gehen kann und Karten erzeugen kann. Aber eben wenn es um das automatisierte Erzeugen geht, sieht das dann meistens so aus,
01:41
wir legen irgendwie mit dem Open-Street-Map-Planeten los, importieren den in eine Datenbank und geben sie dann einem Renderer vor. Und da gibt es immer mehrere Probleme. Das ist einmal Postgres hat einen inhärenten operativen Aufwand,
02:01
da muss sich irgendjemand mit auskennen, da muss irgendjemand operieren, betreiben, optimieren, ausreichend rammen und so weiter und so fort. Und nichtsdestotrotz haben wir aber immer zwei Flaschenhälse, das ist eigentlich immer beim Importieren, was immer relativ lange dauert. Und dann aber auch beim Rendern an sich, da haben wir auch immer einen Flaschenhals,
02:20
weil wir dann die Daten wieder aus der Datenbank rausholen müssen. Postgres hat echt richtig viele Features und richtig viele Vorteile. Wir können damit SQL beigehen, wir können beliebige Daten aus einer Datenbank rausholen. Es hat SID, MVCC Transaktion, also ich kann da parallel Dinge machen, ohne dass sich die Datenbank korrumpiert.
02:40
Ich kann Indizes setzen, das heißt, wenn ich mich umentscheide und irgendwas anderes mit der Datenbank mache, kann ich danach noch Indizes erzeugen. Ich habe ein komplettes Rollenmanagement, ja, ich kann da eben User anlegen, die verwalten. Alles ist eben skriptbar, man kann da Failover realisieren und vieles, vieles mehr. Es hat aber auch ein paar Nachteile.
03:02
Zum Beispiel, wie sieht es denn mit der Performance aus? Die ist meistens nicht so berauschend. Der operative Aufwand, den ich gerade eben schon angemerkt habe, aber auch der Speicherbedarf. Das sind halt eben immer Punkte, wenn man mit größeren Datenmengen arbeitet, fällt das dann immer wieder auf, dass das zu Problemen führt. Ja, und die Frage stellt sich,
03:22
brauchen wir all das, was da in der linken Spalte steht, um eine Karte ändern zu können? Ja, brauchen wir unbedingt ein Rollenmanagement auf der Datenbank? Häufig wird das von irgendeiner Anwendung schon geklärt. Und deshalb habe ich da einen Gegenvorschlag, das zu simplifizieren und diesen ganzen Postgresstack
03:42
gegen ein einziges Zeichen zu ersetzen, und zwar die Pipe. Im Unix-Universum kann man da eben mit dieser Pipe Applikation verknüpfen. Das heißt, das, was aus einem Programm rauskommt, kann ich direkt in ein zweites pumpen, ohne es irgendwo zwischendurch zu speichern, ohne eine Datenbank zu brauchen,
04:00
ohne es nochmal in extra Datei zu tun. Und da könnten wir mit einem Ansatz beigehen, dass wir zum Beispiel Daten erstmal parsen, dann machen wir einen MapReduce, also irgendeine Art von Transformation von Daten, weglassen, filtern, umprojizieren und dann im letzten Schritt rendern. Da können natürlich beliebig viele Dinge noch dazwischen sein,
04:22
da kann man andere Datenquellen, da kann man Datenquellen, die zum Beispiel von Hand bearbeitet wurden, noch reinlegen, aber dass man halt im Prinzip so eine durchgehende Kette hat, in der man nicht nochmal mit einer Datenbank handeln muss. Schritt eins, wir müssen erstmal OSM-Daten in Geodaten wandeln.
04:41
OSM-Daten sind eigentlich keine geographischen Daten, das ist erstmal nur irgendwie so ein Blob. Das müssen wir in Geodaten wandeln, dann können wir es halt filtern, das ist so das, was man üblicherweise immer macht. Und dann also matten, transformieren, also sowas wie integer Werte ausbilden
05:02
oder one-way vereinheitlichen, unifizieren, all sowas. Und dann ins Zielformat konvertieren. Ja, das können Vektortiles sein, das können aber auch Bitmaps sein, sowas in die Richtung. Nur, wie wollen wir das eigentlich machen? Wie kriegt man das denn hin? Weil bisher hatten wir eben immer diesen Kleber,
05:21
Postgres, Postgis, was im Prinzip alles überall kompatibel ist und wo wir das im Prinzip zusammenkleben können. Das hätten wir damit ja nicht mehr, weil wir ja nur noch diese Pipe haben. Ja, wir bräuchten jetzt eben Tools, die jeweils genau eine Sache tun. Also wir müssten eben diese Unix-Philosophie, die es da immer gab, ja, ein Tool für eine Aufgabe,
05:43
im Prinzip auf die Spitze treiben. Ja, dafür bräuchten wir aber ein portables Datenformat. Ja, wieso nehmen wir dann nicht einfach Shapefiles? Nehmen wir doch einfach Shapefiles, die gibt's ja schon. Dann können wir da alles reintun und dann holen wir das wieder raus.
06:01
Nee, machen wir's mal nicht. Das ist Quatsch, oder? War Blödsinn. Ja, den Shapefiles ist kein geeignetes Format. Was bräuchte denn ein geeignetes Format? Das bräuchte Performance. Ja, also wir müssten linear schnell schreiben können und wir müssen parallelisiert daraus lesen können. Wenn wir halt anfangen, eben Planeten zu verarbeiten,
06:22
müssen wir eben entsprechende Performance-Kennzahlen ransetzen. Es muss skalierbar sein. Das heißt, Shapefiles, zwei Gigabyte-Limit, da passt nicht viel rein. Wir brauchen ein Datenformat, was auch mit Dutzenden von Gigabyte klarkommt. Wir brauchen eine Textstruktur, Attributtabellen,
06:40
alles schön und gut. Aber eigentlich wollen wir halt eine freie Textstruktur haben, damit wir halt individualisiert beigehen können und sehr flexibel sind. Und das Ganze muss irgendwie zukunftskompatibel sein. Das heißt, wir müssen auch nach einer Weile feststellen können, ah, dieses Feature, das hätten wir eigentlich schon immer gerne gehabt. Bauen wir es doch jetzt ein.
07:00
Das geht halt mit sowas wie Shape nicht. Evaluieren wir doch mal die Punkte für so ein paar populäre Formate. Shapefile Performance, geht schon einigermaßen. Skalierbar, schlecht, zwei Gigabyte-Limit. Textstruktur, nicht wirklich, zukunftskompatibel.
07:22
Wann gab es das letzte Update für ein Shapefile? Erklärt sich von alleine. Gut, dann nehmen wir doch einfach GeoJSON. GeoJSON macht ja jetzt irgendwie jeder. Wie sieht es dann aus mit der Performance? Ist ein kontinuierlicher Datenblock, ist ein bisschen schlecht zu verarbeiten, nicht so richtig gut. Skalierbar, wie gesagt,
07:40
ich kann es nur von vorne bis hinten durchnudeln, geht so. Textstruktur, ja, gibt es. Zukunftskompatibilität, ja GeoJSON, haben wir jetzt einmal, das ist relativ schwierig zu ändern. Gut, nehmen wir doch GeoPackage. GeoPackage, ich glaube, hier gibt es auch noch, oder gab es schon Vorträge zum Thema GeoPackage. Wie sieht es denn mit der Performance aus?
08:02
Ja, und da fängt das Problem an, wir arbeiten hier mit SQLite. SQLite ist für kleine Datensätze durchaus geeignet. Aber wenn es darum geht, irgendwie was Größeres zu verarbeiten, da haben wir halt einen Bottleneck. Und deshalb ist es auch schlecht skalierbar, meiner Meinung nach. Textstruktur, zukunftskompatibel, ja, das haut schon hinten, meiner Meinung nach.
08:20
Also wir haben da irgendwie so verschiedene Faktoren, die wir berücksichtigen müssen. Das ist halt Flexibilität und Performance, vor allem, meiner Meinung nach. Und die Dinger, die es da gibt, die sind halt irgendwo mit schlechter Performance, aber sehr flexibel oder irgendwie so mäßige Flexibilität, mit etwas besserer Performance, ist irgendwie alles nicht so, das gäbe von mal.
08:42
Eigentlich wollen wir irgendwas da oben haben. Eigentlich wollen wir etwas, was ziemlich flexibel ist und sehr performant. Und da braucht man, meiner Meinung nach, Mut zu neuem, ohne Änderung, keinen Fortschritt. Und was bräuchte denn so ein neues Format, das wir da erarbeiten würden?
09:01
Es müsste binär sein. Denn nur mit binären Datenformaten würden wir ausreichende Performance erreichen. Es muss irgendwie Blöcke haben und streambar sein. Es muss ein einzelner Filestream sein, also nicht wie so bei Shapefiles, was eigentlich kein einzelnes File ist, sondern irgendwie ein Verzeichnis. Es sollte vermutlich nicht SQLite sein,
09:20
weil da einfach die Performance nicht erreichbar ist. Und es sollte auch nicht irgendwas obskures sein, was irgendwie nicht dokumentiert ist. Sondern es muss halt offen und er weiterbar bleiben. Und da habe ich einen Vorschlag. Das ist noch total Beta. Und da muss noch viel diskutiert werden. Und da muss auch noch viel implementiert werden. Das spart ein Dateiformat.
09:42
Basiert auf Protocol Buffers und WKB, wobei das vollkommen flexibel ist. Das ist auch versionierbar und das ist auch in Zukunft ändernbar. Es gibt eine offene Spezifikation. Es gibt eine Referenzimplementierung. Und in meinen, ich wollte sagen,
10:02
von der deutschen Automobilwirtschaft betriebenen Tests, ist Quatsch, nein. Ich habe die Zahlen nicht fälschen lassen. Nein, aber in meinen kleinen Tests kam raus, okay, es ist ungefähr 50% kleiner als GeoJSON Performance. Müsste man alles mal durchbenchmarken. Ich habe da relativ große Hoffnung. Das Ganze ist Version 0.
10:22
Da müssen wir mal drüber diskutieren. Also, die Folien sind verlinkt. Wenn jemand irgendwie schon mal mit Geodatenformaten mal ganz low level gearbeitet hat, sollte sich das vielleicht mal angucken. Ich wäre nämlich sehr froh über Input. Und das Ziel ist, dass man eben Daten als Stream verarbeiten kann.
10:44
Dass wir sagen können, okay, wir nehmen einen Planeten, legen da irgendeinen Mapping an und geben das an irgendeinen Prozess, der zum Beispiel Vektor-Teils rausrendert. Das ist etwas, was heute schon funktioniert. Also, diese Tools habe ich schon gebaut. Aber wie könnte es in der Zukunft aussehen? Es könnte aussehen, dass zum Beispiel andere Tools da reingreifen
11:01
und eben das Datenformat halt rausschreiben. Also, hier zum Beispiel aus mir, was das noch nicht tut und vielleicht irgendwann Jochen, no pressure. Genau, dass man da irgendwie konvertieren könnte. Es könnte aber auch heißen, dass die Tools, die ich jetzt hier ins Paket mit reingebracht habe,
11:21
gar nicht mehr gebraucht werden, sondern dass wir irgendwann beliebige Tools da mit reingeben könnten. Das heißt, wir könnten sagen, ein Tool verarbeitet den Teil der Daten und das nächste Tool, das dann wiederum den Stream bekommt, verarbeitet andere Daten. Und dadurch könnten wir eben durch dieses Datenformat relativ austauschbare Blöcke haben.
11:41
Und jeder könnte halt viel schneller da reingreifen und das verarbeiten. Was fehlt denn noch heute? Meiner Meinung nach fehlt irgendein Markup oder irgendeine Möglichkeit, eben diese Transformation zu definieren. Also, wie schreibe ich denn jetzt nieder,
12:00
wie Daten verarbeitet werden sollen? Also, zum Beispiel, welche Tags interessieren mich überhaupt aus den OSM-Daten? Möchte ich zum Beispiel das MacSpeed-Tag rausnehmen oder das Access-Tag? Oder möchte ich diese Daten, die dort drin stehen, auf eine bestimmte Art und Weise normalisieren, zum Beispiel, indem ich sie in Booleans umwandle oder so was in einer Art? Dafür bräuchten wir meiner Meinung nach eine Sprache.
12:23
Also hier ein Beispiel, ich hab da irgendwie eine Linie, ich hab schon Line-Strings draus erzeugt aus den OSM-Daten und möchte jetzt zum Beispiel sagen, alle Highway Primaries sollen auf einen Transportation Layer geschrieben werden und gleichzeitig sollen sie Class Primary haben. Und irgendwie das Max-Height,
12:41
was hier in irgendwie so komischen esoterischen Einheiten angegeben ist, das möchte ich in Meter umwandeln. Das ist ein konkretes Problem, was häufig auftaucht, wenn man eben OSM-Daten verarbeitet und dafür bräuchten wir halt irgendwie eine Sprache. Alan Kay sagte mal, Simple things should be simple, complex things should be possible,
13:00
also einfache Dinge müssen einfach sein, komplexe Dinge müssen möglich sein und in dem Credo müsste man eben was entwickeln. Es gibt eine kleine Implementierung, das ist meiner Meinung nach nicht die Zukunft, aber es ist etwas, was mein Problem temporär gelöst hatte. So eine kleine, jammelbasierte Sprache,
13:20
der man eben definieren kann, auf welche Tags matche ich? Also ich hab einen OSM-File und da kommen irgendwelche Daten rein und ich möchte zum Beispiel alle Railway mit einem beliebigen Value nehmen und möchte dann eben in die Ausgabe, das eben mit Layer Transportation, Class Railway und den MaxSpeed Parameter möchte ich zu IntCasten
13:41
und auch in den Schlüssel MaxSpeed wieder reinschreiben. Das wäre zum Beispiel eine Möglichkeit, um so Daten umzuwandeln. Da fehlen aber natürlich viele andere Dinge, wie zum Beispiel, wie übersetze ich Tags, also zum Beispiel insbesondere Lateinisierung oder eben Romanisierung oder
14:02
Transliteration und ähnliches. Genau. Nochmal das, was ich gerade eben kurz erklärt hatte, das Filterkriterium im Prinzip, worauf matche ich und was möchte ich am Ende rausgeben? Mit der entsprechenden Übernahme der Werte, also was war zum Beispiel in den Eingangsdaten drin,
14:20
was möchte ich nehmen und wie handele ich das dahingehend um? Da geht aber noch was, da brauchen wir Ideen, da brauchen wir Hilfe, denn es ist noch komplett unklar, wie so ein Format in der Zukunft aussehen könnte. Also es ist das, was ich jetzt gezeigt habe, das ist so ein kleines Beispiel, aber meiner Meinung nach
14:41
gibt es da noch viel mehr Probleme, die eben mit so einer Markup-Sprache gelöst werden könnten und ich denke, dass man sich da jetzt langsam hinbewegen muss und schauen muss, was eventuell mögliche Werkzeuge dafür wären. Was ich damit erreichen möchte, ist eine größere Flexibilität bei der Verarbeitung von Daten mit weniger
15:01
Programmieraufwand, also dass man eben nicht mehr irgendwie kompliziert irgendwelche Files öffnen muss und dann und da irgendwelche Operationen zu machen, die eigentlich total trivial sind, sondern dass man eventuell später einfach in seiner Idee sagt, alles klar, ich möchte jetzt folgende Tags nehmen und die auf folgende Art und Weise umwandeln und dann dadurch eben sehr
15:21
einfach mit OSM-Daten zum Beispiel verarbeiten könnte. Es geht aber auch darum, schneller Daten zu verarbeiten mit weniger Hardware. Heute haben wir das Problem, dass so ein OSM-Planet einfach in der Postgres extrem viele Ressourcen braucht und dass es gar nicht so schnell ist. Ich glaube, dass wir mit existierender Hardware viel schneller zum Ziel kommen
15:41
könnten, wenn wir eben so ein pipelinebasiertes Paradigma verinnerlichen. Aber auch weniger Points of Failure, also dass wir zum Beispiel nicht einen extra Datenlagenadministrator brauchen, nur deshalb, damit Metnik irgendwie aus der Postgres die
16:00
Daten rausladen kann. Es gibt noch viel zu tun. Das waren so ein paar Vorschläge. Es gibt ein paar Tools, die schon implementiert sind. Es gibt eine Version 0 des Standards. Es gibt diese SmartCup, was sehr rudimentär implementiert ist, wo es aber meiner Meinung nach eine richtige Version
16:20
von geben sollte. Da sollte jemand wirklich nochmal mit einem rütteligen Ansatz beigehen. Aber lasst uns die Zukunft gemeinsam bauen. Lasst uns auf vernünftige Standards einigen und das auch gemeinsam gestalten. Jetzt wäre ich bereit für eine Diskussion. Vielen Dank.
16:46
Vielen Dank für diese spannenden Einblicke. Was sind denn hier schon Fragen?
17:01
Ich habe letztes Jahr in Passau über etwas ganz Ähnliches geredet. Der Titel hieß universelle Vektorteile oder Verlustfreie. Deswegen habe ich auch über das Problem nachgedacht. Aber an einer Stelle hast du mich irgendwie jetzt abgehängt, als du gesagt hast, man braucht wirklich nur eine Datenpipe. Ich gehe mit, wenn man sagt, man braucht nur ein File und kein Filesystem.
17:22
Aber dann muss das File random accessfähig sein. Das heißt, das ist dann doch wieder irgendeine Art Datenbank. Das heißt, diesen einen großen Schritt, dass man die Daten mal sortiert und indiziert oder so, den ja sonst die Datenbank macht. Irgendwo muss man den ja machen. Wo machst du ihn? Genau.
17:42
Es ist so gedacht. Deshalb plädiere ich für ein neues Datenformat, damit wir von oben nach unten arbeiten können. Das heißt, ich gehe einmal durch eine komplette Sammlung von Features und schaue eben, was ist jetzt relevant für meine Verarbeitung. Man könnte zum Beispiel sagen,
18:01
ich nehme jetzt den Planet, möchte jetzt aber nur z.B. bonden, rendern. Dann würde ich durch alle Features durchgehen und würde gucken, okay, liegen sie in einer Bounding Box. Und wenn sie nicht in einer Bounding Box liegen, schmeiße ich sie einfach weg. Und kann sie dann eben an eine Subroutine weitergeben, die dann irgendwas anderes mit den Daten anstellt. Und an der Stelle braucht man meiner Meinung nach keinen
18:21
random access, weil man einfach linear halt durchgeht und die relevanten Features einfach an Subprogramme weitergibt. Okay, das verstehe ich aber so. Du beschränkst dich sozusagen auf einen Filter und auf eine Bounding Box, die dich im ersten Schritt auf eine Datenmenge reduziert. Nicht unbedingt. Also man kann ja auch einfach alle Daten sequenziell verarbeiten.
18:58
Um nochmal auf diese Frage zurückzukommen,
19:00
das Problem mit solchen Bounding Box Queries zum Beispiel ist, dass dich ja die USM Ways and Relations interessieren und die haben gar keine Bounding Boxes, weil die überhaupt gar keine Geometrie haben. Sondern erst mal nur Referenzen auf Notes sind. Das heißt, in dem Moment, oder du musst erst einmal diese komplette Ersetzung machen, diese Indizes von dem Way of
19:20
Notes auflösen, bevor du überhaupt an Bounding Box Queries gehen kannst. Bis dahin brauchst du aber glaube ich doch erstmal entweder ein random access oder du brauchst temporäre Datenstrukturen, die diese zu schnell gibt. Oder 64 GB RAM. Ja. Also ja.
19:41
Das geht jetzt nicht mit deinem Ansatz zu widersprechen, wenn du sagst, du möchtest gerne, dass das auf sehr viel kleinere Hardware laufen kann. Und jetzt sagst du, ok, aber 64 GB RAM müssen sein. Genau. Nee, das, also 64 GB ist jetzt nicht meine Vorstellung von kleiner Hardware. Nee, also ist mir schon bewusst, das ist halt auch noch ein riesen Problem. Ich denke, dass man das
20:00
so lösen könnte, dass nicht jeder diesen Prozess durchführen muss. Weil eigentlich ist es Quatsch, jeder, der irgendwas mit OSM-Daten macht, macht heutzutage zuerst das Zusammenbauen der Geometrien. Ja, das heißt, wir laden uns den Planet runter, von Planet OSM Org, verarbeiten dann erstmal die Geometrien oder bauen es zu Geometrien zusammen und machen dann erstmal was.
20:21
Wenn wir vielleicht dahin kommen könnten, dass ich bereits dieses Ding runterladen kann, wo die Geometrien schon gebaut sind, hätten wir viel gewonnen. Weil dann müsste halt einer die Rechenleistung und die 64 GB RAM aufbringen. Und danach wäre es eigentlich ganz einfach. Und dann können wir auch sequenziell verarbeiten, meiner Meinung nach.
20:51
Mal ganz grundsätzlich. Du hast jetzt eine Idee für Prozess und für Datenformat
21:00
vorgestellt. Wäre es nicht sinnvoll, beides zu trennen, dass man die Prozessidee unabhängig vom Datenformat entwickelt und das Datenformat unabhängig von der Prozessidee? Total, total. Also ist auch komplett getrennt. Das Datenformat sagt auch nichts darüber, wie es jetzt verarbeitet werden soll. Sondern das Datenformat ist abgeschlossen und
21:20
ist auch wunderbar dafür geeignet, um es zum Beispiel auf der Festplatte abzulegen und archivieren oder später wieder auszugraben. Ich denke, das Format ist aus einer Prozessnotwendigkeit entstanden. Ist aber jetzt nicht unbedingt verbacken, dass man es nicht voneinander getrennt betrachten kann. Was mir noch aufgefallen ist, dass so ein neues Format
21:43
entsteht und fällt ja sozusagen mit Kompatibilität zu bestehenden Toolchains. Ist dieses OGR-Datenmodell mit deiner Vorstellung kompatibel? Weil wenn du da eine Schnittstelle bauen könntest, hätten zum Beispiel viele Renderer bereits eine Schnittstelle? Weiß ich nicht.
22:01
Das ist ja die Vektorvariante von dieser Githal-Bibliothek. Kann sein, dass das keine Key-Value-Geschichte kennt. Da weiß ich im Detail nicht so. Gut, da müsste man halt im Zweifelsfall Jochen, weißt du was zu? Ja, also irgendwie geht das mit diesen
22:20
Key-Values, weil die an GeoJSON verarbeiten kann mit OGR inzwischen. Das heißt, die haben das da irgendwie drangeflanscht. Also was es letztlich dann macht, ist einfach unendlich viele Layer anzulegen. Oder irgendwie sowas oder unendlich viele Attribute anzulegen. Dynamisch und das geht, aber das funktioniert nicht richtig und vernünftig. Also die Interfaces sind
22:41
dafür eigentlich nicht gemacht. Also das macht keinen Spaß. Also ich glaube, dass man an der Stelle vielleicht nicht versuchen sollte, in erster Linie kompatibel zu sein, weil sonst strengt man sich nachher so arg ein, dass man nichts vernünftiges mehr produziert. Was wir halt bei vielen Formaten gesehen haben. Genau, also der wichtige Schritt ist, sich hier von dem
23:01
zu lösen, was man bisher hat. Und wir können immerhin ja noch gucken, ob man noch einen Compatibility-Slayer irgendwie dazu kriegt. Aber wenn man damit anfängt, dann strengt man sich gleich so arg ein, dass es dann wahrscheinlich nix bringt.
23:25
Hast du dir statt Protokoll-Buffers auch Alternativen, die jetzt nicht allokieren, angeschaut? Also sowas wie Flat-Buffers oder Captain Proto oder Soli-Richtungen? Ja, nee, habe ich nicht. Das wäre denkbar.
23:41
Also das Encoding bzw. das Serialisierungsformat ist unten auch tauschbar theoretisch. Das heißt, wenn man feststellt, jetzt im Diskussions- und Entwicklungsprozess, ja okay, Message-Pack, Flat-Buffers, was auch immer, irgendeins von denen wäre viel geeigneter, setzt man die Versionsnummer um eins hoch und kann es mit dem anderen Format
24:02
serialisieren. Also es ist extra so gedacht, dass man das austauschen kann. Es ist auch so, dass ich jetzt WKB angenommen habe, weil das halt relativ verbreitet ist. Man kann es irgendwie, selbst aus einer Post-Kiss kann man WKB rausholen. Wenn wir aber sagen, wir wollen lieber Tiny-WKB, weil es noch kleiner ist,
24:20
könnte man das auch tun. Also an jeder Stelle ist es austauschbar im Prinzip.
24:43
Zu den Performance-Überlegungen. Wenn man jetzt eben nicht die gesamten Input-Daten für die Weiterverarbeitung braucht, aber im Voraus nicht weiß welche und deswegen das dynamisch machen können muss, dann hat man ja bei der Pipeline das Problem, dass man trotzdem die ganzen Daten lesen muss, um sie zu filtern.
25:01
Bei der Datenbank kann man mit einem Index sich eigentlich genau das rausholen, was jetzt angefragt ist. Wie kann dann der Pipeline-Approach da performanter sein? Genau, das lineare Lesen ist in aller Regel kein großes Problem. Wenn ich einfach große Blöcke lese und das einfach
25:21
durchziehe und kein random read habe, sind die entsprechenden CPU- und Memory-Pipelines einfach extrem schnell. Das heißt, das wenn ich 30 GB File habe, habe ich das in ein paar Sekunden durchgelesen, weil es einfach ein Linear von links nach rechts
25:40
Memory einfach durchgeht. Und ich muss halt nicht zu viel Speicher allokieren und so weiter. Klar, Indizes könnten in bestimmten Cases Vorteile haben, aber in aller Regel will ich, wenn ich halt irgendwie filtern möchte oder sowas in der Art, muss ich mir die Daten in der Regel eh anschauen oder ich mache halt vorher den Effort und
26:01
speichere mir schon vorher einen Index ab. Das heißt, irgendwo habe ich den Aufwand dann doch. Und wenn ich im ersten Verarbeitungsschritt halt irgendwie schon die meisten Daten eliminieren kann, weil sie mich gar nicht interessieren, bin ich natürlich auch schon wieder extrem schnell.
26:29
Ja, dann herzlichen Dank. Ich denke an den vielen Fragen, hast du schon gemerkt, dass das hier doch uns doch sehr bewegt das Thema. Dann würde ich jetzt diese
26:40
Diskussionsrunde beenden und möchte nochmal darauf hinweisen, das ist jetzt gleich an der Statue vom Geographischen Institut. Also wenn man einfach Richtung Bütchen geht, wo euch alle angemeldet habt, werdet ihr auf der linken Seite diese große Statue sehen. Da findet jetzt die Photosession statt. Genau.
27:00
Vielen Dank fürs Zuhören.