Herzlich willkommen zurück auf Bühne 3 zu einem weiteren Vortrag über Geonote. Hier geht es darum, Geonote als Forschungsdatenplattform in einer Bundesforschungseinrichtung einzusetzen und damit auch die

sogenannten FAIR-Prinzipien zu erfüllen. Gleichzeitig wird an dieser Bundesforschungseinrichtung aber Geonote nicht nur einfach eingesetzt, sondern auch die Entwicklung von Geonote wird gefördert. Und wie das funktioniert, zeigt uns jetzt Florian Höt. Ich heiße euch herzlich willkommen zum Vortrag Geonote als Forschungsdatenplattform.

Ich bin Florian Höt, habe im Unigesprogramm der Uni Salzburg ein Master in Geoinformation Science and Systems abgeschlossen und leite den Bereich Forschungsdaten Management im Thünen Institut. Das Thünen Institut ist eine Bundesforschungseinrichtung des Landwirtschaftsministeriums des

und ist politikberatend tätig. Wir forschen in der sogenannten 3x3-Matrix in den Bereichen Wälder, Felder, Meere und jeweils aus der Perspektive der Ökologie, der Ökonomie und der Technologie. In den letzten Jahren sind wir zudem verstärkt im Bereich der ländlichen Räume aktiv und auch in den

Sozialwissenschaften aufgestellt. Im Thünen Institut arbeite ich selbst im Zentrum für Informationsmanagement. Wir sind zentrale IT-Dienstleister des gesamten Instituts und zu uns gehört auch die Bibliothek. Übrigens suchen wir ständig pfiffige oder lernwillige IT-Lehrer und wenn die Beschreibung da oben zu dir passt, dann melde dich doch gerne bei mir.

Nun aber zum Vortrag und dazu zunächst etwas Hintergrund. Seit einiger Zeit wird das Bestreben in der Forschungsgemeinschaft Daten FAIR, also Findable, Accessible, Interoperable und Reusable zu veröffentlichen, immer größer. Gleichzeitig werden Geodaten jedoch schon lange Zeit FAIR

veröffentlicht, mit Isometadaten angereichert, über OGC-Dienste gefunden und gelesen und in der GDI-DE zur Wiederverwendung gelistet. Entsprechend soll in diesem Vortrag gezeigt werden, ob und wie eine Geodatenplattform als Forschungsdatenplattform funktioniert. Im Thünen Institut haben wir dafür Geonode verwendet, ein OSGio-Projekt.

Das Forschungsdatenmanagement ist gut im sogenannten Forschungsdaten- Lebenszyklus umrissen. So werden sie zunächst erst mal aufgenommen, dann werden sie analysiert, dann gespeichert, dann publiziert auf diversen Plattformen. Hoffentlich werden sie dann auch wiedergefunden und dienen

dann oftmals als Basis neuer Forschungsideen, Projekte oder auch Forschungsanträge. Die Infrastruktur sollte jeweilige die jeweiligen Zyklen technisch begleiten. Da die Phasen ineinander laufen, ist hierbei besonders auf Schnittstellen zu achten. Mit diesem Gedanken im Sinn wurde das Forschungsdaten-Infrastruktur-

Konzept erstellt und wird derzeit auch noch weiterentwickelt. Grundsätzlich ist hierbei unsere Infrastruktur in drei Bereiche aufgeteilt. Dem internen Netzwerk, dem sogenannten LAN, unserem Netzbereich, der für externe zugänglich ist, der DMZ, demilitarisierten Zone und den externen Diensten, dem WWW.

Im Tüdeninstitut werden insgesamt drei Geonot-Instanzen verwendet. Zum einen haben wir im LAN das Tüdeninstitut Spatial Data Repository, kurz das TISTA. In der DMZ steht das Tüdeninstitut Spatial Data Exchange sowie der Tüdenatlas. Wir werden nun

anhand eines fiktiven Beispiels die jeweiligen Datenlebenszyklen durchlaufen und ich euch konkret aufzeigen, wo bei uns im Institut Geonot hierfür Unterstützung liefert. Stellen wir uns ein Projekt vor, in dem Bodendaten aufgenommen

