Ja, hallo und herzlich willkommen hier heute auf der FOSGIS-Konferenz beim dritten letzten Tag hier auf Bühne 1. Gibt ein spannendes Programm noch mal zum Abschluss heute Mittwoch auf vier Bühnen,

inklusive Workshops. Von daher wird heute noch mal viel geboten. Und wir hier auf Bühne 1 starten mit einem Vortrag von Christoph Jung und zwar Geodaten auf Smartphones, ein drittes Paradigma nach Desktop und WebGIS-Fragezeichen.

Ich bin sehr gespannt, was Christoph uns gleich erzählt. Wenn Sie Fragen haben, wie die letzten beiden anderen Tage auch, rechts im Manualist neben Ihrem Bild finden Sie einen Fragen-Tab, da können Sie Ihre Frage reinschreiben. Wenn schon ein Mitzuschauer dieselbe Frage gestellt hat wie Sie oder Sie die Frage gut finden, können Sie diese nach oben voten und im Anschluss an den Vortrag

werden wir dann gucken, dass wir so viele Fragen wie möglich innerhalb der fünf Minuten noch beantwortet bekommen. Und von daher bleibt mir jetzt nur noch zu sagen, viel Spaß mit dem Vortrag. Bitteschön Christoph, du bist dran. Hallo und herzlich willkommen zu meiner Präsentation für die FOSGIS 2021.

Mein Name ist Christoph Jung und ich möchte in den nächsten Minuten über ein Thema sprechen, das meiner Meinung nach auf Konferenzen in der GIS-Branche etwas zu kurz kommt. Und das ist das Thema Geodaten auf Smartphones. Im Laufe des Vortrages möchte ich herausstellen, warum nach Desktop und WebGIS das Smartphone die Plattform ist, die von der GIS-Branche viel stärker in

den Fokus gerückt werden sollte. Grundsätzlich geht es unabhängig von der Plattform, auf der wir irgendwelche Systeme oder auch Informationen präsentieren, um Karten. Egal ob wir auf einem Desktop-GIS sind oder im WebGIS, immer geht es um Karten, die man präsentieren möchte, im Idealfall interaktiv.

Ursprünglich gab es nur analoge Karten, die noch von Hand gezeichnet wurden. Aber durch die Verbreitung von Computersystemen und auch die Entwicklung von geografischen Informationssystemen war es möglich, auf dem PC mit georeferenzierten Daten schnelle und vielfältige Karten

zu erstellen. Und die Entwicklung und Verbreitung von Web-Technologien hatte auch auf die GIS-Branche eine sehr große Auswirkung. So haben sich webbasierte GIS-Systeme, also WebGIS, herausgebildet, die wesentlich in ihren Funktionsumfang haben als DesktopGIS, aber dadurch nicht mehr

diese Expertenanwendungen waren, deutlich einsteigerfreundlich für die Anwender waren und so eine viel größere Verbreitung von Geodaten befördert haben. Google Maps und Open Street Maps sind Anwendungen und Projekte, die heute in aller Munde sind und Milliardenfach genutzt werden. Aber das ist nicht das Ende der Entwicklung, denn mittlerweile haben wir

ein neues Thema, dem man sich stellen muss und das ist das Smartphone. Die Frage ist, wie Geodaten momentan auf Smartphones präsentiert werden können und wie man das vielleicht auch in Zukunft besser machen könnte. Mobil ist das Thema, das Auswirkungen auf viele Bereiche der IT hat,

auch auf die GIS-Branche. Ich habe mal eine Statistik ausgesucht über einen Anteil mobiler Suchmaschinenaufrufe in den USA und wir sehen hier, dass wir in einem Zeitraum Ende 2016, Anfang 2017 den Punkt hatten, dass die Mehrzahl der Suchmaschinenaufrufe über mobile Endgeräte stattfanden, also

