Ja, schön, dass Sie hier auf Bühne 1 geblieben sind, so zahlreich. Das freut mich tatsächlich sehr. Ich will auch gar nicht lange um den heißen Brei herumreden. Und zwar wartet nämlich schon hier Armin Rehterath.

Und zwar wird der uns was über Mr. Map Geoportal RLP Reloaded erzählen. Und ich hab gerade noch mal kurz in die Beschreibung geguckt, da hatte ich eben recht. Es gab 2020, auf der letzten Fosk ist da nämlich auch schon ein ersten Prototyp. Und ich bin gespannt, was da so hinzugekommen ist und wie es sich entwickelt hat.

Und von daher würde ich jetzt einfach direkt übergeben, Armin, viel Spaß. Oder wir wünschen uns viel Spaß bei Armin. Bitte schön. Ja, vielen Dank, Dominik. Dann erst mal schön guten Morgen zusammen. Und ich freue mich, euch heute vorstellen zu können, dass das Mr. Map Projekt hat sich ein bisschen weiterentwickelt seit letztem Jahr. Weil der Titel Mr. Map Geoportal Reloaded bezieht sich also auf unser Geoportal Rheinland-Pfalz,

was wir mit verschiedenen Bundesländern einsetzen. Kurz zur historischen Entwicklung des Systems. Also Geoportal ist eigentlich schon ein Dinosaurier unter dem Geoportal. Muss man echt sagen. Es war eines der ersten Geoportal in Deutschland, die überhaupt Karten zeigen konnten. Ist 2007 freigeschaltet worden.

Die Softwarebasis war oder ist noch MapBender MediaWiki Typo 3. Und ab 2009 ist es Saarland dazu gekommen, hat die Software übernommen, weil es als Open Source Software auch publiziert worden ist. 2011 die Stadt Landau in der Pfalz. Und ab 2015 ist Hessen mit dazu gekommen. Das heißt, wir haben momentan vier Instanzen laufen der Geoportal RLP Software.

Das ist einmal Rheinland-Pfalz, dann hier Saarland, Hessen, jeweils ein bisschen anderes Layout und dann auch nochmal die Kommune Stadt Landau mit der Wahl. Die aktuelle Architektur, die hatte ich auch letztes Jahr schon mal vorgestellt gehabt, ist ein bisschen geändert worden im Gegensatz zur alten Architektur. Also wir haben das MediaWiki beibehalten als Content Management System.

Haben wir das Typo 3 komplett weggeschmissen. Und das Frontend wird schon von einer kleinen, relativ einfachen Django App generiert. Das bedeutet, wir haben im Frontend, erstmal vorneweg ein Mod Security Modul vom Apache laufen, haben dann Django und MediaWiki,

also einmal eine PHP Anwendung, einmal eine Python Anwendung und als Core Komponente momentan noch den MapBender 2. Also wirklich echt altes Projekt, was aber auf PHP7 läuft, was sich darum kümmert, Nutzerrollen, Organisationen, Security, Proxy, Layer, Feature Types, Dataset, alles, was das MapBender eigentlich so mit sich bringt.

Der ist extrem aufgebohrt worden in den letzten 15 Jahren seit dem Einsetzen. Und das ist so ein bisschen Schweizer Messer für den Betrieb von Geodateninfrastruktur. Das ist die aktuelle, momentane Architektur. Die ist natürlich nicht zukunftsfähig und wir haben dann vor zwei Jahren damit begonnen, ein neues Backend zu entwickeln unter dem Arbeitsnamen erstmal MrMap.

Die Zielarchitektur, ich stelle die jetzt nochmal kurz hier vor, wir werden am Frontend erstmal gar nichts ändern, weil wir gehen über Restinterfaces quasi auf die Trefferanzeigen für den Katalog und bleiben dann erstmal bei einer relativ einfachen Django App, die das Frontend des Geoprotards generiert. Im Backend wird dann diese ganze MapBender Core Funktionalität,

die wir die einige wahrscheinlich noch kennen, weil sie MapBender selber mal eingesetzt haben, den alten MapBender, also Nutzer, Rollen, Organisationen, Security Proxy, Layer Registry, Feature Type Registry und so weiter, Monitoring von Diensten. Das wird alles im Endeffekt durch MrMap ersetzt werden. Gehen wir zum nächsten Punkt. Wir sehen auch vom Work-in-Progress Nutzer, Rollen, Organisationen,