werden. Das heißt, wir haben externe Partner und die nehmen die auf und liefern uns diese als Datenpakete. Die Daten sollen bilateral ausgetauscht werden. Außerdem sollen auch Metadaten erfasst werden, damit man versteht, was die Daten eigentlich beinhalten und damit man sie besser verwenden kann für Analysen. Zudem

befinden sich die Daten derzeit in aktiver Forschung und entsprechend der Erstverwertungsrechte der Promovierenden zum Beispiel sollen diese zunächst geschützt geteilt werden. Für genau diesen Anwendungsfall gibt es den TISTAX-Knoten. Wie das konkret aussieht, möchte ich an einer kurzen Demo zeigen. Das ist das

Thünen-Institut Spatial Data Exchange, eine Geonot-Instanz in der DMZ. Ich bin bereits eingeloggt. Das Login und so weiter funktioniert für Thünen-Mitarbeitende über LDAP und Externe haben theoretisch verschiedene Login-Möglichkeiten. Wir jedoch machen dedizierte

Accounts für diese. Nachdem man eingeloggt ist, ermöglicht einem der Knoten zum einen komplett neue Ebenen zu erzeugen. Das heißt, eine PostGIS-Tabelle wird dadurch erzeugt, mit Attributen befüllt und kann dann über transaktionale WFS zum Beispiel befüllt werden. Wir haben in unserem Fall jedoch vorhandene Daten und

wollen diese hochladen. Das Ganze funktioniert im Großen und Ganzen wie Dropbox. Theoretisch kann ich meine Daten hier raufziehen oder ich wähle sie einfach aus, suche mir hier die Tello-Boden-Karte raus als Shapefile, sage noch, dass sie in UTF-8 quotiert sind und lade sie hoch. Das Besondere ist, dass in diesem Schritt jetzt eine Menge passiert. Zum einen

wird der Datensatz genommen, an Geo-Server weitergereicht, in eine PostGIS-Datenbank ingestiert. Geo-Server wiederum erstellt Dienste und die wiederum werden in T-Stacks registriert, sodass, wenn ich diesen Datensatz letztlich öffne, ich eine Vorschau hab, der Bodenkarte und ein Dienst wird erstellt mit einer

Vorschaukarte und die jeweiligen Attribute, die da drinne stehen, sind ebenfalls abrufbar über Get-Feature-Request zum Beispiel. Das besonders Gute hier dran ist, dass ich als Hochladender natürlich den Meta-Daten-Assistent benutzen kann, um den Datensatz mit zusätzlichen

Informationen auszustarten. Im Meta-Daten-Assistent gibt es die Möglichkeit, verschiedene ISO-angelehnte Felder auszufüllen, so zum Beispiel die ISO-Kategorie. Es kann einer Gruppe zugeordnet werden und das besonders Interessante in den neuren GeoNode-Versionen ist, dass es in den optionalen Meta-Daten die

Möglichkeit gibt, auch JSON-codierte zusätzliche Meta-Daten einzufügen. Das ist sehr spannend. Dadurch könnte zum Beispiel, wenn ein besonderer Sensor verwendet wurde, um diese Bodendaten aufzunehmen, die Sensormeta-Daten, Einstellungen etc. hier mit rein codiert werden und die sind dann in frontend

auch über die facetierte Suche zu finden. Außerdem gibt es die Möglichkeit, eine DOI hier einzutragen und das besonders Schöne ist, dass der Datensatz, auch die Attribute des Datensatzes auch beschrieben werden können. So zum Beispiel, was B-Typ eigentlich bedeutet und auch die Beschreibung nach welcher Methode

zum Beispiel der Bodentyp hier aufgenommen wurde. Stellen wir uns nun vor, dass das Bodenprojekt abgeschlossen ist und die Ergebnisse der guten wissenschaftlichen Praxis folgend mindestens zehn Jahre aufbewahrt werden sollen. Hierfür ist der Tista-Knoten im Thünen-Institut vorgesehen. Durch das WebUI können, wie eben

gerade schon gezeigt, über Track and Drop Datensätze hochgeladen werden oder komplexere Datentypen auch über eine Vielzahl von Geo-Server registriert werden, zum Beispiel NetCDFs oder Cloud Optimize, GeoTIFs oder ähnliches. Der Metadata-Assistent unterstützt auch hier dabei, die Daten zu beschreiben und kann