Smartphones und Tablets. Heutzutage sind Smartphones die Endgeräte, mit denen der meiste Internet-Traffic produziert wird und mit denen die meisten Internetnutzer in das Internet gehen. Das heißt, möchten wir über Web-Technologien eine GIS-Anwendung präsentieren oder Geodaten präsentieren, dann kommen wir nicht daran vorbei, uns die

Besonderheiten eines Smartphones anzuschauen und Anwendungen speziell auch für Smartphone-Nutzer zu konzipieren und bereitzustellen. Jetzt könnte man ja meinen, wir haben ja Web-GIS-Technologien. Ein Web-GIS läuft im Browser und damit läuft das ja auf dem desktop PC und auf dem Smartphone, also eigentlich plattformunabhängig, so eigentlich im Browser. So ist es auch. Als Beispiel habe ich hier mal den

Baustellenatlas des Freistaates Sachsen rausgesucht. Dieser verfügt über eine Desktop-Version und über eine Mobil-Version. Eine andere Möglichkeit wäre, mit einem responsiven Design Web-GIS so zu gestalten, dass sie sich entsprechend der Größe und Form des Bildschirms

auf dem Endgerät anpassen. Das funktioniert aber tatsächlich gar nicht so toll. Ich habe jetzt hier mal drei Anwendungen herausgesucht aus dem Internet, die demonstrieren, dass das Ganze eben gar nicht so gut läuft. Wir haben links den Baustellenatlas des Freistaates Sachsen, wie eben schon gezeigt, in der Mitte das Geoportal der Republik Polen und rechts den Katalog für isländische Vulkane. Und wir

sehen bei allen drei Anwendungen, dass diese schlecht, teilweise sogar gar nicht bedienbar sind auf dem Smartphone. Das heißt, Smartphone-Nutzer werden ausgeschlossen von der Nutzerschaft dieser Anwendungen. Da das aber über 50 Prozent, also die Mehrzahl der Nutzenden sind, schränken wir natürlich total die potenzielle

Nutzerschaft auf unsere Anwendungen ein. Die Frage ist, warum es ist denn ein Web-GIS oftmals auf dem Smartphone schlechter bedienbar? Da gibt es drei große Themen. Erstens die Größe und die Form des Displays, etwas sehr offensichtliches sicherlich. Wir haben natürlich auf dem Smartphone wesentlich weniger Platz

und wir haben eine ganz andere Displayform. Das sorgt dafür, dass wir Überlagerungen oder Einbindungen und Sachinformation anders gestalten müssen. Das sorgt aber auch dafür, dass wir überlegen müssen, welche Bedienelemente wirklich zwingend notwendig sind zur Bedienung einer Anwendung. Gerade das Thema

herein- und herauszoom ist etwas, was auf dem Smartphone sehr natürlich über Pitch in und Pitch out funktioniert. Da stellt sich natürlich dann die Frage, ob man wirklich noch ein Plus- und Minus-Button zum Zoomen braucht. Nimmt man den raus, hat man gleich wieder mehr Platz geschaffen, um die Karte zu sehen oder andere notwendige Bedienelemente

platzieren zu können. Das zweite Thema sind die Eingabenmöglichkeiten. Auf einem Smartphone interagiert man über Touch, also Berührung. Das Berührung in der Regel mit dem Finger. Auf dem Desktop-PC habe ich dafür eine Maus. Die Genauigkeit, mit der ich Objekte anwählen kann, ist schon mal völlig unterschiedlich. Genauso aber

verfügt nicht nur die Karte auf dem Smartphone über Multitouch-Fähigkeiten. Da habe ich ein Webgist, das im Browser dargestellt wird. Dann hat auch der Browser natürlich Interaktionsmöglichkeiten über Berührung. Zum Beispiel kann ich von links nach rechts wischen, um eine Internetseite zurückzugehen. Solche Interaktionen zwischen Karte und Browser könnten sich

