Chaos Computer Club - archive feed

This is a follow-up to Andreas Bernauer’s talk from BOB

2016: The talk examines the implementation of event-sourcing

in a highly distributed application for configuration

management in a large network of car shops among mobile

devices that are only sporadically connected.

When building an event-sourced systems, it’s a common reflex to

construct projections to answer queries instead of sifting through the

event stream, using the CQRS paradigm. However, CQRS might not quite

be the best way to organize an event-sourced system: The concept of

“responbility” is foggy in many contexts, and the separation between

“read models” and “write models” is the wrong axis to use for

organizing storage and indexing. Moreover, CQRS may lead to

implementing read models prematurely and unnecessarily.

We demonstrate how the implementation of event sourcing and CQRS

played out in our configuration-management application, and reflect

the implications for the architecture of future systems.

about this event: https://bobkonf.de/2022/sperber.html

Ein Erfahrungsbericht mit Blick in die Zukunft für den Einsatz von GeoNode für das Forschungsdatenmanagement in einem Bundesforschungsinstitut.

In den letzten Jahren wurde in der Forschungsgemeinschaft das Verlangen Daten FAIR, also Findable, Accessible, Interoperable und Reproducible zu Veröffentlichen stetig größer. Mittlerweile sind ganze Forschungsprogramme dafür entstanden, wie zum Beispiel das „Nationale Forschungsdaten Infrastruktur“ (NFDI) Programm. Für uns Geoinformatiker*innen ist der FAI Teil von FAIR-Data nichts Neues. Entsprechend liegt es nahe eine Geodatenmanagement Plattform als Grundlage für das Forschungsdatenmanagement zu verwenden, oder?

Dieser Vortrag wird zeigen, wie gut das funktioniert, welche Probleme aufgetreten sind und wie eine große Bundesforschungseinrichtung open-source Entwicklung betreiben und befördern kann. Hierbei wird ein Einblick in das jetzige Infrastrukturkonzept und ein Ausblick auf künftige Entwicklungen gegeben.

about this event: https://pretalx.com/fossgis2022/talk/W8FEZY/

FlatMap ist ein einfaches, kompaktes Dateiformat für OpenStreetMap Daten, das direkten Zugriff auf die OSM Elemente per ID erlaubt (random access). Das ermöglicht Analyse und Verarbeitung von OSM Daten ohne Datenbank. Nach Erläuterung des Formats werden OSM Daten mit FlatMap und der modernen Programmiersprache F# verarbeitet.

FlatMap erlaubt die direkte Verarbeitung von OSM Daten, Datenanalysen und Software werden dadurch einfacher und ressourcenschonender. Es wird praktisch gezeigt, wie mit einer FlatMap Datei und einer einfachen Zugriffsbibliothek die OSM Daten verarbeitet werden können. Dazu wird die moderne Programmiersprache F# verwendet.

Für die kompaktere und effizientere Datenspeicherung werden die Node-Referenzen in Ways aufgelöst. Dies resoniert mit aktuellen Überlegungen zum OSM Datenmodell, wobei dieses hier unverändert bleibt und die Node-Ids in den Ways erhalten bleiben. Eine FlatMap Datei ist daher vollständig.

Sowohl die „planet“ Datei, als auch Extrakte sind kompakt, wobei die Komprimierung mit der Dateigröße zunimmt. Die Kompaktheit ergibt sich aus Datenstruktur (btree) und Codierung (varint, delta, offset). Eine interne byteorientierte generelle Komprimierung, wie sie bei pbf Dateien praktiziert wird, erfolgt nicht. Diese wird auf die gesamte Datei angewandt, etwa für den Dateitransfer. Da eine komprimierte FlatMap Datei so groß wie eine pbf Datei ist, ist FlatMap auch Alternative für die Datenübertragung.

Der Verzicht auf Protocol Buffers, FlatBuffers, Cap’nProto und ähnliche vereinfacht die Implementierung von Zugriffsbibliotheken und erhöht deren Performanz.