die Sauri verwenden. Zu jedem Datensatz werden automatisch Dienste erstellt. Wie das ganze dann aussehen kann, möchte ich ebenso in einer kurzen Live-Demo zeigen. Willkommen im Tista. Tista ist die interne Datendrehscheibe des Thünen-Instituts. Das Login funktioniert ebenso über LDAP und

Datensätze hochgeladen werden und beschrieben werden. Um mal zu zeigen, wie so was aussehen kann, öffne ich die Bodenzustandserhebung der Landwirtschaft, wo die 3.300 Bodenproben und die sind hier von den Thünen-Mitarbeitenden umfangreich beschrieben worden, sodass wir wissen, dass es sich hierbei um Daten

handelt, die nach CC BY benutzt werden können. Neben der Vorschau, wo wir jetzt schon sehen, ok, überall sind Punkte, gibt es auch eine umfassende Beschreibung im Abstract, wo verschiedene weitere Datensätze genannt werden, zum Beispiel Labordaten und Horizontdaten, die zu diesem Datensatz gehören. Und hier kommt die Besonderheit

von Geonote, dass Dokumente an Datensätze angehangen werden können und wir hier eine Verknüpfung haben von diesen beschreibenden Dokumenten hin zu dem eigentlichen Datensatz. Natürlich können auch mehrere Stile an einen Datensatz geknüpft werden, um ihn unterschiedlich zu visualisieren. Besonders wichtig finde ich auch hierbei

eine umfassende Attributbeschreibung, dass wir genau wissen, was in den jeweiligen Koordinaten, zum Beispiel, wie die Koordinaten aufgebaut sind, dass sie nicht punktgenau sind, sondern vier Kilometer um den ursprünglichen Punkt liegen, sowie dass das Hauptboden-Typsymbol nach bodenkundlicher Quartieranleitung 5

aufgenommen wurde oder hier eine Beschreibung nach dem Tün-Report 64. Okay, dann können wir wieder zurückwechseln zu der Präsentation. Der Datensatz ist jetzt umfassend beschrieben und ist auch lizenziert worden. Der Tün-Data-Policy folgend sollen die Forschungsdaten nun

veröffentlicht werden. Hierfür kommt der Atlas-Knoten zum Einsatz. Er ist die tüneneigene Veröffentlichungsplattform und stellt besonders aufgearbeitete Forschungsergebnisse bereit in Form von Geo-Applikationen und APs. Und Metadaten sollen von den Tister-Knoten in den Atlas-Knoten

weitergereicht werden und von dem Atlas-Knoten dann auch weitergereicht werden in die oben drüberliegenden Repositorien, wie zum Beispiel die GDI. Wie das Ganze dann aussehen könnte, möchte ich auch kurz zeigen in einer Mini-Demo. Das ist der derzeitige Release- Candidate des Tün-Atlases. Der Tün-Atlas soll Geodaten

zusammengefasst thematisch in sogenannten Tün-Atlanten bereitstellen. Das heißt, wir haben zum Beispiel den Waldatlas, wir haben den Agraratlas, den Landatlas und den Meeresatlas und gegebenenfalls noch weitere Atlanten. Und in so einer Atlas-Applikation sind dann

verschiedene Datensätze und Erlebnisse, also Geo-Applikationen, zusammengefasst, beschrieben und können hier aufgerufen werden. Zum Beispiel hier die individuale Entwicklung von einer Arbeitsgruppe im Tün-Institut, dem sogenannten Tün-Agraratlas. Der wiederum ruft Datensätze aus dem Atlas auf, um

diese Karte zu rendern und anzuzeigen. Hier jetzt am Beispiel einer Applikation, die die Agrardaten in Gesamtdeutschland ausgewertet hat und auf Gemeindeebene dargestellt hat und auch verschiedene Zeitschnitte anbietet, um sich anzuschauen, wie die

landwirtschaftliche Fläche in den letzten Jahren anders genutzt wurde in den jeweiligen Gemeinden und um Hotspots anzeigen zu lassen. Und alle Daten, die hier jetzt gerendert werden, die Diagramme, die hergestellt worden sind, all diese Datensätze wiederum sind Bestandteil des Atlas. Im Tün-Atlas gibt es zusätzlich