aber überlagern und führen dann eben gerne auch mal zu Fehleingaben, was natürlich die Unzufriedenheit unter den Nutzern verstärkt. Der dritte Punkt sind die unterschiedlichen Nutzungsgewohnheiten. Wir haben auf den Plattformen Desktopgist, Webgist und Smartphone unterschiedliche Nutzergruppen versammelt.

Ein Desktopgist wird in der Regel von Experten genutzt, die sich in der Anwendung von einem GI-System, aber auch im Thema Geodaten sehr stark ausgehen. Zum Smartphone hin nimmt diese Experten ein bisschen hinab. Noch dazu dominieren auch Smartphones die beiden Anwendungen Google Maps und Apple Cutten. Deren Nutzung

ist sehr entscheidend für die Prägung der Nutzerschaft und für die Nutzungsgewohnheiten, die man natürlich dann auch als Erwartung an eine andere Anwendung hat. Ich habe beispielhaft hier mal ein Bild rausgesucht für Apple Cutten. Am Google Maps läuft das genauso und geschaut, was diese Anwendungen eigentlich so ausmachen. Es sind eigenständige Applikationen,

was die Fehlbedienung bei Gesten mal vom Browser, mal von der Karte interpretiert werden, verhindern. Desweiteren lassen sich diese Anwendungen natürlich auch viel stärker im Dienste des Betriebssystems einbinden, zum Beispiel Sprachassistenten oder auch Schnittstellen zu anderen Apps. Thema wäre hier zum Beispiel, dass man ein Routing anbietet oder

standortbasierte Erinnerungen aufruft. Das zweite Thema ist, es gibt keine granulare Ebenensteuerung, wie wir sie aus einem Desktopgist kennen. Die ist etwas sehr Gist spezifisches und Personen,

die keine Erfahrung mit Gis haben und sich auch noch nie Gedanken gemacht haben, wie der Aufbau einer digitalen Karte funktioniert, ist dieses Thema immer neu. Und auch das Logo, das für uns als Gisexperten völlig selbstverständlich ist, wenn es darum geht, eine Ebenensteuerung darzustellen. Also die aufeinander liegenden Kacheln ist für Personen, für Nutzende, die keine Giserfahrung haben,

eben nicht selbst erklären. Google Maps und Apple Karten zeichnen sich dadurch aus, dass sie auf ein Themengebiet fokussiert sind und nur einzelne kuratierte Themen anbieten. Und der dritte Punkt ist die Interaktion mit dem Karteninhalt um Sachdaten abfragen. Aus dem Gis-Bereich kennen wir

ja, dass man mit allen Kartenobjekten eine Interaktion durchführen kann, also sie also anklicken kann, um Sachdaten zu erhalten, ob es nun ein Punkt, Linie, Polygon ist oder eben auch Rastedaten, schon allein um ein Pixel-Value zu erhalten. Das ist aber Menschen, die noch nie etwas mit Gis zu tun hatten, nicht selbstverständlich. Die sehen eine Karte und wollen einfach visuell Information erhalten. Um weitere

Informationen bereitzuhalten, nehmen Apple Karten und Google Maps zusätzliche Marker in ihre Karte auf, die eine Interaktion suggerieren und sich optisch stark vom restlichen Karteninhalt abheben. Und über diese Punkte oder Marker ist eine Sachdatenabfrage möglich. Diese

zusätzlichen Marken sind auch viel einfacher per Finger zu berühren und zu treffen als beispielsweise eine 1 mm dünne Linie. Und genau solche Anwendungen, also einen relativ vorkuratierten Inhalt, mit einer Überlagerung durch Marker, ist heute schon mit OGC-Diensten möglich. Das heißt, das ist kein Geheimwissen

von Google Maps und Apple Karten. Wir können mit Geodateninfrastrukturen, die OGC-Dienste anbieten, wie WMS, TMS, WMTS und WFS, heute schon genau solche Applikationen erstellen. Und zwar, im Gegensatz zum WebGIS-Bereich, ohne die Zuhilfenahme zusätzlicher Frameworks und Bibliotheken, dritte, die man auch immer wieder aktuell halten muss, sondern das geht