Security Proxy und so viele Dinge sind eigentlich auch schon entwickelt und die werde ich jetzt mal gleich kurz vorstellen. Also Vergleich der Backend Views, wer auch MrMap, wer MapBender noch kennt von früher, da gab es einen Backend View, mit dem die Nutzer halt WMS-Dienste, WFS-Dienste, Metadaten verwalten konnten.

Das ist ein bisschen altbacken und halt auch gruselig zu programmieren. Für mich, der ich jetzt wahrscheinlich der letzte Entwickler bin von MapBender 2 Projekt, ist der Aufwand halt immens hoch. Der neue MrMap, der das Backend ersetzt, ist halt sehr modern aufgebaut auf Django-Basis und wir haben dann auch ein Backend, was sich auch von den normalen Menschen, denke ich mal, benutzen lässt.

Also der Unterschied zwischen MrMap Backend und MapBender Backend hier. Neue Funktionen, die im Laufe des letzten Jahres dazugekommen sind. Wir haben ein generisches Monitoring-Modul bekommen für OGC-Dienste. Wir haben eine Verbesserung des Managements von Catalog Service-Gesourcen reingekommen.

Wir haben die Möglichkeit entwickeln lassen von der Firma Terrestris externe Testplattform über die ETF-API zu integrieren in MrMap, insbesondere den Inspire-Validator und die GDI-DE-Test-Suite. Dann haben wir die Möglichkeit geschaffen, die hierarchischen Daten ein bisschen performanter abzulegen in Form von einem MPTT-Tree.

Da zeige ich gleich nochmal ein Beispiel. Und viele, viele Dinge, die unter der Haube passiert sind an der Stelle. Das generische Monitoring-Modul, da gehe ich auch immer kurz drauf ein, oder das MapBender Monitoring-Modul setzen wir seit 2007 ein. Da werden alle 1600 Web-Services jetzt im Fall von Rheinland-Pfalz alle zwei Stunden kontrolliert auf Verfügbarkeit, Identität.

Und falls irgendwas passiert, gibt es ein Notification-System, um die Datenanbieter und die Nutzer, die Abonnenten der Dienste darüber zu benachrichtigen. Das neue in MrMap implementierte Monitoring-Modul arbeitet ähnlich, ist ein bisschen generischer und sieht man jetzt hier auch an der Darstellung. Wir haben also eine Health-Information und da ist ein Check dahinterdefiniert, wo man vorgeben kann, wie schnell muss der Dienst antworten,

um dann quasi eine grüne Ampel zu bekommen, was eigentlich schon implementiert und lässt sich beliebig auf beliebige weitere Ressourcen ergänzen, erweitern, das Modul. Im Bereich der Verbesserung des Managements von CSW-Ressourcen, im aktuellen produktiv laufenden Geoportal nutzen wir auch

Catalog-Services, aber im Endeffekt nur für eine Remote-Suche in Deutschland und in der EU. Neu in MrMap ist halt die Möglichkeit geschaffen worden, auch Kataloge zu harvesten, also es sind ähnliche Funktionalitäten, wie man die vom Geo-Network kennt oder von anderen Katalog-Software-Systemen. Wir haben also Harvesting-Tools drin, um halt komplette Replikation

aller Metadaten aus Katalogen zu schaffen, in MrMap aufzubauen, vielleicht um dann schnellere Suchen anzubieten und so weiter und so fort. Wir haben, so, zurück, ein asynchrones Harvesting auch gemacht, also wir haben an der Stelle jetzt die Möglichkeit geschaffen,

beliebige CSWs alle parallel zu harvesten. Man muss da nicht unbedingt irgendeinen Zeitstempel angeben, wann die gehavestet werden müssen, sondern die Sachen laufen alle asynchron im Backend an der Stelle. Im Bereich der CSWs, die in Deutschland, also bei der GDI.de benutzt werden, verwendet werden, da auch schon seit einigen Jahren angeboten werden von den Bundesländern, von den Bundesbehörden,