noch die Möglichkeit, die GeoNode in den eigenen Fähigkeiten des Styling und der Contenterstellung Geo-Applikationen zu nutzen. Und als Beispiel hierfür möchte ich die Karte der BCD-Landwirtschaft, das Obot Zustandserhebung Landwirtschaft zeigen.

Das ist derselbe Datensatz, den ich bereits gezeigt hatte, jetzt nur besonders aufbereitet für den Tün-Atlas. Und wenn wir uns die Karte in Vollansicht anschauen und nicht nur in der Vorschau, dann wird MapStore geladen. Das ist eine reaktbasierte Applikation von Geo Solutions erstellt. Und wir können

Diagramme und Widgets nutzen, um die Daten anders zu transportieren und bessere Öffentlichkeitsarbeit zu betreiben. So können neben zusätzlichen Informationen, das sind die aus den Metadaten abgeleiteten Informationen, können wir auch Diagramme zeichnen lassen, die sich auch ändern, je nachdem wo man

hinscrollt, beziehungsweise was ebenso möglich ist, ist basierend auf dem Feature-Katalog bestimmte Felder anders in der GetFeature-Template zu rendern. Zum Beispiel hier sind

die jeweiligen Profilfotos der Bodenprofile aufgezeigt und werden automatisch unten angehangen. Prinzipiell ist es möglich, über die Feature-Templates verschiedene Funktionen dort unten reinzumappen. In einem Proof-of-Concept haben wir auch schon einen Matplot-Render-

Service hier unten eingebaut, der dann basierend auf den Informationen des Punktes, Diagramme zeichnet und Zeitverläufe zum Beispiel, wenn man zeitaktive Daten hat. Und wieder zurück zur Präsentation. Für die Phase Discover and Reuse liefern

Tista und Atlas Suchinterfaces und operable Dienste, die Atlas-Daten sollen in Zukunft auch in die GDI und das Agrar-Daten-Repositorium Open Agrar fließen. Zusammenfassen lässt sich somit Folgendes sagen. Grundsätzlich funktioniert die Verwendung von GeoNode als

Forschungsdatenplattform gut, aber es gibt in jeder der Phasen noch Optimierungsbedarfe. Große Datensätze können aus der Plattform derzeit nicht performant analysiert werden, das Open Archives Initiatives Protocol for Media Data Harvesting OIE-PMH ist derzeit nicht vollständig funktionsfähig und Schnittstellen für die Synchronisation der Knoten müssen

noch aufgebaut oder geschliffen werden. Das Meta-Daten-Modell ist außerdem für manche Datenpublikation noch nicht hundertprozentig passend und es müssen gegebenenfalls Anpassungen durchgeführt werden, sowie der Datenfluss von Atlas zur GDI.de und GovData ist noch in der Entwicklung. Das ist ganz schön viel, was noch nicht hervorragend

funktioniert und wir können gerne im Anschluss oder im Laufe der Konferenz darüber diskutieren, ob eine andere Lösung nicht vielleicht sinnvoller wäre. Wir haben uns jedoch für GeoNode entschieden, weil es ein OS-Geo-Projekt ist und wir in der Community uns sehr wohlfühlen und es viele der Bedarfe der Forschenden abgedeckt hat.

So ist eine besonders wichtige Funktion, dass nicht nur Meta-Daten hochgeladen werden, sondern tatsächlich die Datensätze selbst. Forschende wollen Fragen beantworten und dafür reichen Meta-Daten alleine einfach nicht aus. Wir haben uns für GeoNode entschieden, also open for a reason, weil wir die Weiterentwicklung der Plattform

mit Eigenmitteln und auch mit Fördergeldern vorantreiben wollen. Ziel ist es hierbei gemeinsam mit der Forschungscommunity Bedarfe zu beschreiben, umzusetzen und dann als Upstream in das Hauptprojekt einfließen zu lassen. Für größere Änderungen werden dafür sogenannte GeoNode Improvement Proposals, also Gnips, erstellt,

diskutiert und deren Übernahme in das Projekt vom Steuerungskomitee demokratisch beschlossen. Unten drei Beispiele dafür und rechts auch gezeigt ein Beispiel für ein GeoNode Improvement Proposal, wo es darum geht, die nichträumlichen Datensätze gleichberechtigt in GeoNode darzustellen. Wenn man so einen