heute schon mit den Entwicklungserzeugen, die die Hersteller Google und Apple uns schon mitgeben. Und das möchte ich im folgenden präsentieren. Wir sehen hier die Entwicklungsumgebung Xcode, um für iOS zu entwickeln. Und ich habe einfach mal ein kleines groben Grundgerüst für eine kartenbasierte App erstellt und möchte

mal zeigen, wie man hier OGC-Dienste einfügen kann. Grundsätzlich sehen wir hier schon den ersten Marker, den ich gesetzt habe. Um diesen zu beschreiben, habe ich einfach eine Klasse erstellt, die alle notwendigen Informationen mitgibt, um solche Marker zu erstellen. Der hat einen Titel, ein Subtitel und eine Koordinate. Wichtig, die Geodaten müssen,

damit ich sie nutzen kann, alle im Koordinatenreferenzsystem EPSG4326 vorliegen. Und dann ist es immer wichtig, dass ich einen MapView, das ist sozusagen die Karte, die wir hier haben, noch etwas beschreibe mit Daten. Ich muss da Daten mitgeben, die angezeigt werden sollen. Das ist hier

meine Start-Annotation genannt. Und es gibt eine Methode, die nennt sich UpdateUIView, die ich überschreiben muss. Und in der gebe ich einfach meine Daten mit. Da habe ich einfach die wachereable View, der ich per Funktion AddAnnotation meine Start Annotation mitgeben kann. Und mehr ist

das tatsächlich schon gar nicht und ich zeige das Ganze an. Ich habe auch schon mal ein bisschen was vorbereitet, das will ich noch mehr sehen. Jetzt haben wir hier natürlich den Karten Hintergrund von Apple. Wir können aber auch einen ganz anderen einrichten. Dafür habe ich mal vorbereitet. Ich habe hier eine wachereable TMS gemacht und habe hier OpenStreetMap als TMS angegeben. Damit das Ganze dann

angebunden werden kann, muss ich das in meinem MapView, den ich überschreibe, natürlich noch mitgeben, als Variable. Und diese muss am Ende meinem View in der Funktion UpdateUIView auch mitgegeben werden. Sehen wir hier

AddOverlay, AddOverlay und hier gebe ich den selfTMS, also die Variable mit dem OBS-TMS mit. Bei einem TeilOverlay kann ich auch sagen, dass er den Karteninhalt ersetzen soll. Das heißt, ich habe damit eine andere Hintergrundkarte und wenn

wir jetzt hier drauf gehen und wir sehen, dass wir jetzt nicht mehr die Apple-Karten im Hintergrund haben, sondern OpenStreetMap. Das ist erst mal nur die Hintergrundkarte. Die Frage ist jetzt aber, wie können wir jetzt ein WMS einbinden für das Ganze? Und zwar habe ich hier einfach mal

Daten für die Kantone der Schweiz rausgesucht, ein WMS und der wird auch als TeilOverlay hinzugefügt. Den TeilOverlay muss man leider überschreiben und kann da die Kacheln hinzufügen. Hier haben wir dann einen WMS, der nicht mehr den Inhalt überschreibt, sondern der das Ganze ergänzt und wir sehen, hier

kommt ein zusätzlicher Dienst hinzu. Das überschreiben ist natürlich nicht so schön, weil es natürlich nicht ganz so einfach macht. Man sieht hier die lilanen Linien sind die Grenzen der Kantone der Schweiz. Hat aber den schönen Vorteil, dass hier pro Kachel, die man eigentlich aus dem

WMS kennt oder WMTS, ein WMS-Request macht. Das heißt, nicht für den gesamten Screen wird ein WMS-Request erzeugt und immer nur für die einzelnen Karren, sodass stückchenweise das Bild aufgebaut wird. Nachteil ist, man hat natürlich mehrere Requests, die man an den Server sendet und der natürlich entsprechend mehr Last hat.