haben wir einige Fehler festgestellt in den Katalog-Schnittstellen. Beim Testen, die Operation URIs werden teilweise unterschiedlich angegeben, da ist die Spezifikation auch nicht eindeutig. Wir haben verschiedene Interpretationen von Parameter-Namen, das hat mich auch ein bisschen gewundert, weil ja eigentlich diese Catalog-Service-Schnittstelle auch schon seit 2007 von der URIC spezifiziert worden ist.

Wir haben fehlende Rückgabewerte von Next Record, das ist beim Paging und beim Harvesten von Katalogen eigentlich wichtig, dass die Information mit rüberkommt. Und wir haben auch teilweise Fehler in der Server-Komponenten, dass Max Records einfach nicht interpretiert wird. Im Bereich der ETF-Integration haben wir jetzt eine Möglichkeit geschaffen,

über die Metadaten-Anzeige verschiedene beliebige Validatoren auf ETF-Basis halt mit anzubieten. Über so einen Validation-Button kann man sich dann die konfigurierten Validatoren, hier ist der Inspire-Validator dann eben konfiguriert, dass Metadaten validiert werden können oder auch Dienste validiert werden können.

Und dann kann ich über eine einfache Metadatensicht auf den Validator klicken und der Validierungsprozess wird im Backend asynchron quasi gestartet. Im Frontend haben wir dazu noch keins, also keine Möglichkeit, diese Konfiguration für diese ETF-Rest-APIs in der Oberfläche einzutragen. Das kann man aber relativ einfach im Django-Backend machen.

Django hat ein Administrations-Backend, über das sich dann beliebige Validatoren halt in der Datenbank konfigurieren kann. Hier das Beispiel Inspire-Validator, der ist für den Metadatentyp Service halt konfiguriert und dann wird eben gesagt, ich werde eine ETF-Rest-API anschließen, muss die URI auf die API angeben und kann dann auch einen Content-Type aus dem MrMap definieren,

der quasi überprüft werden soll. Ob das jetzt ein Capabilities-Link ist oder ob das jetzt ein Capabilities-Dokument ist oder ob das ein Service-Metadata-Record ist. Und die granulare Konfiguration, welche Test-Suites da durch, also ID's von Tests halt so durchzuführen sind für diesen Test, die kann ich dann in Form von einem JSON hinterlegen.

Das ist relativ einfach. Okay, ich habe eben mal gesagt, wir haben auch die Möglichkeit geschaffen, eben Hierarchien oder hierarchische Strukturen anders als über Parent-Child-Konstrukte zu hinterlegen. Und zwar geben wir halt von diesem normalen Adjacent-List-Modell zu einem Modified-Preordered-Retriverse. Die Vorteile an der Stelle, wir brauchen keine Rekursion,

um diese Layerbäume wieder aufzubauen. Wir können schneller Layerbäume oder Teillayerbäume rauslesen aus der Datenbank. Wir können das nutzen und nutzen das momentan für Webmaps-Services und wollen das auch nutzen für Webmap-Kontext-Dokumente. Und es gibt auch gute Django-Packages dazu, was eigentlich ohne relativ viel Programmieraufwand einfach verwendet werden kann, um Django dann in die Lage versetzt

über diese hochperformante Ablage von hierarchischen Objekten in der relationalen Datenbank und uns die Funktion zur Verfügung zu stellen, die wir brauchen. Im Bereich Testsystem oder Testdienst, den wir dann immer wieder nutzt haben, ist der Geoproxy von Thüringen. Das ist momentan der größte WMS-Dienst

mit den meisten Layern, der uns zur Verfügung steht. Und anhand dessen können wir auch immer relativ gut testen, wie schnell dann die Extraktion aus der Datenbank ist, der Ressourcen und die Anzeige nachher in der Oberfläche. Gehen wir andersherut. Machen wir mal die Motorhaube auf. Also, es ist recht viel passiert unterhalb der Oberfläche,

was man so am Mr.Map-Projekt so selbst direkt nicht sieht. Noch mal ein kleiner Vergleich. Was ist MapBender oder MapBender 2.8? Also, ich nehme jetzt mal einen Volvo-Motor, weil ich gerne einen Volvos schraube. Ein Volvo B30, Baujahr 1971. Mit 6 Zylindern, 3 Liter Hubraum. Und wir versuchen alles rauszukitzeln, was wir rauskitzeln kann.