Gnip erstellt und ihn diskutiert und das Steuerungskomitee beschließen muss, ob er angenommen wird oder nicht, macht es natürlich total viel Sinn, wenn man im Steuerungskomitee drin ist. So wie ich zum Beispiel. Und das Studieninstitut auch die Core Contributor Agreement unterzeichnet hat und wir damit

Core Contributor sind. Die Mitgliedschaft in dem Project Steering Committee oder sowieso eine aktive Mitgliedschaft in der Community, um mögliches Konzepte, die man selber hat, mit auf kurzen Wege mit den langjährigen und überaus erfahrenen GeoNode Entwicklerinnen hin und her zu diskutieren, möglichst rasch und flott sich zu überlegen, wie man einen Upstream

Prozess aus den geförderten Entwicklungsleistungen produzieren kann und die Inhalte dann hoch fließen können. Das spart nicht nur Zeit und Geld, sondern macht auch wahnsinnig glücklich, dann zu sehen, dass die öffentlichen Gelder letztlich für öffentliche Stücke von Software bereitgestellt werden und von anderen Forschungsinstitutionen oder der

generellen Öffentlichkeit genutzt werden können. Wenn man meinen Abstract des Vortrags anguckt, dann wollte ich eigentlich auch noch über die Entwicklungsversion V4 von GeoNode berichten. So viel nur in Kürze. Für die neue Version wurde mächtig refactored, aber auch im Vordergrund. So wurde zum Beispiel das Frontend jetzt entkoppelt und die

neue APV2 massiv geteilt. Außerdem gibt es jetzt einen Storage and Resource Manager, der komplett überarbeitet und neu aufgesetzt wurde und somit viel besseres Harvesting erlaubt. Und einiges mehr. Letzten Endes hat GeoSolutions jedoch bereits ein hervorragendes Webinar zum 3.3.1 Release,

was demnächst kommt, das ist das stable Release, gemacht, sowie auch darin über die Version 4 viel berichtet und das in der Live-Demo gezeigt. Schaut euch das doch einfach an und sprecht mich im Nachgang direkt gerne an, wenn ihr weitere Fragen habt. Zudem gibt es auch den Link zu der Demo-Instanz der V4, damit ihr da

selber drauf rumspielen könnt, unter master.demo.geoNode.org. Außerdem bin ich nicht zum ersten Teil des Research Data Management Life Cycles Plan and Fund eingegangen. Dafür haben wir eine eigene Datenbank, die close sources, und die wollen wir integrieren, da die jedoch close sources ist, ist für den heutigen Vortrag irgendwie langweilig.

Zukünftig wollen wir überlegen, ob wir das Tool Research Data Management Organizer benutzen wollen, und das dann mit GeoNode verknüpfen, um, wenn wir das Datenmanagement beschreiben in Datenmanagementplänen, dass das automatisch an Datensätze angehangen wird, bzw. Metadaten direkt überführt werden können. Außerdem bin ich auf viele

Teile des Infrastrukturkonzepts gar nicht eingegangen. Aufgrund der Zeit der Inspire-Knoten werden eigener Vortrag und die unten gezeigte Data Bench befindet sich schlichtweg noch im Aufbau und ist noch nicht richtig buchreif. Grob umrissen, es gibt auf der Tünen-Webseite das sogenannte TIDAS Konzept, wo es um hochperformante Prozessierung geht, und wir wollen dort

Jupyter Lab Instance mit GeoMesa Workon vielleicht etablieren, aber das ist noch zu diskutieren. Damit bleibt mir nichts weiteres übrig, als mich für die Aufmerksamkeit zu bedanken, und bin sehr gespannt auf die anschließende Diskussion und die hoffentlich vielen tollen Fragen. Florian, vielen Dank für diesen

interessanten Einblick in die Nutzung von Geonote bei euch an Tünen-Institut, und es ist auch sehr schön zu sehen, dass eine Bundesforschungseinrichtung die Entwicklung eines Open-Source-Tools fördern kann. Es sind eine Menge Fragen eingegangen, wir haben aber auch noch eine Frage, die Mathis vorhin nicht

beantworten konnte, deswegen stellen wir sie jetzt dir, vielleicht kannst du es beantworten. Kann man mit Geonote andere Metadatenkataloge harvesten? Ich muss gestehen, ich habe eben gerade angefangen ein bisschen zu recherchieren, weil ich mir selber nicht ganz sicher war. Tatsächlich ist es so, dass es derzeit leider nicht funktioniert. Ich hatte im