Das Format befindet sich in der finalen Entwurfsphase, Feedback ist willkommen. Offen ist etwa die Notwendigkeit von Metadaten, die zurzeit nicht enthalten sind.

https://github.com/snuup/flatmap

https://github.com/snuup/openstreetmap-with-fsharp

about this event: https://pretalx.com/fossgis2022/talk/UHREYA/

Im November 2021 ist ein neues Haupt-Release von MapServer erschienen, die Version 8.0 Wir sehen und an welche Änderungen die Version in den Bereichen Konfiguartion und Funktionen gegenüber den Vorgängern mit sich bringt.

Im November 2021 ist ein neues Haupt-Release von MapServer erschienen, die Version 8.0. Wir sehen und an welche Änderungen die Version in den Bereichen Konfiguration und Funktionen gegenüber den Vorgängern mit sich bringt.

Zur Einleitung darf ein kurzer Abriss der MapServer-Historie nicht fehlen und für Zuhörerinnen, die bisher weniger Berührungspunkt zum MapServer haben gibt es auch eine kurze Erklärung des MapServers (Funktionsweise als cgi-Programm, konfigurierbare OGC-Dienste). Der Schwerpunkt des Vortrags liegt auf den Neuerungen in der aktuellen Version:

- Welche neuen Funktionen stellt MapServer bereit (WFS-T? OGC-API? ...?)

- Was ist bei einem Update von älteren Versionen zu beachten? Für die neue Version wurde ein Aufräumen der Mapfiles angekündigt, veraltete Keywords und Blöcke werden nicht mehr funktionieren und sicher gibt es auch die ein oder andere Neuerung.

about this event: https://pretalx.com/fossgis2022/talk/7TH3ZX/

Viele Institutionen haben in den vergangenen Jahren Geo-Daten aufbereitet und bereitgestellt. Dennoch liegen diese Daten oftmals verteilt und in verschiedenen Formaten vor. Eine effiziente Nutzung der Daten, um die darin enthaltenen Informationen, auch durch eine Kombination der Daten, zu extrahieren, ist oftmals aufwendig. Wir stellen eine auf GeoNode aufbauende Lösung, sowie wissenschaftliche Erkenntnisse zur Entwicklung von Forschungsdateninfrastrukturen anhand verschiedener Projekte vor.

In unterschiedlichen Projekten wurden in enger Zusammenarbeit mit Partnern und Kunden Open-Source-Lösungen entwickelt, die eine Integration von bestehenden Datensätzen in einheitliche Forschungsdateninfrastrukturen (FDI) ermöglichen. Diese Arbeiten fußten in Anforderungsanalysen von der Datenhaltung über die Datenanalyse bis hin zur Visualisierung und dem Deployment. Die Open-Source-Entwicklung baut auf GeoNode auf und stützt sich auf offenen Schnittstellen (insb. des OGC). Eine grundlegende Voraussetzung ist hierbei die parallele Integration verschiedener Datenquellen, die den Anforderungen der jeweiligen Repräsentationsformen (z.B., Vektor, Raster, Zeitreihen) der Daten gerecht werden. Aufgrund des explorativen Charakters der notwendigen Arbeiten, konnten zahlreiche Fragestellungen beantwortet und Erkenntnisse gewonnen werden. Hieraus haben sich Best-Practices ergeben, um Gemeinsamkeiten sowie spürbare Unterschiede zwischen den Anwendern aus dem öffentlichen Sektor, der Wirtschaft und der Forschung bestmöglich zu adressieren. Weiterhin werden im Vortrag Erkenntnisse vorgestellt, welche sich aus der Nutzung von GeoNode in Cloud-Infrastrukturen ergeben haben. Hierzu zählen insbesondere auch Erfahrungen mit dem Deployment unter Nutzung von Kubernetes.

about this event: https://pretalx.com/fossgis2022/talk/MXRMY7/

Eine kurze Vorstellung des VCMap Core anhand eines praktischen Beispiels - Einbinden von OpenStreetMap Inhalten als 3DTiles und Mapbox Vector Tiles.