Wir setzen da 3WD-Doppelvergaser drauf und kriegen dann 155 PS raus. Ist natürlich zu dem Zeitpunkt 1971 echt ein cooles Ergebnis gewesen. Aber dieses System ist natürlich so auch in Zukunft nicht mehr wachbar. Das heißt, Mr.Map ist halt zum Vergleich eigentlich, wir setzen auf die gleiche bewährte Architektur.

Also, ein Guss-Zylinder-Kopf, ein Guss-Block, der bulletproof ist und setzen auf dieses Konstrukt eine Einspritzung und Turbolader, kriegen 644 PS und 808 Newtonmeter raus. Und das ist jetzt eigentlich ein schöner Vergleich für Mr.Map. Im Gegensatz zu MAP Bender 2.8.

Was auch passiert ist, wir sind vom OSGEO GT zu GitHub rübergezogen, weil das OSGEO GT, da kann die Astrid vielleicht sich mal versuchen, drum zu kümmern, recht langsam ist. Und auch ein bisschen wenig Möglichkeiten zur Verfügung stellt. Deswegen war für uns eigentlich irgendwann kam der Zeitpunkt, wo wir das Projekt quasi von der OSGEO nach GitHub rübergezogen haben.

Ist dann auch einfacher, weitere Entwickler mit reinzunehmen in das Projekt. Was wir dann eben auch machen können, ist eine externe Qualitätssicherung durchzuführen. Wir setzen da momentan die Sonar Cloud ein. Und so haben wir auch immer aktuell eine Übersicht über die Qualität des Projekts. Und wir können auch Qualitätshürden einstellen, die dann verhindern, dass schlechte

Codequalität in dieses Projekt zurückfließt. Was wir gemacht haben, ist eine neue Dokumentation aufgebaut. Die ist noch ein bisschen rudimentär und auch nur auf Englisch, aber die beschreibt eigentlich recht gut, was Mr. Maps schon alles kann. Im Bereich User Management, Organisationsregistrie, Service Management, WMS, WFS, CSW, Metadaten,

Editoren haben wir zur Verfügung stehen. Wir haben Metadata Views, die ETF Testing Framework Integration, Monitoring System, Security Proxy, der ist letztes Jahr schon vorgestellt worden von Michelle. Und wir haben auch ein Publisher System für Organisation, Gruppen und User. Und ein Dashboard. Kommen wir weiter. Was wir auch gemacht haben hier, ist eine Anleitung

reingebracht für Softwareentwickler, um da relativ schnell in dieses System mit reinzukommen. Ist also eine relativ kurze Anleitung. Man kann das dann über Docker installieren, wenn man gerne möchte. Oder eben auch normal und konventionellen Weg auf einem DBN-10-System deployen. Die Konfigurationen sind alle, und die Dokumentation ist eigentlich recht übersichtlich. Wir haben hier die Komponenten

für Docker. Das wäre auf der einen Seite die Puskis 11, auf die wir setzen. Wir haben einen Redis Server im Hintergrund, der gebraucht wird für die asynchronen Sachen. Hauptsächlich Map Server für den Security Proxy. Dann nehmen wir die 7.6er Version, die mit drin ist, und Engine X als Web Server. Das hatte ich eben kurz angesprochen

gehabt. Wir sind vor kurzem übergegangen. Auch diese ganzen asynchronen Dinge, die früher bei Ajax abgefrühstückt worden sind, eben auf Websockets umzustellen. Das bedeutet, die Architektur dieser Mr.Map Umgebung sieht jetzt ein bisschen anders als vorher. Wir haben in Engine X das Reverse-Proxy vorneweg, und wir haben dann zwei

verschiedene HTTP-Server. Einmal für die asynchronen Prozesse, den Unicorn und den Unicorn eben für die normalen Prozesse. Und dann Mr.Map als Django Application und Django als Web Framework im Backend stehen. Okay. Das war zur Architektur. Jetzt habe ich mal hier ein kleines GIF gemacht, so ein Registrierungsprozess. An dem kann man recht schön

sehen. Also wir registrieren jetzt einfach einen Dienst mit 30 Layern und Datensätzen, die verlinkt sind an den einzelnen Layern. Die werden dann alle gehavestet bei dem Registrierungsprozess, obwohl so etwas relativ lange dauern kann bei großen umfangreichen Diensten. Das hier ist jetzt noch ein kleiner Dienst, aber wir haben ja teilweise welche mit 800 Layern. Es ist wichtig, dass der Nutzer auch ein Feedback