Man sieht, es geht momentan schon mit Wortmitteln, einen WMS und TMS einzubinden. Das Problem ist aber, ist gar nicht so einfach. Ich habe auf GitHub ein neues Projekt gestartet mit dem Namen Malinki, in dem möchte ich ein Framework oder ein Grundgerüst für eine kartenbasierte mobile App startend

mit iOS erstellen, sodass es rein per Konfiguration möglich sein soll, WMS, TMS, WMTS und WFS in die eigene App einzubinden und so Apps deutlich einfacher und schneller zu erstellen, sodass wir die Nutzer, die die Mehrheit darstellen, und das

sind Smartphone Nutzer, mit auf sie abgestimmten Anwendungen versorgen können. So viel zum Thema Geodaten auf Smartphones, beziehungsweise meine Gedanken, die ich habe zu dem Thema. Ich hoffe, es war ein bisschen spannend, Sie konnten was mitnehmen. Momentan ist noch nicht so viel los in dem Repository auf GitHub, aber ich hoffe, dass ich in einem Jahr bei den

nächsten Posts gesehen dann wieder ein bisschen was präsentieren kann dazu. Vielen Dank. Ja, danke auf jeden Fall, Christoph, für diesen interessanten Vortrag zum Thema Geodaten auf Smartphones. Schön,

dass du hier bist und wir noch ein paar Fragen beantworten können. Tatsächlich kamen auch gerade kurz vor Ende noch zwei quasi in den Fragentap rein. Fangen wir mit der ersten an, auch so ein bisschen kritisch, so ein bisschen, wo der

Bezug zu FOSS ist, gerade weil Apple und Google ja sind die jetzt plötzlich on Vogue auf der FOSS Geszene. Kannst du vielleicht einfach was dazu sagen? Das sind ja eigentlich beide Fragen ein bisschen kritisch, insofern auch schon mal schön so ein Thema zu haben. Natürlich sind Apple und Google nicht free and open source, das ist richtig, aber ich kann natürlich in den entsprechenden

Werkzeugen, die es gibt, eben Dienste einbinden, die eben aus der FOSS Geszene kommen und das ist eine ganz wichtige Sache. Ich meine, jeder muss ja auch irgendwo mal Geld verdienen und man kann natürlich auch Bezahl-Apps auf Plattform für Android und IOS bereitstellen und es wäre schön, wenn ich meine, wenn ich als

Diensteanbieter eine quelloffene GDI einsetze, dass ich diese Dienste beispielsweise in WMS, in WFS etc. eben auch in meinen Apps dann eben noch einbinden kann oder ich muss deswegen auch immer wegen irgendwelchen Restriktionen in-house Applikationen einsetzen, die halt close to the scene sind

und dann möchte ich natürlich auch Werkzeuge, die ich schon habe, wenn ich zum Beispiel halt einen Geo-Server nutze und dann WMS publiziere, eben auch nutzen, um dann die Kollegen entsprechend zu unterstützen. Insofern sollte das jetzt weniger eine Werbung sein, um auf Google oder Apple zu entwickeln, sondern zeigen, dass auch auf diesen Plattformen man mit FOSS GIZ arbeiten kann.

Ja, auch noch eine spannende Frage, die auch gerade ganz viele Votes bekommt, die sicherlich auch viele interessiert, ob es eine native Möglichkeit gibt für OGC-Dienste, ob es die nur auf IOS gibt oder auch auf Android? Also gibt es diese native Möglichkeit für OGC-Dienste

nur auf IOS, weil das ist ja gerade auf IOS gesagt, oder auch für Android? Die gibt es genauso auch für Android. Letztendlich machen wir hier nichts anderes als ein HTTP GET Request zu machen. Also die OGC-Dienste sind ja total simpel eigentlich gemacht, dass es ja eine REST API hat und alles zustandslos ist. Das heißt, ich kann das ja tendenziell auch alles von Hand relativ einfach über

