WPS für kommunale GDIs - Eine Fallstudie über den Mehrwert von Web Processing Services (WPS) am Beispiel der Geodateninfrastruktur Freiburg (GDI-FR)
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 77 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46470 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
1
11
12
13
16
18
19
23
24
30
34
41
43
46
65
69
70
72
77
00:00
Workplace ShellProcessing <Programmiersprache>InternetdienstSpatial data infrastructureImplementationDesktopClient (computing)Component-based software engineeringNFSUniform resource locatoroutputSoap <Programm>ACCESS <Programm>Workplace ShellWEBUniform resource locatorMilitary operationData typeImplementationBlogProcess (computing)Disk read-and-write headProcessing <Programmiersprache>outputStandard deviationWeb serviceInterface (computing)Open sourceSpatial data infrastructureString (computer science)BASICComputer animation
06:58
Workplace ShellWeb serviceImage registrationSpatial data infrastructureAutomationComponent-based software engineeringDigitizingSQLParameter (computer programming)Particle detectorIP addressCoordinate systemWorkplace ShellCommunications protocolWeb serviceSpatial data infrastructureComponent-based software engineeringAnbindung <Informatik>InternetdienstFunction (mathematics)VerschneidungZahlBerechnungRoute of administrationProcess (computing)Soap <Programm>Interface (computing)Uniform resource locatorProbability distributionGeometry
13:49
Workplace ShellIP addressCoordinate systemFunction (mathematics)SoftwareMetreIP addressWEBXMLProgram flowchart
15:07
Computational fluid dynamicsMicrosoft DynamicsSpatial data infrastructureWorkplace ShellMessage passingoutputQUICK <Programm>FlussdiagrammInformationProcess (computing)DruckwelleÜberdruckBerechnungIP addressFORTRANVoxelComputer animation
17:53
Workplace ShellDerived set (mathematics)Configuration spaceMathematical analysisAbschätzungImplementationServer (computing)Version <Informatik>Gateway (telecommunications)Computer animation
18:32
Workplace ShelloutputImplementationGNU <Software>Server (computing)XMLWorkplace ShellIP addressRadiusLecture/Conference
19:51
Workplace ShellBerechnungComputer animation
20:11
Workplace ShellKennlinieScalar potentialPlane (geometry)UsabilityData qualityWorkplace ShellComputer musicSoftwareNormal (geometry)Interface (chemistry)Web browserScientific modellingProcess (computing)Route of administrationInterface (computing)Focus (optics)Hausdorff spaceComputer animation
24:48
DDE
Transcript: German(auto-generated)
00:08
Herzlich willkommen zum dritten Vortrag in diesem Blog. Michael Schulz hat uns ja am Mittwoch versprochen, dass er beweisen wird, dass die Stadt Freiburg Open Source einsetzt. Das kann er jetzt live tun. Er wird uns jetzt in einer Fallstunde erklären, wie man Web Processing
00:24
Services in kommunalen Geodateninfrastrukturen einsetzen kann. Ja, vielen Dank. Ein bisschen weiter weg. Willkommen noch mal zu einem der letzten Vorträge auf der Voskis. Heute ist ja auch schon der letzte Tag leider.
00:41
Ich stehe hier jetzt eigentlich nur stellvertretend für meinen Kollegen Gunnar Ströer, der eigentlich diesen Vortrag halten wollte und ihn eigentlich auch natürlich inhaltlich vor allem komplett erstellt hat. Das heißt, ich bitte so ein bisschen Nachsicht, wenn ich nicht zu jeder Folie die gesamte Tiefe
01:01
ihn bieten kann, die er hier gebracht hätte. Aber wir versuchen es einfach mal. Es ist jetzt ein Thema, bei dem ich auch ein bisschen beteiligt war. Letztendlich ist es vor allem das Thema seiner Masterarbeit, die er gemacht hat. Es geht dabei um das Thema Web Processing Services, also ein OGC Standard.
01:23
Und wir wollten oder er wollte damit vor allem erst mal schauen, lohnt sich denn der Einsatz von Web Processing Services für eine kommunale Geodateninfrastruktur? Da komme ich nachher noch mal drauf, warum WPS vielleicht ein bisschen
01:41
spezieller ist als andere OGC Standards. Ich möchte euch also ein bisschen was über die WPS Basic sagen, ein bisschen den Inhalt dieser Frage diskutieren. Verlohnen sich WPS Services für kommunale GDIs? Wir werden das oder er hat das an einer ganz konkreten Fallstudie dann eigentlich versucht umzusetzen und
02:03
da werde ich ein bisschen was zu seiner Implementierung und zu den Ergebnissen dann dazu sagen. WPS ist ein OGC Standard, gibt es schon eine ganze Weile, ist mit Sicherheit aber einer der Standards vom OGC, die jetzt
02:21
weniger stark adaptiert worden sind, weil ihr die Spezifikation auch deutlich abstrakter ist als zum Beispiel WMS oder WFS. Der WPS, es steht hier, einige der Sachen sind auf Englisch, weil er hat diesen Vortrag auch in einer
02:40
ähnlichen Variante bei Unigis gehalten, deswegen sind ein paar Sachen auf Englisch. Das OGC versteht also unter einem WPS, die standardisierte Schnittstelle, um räumliche Prozesse miteinander zu verknüpfen und über diese standardisierte Schnittstelle sozusagen das Auffinden und das
03:03
Ausführen dieser Prozesse zu ermöglichen, die dann von irgendeinem Client, sei es jetzt ein Webclient oder auch ein Kugis zum Beispiel aufrufen würde. Das grundlegende Prinzip von WPS ist, dass es eben jetzt
03:22
diese drei unterschiedlichen Aspekte gibt. Ich habe also einen WPS-Client, der einen Aufruf macht. Ich habe einen WPS-Server, sagen wir mal, also der in der Mitte sitzt, der die Anfragen entgegennimmt und der selber aber wieder die Ausführung der einzelnen Prozesse eventuell
03:40
noch mal an eine dritte, an einen entfernten Dienst weitergeben kann. Und diese rote rosa-liche Spalte, die Processing-Komponenz, die hat er jetzt noch mal unterteilt. Natürlich gibt es ganz klassische räumliche Operationen, die man da durchführen kann, aber das muss gar nicht unbedingt sein. Das kann also im Prinzip jede spezielle Funktion, die
04:05
in so einem Prozess gekapselt werden kann, kann darüber auch dann aufgerufen werden. Viele der OGC-Standards folgen ja so einem ganz klaren, immer möglichst gleichbleibenden Konstrukt, wie die Anfragen
04:26
hin und her geschickt werden. Das macht auch der WPS. Das ist jetzt noch, ich glaube, grundlegend eher auf dem WPS 1.0 basierend. Und natürlich, wie bei allen, gibt es Standard-Get-Capabilities-Abfrage.
04:42
Das heißt, da kann der WPS erst mal sagen, was kann ich denn überhaupt machen? Welche Prozesse biete ich an? Das heißt, ein Prozess würde jetzt zum Beispiel ein bisschen wie ein WFS-Feature-Type oder WMS-Layer entsprechen. Also, welche Layer habe ich überhaupt? In dem Fall, welche Prozesse habe ich? Und dann kann man einen einzelnen Prozess
05:02
noch spezieller abfragen. Describe-Process heißt es dann. Das heißt, da würde ich quasi die Infos zu einem speziellen Prozess bekommen. Die brauche ich natürlich, weil so ein Prozess, der kann ja Inputs und Outputs haben. Und diese Inputs und Outputs werden in so einem Describe-Process dann tatsächlich beschrieben. Und ganz am Ende gibt es dann noch
05:23
die Execute-Funktion, die sozusagen das wirkliche Ausführen des Prozesses initiiert. Also, das waren die Pflichtoperationen. Es gibt noch ein paar andere, aber wir beschränken uns jetzt mal auf die Pflichtoperationen. Der WPS, ich habe es gerade schon gesagt, das Execute kann mit Inputs
05:43
und Outputs umgeben. Es gibt dazu unterschiedliche Typen von Inputs und Outputs. Also, man kann ganz einfache, ein Typ heißt zum Beispiel Literal Data, da kann ich also einfach ein Wert eingeben, also eine Zahl, eins oder ein String. Ist also ganz einfach. Spannend wird es natürlich dann, wenn es um sogenannte Complex-Inputs geht. Da kann ich
06:04
im Prinzip erstmal alles irgendwie in den WPS reingeben, sei es eine UAL. Der WPS wird dann versuchen, diese UAL aufzulösen. Es könnte zum Beispiel eine WFS-UAL sein, die würde ihm also irgendeine Vector-Daten zurückliefern. Es kann aber auch ein komplexer Input
06:20
sein, eine GML-Struktur, die innerhalb des Execute-Bodies quasi mitgeschickt wird. Da ist man dann sehr frei. Das Gleiche gilt genauso für die Outputs. Bei den Outputs kann der WPS entweder die Ausgabe ohne irgendeinen Header außen rum wieder zurückgeben. Das
06:44
wäre dann zum Beispiel so, wenn man ein Bild bekommt, dann könnte man das Bild direkt darstellen im Brause oder so was. Oder er kann es eingekapselt in eine richtige Antwortstruktur geben, auch zum Beispiel mit einer UAL, wo das Ergebnis abgelegt worden ist. Wir hatten es heute Morgen bei dem anderen Vortrag von einem
07:02
Kollegen mit dem Function as a Service. Auch hier ist das Thema Synchrone- und Asynchronenausführung. Wenn man sich vorstellt, ich habe einen Prozess, der berechnet mir als Standard-Testprozess, macht man immer vielleicht so, ich gebe eine Zahl ein, ich gebe eine zweite Zahl ein und ich kriege das Ergebnis, also eins plus zwei, drei, dann geht es sehr
07:20
schnell. Da mache ich eine Synchrone-Ausführung, weil ich schicke die Anfrage ab und warte direkt auf das Ergebnis Synchrone-Ausführung. Bei einer Asynchronenausführung, was wir nachher im Fallbeispiel haben, da ist es natürlich so, ich muss vielleicht große Datenmengen übertragen oder ich übergebe eine UAL und diese UAL muss große Datenmengen erst abrufen.
07:41
Da will ich als Anwender natürlich nicht drauf warten, bis der fertig ist mit der Prozessierung, sondern dann kriege ich quasi gleich zurück von dem WPS-Server, die antwortet okay, die Ausführung ist gestartet und sobald die UAL mit zurückgeschickt, findest du das Ergebnis und das ist dann die Asynchronenausführung, der bietet auch
08:02
die Möglichkeit dann, also so Prozessangaben, wie fertig ist der Prozess, das kann man immer, man kann die UAL, die Ergebnis-UAL immer wieder aktualisieren und bekommt dann quasi die Info, okay, zehn Prozent fertig, 20 Prozent fertig. WPS hat von Anfang an sehr großen Wert darauf
08:21
eingelegt, weitere Protokolle zu unterstützen, nämlich zum Beispiel Soap oder auch Whistle, um die Einbindung in andere Workflow-Engines vor allem zu ermöglichen. Also WPS selber ist ein Teil, hat einen bestimmten
08:41
Aspekt von Workflow-Orchestrierung, wenn es aber komplexer wird, dann bietet es sich eigentlich eher an, auf eine andere Workflow-Engine zu gehen und der WPS-Server unterstützt quasi die ganz normalen Standard-OGC-Anfragen und er unterstützt aber auch zum Beispiel eine Whistle-Anfrage und gibt seine Prozesse auch in diesem Protokoll raus. Genau und
09:03
jetzt ist natürlich die Frage, lohnt sich so ein abstrakter WPS-Server auch von einer kommunalen GDI? Er hat dann eben in der Arbeit das bisschen untersucht und zwei Sachen sind so ein bisschen rausgekommen. Zuerst ist, dass es aktuell noch nicht einfach in der wirklich breiten, im breiten Einsatz
09:22
ist, meist von internationalen Forschungseinrichtungen eingesetzt wird. Das kann ich bestätigen, ich habe auch da schon mal gearbeitet und mit WPS gearbeitet, da macht das irgendwie noch mal ein bisschen mehr Sinn, weil man wirklich auch räumlich verteilt sitzt. Viele sitzen dann auf ihren Daten und vielleicht auch auf ihren Modellen, weil da geht es natürlich eventuell tatsächlich um die Anbindung von
09:41
irgendwelchen Berechnungsmodellen und die kann man nicht so einfach irgendwo hingeben, aber man kann natürlich eine Schnittstelle über WPS nach außen bieten. Aktuelles Thema ist auch, dass das Registrieren von WPS-Diensten anscheinend nicht so häufig stattfindet, zum Beispiel in Katalogdiensten und man deswegen gar nicht so viele tatsächlich auch
10:01
finden kann über Geodatenkataloge. Eine These, die wir letztendlich da haben, ist, dass WPS vor allem mit einer offenen, also auch nicht unbedingt Open Source, aber zumindest mit einer offenen Geodateninfrastruktur funktioniert oder Sinn macht, im Gegensatz
10:21
jetzt zu einer komplett abgeschlossenen proprietären Infrastruktur, wie jetzt der komplette Produktdeck von Esri. Da habe ich natürlich ganz viele Funktionen und die Tools arbeiten sowieso miteinander. Wenn ich mich in der Welt bewege, dann ist die Frage, ob so ein Service Sinn macht. Aber in einer offenen Geodateninfrastruktur,
10:42
wo ich ganz viele verteilte Dienste habe, da kann es durchaus Sinn machen, diesen Lösungsweg über den WPS zu gehen. Hier mal noch mal einfach die Struktur von unserer Freiburger GDI und der WPS kann sich da eben ganz gut mit einbinden. So, für die
11:01
Fallstudie war jetzt so ein bisschen der Punkt, wie kommen wir denn an einen guten Anwendungsfall. Das ist nämlich auch gar nicht so einfach, weil ich meine die ganzen Beispiele, die man immer findet, das war wie gesagt das besprochene 1 plus 1 oder 1 plus 2. Das heißt, wir wollten eigentlich was finden, wo wir eine räumliche Fragestellung mit einer nicht räumlichen Komponente irgendwie verbinden können. Es wäre schön, wenn die
11:21
Herkunft der Frage nicht aus unserem klassischen Geobereich käme. Im Normalfall wäre es gut, wenn die Leute, die damit arbeiten, eigentlich jetzt keine Gist-Experten sind und die Frage sollte eine notwendige Komplexität aufweisen. Und es wäre natürlich schön, wenn es für die Aufgabe bisher noch
11:41
keinen existierenden Workflow gibt. Dann war natürlich noch ein Aspekt, ist, wenn ich das Ganze bewerten will, dann muss ich natürlich auch irgendwie noch eine Messbarkeit der Ergebnisse im Auge haben. Also da hat man sich dann so ein paar Sachen angeschaut, wie zum Beispiel das Thema eben Datenabgaben. Kann man das irgendwie automatisieren?
12:01
Häufige Funktionen wie Verschneidung von Flurstücken mit Adressen, solche Sachen, Geocoding, Reverse Geocoding. Das waren alles so sehr geolastige Themen, die wir dann fanden nicht so spannend waren und vielleicht auch nicht diese Anforderung von vorher erfüllten. Und wir haben uns letztendlich, sind wir auf diesen Punkt gekommen, als wir mit
12:22
dem Amt Verbrannt und Katastrophenschutz zusammensaßen und hier in Freiburg, dem Fraunhofer Ernst-Mach-Institut. Das ist Thema Kampfmittelbeseitigung und Evakuationsradien und die Berechnung dieser Evakuationsradien eigentlich ein ganz spannender Punkt ist, weil er im Prinzip eine Vielzahl
12:43
von verteilten Verantwortlichkeiten hat. Man sieht es mal hier auf diesem Ablaufschema. Es gibt erst mal eine grundlegende Verteilung an Aufgaben in die lokale Behörde und in übergeordnete Behörden. Also der Kampfmittelbeseitigungsdienst ist vom Land. Dann gibt es innerhalb der Stadt unterschiedliche Verantwortlichkeiten, auch Datenhoheiten.
13:01
Also das ganze Thema Adress, Melderegister liegt halt bei einem Amt. Die andere Sache ist das amtveröffentliche Ordnung, die dann wirklich diese Anordnung als Polizeibehörde wahrnimmt, wenn es um die Evakuierung geht. Also da ist schon mal eine verteilte Aufgabenstellung gegeben. Und wir haben uns also einen schönen, gut
13:23
ausgegangenen Kampfmittelbeseitigungsfall rausgesucht, der vor drei Jahren, ziemlich genau drei Jahren eigentlich, ne vier Jahren, hier in Freiburg ganz in der Nähe war, in der Klarastraße auf der anderen Seite von der Bahnlinie. Dort wurde eine Fliegerbombe gefunden, 300 Kilo knapp. Und es war also die
13:42
Frage eben, wie wir das, wir haben das jetzt quasi nachgespielt. Beim damaligen Zeitpunkt hat man einfach das ganz normal gemacht. Man sieht jetzt mal hier, kann man sich ungefähr vorstellen, wir sind jetzt ungefähr hier, da sehen Sie die Maus, also außerhalb der Karte, ja da ist ungefähr das naturwissenschaftliche Institut,
14:01
hier ist der Bahnhof und auf der anderen Seite des Bahnhofs war diese Fliegerbombe gefunden. Das war jetzt mal der Evakuierungsradius, das machen die dann eher so 300 Kilo, 300 Meter und dann wird halt geguckt, welche Adressen liegen da drin. Aktuell lief es halt noch
14:22
sehr analog, da wird dann wirklich eine Karte ausgedruckt, da wird was draufgemalt, das wird dann irgendwo hin gesandt, also war noch, ist eine sehr analoge Variante. So, in unserem Fall, da haben wir jetzt einfach hier nochmal die einzelnen Komponenten, die jetzt hier mitspielen und da ist besonders spannend natürlich der Punkt hier unten, also das sind
14:41
quasi unsere internen Ressourcen, die wir haben, Tools, Datenbanken, die Daten überhaupt, dann unser Web-Processing-Service, der in der Mitte steht und unterschiedliche Funktionen bereitstellt, wir haben dann letztendlich die Alarmierungskette an den Katastrophenschutz, die Ordnungsbehörde und hier unten haben wir eigentlich das ganz spannende, außenstehende
15:00
Berechnungsmodell, das ist nämlich der Apollo Blast Simulator, das ist also die Software vom Fraunhofer Ernst-Mach-Institut und dieser Apollo Blast Simulator ist jetzt sozusagen eine, ich weiß schon gar nicht mehr, also ich glaube, in Fortran geschriebene Computational Fluid Dynamics Tool, um die Druckwellenverteilung
15:24
zu modellieren. Ist auch, hat natürlich eine räumliche Komponente, ist aber jetzt nicht georeferenziert, sondern arbeitet quasi in einem 000-basierten Wachsleraum. Da sieht man also schon, es hat nicht eine räumliche Komponente, aber die Übergabe der Daten ist schon nicht so ganz trivial und
15:41
was letztendlich passiert, man sieht das hier in diesem farbigen Bild, im Prinzip werden basierend auf dem Gebäudemodell unterschiedliche Druckstärken errechnet, also an welcher Stelle tritt welcher Überdruck auf und an diesen Kennzahlen, die auf der anderen Seite sind, da sieht man dann auch welche
16:00
unterschiedlichen Materialien sind quasi mit welchem Druck sozusagen betroffen, also wie bekommt das Beton ab, wie bekommt das Sicherheits- oder normales Glas ab. Ja, wir haben also beschlossen, wir machen zwei Prozesse letztendlich, also zwei grobe Stränge. Das eine ist, wir machen eine schnelle
16:20
Vorselektion, im Falle, das was ist, damit man schnell die Adresslisten bestimmen kann. Das ist also ein Prozess, der braucht erstmal einfach nur den Punkt, wo ist die, wo ist das Kampfmittel gefunden worden und man braucht eine grobe Schätzung, wie schwer ist es, dann hat man hier letztendlich einen kleinen Prozess, der einem am
16:42
Ende rausgibt, welche Adressen sind betroffen, wie viele Einwohner sind da wahrscheinlich drin und diese Sachen werden letztendlich automatisch dadurch erstellt. Der zweite Punkt, das ist quasi das, was parallel letztendlich angestoßen wird, da geht es nämlich jetzt drum sozusagen auf detaillierteren
17:02
Informationen, die Informationen zusammen zu bringen, die der Apollo Blast Simulator für die tatsächliche Berechnung braucht. Der braucht nämlich wesentlich mehr Informationen. Einerseits brauchen wir mehr und genauere Informationen über den Kampfmittel und dann braucht er auch wesentlich mehr
17:20
Informationen. Er braucht ein 3D-Start-Modell, er braucht ein Geländemodell, er braucht, was braucht er denn noch alles, naja, lasst uns mal da dabei, er braucht eine ganze, kriegt so eine Konfigurationsdatei und die wird quasi dann dort hingeschoben und dann rechnet der Prozess und das kann durchaus auch länger dauern, also da sind wir dann eher so in der Berechnung von halbe Stunde
17:40
bis mehrere Stunden, also ein typischer asynchroner Prozess und er liefert dann letztendlich dieses, diese, diese Verteilung der Druckwellen liefert er wieder zurück. Hier jetzt einfach nochmal die unterschiedlichen Unterprozesse, die sozusagen in diesem Gesamtkonstrukt
18:00
definiert wurden. Wenn ich jetzt gar nicht so arg tief drauf eingehe, weil das dann doch sehr spezifisch für den, für den Apollo Blast Simulator ist. Wir haben das Ganze implementiert mit PyWPS, ein WPS, Open-Source-WPS-Projekt, was es schon relativ lange gibt, habe ich früher auch mal mitgemacht bei denen
18:22
und das bietet sich einfach an, weil es wirklich total einfach zum Aufsetzen ist, keine großen Abhängigkeiten hat mit Python, auch Gedal-Anbindung kann man sehr gut letztendlich arbeiten. Genau, das sind jetzt einfach nochmal die Prozesse, die, wie sie letztendlich in dem WPS-Prozess definiert worden sind
18:40
und ja, also die Schwierigkeit ist natürlich immer, wenn man das jetzt bewerten will, ist es sinnvoll, sowas von der Kommune einzusetzen oder nicht, dann ist natürlich die Abgrenzung dieses Prozesses und die Wiederverwendbarkeit,
19:01
das ist natürlich eine schwierige, eine schwierige Sache. Das heißt, dieser Evakuerierungsfall kommt nicht so häufig vor, aber bestimmte Komponenten, die sozusagen innerhalb dieses Prozesses stattfinden, die kommen schon deutlich häufiger vor und die könnten wir dann auch letztendlich weiter
19:21
verwenden. Nur mal so zum Ergebnis, was passiert, wenn man also den Prozess abgeschickt hat, dann bekommt man das Ergebnis zum Beispiel im Kugis wieder rein, in dem Fall werden also alle Gebäude zurückgeliefert, es werden alle POIs, die davon betroffen sind, zurückgeliefert, es gibt auch noch eine Klassifizierung nach kritischen POIs, in dem Fall sieht man es einfach mal, das ist quasi der
19:40
der 300-Meter-Radius, der dort genommen wurde und dann werden einfach die Gebäude zurückgeliefert. Im Prinzip, wären wir früher jetzt hergegangen, hätte all diese Adressen und diesen Umkreis evakuiert. Mit der Berechnung durch den Apollo ist man jetzt auf so ein natürlich anders geformtes Ergebnis gekommen. Wechseln wir einfach nochmal kurz hin und her. Das rote Dreieck
20:00
ist der Bombenfund, das ist also hier, das heißt, wir befinden uns hier in einem deutlich kleineren Bereich, den wir dann eigentlich hätte evakuieren müssen. Man hat also hier, das Ergebnis war letztendlich, dass man um 71 Prozent die Fläche und natürlich entsprechend die Anzahl an Häusern hat
20:21
reduzieren können. Vielleicht einfach nochmal so ein paar Ergebnisse. Hier sind jetzt quasi die sozusagen die Betroffenheit unterschiedlicher Materialien von einem von einer möglichen Explosion. Auf der einen Seite normales Glas, das nächste auf der anderen Seite ist also eine Trommelfellverletzung oder hier bis hin zur
20:42
letalen, also ja, Lebensgefahr. Ja, letztendlich sind wir da drauf gekommen, dass für solche komplexen Anwendungen die WPS-Nutzung durchaus sinnvoll sein kann, vor allem, wenn man komplett externe Prozesse und Modelle in seinen eigenen Workflow mit einbinden kann.
21:01
Wenn ich sowas, jetzt zum Beispiel, deswegen steht hier die Spalte Skripte, wenn ich sowas skripten will, dann wird es natürlich sehr schwer und sehr schwer händelbar. Der WPS bietet da eigentlich einfach wieder so eine Abstraktionsebene, die das Verknüpfen von diesen unterschiedlichen verteilten Modellen oder Prozessen möglich macht, bietet eine sehr schöne Schnittstelle dafür, genau.
21:24
Wir sind, gehen eigentlich davon aus, nach der nach der Arbeit, dass wir für WPS-Prozesse auf jeden Fall Anwendungsfälle finden und haben können und eine Wiederverwendbarkeit durchaus sichtbar ist. Vor allem können wir auch eine Komplexität letztendlich von so einer Prozesskette
21:41
eigentlich ziemlich gut verstecken von einem Anwender, der damit eigentlich nicht so viel mit dem, mit dem tatsächlichen, mit der Komplexität zu tun hat. Das ist eigentlich eine ganz gute Sache. Es kann kompliziert sein, sensible Daten zum Beispiel in so einen Prozess einzuspeisen. Es kann aber auch ein Vorteil sein, weil natürlich der Prozess das letztendlich
22:01
im Hintergrund auch selber machen kann und vielleicht gar nicht die Berechtigung des Benutzers, der den Prozess ausführt, dann in dem Fall das Entscheidende ist. Ja, ich würde mal sagen, ich lasse es mal hier und vielleicht gibt es noch die eine oder andere Frage. Ich hoffe, ich konnte dem Gunnar sein
22:21
Anliegen halbwegs rüberbringen und natürlich auch weiterhin für die Nutzung von WPS ein bisschen werben. Es ist also auf jeden Fall eine spannende Sache, vor allem mit den neuen Sachen, die es jetzt gibt, auch mit der OTC API. Das heißt, die Verwendung von WPS mit mit REST APIs und mit JSON Ergebnissen, da kann man natürlich jetzt vor allem, wenn man es im Browser macht,
22:41
deutlich besser umgehen. Das ist alles noch XML basiert, ist ein bisschen komplizierter. Vielen Dank. Vielen Dank, Michael. Hat jemand eine Frage an Michael Schulz?
23:07
Also, ihr habt ja diesen Anwendungsfall schon sehr gut ausgearbeitet. Soll das auch mal wirklich benutzt werden oder bleibt das eine Fallstudie? Nee, das soll wirklich benutzt werden. Wer sich vielleicht erinnert,
23:21
es gab, glaube ich, vor zwei, drei Monaten einen Fall in Düsseldorf oder Dortmund, wo eine Fliegerbombe gefunden wurde, wo deutlich größer, wo auch ein relativ großer Evakuierungsradius durchgesetzt wurde. Tatsächlich war es so, auch der Kampfmittelbeseitigungsdienst
23:41
Nordrhein-Westfalen arbeitet mit dem Fraunhofer EMI zusammen und hat auch dort diese Apollo Blast Simulator Geschichte eingesetzt. Und es gab dort etliche Fälle, wo sozusagen der Evakuierungsradius so eingegrenzt werden konnte, dass bestimmte Sachen nicht evakuiert werden mussten.
24:01
Zum Beispiel ein Krankenhaus, glaube ich, war da dabei, wo man dann vielleicht Patienten nur innerhalb des Krankenhauses auf eine andere Seite umlegen musste und aber jetzt nicht Intensivpatienten oder solche Sachen irgendwie wirklich rausbringen musste. Also, das ist schon wirklich im Einsatz. Unser Fokus war das Thema WPS.
24:21
Der Einsatz der Software ist schon ganz klar. Also wir sind da auch noch dran, mit dem Amtverbrannung Katastrophenschutz jetzt wirklich auf die auf die Beine zu stellen. Danke. Gibt es noch Fragen?
24:40
Dann vielen Dank nochmal an Michael Schulz für diesen schönen Vortrag.