Der VCMap Core ist eine JavaScript Bibliothek zur Darstellung eines multidimensionalen WebGIS. Sie ermöglicht die einfache Einbindung von Geodaten, welche sowohl in 2D als auch 3D mit OpenLayers und CesiumJS dargestellt werden können.

Durch die Offenlegung des Quellcodes wollen wir Coder dazu ermutigen eigenständige Weiterentwicklungen on top zu realisieren. Unsere User, wie auch wir, sind an einem Austausch der Entwicklungen interessiert und wollen dies über OS Software realisieren.

Mit einem Live Beispiel illustrieren wir, wie man mit OpenData und dem @vcmap/core in wenigen Schritten eine Anwendung baut. Dabei möchten wir einen Einblick in die Struktur der Bibliothek vermitteln und darstellen, was den @vcmap/core einzigartig macht und wie wir hoffen die OS Community dadurch zu bereichern.

about this event: https://pretalx.com/fossgis2022/talk/RLVNSY/

The Rust systems programming language promises to

overcome the seemingly fundamental tradeoff in language design

between high-level safety guarantees and low-level control

over resource management. Unfortunately, none of Rust’s safety

claims have been formally proven, and there is good reason to

question whether they actually hold. Specifically, Rust

employs a strong, ownership-based type system, but then

extends the expressive power of this core type system through

libraries that internally use unsafe features.

In this talk, I will present RustBelt, the first formal (and

machine-checked) safety proof for a language representing a realistic

subset of Rust. Our proof is extensible in the sense that, for each

new Rust library that uses unsafe features, we can say what

verification condition it must satisfy in order for it to be deemed a

safe extension to the language.

We have carried out this verification for some of the most important

libraries that are used throughout the Rust ecosystem. The secret

weapon that makes RustBelt possible is the Iris framework for

higher-order concurrent separation logic in Coq.

The talk will not assume any prior familiarity with concurrent separation logic or Rust.

about this event: https://bobkonf.de/2022/dreyer.html

Die OpenStreetMap-Foundation hat im Herbst 2021 die Engineering Working Group neu gegründet. Was ist eigentlich die Aufgabe dieses Gremiums? Wer kann mitarbeiten und wer arbeitet mit? Was hat das Gremium für Pläne und Einfluss? Hat es das nicht schon früher gegeben? Warum sollte diesmal alles besser werden?

Die OpenStreetMap-Foundation (OSMF) ist der rechtliche Eigentümer für die Datenbank, die Server auf denen OpenStreetMap (OSM) liegt und alle weiteren Dinge aus dem OpenStreetMap-Universum, das vor dem Recht einen Eigentümer braucht. Dementsprechend ist das Motto der OSMF gegenüber OSM "to support not control". Um dieser Mission gerecht zu werden, hat die OSMF Arbeitsgruppen gegründet, die spezifische Aufgaben in OSM lösen sollen.

Eine der Arbeitsgruppen ist die "Engineering Working Group" (EWG). Die EWG soll dabei helfen, dass für die OSM benötigte Software tatsächlich entwickelt wird. Da OSM nur funktionieren kann, wenn der größte Teil der Software von Freiwilligen entwickelt wird, ist die erste und größte Herausforderung, die Lücken scharf abzugrenzen, an welchen Stellen eine Entwicklung einerseits hohen Leidendruck hat, andererseits frewillige Beiträge absehbar nicht zu erwarten sind. Und natürlich die Unterstützung stattfindender freiwilliger Entwicklung, indem Interessierten geholfen wird, die richtigen Ansprechpartner zu finden.

Soweit die Theorie.

Es hat mehrere Anläufe gegeben, die EWG einzurichten und aktiv zu halten. Die vorherigen Inkarnationen haben allerdings auch noch nicht die Möglichkeit mitbekommen, Aufgaben auszuschreiben. Dennoch löst hier Geld leider nicht automatisch Probleme. Das für die OSM-Website benutzte Framework Ruby on Rails ist mitterweile stark aus der Mode gekommen, und ein erster Auflauf, noch vor Gründung der EWG eine Aufgabe auszuschreiben, hat zu keinen Geboten geführt.

