WMS Time Dimension
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 |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 95 | |
Author | ||
License | CC Attribution 3.0 Unported: 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/36163 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
| |
Keywords |
1
6
10
11
12
14
15
16
23
28
37
39
41
50
53
54
58
60
62
68
70
71
72
74
76
77
78
79
82
83
86
90
95
00:00
Service (economics)Lecture/Conference
00:49
Spatial data infrastructureInformationRow (database)Spatial data infrastructureComponent-based software engineeringMetadataZahlComputer animationLecture/Conference
02:08
Spatial data infrastructureData conversionSet (mathematics)Data conversionVariable (mathematics)Client (computing)Service (economics)Spatial data infrastructureComputer animation
02:51
Spatial data infrastructureInternetdienstService (economics)XMLClient (computing)String (computer science)Service (economics)Spatial data infrastructureVariable (mathematics)Product (category theory)ZahlDistanceClient (computing)WebsiteWeb serviceInformationUser-generated contentWEBComputer animation
05:03
Service (economics)XMLClient (computing)String (computer science)InformationComputer animation
05:31
World Wide WebAttribute grammarElement (mathematics)InformationZeitintervallStandard deviation
06:54
MultiplicationVersion <Informatik>Computer animation
07:26
Mail ServerStructural loadWireless LANService (economics)Point (geometry)Component-based software engineeringComputer animation
08:03
World Wide WebHospital information systemEASY <Programm>Mail ServerDownloadBlogServer (computing)Server (computing)Vector graphicsComponent-based software engineeringComputer animation
08:32
HTTPComputer-generated imageryGeoServerTypVECTOR <Programm>GeometryWorld Wide WebERNA <Programm>Open sourceClient (computing)Component-based software engineeringComputer animationXMLUML
08:54
NeWSVariable (mathematics)Function (mathematics)UpdateConfiguration spaceClient (computing)MatroidHome pageComputer animation
09:50
Menu (computing)World Wide WebCodeHTTPPredictionClient (computing)Component-based software engineeringMatroidParameter (computer programming)Computer animation
10:27
Structural equation modelingService (economics)Computer animation
11:01
World Wide WebData conversionInternetdienstClient (computing)Mach's principleWindows RegistrySpatial data infrastructureData bufferManual of StyleClient (computing)Degrees of freedom (physics and chemistry)WebcastMetadataManual of StyleData modelService (economics)Data bufferDynamic rangeData conversionZahlSpatial data infrastructureEigenvalues and eigenvectorsSource codeExterior algebraComponent-based software engineeringRoute of administrationRealisierung <Mathematik>Computer animation
13:02
Server (computing)Data conversionWorld Wide WebUser interfaceWeb pageGroup actionAttributwertTable (information)Client (computing)Service (economics)DatabaseSource code
13:56
Data conversionServer (computing)Parameter (computer programming)Client (computing)ZahlMach's principleSoftwareRow (database)Client (computing)Data conversionData bufferServer (computing)Liste <Informatik>Social classInterpolationComputer animation
15:45
Client (computing)Data conversionBASICFreewareOpen sourceSound effectComputer animation
16:34
Scale (map)Client (computing)Data conversionServer (computing)HTTP cookieParameter (computer programming)ZahlVariable (mathematics)Client (computing)Parameter (computer programming)Slide ruleMilitary baseSatelliteInterface (computing)Computer animation
18:04
UploadingDVDScale (map)WEBPhysical quantityComputer animationEngineering drawing
18:38
World Wide WebXMLUploadingMusical ensembleCoordinate systemMetadataLoop (music)Data conversionComputer animation
19:05
Data conversionAbbildung <Physik>MetadataData conversionMetadataInterface (computing)Client (computing)Systems <München>Computer animation
19:51
Server (computing)Standard deviationComponent-based software engineeringGeneric programmingHigh availabilityClient (computing)SoftwareFRAMEWORK <Programm>GeometryAnbindung <Informatik>Proof theoryDesktopJavaScriptPlug-in (computing)Open sourceLecture/Conference
22:57
Loop (music)Coordinate systemMetadataGeometryClient (computing)Instanz <Informatik>Open sourceJavaScriptSoftwareComputer animation
23:35
Service (economics)JavaScriptStandard deviationProduct (category theory)FrequencyModule (mathematics)PAPData conversionLecture/Conference
25:53
ZahlScale (map)EmoticonSmart cardComputer animation
26:18
Lecture/Conference
Transcript: German(auto-generated)
00:07
Ja, ich freue mich darauf, dass Armin Retterath uns jetzt etwas über WMS-Dienste erzählt, aber nicht einfach WMS-Dienste, sondern WMS-Time-Dienste, also wir kriegen jetzt auch nicht nur eine räumliche, sondern auch mal eine zeitliche Dimension rein und können die angeblich
00:23
auch nutzen. Wir schauen mal wieder gut, dass es funktioniert. Sorry, haben wir vergessen.
00:42
Hallo. Erstmal schönen guten Morgen zusammen oder Nachmittag. Thema heute oder beziehungsweise meines Vortrags ist die Bereitstellung zeitlich variabler Daten über die WMS-Interfaces, da gibt es Möglichkeiten zu und wir haben uns in den letzten Jahren, also ich kümmere mich in Rheinland-Pfalz, im Saarland und in Hessen
01:00
um die Geodateninfrastrukturen und die zentralen Geoportale und in den letzten Jahren ist es halt immer mehr als die Zahl der Datensätze angestiegen und viele Datensätze, die publiziert werden, mit Metadaten beschrieben werden und publiziert sich eigentlich nur in der zeitlichen Dimension. Das führt bei der Recherche der Daten immer wieder zu Problemen und beim Auffinden
01:23
von Informationen und da haben wir uns dann überlegt, gibt es denn Möglichkeiten, die das OGC bietet, jetzt zeitlich variable Daten auch über WMS-Interfaces zu publizieren und das war halt auch das Thema des Vortrags. Kurzer Überblick, erstmal, wie wird ein WMS in der Geodateninfrastruktur
01:43
genutzt oder wie sollte er genutzt werden, da gehe ich kurz darauf ein. Probleme, die auftauchen, die ich jetzt gerade erst einmal erläutert hatte. Dann gehe ich auf die Möglichkeiten, die die WMS-Spezifikation oder die Spezifikationen eigentlich nativ schon mitbringen, um zeitlich variable Daten oder auch multidimensionale Daten zu publizieren.
02:04
Ich zeige nochmal kurz die existierenden Foskes-Komponenten, die da Verbreitung finden und die auch eingesetzt werden. Und dann stelle ich die Idee dieser generischen Integration von zeitlich variablen WMS-Diensten in Geodateninfrastrukturen am praktischen
02:21
Beispiel vor und gehe dann eben auf die Umsetzung ein und versuche dann an dem praktischen Beispiel nochmal zu erläutern, wie der client funktioniert. Zusammenfassend dann in einem Artikel oder Absatz Lessons learned. Also Nutzung von WMS-Diensten in Geodateninfrastruktur, normalerweise besucht der Nutzer nach Daten, dass ich weiß nicht, ob das jetzt zu sehen ist
02:42
weiterhin. Da oben ist ein Suchbegriff eingegeben worden, Liegenschaftskarte. Das ist jetzt ein Beispiel aus unserem Geoportal. Es gibt dann im Endeffekt in der Rubrik Interaktive Daten 84 Treffer zu diesem Begriff Liegenschaftskarte. Dann wählt der in den Geodateninfrastrukturen unserer
03:00
drei Länder, die ich da betreue, im Endeffekt eine Kartenebene aus, die diesem Suchbegriff entspricht und lädt die dann dynamisch in den Client hinzu, in dieses WebGIS-System, was wir eben auf Basis von MAPender 2 noch betreiben. Ich weiß nicht, ob das jetzt auch weiter hinten zu sehen ist. Dieses dynamische Hinzuladen des einen Layers der Liegenschaftskarte wird
03:22
dann hier visualisiert und da steht dann im Endeffekt ein Name dran, ein Layer-Title, der heißt Leaker Hard 2014 RP. Also ist das eine historische Liegenschaftskarte aus Rheinland-Pfalz aus dem Jahre 2014. So kann ein Nutzer in der aktuellen Phase auf historische Daten zugreifen.
03:41
Das führt natürlich dann zu Problemen, wenn ich zeitlich variable Produkte habe. Jetzt habe ich ein schlechtes Beispiel gemacht. Wir stellen derzeit also die Liegenschaftskarte in alle zwei Jahre, in zweijährigen Abständen, zur Verfügung die historischen Versionen und ein Nutzer müsste jetzt im Endeffekt diese ganzen historischen Layer erst mal finden über die Geodateninfrastruktur, dynamisch in
04:03
den Klienten hinzuladen und dann dementsprechend die Layer selektieren oder deselektieren, wenn er sich eine Übersicht darüber schaffen will, wie sich das Liegenschaftskartaster beispielsweise verändert hat in den letzten Jahren. Das ist natürlich nicht sehr pragmatisch der Ansatz. Die Probleme, die auftauchen, hatte ich eben schon mal kurz erwähnt.
04:20
Wir haben also einen inflationären Anstieg von Informationsressourcen. Viele Layer und Dienste erschweren im Endeffekt die Nutzung in dem Geodatensystem. Also auch die UI wird überladen durch die Zahl der variablen Daten und wir haben auch einen erhöhten Aufwand bei der Einrichtung und Betrieb der Interfaces, der Service Interfaces für die Geodateninfrastruktur. So wie können wir dem begegnen?
04:42
Jetzt gehe ich auf die Möglichkeiten der WMS Spezifikation ein. Seit 2001, und das ist jetzt wirklich lange her, bringt die WMS Spezifikation auch schon die Möglichkeit mit, zeitlich variable Daten zu publizieren. Das wird dann mit dem Überschrift Time Dimension bezeichnet und auch da wird schon darauf hingewiesen,
05:01
dass ein UGC Web Service oder Web Map Service diese Informationen zu den zeitlich variablen Datenquellen bzw. Layern in seinen Capabilities Dokumenten dokumentieren soll und dass es dann die Möglichkeit gibt, einzelne Werte, eine Liste von Werten oder auch Intervalle dort anzugeben, falls dieser Layer zeitlich variabel ist.
05:23
In der WMS 1.1.0 und in der WMS 1.1.1 Spezifikation, das ist mal so ein kleiner XML-Snippet zu sehen, gibt es im Layer-Bereich einmal ein Dimension-Element und einmal ein Extend-Element. Dieses Dimension-Element ist eine generische Dimensionsangabe für den jeweiligen Layer, der beinhaltet den Namen Time
05:44
für zeitlich variable Layer und eine Einheitsangabe, in diesem Anfrage der Layer zu definieren und zu formulieren sind. Der zweite Teil heißt Extend und da wird im Endeffekt das Metadatum mitgegeben, in welchem Intervall jetzt hier diese Datenquelle
06:02
Daten zur Verfügung steht oder für welches Zeitintervall, hier von 1999 bis 2000 und mit der Periode von einem Tag, pay one day, das lässt sich alles der ISO-Norm entnehmen, wie das anzugeben ist. Bei der WMS 1.3.0 Spezifikation, der aktuellen ISO 928, haben wir die Elemente zusammengefasst, das heißt,
06:23
da haben wir einen kleinen Unterschied, das hat der Till auch schon mal angesprochen, die verschiedenen OJC-Standards unterscheiden sich leicht in ihrer Bedienung. Und wenn ich jetzt ein generisches System aufsetzen will, muss ich das natürlich wissen im Vorfeld, das heißt, ich habe im Endeffekt bei der neuen WMS Spezifikation nur noch ein Dimension-Element mit mehreren Attributen,
06:43
die ähnliche Informationen oder die gleichen Informationen beinhalten wie auch bei der alten WMS Spezifikation. So, die Option vom Webmapservice, jetzt mal einfach die ISO 928, die 3.0-Version, hat also verschiedene Pflichtwerte und optionale Werte, die verpflichtenden Werte
07:02
waren Name und Einheit, bei der Zeitangabe ist das dann immer Time und ISO 8601 und dann gibt es eben noch den Extend als verpflichtendes Element, mandatory hier im unteren Teil und der Extend definiert dann eben die zeitliche Ausdehnung des Layers. So, der Extend-Syntax bei der WMS Spezifikation kann
07:25
und jetzt gehen wir auf die Beispiele ein, das hatte ich eben auch schon mal kurz erwähnt, ein Einzelwert beinhalten oder halt eine Komma-separierte Liste mit einzelnen Zeitpunkten, in der die Daten, der Layer-Daten publiziert oder eben auch eine, wie heißt das hier, ein Intervall mit einem
07:41
Anfangswert, Maximalwert und mit einer Auflösung. Das Beispiel hatte ich eben schon gezeigt gehabt. So, welche Server-Komponenten bieten sich jetzt im Bereich Foskis an, die sowas auch serverseitig schon nativ unterstützen? Der Mapserver hat für die WMS-Time-Unterstützung native Möglichkeiten, hat auch die Unterstützung
08:02
der verschiedenen Time-Patterns, die da angegeben sind und in der Doku wird relativ einfach, also gut beschrieben, wie ich ein Web-Mapservice so aufsetze, dass er sowohl zeitlich variable Vektordaten, als auch zeitlich variable Rastadaten publizieren kann über ein einheitliches Capabilities-Dokument. Die zweite Server-Komponente, die weit
08:21
verbreitet ist, ist der Geo-Server. Auch der Geo-Server hat eine Unterstützung für zeitlich variable Daten, die er publizieren kann und da gibt es sogar eine User-Interface für eine Oberfläche, die im Endeffekt dann ermöglicht, hier über diesen Dimension-Writer hier die verschiedenen Zeitangaben da vorzudefinieren.
08:43
Da werden wir bei den Server-Komponenten im Open-Source-Client-Bereich, jetzt gehe ich auf die JavaScript-Bibliotheken ein, die am weitesten verbreitet sind, haben wir Open-Layers, da muss man noch mal F5 drücken, damit da was zu sehen ist. Genau, in der Open-Layers-Dokumentation
09:03
ist auch ein Beispiel vorhanden, wie man einen zeitlich variablen WMS-Layer integrieren kann, die Integration selber, also hier ist jetzt ein Beispiel, in dem man quasi auch ein Video abspielen kann, wo einfach die einzelnen vorhandenen Zeitwerte nacheinander durchlaufen
09:21
werden und man dann so eine kleine Szene darstellen kann. Die Konfiguration in Open-Layers erfolgt etwas schwieriger, da muss man anfangen zu coden, es gibt da ein Update-Info-Set-Time-Funktion, den man programmieren muss, um dann quasi solche Clients zu erstellen und die man dann auf der Homepage
09:42
visualisieren kann. Im weiteren Umfeld gibt es Leaflet, auch Leaflet ist eine JavaScript-Bibliothek, die diese Zeitvariable mit unterstützt bei WMS, auch sie ist in der Lage, nativ auch schon direkt Videos abspielen zu lassen, und hier sind jetzt Wellenbewegungen oder Vorhersagen im Mittelmeerraum,
10:01
die man damit schön visualisieren kann als Beispiel vorgeführt. Auch bei Leaflet ist es so, dass wir diesen Time-Parameter, die Integration, ich muss den Layer angeben, muss aber dann immer noch ein bisschen coden, um halt diese Variabilität der Zeit dann eben dem Client klarzumachen. Also ohne
10:21
programmieren geht es nicht, ist natürlich nicht besonders nutzerfreundlich. Es geben auch weitere Client-Komponente, die da schon Unterstützung hat, das war der Mapender 3, ist im Rahmen von einem Regionalverband Ruhr, die hatten, glaube ich, damals ein paar Auftrag von drei Jahren oder so, halt die wollten zeitlich variable Luftbilder, die sie in ihrem Datenbestand haben, an den Endnutzer
10:40
bringen und denen war es natürlich auch zu aufwendig, halt mehrere Dienste für jeden Jahrgang da aufzusetzen oder verschiedene Layer aufzusetzen. Und da gibt es also auch eine, inwieweit die jetzt rudimentär ist, weiß ich nicht, aber der Mapender 3 verfügt über eine Bibliothek, mit der man zeitlich variable WMS visualisieren kann. Die werden jetzt hier derzeit
11:00
eben über eine Auswahlbox oben angezeigt. So viel jetzt zu Clients. Wie sieht es aus? Status quo. Es gibt eine sehr gute Unterstützung in den FOSS-Komponenten. Es gibt viele Anwendungsfälle und Realisierungen, insbesondere aus dem Bereich der Meteorologie und der Ozeanografie, also die auch wirklich großen
11:20
Datenvolumen zu tun haben. Und die Umsetzung erfolgt in der Regel durch Anfassen des Quellcodes, was für die Integration in allgemeine Geodateninfrastrukturen eigentlich eher suboptimal ist. So, jetzt kommt die Idee, die wir damals oder vor drei Jahren eigentlich hatten, im Bereich der Geodateninfrastrukturen der drei Bundesländer. Das war also
11:42
erstmal versuchen, die Zahl der Freiheitsgrade zu reduzieren, die die WMS-Spezifikation eigentlich bezüglich der zeitlich variable Bereitstellung von Daten mitbringt. Und da gibt es, es ist interessant, dieses Dokument sich mal anzuschauen, ein OGC Best Practice Paper von 2014, wo die meteorologischen Dienste,
12:00
das ist eine globale Arbeitsgruppe, sich zusammengesetzt hatten, genau dieses Problem mal intensiver beleuchtet haben. Und da werden die Freiheitsgrade auch schon eingeschränkt. Da geht es um zeitlich und höhenmäßig variable Daten. Die zweite Idee war eben, den Client automatisch anhand der Infos aus den Capabilities-Dokumenten erzeugen zu lassen, sodass eine dynamische Integration von eines
12:21
beliebigen Dienstes in den Webcast Client, den wir da verwenden, halt automatisch ohne Coding dem Nutzer ermöglicht, verschiedene Zeitpunkte auszuwählen. Und es sollten möglichst einfaches UI in der Geoportal-Anwendung geschaffen werden. Rahmenbedingungen war, wir haben ein Geoportal, das ist eben auf MapBender 2 Basis. Das bedeutet, die Dienste werden
12:41
registriert von den Nutzern zur Publikation der Metadaten. Wir nutzen einen Webmap-Context und das hat Till eben auch mal kurz angesprochen gehabt als Zwischenspeicher für die Initialisierung der Kartenzusammenstellungen. Und bei uns ist halt ein dynamisches Hinzuladen beliebiger Layer möglich. So, wir haben wieder serverseitig umgesetzt. Wir haben erst mal
13:01
das Datenmodell des MapBenders erweitert. Das wird erst mal in der Datenbank in der Relational-Modell abgelegt und es gibt jetzt eine neue Tabelle, Layer Dimension, die die Attributwerte aus den WMS-Spezifikationen beinhaltet und dementsprechend kann man relativ schnell die Sachen aus dieser Struktur herausziehen und für den Aufbau des Clients verwenden. Dann haben wir, was ja auch schon
13:23
erwähnt worden ist, wir speichern unser Mapset oder den aktuellen Zustand des Clients bei jeder Aktion in einem Webmap-Context-Dokument, einem XML-Dokument ab und dieses XML-Dokument, WMC-Dokument beinhaltet. Da muss man auch mal den Standard genau durchlesen, sogar schon die Möglichkeit, die aktuell
13:41
eingestellte Zeit mit abzuspeichern. Eigentlich war auch das WMC-Dokument seiner Zeit weit voraus. Damals war es wahrscheinlich gar keine Dienste, die das unterstützt haben, aber die Unterstützung ist drin und hat für uns dann einiges erleichtert. Genau, es gibt ein paar Unterschiede im Bereich WMS- und WMC-Handling bezüglich der Attributnamen.
14:01
Das ist jetzt für jemanden relevant, der das selbst umsetzen will für seine Software, ist aber eigentlich an der Stelle vielleicht nicht so wichtig. Serverseitige Umsetzung, wie wird der aktuell eingestellte Wert in dem WMC abgelegt? Der wird unter dem Attribut UserValue, das ist
14:20
also der, den der Nutzer ausgewählt hat, in den Zwischenspeicher geschrieben und kann aus dem Zwischenspeicher wieder aufgeladen werden. Grundlegende Überlegungen, jetzt gehen wir in die UI- Bewegung rein. Man braucht natürlich, wenn man so ein Open-Source-Projekt, um so eine Funktion erweitern will, eine Open-Source-Bibliothek, am besten eine JavaScript-Bibliothek,
14:40
die also eine User-Interface an der Zeitleiste oder so was zur Verfügung stellt. Das war der erste Schritt. Der zweite Schritt war dann, dass wir gesagt haben, die ausgewählte Zeit, die im User- Interface an der Zeitleiste anklickbar ist, die soll dann auch im Layer-Baum erscheinen, damit der Nutzer auch sieht, welchen Zeitpunkt er ausgewählt
15:00
hat und dann verschiedene Layer miteinander vergleichen kann. Und wir haben es erst mal darauf beschränkt, Einzelfälle, kommer separierte Listen und eben diese Intervalle zu supporten vom Client. Und was dann ein bisschen schwieriger ist, ist halt, dass man, es gibt ein Problem, wenn wir jetzt sehr, sehr viele
15:20
Daten, hunderte von Millionen von Datensätzen hat, manche Server erwarten, dass man genau das, den Zeitpunkt trifft mit der Anfrage, der Get-Map-Anfrage, der auch vorhanden ist, wo Daten für existieren. Das heißt, man muss da schon ein bisschen mehr Rechenleistung reinstecken, um dieses Interpolationsproblem zu lösen. Das haben wir dann serverseitig gemacht.
15:41
Kleinseitige Umsetzung, wir haben uns über, wir haben dann genommen die, ich weiß nicht, ob das jemand hier kennt. Das ist die WistJS-Bibliothek. Die ist eigentlich, also nach ein paar Tagen Recherche war das die einzige Möglichkeit, die sich da angeboten hat als Open-Source JavaScript-Bibliothek einen sehr, sehr einfach zu
16:01
konfigurierenden Zeitstrahl zur Verfügung zu stellen. Und die haben wir dann eben aus dem Netz geladen und dann integriert. Und noch fünf Minuten, oder? Okay, genau. Die Zeitanzeige im Layerbaum, das ist jetzt ein Screenshot an der Stelle. Wir haben hier den Klienten, der aufgeht und im Endeffekt, wenn ich jetzt dieses Zeit,
16:21
diesen Zeitpunkt auswähle in der Zeitleiste, wird auch automatisch am Layerbaum dieser Zeitpunkt auch noch mal dargestellt, damit der Nutzer ein Feedback bekommt, wie das aussieht. Gehen wir auf die Times-Slider-Varianten, sind zwei verschiedene Varianten anhand der Zahl der diskreten Stützpunkte. Klar, dass eine Maximalzahl nicht überschreitet,
16:40
überschritten werden soll. Die haben wir derzeit bei oft 200 gesetzt, aber die kann man konfigurieren. Und falls die Zahl überschritten wird, wird halt ein Slider aktiviert, den man dann eben schieben kann. Und beim Schieben ist es dann wichtig, wenn man ihn loslässt, muss er halt auf den Sollwert springen, weil man kann ihn ja an jeder Stelle loslassen. Man weiß natürlich aber jetzt kleinzeitig erst mal nicht, an welcher Stelle überhaupt
17:00
Daten existieren. Das ist also dann serverseitig zu lösen. Die serverseitige Ermittlung von diesem Nierest-Value-Wert wird einfach über eine JSON-Schnittstelle realisiert, wo ich dann einen Parameter Snap-to-Crit, den User-Value, der abgesetzt wird, abschicke, den Extend mit abschicke und dann serverseitig zurückgeliefert bekomme,
17:20
wo der nächste Wert ist, für den der Layer Daten liefert. Ist jetzt auch eine technische Sache. Praktische Beispiele. Da wir nur noch fünf Minuten haben, nehme ich jetzt einfach mal ein paar Beispiele raus. Deutscher Wetterdienst, der stellt schon seit Jahren, das weiß auch kaum einer, zeitlich variable Daten zur Verfügung. Nur weil wir keine Clients haben, die diese zeitlich variablen Daten konsumieren können,
17:41
sieht man halt immer nur das aktuelle mit der Wolken-Bedeckungs-Bild beispielsweise. Gehen wir mal rein. Der DVD-Server mit der Satelliten-Bedeckung, das ist jetzt hier 20. März dritter, 12 Uhr. Und wenn ich jetzt meinen Slider aktiviere und wähle jetzt einen anderen Zeitpunkt aus, dann variiert auch das Satellitenwerk,
18:00
das Wolken-Bedeckungs-Bild an der Stelle. Lässt sich also sehr schön zeigen. Anderes Beispiel wäre historische Liegenschaftskarte. Das hatte ich eben auch mal erwähnt. Das ist jetzt ein praktisches Beispiel, was noch nicht publiziert ist, aber was wir schon zur Verfügung stehen haben, dass das Problem an der aus den ersten Screenshots eigentlich beheben soll. Hier lässt sich dann auswählen
18:20
eine Liegenschaftskarte aus einem Intervall 2006. Das ist der aktuell ausgewählte Bereich 2012. Und jetzt sehe ich auch schon, da haben sich die Fluschungsgrenzen verändert 2016. Und auch die Art der Karte und die Häuser sind auch eingemessen worden. Also damit lassen sich also beliebige Datenquellen relativ einfach auswählen. Ich gehe jetzt auf ein anderes
18:41
Beispiel auf. Wo haben wir denn jetzt hier? Genau das Beispiel vom Kommunalverband Ruhr. Hier sind es Luftbilder, die sich zeitlich variabel unterscheiden. Und da kann ich eben auch auswählen, aus verschiedenen Jahrgängen und kann die dann dementsprechend überblenden.
19:01
Genau jetzt sind wir noch zwei Minuten. Packen wir mal zusammen, was wir gelernt haben. Also generische Umsetzung ist möglich. Man braucht so anderthalb Wochen Zeit, je nachdem, wie gut man programmieren kann. Mit den Kleins entwickeln sich auch nach und nach neue Anwendungsfälle dafür. Es muss erst mal gezeigt werden, da das möglich ist. Sonst würde das keiner umsetzen, auch serverseitig nicht umsetzen.
19:21
Es gibt aber auch noch viel zu tun. Also was schön wäre, wenn auch die GISS-Systeme, die Desktop-GISS-Systeme, die einen Support für diese WMS-Time-Schnittstelle hätten. Und da fehlt, glaube ich, noch ein QGIS Plugin, was das Nativ abbildet. Und man muss sich Gedanken darüber machen, wie man diese Sachen auch in die Metadaten hineinbekommt, dass man die Metadaten
19:42
sauber publiziert, dass es sich da um zeitlich variable Layer handelt, die man dann konsumieren kann. Genau. Dann wäre ich jetzt so weit durch und stehe zur Verfügung für Fragen. Ja, vielen Dank.
20:02
Dann gleich gibt es Fragen. Also es ist im Prinzip, wenn ich es richtig verstehe, noch eine Verständnisfrage.
20:21
Ist es quasi in den Standards vorgesehen? Es geht prinzipiell auch von den Server-Komponenten her. Aber in den Clients ist es nicht direkt mit implementiert. Man muss da selber Hand anlegen. Aber ist das bei allen verfügbaren Client-Software-Komponenten so, dass die keine zeitliche Unterstützung bieten? Ich habe eben die Beispiele
20:40
für Open-Layers und Leaflet als JavaScript-Bibliotheken extrem weit verbreitet sind gezeigt. Und da muss man halt coden. Sonst geht es nicht. Nativ unterstützt das keiner. Das ist halt ein Problem. Und da fehlt einfach so eine native Unterstützung, die wir jetzt, sagen wir mal, in den alten Mappender, das ist ja schon älter, das Framework rein programmiert haben, implementiert haben. Das ist dann ein Proof of Concept.
21:01
Das funktioniert. Man muss halt dementsprechend ein bisschen Zeit investieren und Arbeit investieren. Man hat aber dafür dann nachher natürlich die schöne Möglichkeit auf beliebige Server-Komponenten, die ebenfalls zeitlich variable Daten publizieren, zugreifen zu können. Und ob das jetzt Jahreszahlen sind oder Zeitpunkte oder was auch immer, ist im Endeffekt egal. Und es ist ein bisschen schade,
21:20
dass der ganze Meteorologie-Bereich und Ozeanographie-Bereich sich da schon seit Jahren mit beschäftigt und auch ihre Daten auch dementsprechend publiziert. Auch die ganzen Sachen von OMET und so, die kriegt man auch mit zeitlich variablen Layern, werden die publiziert. Nur nutzt sie keiner, weil keiner weiß. Weil wenn ich die Capabilities jetzt im normalen Desktop giss reinlade, sehe ich diesen Layer und der ist halt, stellt halt nur den aktuellsten
21:41
Zeitpunkt wieder zur Verfügung. Das ist dann ziemlich blöd. Von daher war das eigentlich mehr so ein Hinweis drauf oder ein Anreiz, das einfach mal umzusetzen in den auch in den Open Source Tools vielleicht eben als Kugis Plugin oder so, dass wir das da eben unterstützen können. Und interessant ist auch, dass die Sachen alles schon in dem alten, uralten WMC Dokument schon vorhanden waren, dass man sich damals
22:01
1999 schon Gedanken darüber gemacht hat, dass das eine coole Sache ist, dass in dem Zustand des Karten-Viewers die Zeit mit eingeblendet werden kann die aktuell ausgewählte Dimension. Aber es dauert halt auch immer scheinbar Jahrzehnte, bis sich sowas durchsetzt. Ich weiß es nicht.
22:23
Ja, eine kurze Anmerkung erst mal hätte man beim Till vorhin auch schon sagen können. Standards sind super und wichtig für uns, weil sie stehen und fallen halt mit der Akzeptanz. Die Server können das schon lange und wenn man aber keine generischen Client Anbindung hat, um den Standard zum Endnutzer zu bringen,
22:40
dann ist es halt schwer mit der Akzeptanz. Deswegen gut, dass ihr dann Anfang gemacht habt und jetzt meine eigentliche Frage. Du hattest diese WistJS hieß es glaube ich. Ja, WistJS Bibliothek. Das hat erstmal nichts mit Geo und so zu tun. Das ist eine reine JavaScript Bibliothek für Time Manipulation. Habt ihr das jetzt erweitert für Geo Bezug und OGC
23:00
oder habt ihr das jetzt nur genutzt um eure Portallösung WMS Time Compatible zu machen? Genau, ging nur darum, einen Client UI zu haben, die im Endeffekt eine einfach konfigurierbare Zeitstrahlmöglichkeit bietet. Das wird für Projektmanagement Software oder sowas normalerweise verwendet. Ich kann einzelne Instanzen definieren. Ich kann es leider definieren im JavaScript Bereich
23:21
und es ist halt kostenfrei und ist Open Source. Von daher hat es sich eigentlich angeboten zu nutzen. Ich habe auch nichts anderes gefunden im Open Source Bereich, was so einfach integrierbar war. Im Endeffekt werden ja nur die Extents und die Zeitwerte entweder Komma separiert oder halt dann eben als Perioden oder was auch immer dem Modul übergeben und daraus initialisiert sich dann diese JavaScript.
23:43
Ja, UI. Und wenn er dann auswählt, wird dann über eine serverseitige Aufruf im Endeffekt was geändert und so. Also eigentlich relativ, sag mal, eineinhalb Wochen hat das gedauert, bis es umgesetzt war. Aber eineinhalb Wochen sind nicht viel. Kann man mal investieren.
24:00
Auch bei den Frameworks, die sonst wo im Webgist-Bereich oder wo immer eingesetzt werden, kann man auch darüber nachdenken, ob man das nicht auch mit umsetzt. Vor allen Dingen werden die Standards das hergeben und wir werden von Deutschland Seite aus auch auf die auf dieses Best-Project das Paper hinweisen bei dem neuen Standard der GDI-DE wird, wenn zeitlich variable Daten publiziert
24:21
werden sollen mit diesen WMS-Diensten wird darauf hingewiesen, dass dieses Best-Project das Paper anzuhalten ist, sodass man auch eine gewisse Planungssicherheit hat im Umsetzen. Ansonsten, klar, steht in den Standards drin. Aber wenn da keine Vereinheitlichung oder Verabredung diesbezüglich geht, wieder anzuverwenden ist, dann wird er wahrscheinlich auch von den Firmen nicht akzeptiert.
24:41
Oder von den Nutzern. Okay. Sonst noch Fragen aus dem Publikum? Also mich würde hier noch interessieren. Kommt das bei den Benutzern an? Also kommen Benutzer da selber auf die Idee? Müssen die dahin geschubst werden?
25:01
Auch so ein Button zu klicken und zu sagen, ich kann mir jetzt die Daten auch zu verschiedenen Zeitpunkten angucken? Wir haben derzeit ja noch keine publizierten Dienste aus Rheinland-Pfalz selber oder aus Hessen oder aus dem Saarland vorhanden, sondern wir nutzen diesen deutschen Wetterdienst, den Dienst vom deutschen Wetterdienst und die Luftbilder vom Kommunalverband oder Regionalverband Ruhr,
25:20
die wir jetzt über ein WMC-Dokument schon auf der verlinkt hatten. Das heißt, die Nutzer kommen derzeit oder schon seit zwei Jahren gar nicht an die Funktion ran, wenn sie es nicht wissen, wo sie sie finden. Die müssten erst mal die Produkte auch dementsprechend aufbereitet vorliegen haben. Und deswegen hatte ich diesen Basisliegenschaftskartendienst hier, diese oder historische TK.
25:41
Die sind noch nicht publiziert. Die werden aber in den nächsten Wochen oder so publiziert werden. Historische topografische Karten kann ja auch interessant sein. Ich weiß zwar nicht, für wen. Aber mag ja sein, dass man sich die Landschaft im Wandel da anschauen will. Und dann kann ich dann eben hier im Endeffekt mir die einzelnen Zeit, Zeitwerte hier auswählen und mir dann
26:01
topografische Karten von 1963 anschauen. Wie hat sich Koblenz entwickelt, der Deutsche Eck oder wo es eine Autobahn gebaut wurde? Ich weiß es nicht, keine Ahnung. Anwendungsfälle gibt es sicherlich viele. Aber da die Daten noch nicht so publiziert sind, wacht man erst mal ab, wenn die Dienste sehen. Und vielleicht auf der nächsten Foskiss, was es an Erfahrungsberichten gibt. Werden wir sehen.
26:20
Okay, ja, vielen Dank. Ähm, nochmal.