Vortrag ja schon angesprochen, Geonote Version 4 wird derzeit entwickelt und befindet sich gerade in so einer Art Alpha unter master.geonote oder master.demo.geonote.org und dafür weiß ich, wurde ein Metadaten Harvesting aufgebaut, wo Dokumente

aus einem Dokumentenmanagement System rausgehavestet wurden und es gibt auch eine neue Plugable Service Types für Harvester, wo man so etwas implementieren könnte, aber es funktioniert derzeit noch nicht. Also es ist praktisch in Entwicklung, es ist aber noch nicht fertig.

Wobei ich muss kurz ergänzen, was geht, es können WMS Dienste gehavestet werden und es können andere Geonote Instanzen gehavestet werden. Also das funktioniert schon. Gut, nächste Frage. Können die Metadaten für ausgewählte Datensätze zum Beispiel als

CSV exportiert werden? Für ausgewählte Datensätze, okay. Nee, derzeit nicht. Du kannst einen einzelnen Datensatz dir anschauen und davon die Metadaten runterladen, aber du kannst nicht fünf Metadatensätze auswählen und von diesen fünf dann etwas einen Metadaten

Abstract oder so runterziehen. Das funktioniert nicht, müsste man auch implementieren. Mehrere Fallformate, die man exportieren kann. Für das Metadaten, für den Metadaten Export, das sind diverse. Ich müsste selber nachgucken oder geht doch einfach auf eine der Demonstanzen und schaut euch das an.

Also das ist ISO, der Feature Catalog kann runtergeladen werden und noch diverse andere. Letztendlich ist es ja ein Pi CSW im Hintergrund und relativ alles, was der Pi CSW ausspucken kann, wird dort auch gelistet. Frage zur Prozessierung.

Werden nur die Rohdaten oder auch die politischen Ergebnisse oder veredelte Daten nach einer Prozessierung in Gionote gehalten bei euch? Grundsätzlich ist es so, dass auch die Zwischenschritte bzw. die fertigen Datensätze, also die fertig analysierten Datensätze vorgehalten werden.

Allerdings muss man immer bedenken, Tista, das ist ja unsere Gionote Instanz im internen Netz, das ist ja im Backup und dann später in der Langzeit Datenspeicherung und die Speicherbedarfe schießen exponentiell in die Höhe, wenn man jeden Zwischenschritt mitspeichern würde. Das heißt, wir versuchen abzuschätzen,

wo Datensätze in dem Speicherbereich liegen müssen, der in die Langzeit Datenspeicherung geht und wo Datensätze einfach nur registriert werden, die auf anderen Speichern liegen, die nicht in die Langzeit Datenspeicherung reingehen und gegebenenfalls nicht mehr ins Backup reingehen. Das geht ja ganz zum Schluss, der diese Data Bench gezeigt, da bin ich nicht viel drauf eingegangen.

Data Bench ist zum Beispiel der Speicherort, wo wir Daten vom BKG vorliegen haben. Die BKG Daten sind ja nicht unsere Daten, die bekommen wir, die werden im TÜN-Institut teilweise nochmal veredelt und für unsere Forschungsfragen ergänzt und ein bisschen umgebaut. Und diese Datensätze liegen dort

vor, weil wir sie prinzipiell jederzeit wieder herstellen können. Deshalb müssen wir sie nicht in den Langzeit Datenspeicher übernehmen, weil da müssen unsere selbst aufgenommenen Forschungsdaten wie die Bodenzustandserhebung oder die ozeanografischen Daten mit Tausenden von Datenpunkten, die können wir nie wieder herstellen. Die müssen

im TÜSTER nativ liegen und dann gibt es viele Datensätze, die im TÜSTER nur registriert sind. Tausende von Datensätzen sind wir bei der nächsten Frage. Wie sieht das mit 3D-Daten wie Punktwolken aus? Können diese Performante in Gionote abgebildet werden? Das ist derzeit

nicht der Fall. Ich weiß, dass GeoSolutions für Gionote Version 4 daran arbeitet. Es gibt auch irgendwo einen Proof of Concept. Ich bin mir nicht sicher, ob der das auf die Master Demo geschafft hat. Ich denke nicht. Aber da wird drüber nachgedacht. Derzeit ist es so, wir hatten gerade,