Die EWG hat ihre Mitglieder nach zwei Aufrufen Ende letzten Jahres zur Mitarbeit gewonnen und auf diesem Weg ein paar neue Gesichter, mich eingeschlossen, in die Arbeit der OSMF eingebunden. Allerdings haben alle genug OSM-Aufgaben, um dann doch weniger Zeit zu investieren, als die EWG für volles Tempo bräuchte.

Sie trifft sich alle zwei Wochen. Aktuell gibt es einen Entwurf für Standardklauseln für Ausschreibungen. Bei den Aufgaben hat sich herausgestellt, dass die ersten, die als kleine Aufgaben identifziert worden sind, mittlerweile von Freiwilligen implementiert worden sind - die dringenden und leicht umsetzbaren Aufgaben sind also gut identifziert worden. Für die erste Runde Ausschreibungen muss also nochmal neu gesucht werden.

about this event: https://pretalx.com/fossgis2022/talk/98EFRD/

In einer modernen Arbeitswelt ist es weit verbreitet, dass Teams nicht immer am gleichen Ort arbeiten. Um in solchen Situationen effektive Methoden der Wissensvermittlung bereitzustellen, haben wir eine interne Wissensdatenbank aufgebaut, um Fragen entweder direkt zu beantworten oder die Nutzenden auf diese aufmerksam zu machen. Dadurch leisten wir einen Beitrag weg von Insellösungen hin zum gemeinsamen Arbeiten.

Innerhalb der VSB Gruppe dient QGIS als bewährtes Opensource Werkzeug, um Daten anzuzeigen, zu bearbeiten und dann daraus Karten zu erstellen. Viele Kollegen*innen nutzen dieses Werkzeug aktiv und kennen auch die grundlegenden Funktionen. Wenn es aber um Tätigkeiten geht, wie das berechnen von Flächen aus Teilflächen oder das Erstellen von Statistiken, die ein tieferes Verständnis erfordern, stoßen sie an ihre Grenzen. Dann kommen wir als GIS-Team ins Spiel und unterstützen die Kollegen*innen bei ihrer Arbeit mit QGIS. Daher nehmen wir als GIS-Team eine entscheidende Rolle ein bei der Bereitstellung von Geodaten, der Beantwortung von Fragen zu Geodaten und QGIS sowie der Schulung der Kolleginnen und Kollegen in QGIS ein.

Da wir neben unseren Unterstützungsaufgaben auch weitere Aufgaben wie die Datenbankadministration und Softwareentwicklung zu bewältigen haben, war schnell für uns klar, dass wir ein System brauchen um Supportanfragen zu lenken und auf ein Mindestmaß zu reduzieren.

Hier kam nun das Wissensmanagement ins Spiel. Mithilfe unseres Intranets konnten wir eine kleine Wikipedia mit Mitschnitten unserer Schulungen, Anleitungen zu bestimmten Prozessen im GIS und kurze Tutorials zu speziellen Fragestellungen aufbauen. Dadurch können wir Nutzende schnell helfen, auch wenn wir grade nicht erreichbar sind. Bis aber dieses als Lösung anerkannt wird, bedarf es viel Geduld und Überzeugungskraft. Daher ist ein weiterer Baustein der Strategie, sich in Regelmäßigen Abständen Feedback einzuholen und anhand dessen das Wissensmanagement anzupassen und zu erweitern.

Der hier vorgestellte Vortrag soll den Weg vom alten Zustand (alle Teams haben ihre eignen Datenquellen, eigene Vorgaben und Ideen wie sie mit QGIS bzw. Geodaten arbeiten) hin zum jetzigen Stand skizzieren und wie Wissenstransfer und Bereitstellung ein wichtiger Baustein in der Arbeit mit Verteilten Teams ist.

about this event: https://pretalx.com/fossgis2022/talk/DSEMJE/