bekommt über diesen Status jeweils des Registrierungsprozesses. Und da setzt man momentan eben auf Websockets. Okay. Was auch unter der Haube passiert ist, wir sind, das ist jetzt ein Programm mit mehr Paradigma von den klassenbasierten Views von Django. Da sind wir von den Function-Based Views zu klassenbasierten Views gegangen. Das gibt eine bessere Erweiterbarkeit.

Quelltext wiederverwendbar. Feeds von Django können wir weiter nutzen, Detailansichten, Listen und so weiter. Und alle Views sind eigentlich schon überarbeitet worden. Jonas, vielen Dank. Das hast du super gemacht. Und das Rechte- und Rollensystem hat der Jonas auch überarbeitet. Wir haben also, wir sind von einem eigenen Rollensystem, was letztes Jahr noch vorgestellt worden ist,

zu einem Standard-Package gegangen, Django Guardian. Dazu haben wir dann eine Erweiterung bekommen, eine ACL-basierte Erweiterung, die dann auch ermöglicht über Rollenberechtigung bis auf die Objektebene runterzustricken. Und die Erweiterung für die Class-Based Views liefert Django auch schon mit. Damit haben wir weniger Programmierarbeit. Und

die Automation der Berechtigungsvergabe wird zwar schwieriger, aber die Erweiterung der Views dann eben einfacher. Okay, weiteres Reingenierungen des Systems. Wir haben das Modell auch in den letzten Wochen intensiv überarbeitet, das Informationsmodell im Backend und haben dann eine konsequente Vererbung eingeführt von den Ressourcen zu den Metadaten und dann eben

auf Dataset, Metadata Service, Metadata und weitere Metadata Entities. Der XML-Parser ist auch schon mal überarbeitet worden. Da sitzt der Jonas, glaube ich, jetzt auch noch dran. Der ist extrem verschlankt worden. Und sehr, sehr generisch, sodass beliebige XML-Dokumente jetzt problemlos ergänzt werden können. Jetzt momentan für Metadaten-Capabilities und die Operation

der Dienste. Die Parallelisierung der Persistierung von Metadaten ist erfolgt. Das führt dazu, dass auch sehr, sehr große, umfangreiche Dienste und Kataloge halt recht performant geharvestet werden können. Und so weiter und so fort. Also das ist recht viel passiert im ganzen Projekt. Einen Punkt,

den ich nochmal besonders hervorheben will, hatte ich auch in der Vorstellung auch schon erwähnt am Anfang. Der MapBender hat früher auf WMC-Dokumente gesetzt. Also XML-Dokumente, die von der OGC spezifiziert waren, hat die um Metadaten ergänzt und wir haben diese Konstrukte genutzt, um die Karten, um Karten anzubieten im Geoporteil. Der Begriff Karten entspricht einem

mit Metadaten angereicherten WebMap-Kontext Dokument. Im MrMap-Projekt gehen wir da jetzt ein bisschen anders vor. Das ist kein XML, das wir verwenden. Wir werden ein relationales Modell aufsetzen. Map-Kontext-Objekt besteht aus beliebig vielen Kontext-Layern. Diese Kontext-Layer können View-Options haben oder Create, Read, Update

und Delete-Options. View-Options könnten WMS-Layer sein. Die Code-Options könnten über die WFS-Interfaces oder OGC-API-Features- Interfaces bereitgestellt werden. Und wir ergänzen Map-Kontext und Kontext-Metadata wie auch zuvor. Und die Kontext-Layer basieren aber auf Dataset-Metadata-Konstrukte. Das ist so die

neue Einführung, die Idee dahinter. Wir haben dann die Idee im Endeffekt über MrMap auf ISO-Metadaten und OBS-Kontext REST-API-basierendes Interface anzubieten. Also wir nehmen erstmal OBS-Kontext, weil wir nichts anderes haben, und würden dann dieses Interface als REST-Schnittstelle bereitstellen,