irgendwelche HTTP-Libraries am Ende nachprogrammieren. Das ist ja das Schöne an den OGC-Diensten. Genau. Dann genau die zweite Frage, die eben auch reinkam. Wenn ich ein Engineering-Team habe, die bereits WebGiz programmieren, welche Eigenschaft sollte die höhere Engineering-Kosten für

eine qualitative Entwicklung rechtfertigen? Das ist eine sehr interessante Frage. Die Frage kommt immer, wenn man ein neues Produkt einführen möchte, auch in-house. Das habe ich in meinem Arbeitsleben auch ständig zu tun, wenn wir nicht mit der Eier legen wollen, weil wir auch noch das fünfte Produkt herstellen wollen. Es ist immer die Frage, was ich abziele. Wenn ich natürlich sage,

ich möchte ein allgemeines Werkzeug haben, mit dem ich relativ einfache Sachen machen möchte für einen grenzenden Dutzerkreis, der sich entsprechend auskennt, dann brauche ich das nicht machen möchte ich. Aber letztendlich vielleicht irgendeinen Mehrwert schaffen, auch zum Beispiel, wenn ich jetzt eine Kommune bin oder ein Landkreis oder ein Bundesland und ich möchte den Bürgern einen hohen Mehrwert geben, dann haben eben mobile Applikationen

mehr Funktionsumfang, gerade in der Integration in das Betriebssystem, als das Web-Applikationen haben. Genau das ist der Vorteil, ob sich der am Ende monetär rechnet durch den größten Aufwand, sei halt dann die Frage. Genau deswegen möchte ich aber das Projekt, was ich am Ende gesagt hatte, mit Malinki starten, dass man eben viel einfacher

eine relativ simple, nur auf Konfiguration basierende App erstellen kann, dass eben diese Entwicklungskosten, die man immer machen muss, einfach mal wegfallen oder zum Großteil, weil Frameworks oder ich sag mal auch Prototypen, um Web-GIS bereitzustellen. Das haben wir im GIS Bereich schon, gerade wenn ich im Kugus Bereich bin mit dem Plug-in QGIS2-Web, kann ich sehr einfach eine simple

Web-Anwendung auf Knopfdruck herstellen. Das klappt jetzt auch nicht bei allen Sachen immer super, aber da kann ich schon was. Und sowas fehlt eigentlich im Mobile-App-Bereich und damit fallen natürlich das Smartphone Nutzer schnell auch mal ein bisschen runter, gerade auch, weil ich natürlich ein bisschen auch denken muss, wie muss ich dann meine Dienste auch konfigurieren bezüglich Sichtbarkeit, weil ich habe ein kleineres Display, wenn ich das gesamte Objekt

sehen möchte, zum Beispiel ein sehr großes Flurstück, dann muss ich halt weiter rauszoomen als auf meinem Desktop-Rechner. Solche Sachen muss ich dann halt bedenken, wenn ich das natürlich nicht mache und sage, ich möchte die gleiche Karte, die ich auf einem Web-GIS habe, eins zu eins auch, wie ich sie auf einem Desktop sehe, auch auf einem Smartphone sehe, dann ist der Aufwand eine Mobile-App zu machen, eigentlich dann nicht mehr gerechterdigt.

Wenn ich aber wirklich mich spezialisieren möchte, auf den Smartphone Nutzer, dann komme ich da eigentlich fast gar nicht mehr drumherum. Hier kam eine Frage nach dem Code. Du hattest gerade auch einen GitHub-Link gepostet. Findet man da auch den Code als Beispiel? Noch nicht. Soweit bin ich noch nicht. Soweit bin ich noch nicht. Ich habe das erst gestartet. Aber wirst du tun, quasi.