Das einfach zu bedienende QGIS Plugin für HELIOS++ verbindet die Vielseitigkeit des LiDAR-Simulators HELIOS++ mit der Nutzerfreundlichkeit des Geoinformationssystems QGIS. In dieser Demo-Session werden wir HELIOS++ sowie das Plugin und seine Funktionalitäten anschaulich vorstellen. Wir demonstrieren den gesamten Ablauf des virtuellen Laserscannings, von der Erstellung der Szene und Konfiguration der Aufnahmeparameter bis zur finalen Punktwolke.

HELIOS++ ist eine Open-Source-Software für die Simulation von Laserscanning, die in C++ implementiert ist. Sie bietet ein gutes Maß an Realismus trotz geringer Laufzeiten und niedriger Anforderungen an den Computer, und ist darüber hinaus einfach konfigurier- und bedienbar. Die Python-Anbindung („pyhelios“) ermöglicht die Konfiguration und Ausführung von HELIOS++ durch eine weit verbreitete Skriptsprache. Dadurch kann die Simulation direkt in einem Programmcode mit der Datenauswertung kombiniert werden. Zudem ermöglicht pyhelios die Anknüpfung an externe Software wie zum Beispiel Geoinformationssyteme und Software zur 3D Punktwolkenprozessierung.

Um HELIOS++ nutzerfreundlicher zu machen, haben wir ein QGIS Plugin entwickelt, das die Funktionalität der Software in eines der gängigsten GIS-Programme einbettet. Dieses QGIS Plugin, AEOS (der Name eines der Pferde, die den Sonnenwagen von HELIOS in der griechischen Mythologie ziehen), werden wir in dieser Demo Session bei der FOSSGIS 2022 vorstellen.

In der Session demonstrieren wir einen Workflow mit einigen LiDAR Simulationen, die die verschiedenen Einsatzmöglichkeiten der Implementierung von HELIOS++ in QGIS und die Vielseitigkeit von HELIOS++ beleuchten. Dabei werden sowohl terrestrische, als auch drohnengestützte und flugzeugbasierte Aufnahmen mit unterschiedlichen Sensoren simuliert.

Zunächst wird die Szene generiert, also ein 3D-Modell, das mit dem simulierten Sensor abgetastet werden soll. In QGIS wird hierfür ein Digitales Geländemodell (DGM) geladen, das durch Gebäudemodelle aus OSM-Daten zu einem 3D Modell einer Stadt ergänzt wird.

Die Stadt wird dann mit verschiedenen virtuellen Laserscanning-Aufnahmen (VLS; virtual laser scanning) erfasst, die direkt in QGIS konfiguriert, ausgeführt und visualisiert werden. Dabei sollen verschiedene Plattformen, von flugzeuggestütztem Laserscanning (ALS) bis zu mobilem Laserscanning (MLS), eingesetzt werden, die mit Sensoren unterschiedlicher Genauigkeiten und Auflösungen ausgestattet werden. Die resultierenden Punktwolken können direkt in QGIS als Layer geladen und verglichen werden.

Das untersuchte Szenario entspricht einer der vielen Anwendungsmöglichkeiten von HELIOS++. Hier wird eine Datenaufnahme simuliert, was zur Planung und Optimierung vor der tatsächlichen Durchführung dient. Die simulierten Daten können auf ihre Eignung zur Untersuchung bestimmter Fragestellungen geprüft werden, zum Beispiel hinsichtlich der räumlichen Abdeckung oder Auflösung, um geeignete Parameter für die echte Datenerfassung zu ermitteln und zu validieren.

**Referenz:**

Winiwarter, L., Esmorís Pena, A., Weiser, H., Anders, K., Martínez Sanchez, J., Searle, M., Höfle, B. (2021): Virtual laser scanning with HELIOS++: A novel take on ray tracing-based simulation of topographic 3D laser scanning. Remote Sensing of Environment, 112772, https://doi.org/10.1016/j.rse.2021.112772

about this event: https://pretalx.com/fossgis2022/talk/JPEZDH/