sodass beliebige Web-Client, ob das jetzt MapBender 3, Leaflet, OpenLayers, SASE und QGIS oder Master-Portal wäre, direkt auf dieses performante Service-Backend zugreifen kann und sich da diese Karten- konfigurationen rausziehen kann, den Zustand zwischenspeichern kann. Was wir dann erhalten über diese Map-Kontext- Dokumente ist im Endeffekt ein sehr generisches

Layer-Konzept. Wir haben hier so einen Screenshot vom Produktivsystem. Da ist das vielleicht ein bisschen dargestellt. Wir haben einen Layer, der heißt hier Gemarkungen. Der Titel der Gemarkungen wäre Dataset-Meter-Data-Information. Die können wir da rausnehmen. Wir können die Darstellung der Gemarkungen über ein BMS-Rendering realisieren und die Abfrage der Daten

über Get-Feature oder Get-Feature-Info realisieren und der Feature-Type- Access, also der direkte Access auf die Datenbank-Tabelle erfolgt dann hier über diesem Tabellensymbol am Layer. Damit kommen wir ein bisschen aus diesem komplexeren GDI-Konstrukt raus und der Nutzer, der sieht halt wirklich nur Datensätze und die Möglichkeiten, diese Datensätze zu nutzen.

Der Kontext-Editor ist auch schon rudimentär fertig. Der wird momentan von der Terrestris entwickelt und erlaubt dann im Backend die verschiedenen registrierten Ressourcen in beliebigen hierarchischen Verschachtelungs-Eben miteinander zu kombinieren und als Web-Map- Kontext oder Map-Kontext-Dokument im relationalen Modell abzulegen.

Nochmal zusammenfassend, also die Code-Stabilität und Qualität wurde stark verbessert. Das Deployment, der Aufbau des Entwicklungssystems ist sehr, sehr einfach geworden und die Nutzung von LabSockets bereitet auch für uns einen einfachen Weg, falls wir dann irgendwann Sensordaten integrieren wollen. Das ist eine ganz coole Technologie und wir hoffen Ende des Jahres oder vielleicht Ende des dritten Quartals die erste stabile

Version vorliegen zu haben, die man dann als 1.0 auch schon für ganz, ganz viele Aufgaben im Rahmen einer GDI verwenden kann und würden dann auch eine der Komponenten schon direkt in unser Geo-Portal Produktivsystem als Komponente mit einbinden, wäre wahrscheinlich die verteilte Suche in verteilten Katalogen,

die wir dann eben schon von Mr. Lab dann nutzen würden. Okay, das könnte ich noch, wenn ich noch ein bisschen Zeit hätte, die ich nicht mehr habe, die Staging zeigen, also wir haben das Staging-System, wo man sich anmelden kann oder ein Nutzerkonto anlegen kann und Dienste registrieren kann, aber ich denke, wir sind jetzt an den Punkt angelangt, wo Fragen gestellt werden können.

Ja, damit wäre ich so weit am Ende. Gut, wunderbar. Dann danke, Armin, auf jeden Fall für diesen interessanten Vortrag und für den Einblick und tatsächlich sind auch Fragen angekommen und von daher, genau,

arbeiten wir jetzt einfach mal ab. Fangen wir einfach mal an. Ich hoffe, die Regie, ich hoffe, man sieht mich, aber ich glaube schon. Genau, fangen wir an mit der Frage mit den meisten Votes. Die hast du bestimmt auch schon häufiger gehört. Wieso kein Abbild auf die aktuelle MapBender-Version, also kein MapBender 3?

Ja, gut. Die Diskussion hatten wir schon vor acht, neun Jahren, als MapBender 3 entwickelt worden ist, geführt gehabt. Meine Idee war damals gewesen, MapBender 3 halt so zu entwickeln, dass wir eine Migrationsmöglichkeit bekommen, von der MapBender 2 Instanz auf MapBender 3. Die haben wir nicht hinbekommen. Und MapBender 3 hat halt diese ganzen Funktionalitäten im Backend

zur Verwaltung der Dienste, Verwaltung von Metadaten ist da nicht vorhanden. MapBender 3 hat sich sehr, sehr stark auf die ja, sagen wir mal so, auf die GUI-Baukasten-Funktionalität von MapBender 2 fokussiert, was ja auch eine gute Sache ist und deswegen ist MapBender 3 auch sehr, sehr gut einsetzbar für diesen Anwendungsfall. Aber das, was wir für Geodateninfrastruktur brauchen, also Verwaltung von Metadaten,