Genau. Ich hoffe, dass ich bis zur nächsten Fosges vielleicht soweit bin, dass ich da schon mal was präsentieren kann. Ich habe jetzt angefangen, erst mal nur so ein bisschen Richtung Architektur, mir das alles zu machen. Das erste, was man ja macht beim Software-Projekt, ist immer viele Slides zu erstellen. Wie stellt man sich was vor und wie sieht der Prototyp aus? Eben dann ans Programmieren ran geht. Also aber ich denke, da gehe ich bald los und ich hoffe, dass ich dann

im nächsten Jahr dann schon ein bisschen was präsentieren kann zu dem Thema. Genau. Ja, ich glaube. Und wenn du zwischendurch einfach die die Demosachen von heute dahin packst, sind die Leute, glaube ich, auch schon glücklich. Ja, genau. Eine Frage schaffen wir noch. Smartphone Nutzer sind die Mehrheit und bisher in der Fosges Szene immer noch nicht ausreichend berücksichtigt. Aber ist eine PWA Web App nicht die zukunftsfigurige,

weil offenere Plattform? Auch eine sehr interessante Frage. Da muss ich jetzt kurz fragen, was ist ein PWA Web App? Vielleicht jetzt oute ich mich gleich das, was ich nicht weiß. Nein, alles gut. Eine Progressive Web App quasi ist damit, glaube ich, gemeint. Also dass wir hier

hybride App reingehen, also sprich, das gekapselt haben und dann oder in welche Richtung geht es dann? Genau, quasi so ein bisschen, sag ich mal, eine Responsive Web Seite, aber als App. Ja, ja, ja. Ich das verstehen. Genau. Das Thema gibt es in allen Bereichen, wo man irgendwo mit mobile Apps zu tun hat. Ich war früher auch ein großer Anhänger von Werkzeugen,

die universal einsetzbar sind. Das hat sich im Laufe der Zeit auch beruflich Erfahrung ein bisschen so gemacht, dass ich immer mehr in die Richtung gegangen bin, dass ich mehr spezialisierte Tools haben möchte, die für entsprechende Plattformen wirklich konzipiert sind. Deswegen bin ich halt, man hat es vielleicht gesehen an der Präsentation ein bisschen im Apple Umfeld

privat gelandet und bin der Meinung, man sollte vielleicht oder ich persönlich möchte halt doch mehr die nativen Werkzeuge, die man von Google und Apple bekommt, dann unterstützen und nicht auf hybride Apps gehen. Ja, ist aber rein persönlicher. Genau ist ja auch. Und wo sich die Welt

hin entwickelt, wenn man das jetzt wüsste, dann genau insofern das ja auch schön zu wissen. Mit Blick auf die Uhr schaffen wir die eine letzte Frage auch noch. Vielleicht kannst du da was zu sagen. Mit welchen Fosstools sollen Strichstrich können denn am besten entsprechende Dienste bereitgestellt und getestet werden? Das ist eigentlich völlig egal, denn die OGC-Dienste

zeigen einem ja nicht an, was für ein Server dahintersteht. Ja, also wenn ich den Anfrage kann mir eigentlich völlig egal sein, ob das ein ARCUS Service, ob das ein Geo Service, ein Microsoft-Server. Hauptsache, ich habe einen OGC-Konform Service am Ende noch. Also insofern ist das eigentlich völlig frei, was man da nimmt. Alles klar. Wunderbar. Dann danke ich dir

auf jeden Fall nochmal für deinen Vortrag und danke auch, dass du für die etwas kritischen Fragen ist ja auch mal ganz gut, wenn nicht nur alles gestuckt wird, zur Verfügung standest. Und von daher haben wir jetzt hier fünf Minuten Pause. Sie können den Raum wechseln. Sie können aber auch gerne hier bleiben, weil hier geht es nämlich gleich um 9.30 Uhr weiter

mit Armin Reterath, Mr. Map, Geo-Portal, RLP, Reloaded. Gab es, glaube ich, letztes Jahr auch schon einen Vortrag zu und von daher bin ich gespannt, was da dieses Mal kommt. Und von daher würde ich sagen, bis gleich. Ciao. Tschüss.