We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Kennst du deine GDI? - Intelligenz zwischen den GDI-Komponenten

00:00

Formal Metadata

Title
Kennst du deine GDI? - Intelligenz zwischen den GDI-Komponenten
Title of Series
Number of Parts
68
Author
License
CC Attribution 3.0 Germany:
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Als Verantwortliche einer aus mehreren Softwarekomponenten und vielen Daten aufgebauten GDI sind wir regelmäßig mit typischen Fragen konfrontiert, die wir heute nicht ohne Stirnrunzeln beantworten können: - Wo wirkt sich eine Schemaänderung des Parzellendatensatzes in der GDI überall aus? - Wieso läuft das QGIS-Plug-In des ehemaligen Arbeitskollegen nicht mehr? - Habe ich die Kartendefinitionen für QGIS-Desktop, WMS und WebGIS konsistent nachgeführt? - Wie stelle ich in Datenbank und Diensten eine einheitliche Zugriffsverwaltung des Datensatzes „Notfall-Trinkwasserversorgung" sicher? Im Rahmen der Gesamterneuerung der GDI des Kantons Solothurn wurde mit Unterstützung der WhereGroup ein Grobkonzept erarbeitet. Dieses hält fest, dass eine Verbesserung der GDI insbesondere bezüglich der „Intelligenz" zwischen den einzelnen Komponenten erreicht werden kann. Aufgrund dieser Erkenntnis wurde anschließend ein konzeptionelles Datenmodell für die GDI erarbeitet, welches die Zusammenhänge zwischen Daten, Diensten und Applikationen abbildet. Dieses GDI-Datenmodell bildet auch zentrale Konfigurationen wie Gruppenebenen und ganze Karten ab welche mittels entsprechender Funktionalität in Mapserver-Mapfiles und QGIS-Projekte übersetzt werden. In der Präsentation werden die zentralen Oberklassen "Datensatz", "Anwendung" und "Dienst" des Metamodells vorgestellt und aufgezeigt wie das Datenmodell die einleitend aufgeworfenen Fragen beantwortet.
Keywords
1
Thumbnail
13:04
24
39
58
59
Thumbnail
36:34
PrüfprogrammSpatial data infrastructurePhysical quantityRoute of administrationSpatial data infrastructureJSONXMLMeeting/Interview
Spatial data infrastructureMetamodellInternetdienstSmart cardMaxima and minimaRow (database)InformationBusiness reportingClient (computing)Service (economics)Route of administrationPlane (geometry)MetreSpeciesData modelObject (grammar)Derived set (mathematics)PDF <Dateiformat>BioinformatikComponent-based software engineeringVector graphicsTable (information)MetamodellSpatial data infrastructureDepictionFile viewerProduct (category theory)Computer animation
InternetdienstSpatial data infrastructureMetamodellSoftwareEXTRACTSocial classRow (database)Set (mathematics)Functional (mathematics)InformationDepictionClient (computing)Component-based software engineeringRoute of administrationMemory cardLevel (video gaming)Spatial data infrastructurePattern languageFile viewerService (economics)Product (category theory)DiagramChainingSmart cardLADY <Programmiersprache>HöheEckePlane (geometry)Computer animation
Set (mathematics)InformationData modelRow (database)Lecture/Conference
UntermodulSpatial data infrastructureRow (database)Computer animationProgram flowchart
Row (database)Service (economics)ArmProcess (computing)User interfaceMoment (mathematics)Information modelMetadataComponent-based software engineeringAbbildung <Physik>Focus (optics)Route of administrationModule (mathematics)Graphical user interfaceData modelServer (computing)Computing platformMetamodellLecture/Conference
Transcript: German(auto-generated)
Gut, dann kommen wir zum nächsten Beitrag. Wie gesagt, Oliver Jecker arbeitet für den Kanton Solothurn seit ca. ein Jahr. Vorher hat er für den Kanton Aargaard gearbeitet.
Und der Kanton Solothurn ist ja eigentlich ein Pionier in Sachen Foskies in der Schweiz und hat aber das Problem, dass die Infrastruktur über die Jahre hinweg angewachsen ist mit sehr vielen kleinen und grösseren Applikationen und Tools. Und da ist es oft sehr schwierig, den Überblick zu behalten.
Und dieser Problematik hat sich jetzt das Team angenommen. Und ich bin gespannt, was die Lösungsansätze für die Dokumentation der komplexen Infrastruktur sind. Danke, guten Morgen aus der Schweiz. Mein Vortrag heisst, kennst du deine GDI?
Also sprich richtet sich an die Personen primär, die eben eine GDI verwalten. Ja, wir haben sehr viele tolle Open-Source-GDI-Komponenten. Da sind nur ein paar daraus abgebildet.
Ich denke, in jeder typischen GDI sind da mehrere davon im Einsatz. Bei uns auch. Und das ändert ja auch ab und zu. Also das entwickelt sich, wenn die GDI in der Zeit fortschreitet. Dann eine GDI hat viele Applikationen, die von der GDI abhängen
und Informationen daraus beziehen. Seien das konfigurierte Karten in verschiedensten Clients. Dann natürlich Kartendienste. Dann auch Direktzugriffe auf Vektordaten im Postgis, typischerweise.
Oder Rasterdaten in einer Dateiablage. Auch Datendienste, WFS. Und bei uns werden dann auch Restdienste eingesetzt werden. Und dann hat man noch spezifische Schnittstellendienste zu anderen Applikationen.
Zum Beispiel zu einer Geschäftsverwaltung. Ausgangsdaten und Produkte. Wir haben einige Datensätze. Die sind sehr vielfältig, werden die verwendet und wiederverwendet.
Und da hat man ETAL-Prozesse dazwischen geschaltet. Und da X-Ableitungen. Und ja, auch das einfällt, dass man im Überblick behalten muss.
Sumiert bedeutet das für uns mit dem Max und der GDI. Dass uns irgendwann einmal der Kopf ganz gehörig rauchte. Und wir suchten da nach einer Lösung. Also die Informationen waren sehr stark in den Köpfen. Auch verteilt, nicht in jedem Kopf dasselbe.
Und ja, kennt man wahrscheinlich das Problem. Dann geht ein Mitarbeiter mal in eine andere Firma. Das ist immer schade. Und für all diese Fragestellungen suchte mir eine Lösung. Und vor gut einem Jahr haben wir mit der Unterstützung von der Wear Group ein Konzept erstellt.
Und ein Teil daraus war die Überlegung, die wesentlichen Beziehungen festzuhalten. Und auf Basis dieser Überlebung haben wir dann ein Metamodell erstellt.
Also es ist einfach ein konzeptionelles Datenmodell. Was ich euch nun im Rest des Vortrages näherbringen möchte. Was sind die wesentlichen zwei Lösungsansätze im Metamodell drin? Der erste Lösungsansatz ist, wiederkehrende Standardobjekte einmalig strukturiert zu beschreiben.
Und was sind Standardobjekte in der Geoinformatik? Das sind die Datensätze selbst. Vektordaten, tabellarische Daten, Rasterdaten. Dann Dienste und Karten- und Kartenebenen.
Das zweite wichtige Element im Lösungsansatz ist, die Beziehungen festzuhalten. Und zwar einerseits die Beziehungen unter den Standardkomponenten, hier in grün dargestellt.
Und als zweites die Beziehungen zu den Applikationen, die dann die Standardobjekte konsumieren und von ihnen abhängig sind. Gut, das Metamodell ist nicht riesig, es ist auch nicht klein.
Im Rahmen vom Vortrag heute möchte ich euch insbesondere diese drei eingerahmten Bereiche des Metamodells näherbringen. Ich beginne dann mit dem grünen Teil, das sind die Beziehungen zwischen Daten und Karten.
Im roten Teil, da sind die Beziehungen abgebildet zwischen Datendiensten und Applikationen. Und im gelben Teil die Beziehungen von Ausgangsdaten und ihren Ableitungen. Gut, Beziehungen, Daten, Karten.
Bitte entschuldigt da all die roten Rähnchen. Ich bin schon auf Plan B im PDF. Im ODP, das nicht funktioniert, würde ich mit den Rähnchen durch diese Folie führen. Ich mache sie jetzt auf der Tonspur. Gut, die Klassen, die da involviert sind in diesem Teilmodell, das ist links das Dataset.
Das ist einfach ein Datensatz, also sprich eine Tabelle oder eine Rasterebene. Dann das Dataset View. Das ist eine Darstellung eines Datensatzes.
Und ihr seht hier die Beziehung dazwischen. Besagt, ich kann auch fünf Darstellungen haben für das Gleiche. Zum Beispiel einen partiellen Datensatz habe ich dann auf fünf verschiedene Arten dargestellt.
Dann das Product Set. Das ist eine Gruppe von Datensätzen oder von Darstellungen. Das seht ihr auch an der grünen Beziehung, die besagt ein Product Set contains Data Product oben.
Und das Data Product kann dann wiederum eben sein ein Dataset oder eine Dataset View. Wer es kennt, das ist das Composite Pattern. Sprich, damit kann ich eine beliebig verschachtelte Karte dann letztendlich mir zusammen konfigurieren.
Die Map rechts unten, die besitzt einfach noch eine zweite Beziehung. BG Layer, um die Hintergrundebenen konfigurieren zu können. Jetzt wozu nutzen wir das?
Das werden wir einsetzen, eben wichtig immer Übersicht behalten. Und aus dieser Struktur werden wir automatisch QGIS, Projektfile, Teile konfigurieren und WMS, WFS, Webgießkarten.
Dann Beziehungen, Datendienste, Applikationen. Im Diagramm links die Daten in der Klasse Data Product. Und dann auf der rechten Seite drei Klassen, die eigentlich etwas Applikatorisches, etwas Funktionales darstellen.
Und ganz wichtig ist die Beziehung zwischen Data Product und Software Component. Ein typisches Beispiel hier ist, ich habe einen Dienst, das ist eine Software Komponente.
Und diese ist abhängig von Datensätzen. Also wenn das zum Beispiel ein WFS ist oder ein WMS, die arbeiten ja immer sehr eng mit den Daten zusammen. Damit habe ich die Übersicht, was wovon abhängt.
Die Beziehung funktioniert auch auf die andere Seite. Das Ergebnis eines WFS, wenn ich zum Beispiel ein WFS vom Bund oder von einer anderen GDI anzapfe,
dann erhalte ich ja als Resultat des WFS eigentlich ein Data Product, der gibt mir ja auch in dem Sinn einen Datensatz zurück. Sprich, das ist dann die Abhängigkeit auf die andere Seite von einem Data Product auf einen Service.
Das brauchen wir primär mal, um den Überblick zu behalten. Eben wenn wir eine Schemeinderung bekommen, um zu sehen, wo müssen wir da überall Hand anlegen. Und wir werden die Beziehungen auch nutzen, um das Verhalten des WebGIS Clients zu steuern.
Sprich, wenn ich einen spezifischen Dienst habe zum Informationen generieren, dann weiss das das Meka-Modell und ich kann im WebGIS das GUI entsprechend rendern.
Gut, Ausgangsdaten und Produkte. Das kennen wahrscheinlich einige von euch. Das ist eigentlich ETL, Extract Transform Load. Und das Transform darin, das ist die Klasse Transformation.
Und die hat zwei Beziehungen zu Datensätzen. Und wenn ich jetzt vom Resultat-Datensatz aus schaue, dann ist das eben ein Resultat einer Transformation. Sprich, das ist die linke obere Beziehung.
Und diese Transformation wiederum verwendet meinetwegen fünf andere Datensätze. Und damit habe ich diese Abhängigkeiten konfiguriert. Und wie das Diagramm links oben zeigt, habe ich ja häufig auch Verkettungen.
Das ein Zwischenresultat ist dann wieder ein Ausgangsdatensatz für eine weitere Verarbeitung. Und mit diesem Wissen kann ich dann diese Verkettungen automatisch anwerfen, wenn ganz links aussen eine Datenaktualisierung reinkommt.
Gut, ich bin auf diese drei Teile des Metamodells eingegangen. Ihr seht da links und rechts oben. Es gibt noch zwei weitere Teile im Metamodell.
Das linke obere kümmert sich um Benutzer und rechte Verwaltung. Und das rechte obere um schlichte Kontaktinformationen. Also ich habe eine Komponente, die läuft seit fünf Jahren wunderbar. Und jetzt kommt eine Änderung rein, damit wir einfach an einer Stelle registriert haben,
wer sind da die Ansprechpersonen. Ich wäre schon am Ende des Vortrages.
Ich möchte mich bedanken und ich denke, das ist ein hochspannendes Thema. Mir ist auch keine andere Organisation bekannt, zumindest in der Schweiz, die sich diesen Problem mal wirklich angenommen hat. Weil das Problem haben wahrscheinlich wir alle, die eine größere GDI betreiben.
Und darum bin ich mir auch sicher, dass es jede Menge Fragen gibt oder Vorschläge.
Ich habe eine Frage. Sind die Informationen jetzt auch schon abgefüllt, alle in diesem Modell? Oder wird das noch eine Zeit in Ausspruch nehmen? Danke für die Frage. Also für mich ist der Zeitpunkt, und das präsentieren auch sehr günstig, das ist noch ein konzeptionelles Datenmodell.
Sprich, wir sind am Ende der Konzeptphase. Also das gibt es noch nicht implementiert. Und wir sind da auch dankbar, wenn irgendwelche Vorschläge kommen. Ja, macht es doch so oder habt ihr es gedacht an und so weiter.
Wenn ich die Grafik richtig in Erinnerung habe, die Übersicht, dann fehlt mir die Beziehung zwischen den Usern und also Berechtigungen auf den Datensätzen tatsächlich. Ja, genau das habe ich ausgeblendet, da muss ich da nach hinten. Das ist eben das linke obere Teilmodell.
Und da, genau, permitted, das ist dann der Benutzer, die Klasse permitted. Und die hat über resource permission dann die Beziehung zu einer GDI-Resource. Und fast alles im unteren Teilmodell ist eine GDI-Resource.
Gibt es da Ambition oder Pläne, das irgendwie zu dokumentieren und anderen bereitzustellen oder? Ja, also die Dokumentation ist auch für uns wichtig. Und das wird oben so sein, die Implementation davon.
Ich hätte auch noch eine kurze Zwischenfrage, bevor wir da hinten weiter machen. Gibt es dann ein Werkzeug geplant, das zu verwalten, ein GUI, irgendetwas? Wie wollt ihr das umsetzen, GUI-mäßig?
Was haben wir da gesagt, weiß ich nicht mehr auswendig. Aber es wird ein GUI geben, das auf verschiedenen Plattformen laufen wird. Webbasiert oder? Wahrscheinlich, ja. Bei dem Informationsmodell gibt es da eine Abbildung auf die Hardware-Ebene.
Also auf welchen Server das läuft oder die Software-Komponenten, wenn man jetzt im Bereich von Diensten guckt zum Beispiel. Danke, das haben wir diskutiert und im Moment noch nicht gemacht. Also das ist noch nicht Teil vom Modell. Ich denke, das primär deckt die Software-Seite an
und noch nicht, wo jetzt ein Modul, auf welchem Server das läuft. Wir haben noch viel Zeit.
Also wir können wirklich auch eine Diskussion führen gerne. Weil das ja auch noch im frühen Stadium ist, wäre das ein günstiger Zeitpunkt. Ja, also ich hätte die Frage,
wie wird denn angestrebt, das ganze System dann quasi auch über die Standardmetadaten letztendlich zu beschreiben? Oder soll es einfach nochmal ein parallelles Metamodell zu den Metadaten, die ja sowieso alle Dienste und Datensätze und Anwendungen eigentlich haben sollten, die ja auch bestimmte Verknüpfungen schon ermöglichen.
Soll das parallel sein oder soll das da in die Metadaten integriert werden? Ja, also der Stand bei uns bezüglich der Metadaten ist, der Fokus ist auf den Datensätzen. Und ich glaube, das ist erkennbar. Der Fokus dieser Metadaten ist eben insbesondere die Prozesse,
die Abhängigkeiten zwischen Datendiensten, Applikationen. Und das wird einen Moment parallel laufen jetzt bei uns. Aber dann ist schon der Ansatz, dass es dann integriert wird. Was machen wir schrittweise?
Ich hätte auch noch eine Frage. Und zwar, wer ist genau der Anwender an solch einem System? Ist es rein intern oder ist es auch eben geeignet, Teile daraus zu publizieren, sagen wir jetzt über die Gießfachstelle hinaus für andere Ämter?
Oder habt ihr das schon durchgedacht? Ja, also bei uns ist der Ansatz noch eher intern, dass das die Gießfachstelle betreut. Aber natürlich kann man die Benutzeroberfläche, um das Datenmodell zu pflegen,
kann man auch freischalten für weitere Benutzer.