also Status heute, noch nicht die Bedarfe, das abzubilden. Ich weiß aber von einem Projekt des TÜN-Instituts in Eberswalde. Die sind mit Drohnen durch verschiedene Forstbereiche geflogen. Und die wollen das auch ablegen. Das heißt, es könnte angehen, dass wir Gelder, die wir vom BMAL bekommen haben, dafür

demnächst verwenden werden, um das zu ermöglichen. Also 3D Last zum Beispiel. Klingt interessant. Oder Punktwolken, nicht nur Laser-Scanning-Daten. Noch mal zurück zum Metadaten-Katalog. Wie kann der Metadaten-Katalog erweitert beziehungsweise angepasst werden?

Ja, das ist prinzipiell möglich, wobei man immer gucken muss. Metadaten selber werden in GeoNode vorgehalten, von dem GeoNode Resource-Base-Modell. Also Resource-Base ist das Django-Modell, das verwendet wird, um die Ressource abzubilden und zu beschreiben. Und

das wiederum wird über herausgegeben, als CSW-Schnittstelle. Das heißt, jetzt gerade ist es so, wir haben über die CSW-Schnittstelle Datensätze, die rausgehen, die nicht vollumfänglich dementsprechend, was in GeoNode nativen Katalog eigentlich vorliegt. Dafür gibt es die Rest-APV2,

die seit 3.3.1 oder 3.2.1 oder so ist sie mit dabei. Also schon seit einiger Zeit. Die funktioniert auch mal vorragend. Und über diese Rest-AP werden die ganzen anderen zusätzlichen Felder mit abgedeckt. Und um das reinzuarbeiten, also das ist möglich definitiv, aber es ist Entwicklungsaufwand. Es ist jetzt nicht so zusammen zu konfigurieren. Und es müsste

dann das Resource-Base- Modell gegebenenfalls angepasst werden. Und die außerdem die Rest-APV2 müsste auch entsprechend angepasst werden. Das ist ein Django REST-Framework, sodass auch die Ressourcen über die AP sauber abgebildet werden. Aber auch da weiß ich,

hat GeoSolutions gerade angefangen, das Resource-Base-Metadaten-Modell umzubauen. Ich suche gleich nochmal in Github, wo genau der Issue ist. Dann könnt ihr gerne euch das angucken und da seid ihr herzlich eingeladen, auch mit zu diskutieren darüber, wie wir das möglichst klug umbauen und einbauen.

Alles klar, vielen Dank. Mitdiskutieren bringt uns zu dem nächsten Punkt. Gibt es eine Anwender-Community für Geonote, die sich regelmäßig trifft? Also zum einen, es gibt seit Neuesten eine Forschungs-Community, die deutsche Geonote-Forschungs-Community,

wo unter anderem 5toN mit dabei ist, aber auch das JKI, das diverse andere UFZ, du unter anderem auch. Und ganz viele andere, also Leibniz-Institute, etc. Da könnt ihr gerne euch melden und dann seid ihr bei den nächsten Sitzungen mit dabei. Eine Anwender-Community

von Geonote gibt es derzeit meines Wissens nach nicht. Wir haben nur einen sehr aktiven Gitterchat, über den ihr euch melden könnt. Und wenn ihr Interesse habt, dann meldet euch einfach bei mir, weil ich bin mit Toni Schönbuchner von CSGIS zusammen, die deutsche Geonote-Community, was das Project Steering Committee angeht. Deshalb einfach mal her, schreibt mir eine Mail

und lasst uns auf jeden Fall eine Gründe. Ja, hört sich gut an. Könntest du dir vorstellen, dass wir irgendwann mal so eine Art Anwender-Treffen hier im Rahmen der FOSCIS haben werden? Wenn genug Leute Lust hätten, darüber zu diskutieren, lieben, gerne. Also,

das ist ja auch meine Aufgabe, sowohl aus dem Project Steering Committee und von mir als Mensch, als auch von meinem Arbeitgeber, weil wir Core-Contributor sind. Und da zählt sowas natürlich auch rein. Also, wer Interesse hat an Geonote und da mehr erfahren möchte, der wendet sich an Florian Höth. Florian,

vielen Dank. Gerne.