von Diensten und so weiter, war im MapBender 2 ganz, ganz anders umgesetzt. Und das haben wir eben in Form von Mr. Map dann noch mal optimiert, sagen wir mal so. Genau. Andere Frage, die ich auch quasi ein bisschen anders gestellt hätte, wenn Sie keiner gestellt hätte, wie viele Personen sind in Geo-Portal-RLP aktiv oder entwickeln beispielsweise Code? Kannst du vielleicht

ein bisschen was zur Struktur sagen, wer da gerade alles mitentwickelt? Also das ganze Geo-Portal-RLP-Projekt, das kümmert sich ja auch um MapBender 2, um die Frontends und so weiter. Wir haben in Hessen, haben wir zwei Personen sitzen, die mitentwickeln können. Wir haben im Saarland noch einen Kollegen sitzen, der

was machen kann. Wir haben die Terrestris mit im Boot, die Module entwickelt für Mr. Map bei dem neuen Projekt. Wir haben die Firma NetGiz in Trier im Boot, die hat den Mobile Client entwickelt und die können für solche Zecke einsetzen. Und im eigenen Haus haben wir momentan zwei Informatiker, den André, den Jonas und dann eben auch noch mich.

Und wir arbeiten da zusammen eben an diesen Projekten. Alles klar. Auf die Urgucke schaffen wir die anderen beiden Fragen auch noch. Ich bin mir nicht sicher, ob der Fragesteller das so meinte, was sind die Vorteile von MapBender gegenüber OpenLayers oder meint er vielleicht, was sind die Vorteile von Mr. Map gegenüber OpenLayers? Ja, ja gut.

Mr. Map hat da gar keinen Kartenführer drin. Also OpenLayers und Mr. Map sind zwei getrennte Dinge. Ich glaube, ich hatte das eben an dem einen Beispiel ganz gut Zeit gehabt mit dem mit dem Screenshot hier rein. Genau. Sonst kannst du im Zweifel ja auch noch mal ein, zwei Sätze sagen, warum MapBender und nicht, was die Vorteile von MapBender gegenüber OpenLayers sind, weil das ja auch

quasi... MapBender und OpenLayers? Gut, die kann ich jetzt stellen. Ich bin jetzt kein Vertreter von MapBender. Genau, lassen wir die Frage... Genau. Dann haben wir noch eine letzte Frage. Ist OWS Context dann offiziell Standard? Geht die entsprechende REST-API in Richtung OJC-API?

Ja, OJC-API. Ich glaube, die OJC hat noch keinen Entwurf für eine Context-API. Das wäre für uns jetzt mal so ein Anfangspunkt. Wir setzen auf dieses OWS-Context-Dokument, was quasi von der OJC vor paar Jahren mal entwickelt worden ist, als Nachfolger vom WMC-Standard. Der gibt uns die Möglichkeiten, WFS, WMS-Resourcen, KML-Resourcen

und beliebige weitere Web-Services in einem JSON-Konstrukt oder XML-Konstrukt zu verwalten, abzuspeichern und auszutauschen. Wie die API aussieht, da müssen wir uns dann mit der OJC auch drüber unterhalten. Aber wir haben derzeit international kein anderes Dokument, was uns quasi so eine generische KUGIS-Projektdatei, damit könnte man vielleicht

Vergleichen, zur Verfügung stellen. Deswegen setzen wir im ersten Schritt auf OWS-Context, bohren das auf, soweit wir es brauchen und bauen eine API drauf und gucken dann ob wir mit der OJC zusammenarbeiten und dann so einen neuen, guten Standard für den Austausch von solchen Systemen entwickeln. Wir haben gestern vom MapBanner3-Projekt, vom Olaf Knopp ja auch schon gehört. MapBanner3

baut ja auch schon so was Ähnliches ein, in ihren neuen Client. Also sie haben so Shared Instances, die sie ja austauschen können. Die Anforderungen kommen in allen Projekten. Existieren die Anforderungen. Und wir haben aber leider keinen Standard. Das ist ein bisschen schade. Alles klar. Wunderbar. Dann, Armin, danke für deinen interessanten Vortrag.

Genau, danke, dass du nochmal für Fragen zur Verfügung standest.