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

Couchbase Mobile, GeoCouch und MapQuery

00:00

Formal Metadata

Title
Couchbase Mobile, GeoCouch und MapQuery
Subtitle
Mobile Anwendungen auch ohne Konnektivität
Title of Series
Number of Parts
47
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Die moderne mobile Welt ermöglicht uns fast grenzenlosen Zugriff auf Informationen und Daten. Problematisch wird es jedoch, wenn die Verbindung zum Internet unterbrochen ist, beispielsweise in einem Tunnel oder in Gegenden, in denen das Netz noch nicht ausgebaut wurde. Funklöcher sind immer ärgerlich, besonders jedoch, wenn man eine Verbindung zu einem zentralen Server benötigt, etwa zum Übertragen der gerade gesammelten Informationen im Feld. Die Lösung des Problems besteht darin, die Daten zunächst lokal auf dem mobilen Gerät zu speichern und erst dann zu übertragen wenn eine Internetverbindung besteht. Damit sich Entwickler um die Applikation selbst und nicht um die Synchronisation kümmern müssen, kommt Couchbase Mobile zum Einsatz. Diese Datenbank liefert bereits alles, um eine solche Offline-Anwendung zu schreiben. Dabei ist Couchbase Mobile mehr als eine Datenbank. Sie kann nicht nur Daten im JSON Format speichern, sondern auch HTML5-Anwendungen direkt ausführen. Es genügen also bereits Grundkenntnisse im Webbereich, um eine Anwendung zu entwickeln. Durch GeoCouch ist es möglich, räumliche Anfragen lokal auf dem Gerät zu bearbeiten. MapQuery, ein Web-Mapping-Framework das auf OpenLayers und jQuery basiert, vereinfacht die Entwicklung zusätzlich. Dieser Vortrag gibt zunächst einen kurzen Überblick über die verwendeten Technologien Couchbase Mobile, GeoCouch und MapQuery. Danach wird demonstriert, wie leicht eine Anwendung gebaut werden kann, die die oben beschriebene Datensynchronisation ermöglicht. Alle erwähnten Softwareprodukte sind Open Source. Couchbase Mobile und GeoCouch stehen unter der Apache License Version 2.0, MapQuery steht unter der MIT Lizenz.
17
27
29
34
Thumbnail
25:44
47
Open sourceRothe-VerfahrenGeometryComputer wormERLANGWorld Wide WebOpen sourceJavaScriptComputer animation
World Wide WebInternetHausdorff spaceServer (computing)Boom (sailing)Graphics tablet
La Pomme MarseilleArtificial neural networkDrum memorySun <Marke>Insertion lossApache <Programm>Computer musicIMSDatabaseServer (computing)Volumetric flow rateConditional-access moduleApache <Programm>SoftwarePostgreSQLUpdateSmart cardInternetCouchDBResponse time (technology)Wireless LANTable (information)Server (computing)DatabaseVersion <Informatik>Route of administrationImplikationData structureField extensionRow (database)Bus (computing)Data transmissionPoint (geometry)FacebookData storage deviceXMLUML
World Wide WebApache <Programm>GeometryMenu (computing)CouchDBComputer animation
Maximum likelihoodHidden Markov modelComa BerenicesDatabaseExpert systemTable (information)RectangleVersion <Informatik>EstimationQuery languagePDF <Dateiformat>PrototypeCouchDB
SummierbarkeitFunktionalitätGeometryAPIHTTPSun <Marke>Cache (computing)Vector graphicsTAXField extensionRadiusData structureServer (computing)Maxima and minimaAndroid (robot)DatabaseClient (computing)AuthenticationMilan <Programmiersprache>Moving averageHTMLjQueryExt functorZugriffTranslation memoryBack-face cullingBIND <Programm>TypUniform resource locatorComponent-based software engineeringSmart cardSummationFunction (mathematics)InformationPropositional formulaOpen sourceDatabaseEvent horizonGeometryExpert systemVector graphicsPositionMusical ensembleFluxPlane (geometry)APIPolygonParameter (computer programming)RadiusData structureField extensionNumberAuthenticationQuery languageZugriffLiniePrototypeCodeRoute of administrationProxy serverMacro (computer science)Data storage deviceState of matterCommunications protocolSpeciesFORTRANEigenvalues and eigenvectorsCouchDBGEOS <Betriebssystem>Data storage deviceSoftware repositoryPAPGeodesicProduct (category theory)Channel <Internet>Server (computing)Version <Informatik>Android (robot)jQueryWeb pageMobile appComputer animation
Transcript: German(auto-generated)
In meinem Vortrag, für die, die sich wundern, warum der Titel anders ist, als ihr Programmheft, der Name vom Produkt hat sich geändert und wer die Historie von CouchSpace kennt, weiß, dass wir das gerne mal durchführen, so Dinge zu ändern. Also, beginnen möchte ich kurz aber mit, wer ich halt überhaupt bin, für die, die es nicht wissen. Ich arbeite für CouchSpace und habe eben GeoCouch entwickelt und im Prinzip mache ich alles,
was Open Source ist und eben hauptsächlich Erlang und JavaScript. Mein Lieblingsprogrammiersprache ist aber Python. Jetzt geht es aber gleich los mit einem Beispiel. Also ich will anfangen mit, was können Sie Tolles mit dem ganzen, wie der Titel eben sagt, mit CouchSpace, SyncPoint, GeoCouch und MapQuery anfangen, damit Sie eine Idee haben,
warum Sie in dem Vortrag überhaupt sind und dann können Sie quasi, wenn das Beispiel vorbei ist und Sie sagen, es interessiert Sie überhaupt nicht, gleich wieder gehen, bevor ich dann in die Details einsteige. Das Beispiel könnte man überschreiben mit dem Titel Replikation. Und zwar nehmen Sie mal an, Sie sind einfach irgendwo in der Wildnis. Sie haben keinen Empfang. Sie wollen jetzt aber zum Beispiel aufnehmen, was für Vegetation dort ist oder die Bäume oder so.
Natürlich ist normal auf einem Tablet oder einem mobilen Gerät die Lösung, man hat eine Internetverbindung, trägt da die Daten ein, die werden übertragen und dort gespeichert. Das Problem ist aber, wenn ich keinen Empfang habe, habe ich auch kein Internet. Die Lösung ist, man speichert das auf dem mobilen Gerät und wenn man dann eben zurückkommt
in die Firma oder nach Hause oder wieder Empfang hat, überträgt man die Daten dann einfach von dem mobilen Gerät, man repliziert die Daten eben vom mobilen Gerät auf den Server. Es gibt auch noch andere Fälle und zwar, es gab mal Empfang, aber es gibt jetzt keinen mehr. Im Katastrophenfall ist es auch wichtig, dass man vor Ort sein kann, dort Daten sammeln kann
oder eventuell Daten aktualisieren kann. Und anhand dieses Katastrophenbeispiels will ich jetzt mal durchspielen. Also ich bin jetzt vor Ort, habe ein mobiles Gerät. Da ist der aktuelle Kartendatensatz gespeichert und ich kenne mich aus, wo ich bin und wo ich hin will. Jetzt kann ich dort eben neue Daten eintragen oder eben Daten aktualisieren.
Zum Beispiel könnte es sein, dass auf meiner Karte ist das Gebäude als nicht eingestürzt, gekennzeichnet, es ist aber mittlerweile eingestürzt. Das könnte ich einfach eintragen. Jetzt, wie beschrieben, habe ich keine Verbindung momentan. Das heißt, ich gehe dann zum Beispiel abends immer zum Basecamp zurück
und tue da die Daten übertragen. Es könnte sein, dass sie zum Beispiel einen Hotspot aufgebaut haben und ich übertrage das Ganze dann via WLAN. Falls das auch nicht der Fall ist, kann ich auch einfach hingehen, das direkt einstöpseln und übertrage so meine Daten. Wir können jetzt noch einen Schritt weiter gehen und sagen, es gibt dann noch zu diesen kleineren Punkten, wo man Daten übertragen kann,
noch einen zentralen Punkt, der zum Beispiel tägliche Updates bekommt. Der könnte dann eben noch weiter weg sein und ich muss zum Beispiel mit dem Auto hinfahren. Wenn dann aber jetzt mittlerweile die Infrastruktur wieder aufgebaut ist und es gibt zum Beispiel wieder Internet oder ein größeres WLAN, dann kann ich auch direkt von mobilen Klienten direkt auf diesen Server übertragen.
Das heißt, die mittlere Schicht fällt einfach weg. Aber ich muss jetzt irgendwie nicht die Software groß umändern, sondern was ich eigentlich mache, ich ändere nur um, wohin will ich meine Daten replizieren. Das Tolle ist jetzt aber, das funktioniert jetzt nicht, wie hier beschrieben, quasi von unten nach oben, sondern was man machen kann ist, es ist echte Multimasterreplikation.
Das bedeutet, wenn ich nun Updates bekomme zum zentralen Server, kann ich die auch zurückspielen. Also als Beispiel wäre jetzt, während jetzt eben so eine Katastrophe stattgefunden hat, tun Leute bei OpenStreetMap über das Internet die Kartendaten täglich aktualisieren.
Jetzt kann eben das auf den zentralen Server gespielt werden und ich kriege eben jeden Tag neue Kartenupdates nach unten repliziert auf mein mobiles Gerät. Und wenn ich eben Änderungen vornehme und es wird wieder zurückgespielt, sehen natürlich auch die, die die Karten online editiert haben, ok, es hat sich was geändert und natürlich ist es viel vertrauenswürdiger, wenn ich jetzt Daten geändert habe von
jemandem, der vor Ort ist. Also würde das wahrscheinlich dann einfach übernommen werden. So, dann kommen wir jetzt dazu, was sind es für Technologien und so weiter. Wer mich kennt, weiß, ich habe immer Vorträge über CouchDB gehalten, heute ist es eben ein CouchBase Vortrag und das Wichtigste ist erst mal zu merken, CouchBase ist nicht der Patchy CouchDB.
Das war noch vor einem Vierteljahr so, jetzt aber nicht mehr und es ist ganz wichtig, weil da gab es im Internet, wer sich da ein bisschen rumgesucht hat oder hin und wieder was mitbekommen hat, Mods, das Kuddelmuddel, was ist mit der Patchy CouchDB, also um es kurz zu fassen, Patchy CouchDB gibt es, es wird weiterentwickelt, bald gibt es eine aktuelle Version und CouchBase ist
im Prinzip ein Fork von Patchy CouchDB bereits im September oder so und für den normalen Anwender hat es einfach miteinander überhaupt nichts zu tun. Das ist so die einfachste Vorstellung, dann kommt man nicht so durch ein Thunder was was ist und was was kann. Ich will aber jetzt eben auf CouchBase eingehen. CouchBase ist sowohl
eine Firma als auch ein Produkt. Die Firma hat eben, ist hauptsächlich tätig, die Kunden sind hauptsächlich welche, die viele Daten haben und schnelle Antwortzeiten wohnen und so, also der bekannteste Kunde ist wohl Synga, die machen diese ganzen Online-Facebook-Social-Gaming-Spiele
oder eben so Werbepartner, die eben schnell Werbung schalten müssen innerhalb von Millisekunden entscheiden müssen, was für Werbung sie schalten und so weiter. Ich will jetzt aber eigentlich aufs Produkt eingehen. Das Hauptprodukt ist CouchBase Server und damit anzufangen, es ist eine Datenbank. Sie ist nicht relational und sie ist
dokumentbasiert, das heißt für die, die aus der SQL-Welt kommen, da ist ja quasi so die kleinste Einheit ist im Prinzip in einer Tabelle so eine Zeile. Bei CouchBase ist die kleinste Einheit ein Dokument und ein Dokument ist eine komplexere Datenstruktur, das heißt im Falle von CouchBase ist es
einfach JSON, das heißt alles was JSON ist, kann ich einfach da drin speichern und dann natürlich auch wieder abfragen. Die Ziele von CouchBase Server sind, dass die Daten verteilt werden eben über mehrere Server, dann wenn einer ausfällt, kann ich einen anderen hochfahren und so weiter, das wird alles gemanagt über eine schöne Oberfläche. Dann hohen
Datendurchsatz, allerdings bei geringer Latenzzeit, das heißt schnelle Antwortzeiten. Es muss eben mal so Online-Games, muss es immer alles ziemlich schnell passieren und natürlich ziemlich viel. So, dann komme ich jetzt schon zu GeoCouch, das ist quasi ein weiterer Baustein in dem ganzen Teil. GeoCouch ist eben eine Erweiterung, um Geo-Daten zu speichern.
Man kann das jetzt vergleichen mit was PostGIS für PostgreSQL ist. So ist es eben GeoCouch für sowohl Apache Couch, jetzt kommt es wieder verwirrend, GeoCouch funktioniert mit CouchBase, aber auch mit Apache CouchDB und ich gehe entwickelt für beides.
Die sind eben gerade noch ähnlich genug, dass es funktioniert. Also im Prinzip hat man die gleiche API und ich kann eben entscheiden, ob ich jetzt eben die Vorzüge von Apache CouchDB haben will mit den Geo-Sachen oder ob ich die Vorzüge von CouchBase haben will mit den Geo-Sachen. Die API bleibt die gleiche. Um zu verstehen, was GeoCouch eigentlich so macht, will ich
kurz erklären, woher das kam. Und zwar war das 2008, war ich in Australien und da hatten wir einen Kunden und der wollte, der hatte eben alle zwei Jahre hat er so eine PDF veröffentlicht von der Wasserqualität und so weiter und der wollte jetzt eben so ein neues schickes Web-Interface
haben, mit dem man rumklicken kann, Daten vergleichen kann und so weiter. Für den Prototypen haben wir XML bekommen, das haben wir zu JSON konvertiert, weil das gerade mit dem Webmapping, also wir haben Open Layers verwendet, damit ist der JSON super händelbar und dann kam aber der Tag, wo er die fertige Version haben wollte. Und bei der fertigen Version war es natürlich der übliche Stack, also
unten eine Datenbank, ich glaube das war sogar eine Oracle-Datenbank, dann drüber ein Geo-Server und der Geo-Server gibt dann JSON aus. Wir mussten sogar den Geo-Server anpassen, dass das JSON so kommt, wie wir das haben wollten und das Datenbank-Schema hat eben, also ich hatte einen Datenbank-Experten im In-House, der hat irgendwie acht Wochen gebraucht, bis das Datenbank-Schema fertig war und das Datenbank-Schema war dann aber so, dass man für jede
Anfrage brauchte einen Cross-Join über alle Tabellen. Das heißt, das Ganze normalisieren, was der acht Wochen lang gemacht hat, hätte ich einfach auch sparen können. Und das war eben der Zeitpunkt, wo ich mir gedacht habe, hätte ich da CouchDB nehmen können, hätte ich einfach das JSON von dem XML, das wir schon hatten, genommen, reingespeichert, wieder geholt und fertig. Damals war aber das Problem, man konnte keine Rechtex-Abfragen, also
keine Bounding Box-Abfragen auf CouchDB fahren. Das heißt, wenn ich jetzt zum Beispiel eine Karte darstellen wollen würde, hätte ich immer alle Daten holen müssen und natürlich würde ich nicht alle Daten auf meiner Karte darstellen. Das war eben der Zeitpunkt, wo ich mir gedacht habe, wenn es sowas geben würde, wäre es cool, also mache ich es einfach. So begann eben Geo-Couch.
Was kann jetzt Geo-Couch? Zum einen, also da bin ich eigentlich relativ stolz drauf, es kann alle Geometrierarten. Es gibt relativ viele Datenbanken, die jetzt immer wieder auftauchen im Internet, die kann irgendwie tolle Geosachen, aber meistens sind es nur Punkte. Und wer schon mal zu tun hatte mit Punkten, ist alles total einfach. Also eine Punkt-Polygon-Abfrage
schreibe ich in fünf Minuten. Aber ob jetzt ein Polygon, ein anderes Polygon schneidet, ist schon wesentlich aufwendiger. Die API läuft immer über HTTP ab. Das ist die Open Search Spezifikation. Also es wird jetzt dann, also ich zeige es schon ungefähr seit eineinhalb Jahren bei jedem meiner Vorträge, dass es ist bald ein OGC-Standard. Es ist auf
einem Fast-Track-Prozess, der jetzt bereits schon glaube ich zwei Jahre dauert, aber es wird bald so weit sein hoffentlich. Also es gab keine großen Änderungen mehr und hoffentlich wird es bald eben sogar ein OGC-Standard werden. Dann eben alles ist JSON, eben einfach zu verarbeiten und was momentan eben unterstützt wird, ist nur eine Rechtex-Abfrage und jetzt neu dazukommend eben ist jetzt die Geometrie-Suche. Das heißt, ich kann
zum Beispiel sagen, gib mir alle Flüsse in dem und dem Polygon. Oder diese Linie, alles was diese Linie schneidet, will ich haben. Das wird implementiert mit Hilfe von Geos. Also ich habe das nicht selber geschrieben, weil das ja irrsinnig und komplex ist, sondern ich nehme da einfach Geos dafür, weil das ist ja erprobt und funktioniert einfach. Wer verwendet GeoCouch?
Jetzt muss ich wieder einen Schritt zurückgehen und zwar das Problem ist, CouchBase ist relativ neu. Und natürlich haben die, die bisher GeoCouch verwenden, auch CouchDB verwendet, weil es ist aber nichts anderes. Deswegen sind jetzt diese Anwender verwenden teilweise sogar nur CouchDB ohne GeoCouch, aber es sind quasi die Projekte im Geo-Bereich.
Zum einen, wer eben als Tilecache, wer muss ich MapProxy nennen, wer in dem Vortrag war, weiß es, da gibt es mittlerweile ein CouchDB Backend dafür. Dann, wenn man zum Beispiel Vector-Daten hat, das wäre eben das Beispiel aus Australien, da kann man einfach GeoCouch und MapQuery, auf das ich später noch kommen verwenden. Und wenn man es aber einfach nur als Datenbank eben nennen will, was es ja eigentlich ist, gibt es bereits für Google,
gibt es bereits, ist bereits in der neuen Version drin, dass man im CouchDB einfach speichern kann. Also ich kann einfach mit OGR zu OGR einfach eine Shapefile direkt in CouchDB speichern. Bei GeoTools ist es experimentell. Das hat man eben angefangen, das weiß nicht, wie gut es funktioniert, aber ist schon im Search Repository.
Und bei Degree haben wir letztes Jahr beim Bolzena Codesprint mal ein bisschen rumgebastelt. Also da gibt es auch so experimentell mal schauen, wie es funktioniert. Und ja, es lief mal grob, ist es nicht nicht so toll, aber es funktioniert mal grob. Also man sieht eben, es ist relativ leicht, in die aktuellen Produkte zu integrieren. In der Zukunft muss es natürlich mehr Abfragemöglichkeiten geben.
Zum einen eine nächste Nachbarnabfrage. Das bedeutet, ich will zum Beispiel wissen, was sind die nächst liegenden fünf Tankstellen. Natürlich, wenn ich zum Beispiel in der Wüste bin, kann es relativ weit weg sein. Die andere, und da gibt es eben bereits einen Prototypen. Der wurde von Tobias Sauerwein programmiert. Er ist eben Student und der hatte mich eben gefragt,
ja was könnte ich so für GeoCouch einbauen, was nicht so kompliziert ist. Dann habe ich gesagt, ja, schau dir das mal an. Dann hat er das quasi ohne weitere Hilfe einfach implementiert und es funktioniert. Das muss ich jetzt eben dann noch ins Office Select GeoCouch aufnehmen. Und natürlich die Radiosuche, dass man eben sagen kann, ja gib mir alles im Umkreis von fünf Kilometern. Ein weiterer Punkt, den ich machen will,
den erwähne ich auch schon seit ich eigentlich denken kann. Aber ich habe tatsächlich letzte Woche damit angefangen, das zu programmieren. Und zwar sind es multidimensionale Abfragen. Das heißt, ich will nicht nur wissen, was ist in diesem Polygon, sondern ich will wissen, was war zu dem Zeitpunkt. Ein Beispiel wäre, also jemand, der es unbedingt haben will, ist, der macht Analyse von Satellitendaten.
Und er hat natürlich dann eben, will dann die Satellitendaten von einem bestimmten Polygon haben, will dann aber natürlich von einem bestimmten Zeitraum haben und dann wahrscheinlich noch ein bestimmtes Spektrum und vielleicht noch ein Attribut dazu. Und dann hat es eben in der Welt der multidimensionalen Abfragen. Und es ist aber irrsinnig kompliziert. Deswegen gibt es das auch nicht wirklich, weil das einfach halt ziemlich kompliziert ist.
Und wer von Ihnen vielleicht eine Datenstruktur kennt, die dafür geeignet ist. Es gibt da wirklich viele. Ich habe da irrsinnig viele Papers gelesen. Das Problem ist aber immer, die betrachten immer nur Spezialfälle und sehr selten Geodaten. Und wenn es Geodaten sind, ist es halt immer ja so ein kleiner Spezialfall. Und das andere geht dann schon irgendwie.
Aber ich muss mich natürlich um das andere geht schon irgendwie auch kümmern. Deswegen, als wer da irgendwas weiß, einfach Bescheid geben, ich wäre daran interessiert. So, dann kommen wir jetzt zu einer Übersicht. Was haben wir jetzt bis jetzt alles gehört? Also wir hatten jetzt einen Couchbase Server. Und da gibt es eben Geocouch als Erweiterung. Das ist eben so eingebaut. Genau.
Das wird dann später noch mehr. Das ganze Bild wird voll. Deswegen ist es mal der Einstieg. So, dann kommen wir jetzt zum Eigenlichen. Also der Vortrag war ja angekündigt als Couchbase Mobile. Couchbase Mobile gibt es nicht mehr seit November. Das Teil heißt jetzt Couchbase SyncPoint. Ist auch was ein bisschen anderes. Und zwar ist es so, wir haben festgestellt, dass die meisten Kunden wollen,
wenn sie in der mobilen Welt sind, irgendeine schicke Lösung haben, wie sie eben auch die Daten managen können. Also die wollen nicht nur die Replikation, sondern mehr. Zunächst gehe ich aber drauf ein, was ist auf der untersten Ebene? Jetzt wieder ein toller Neuname. TouchDB. TouchDB, wie der Name schon andeutet, hat das ein bisschen was mit CouchDB zu tun.
Und zwar ist es so, die Replikation ist eben CouchDB kompatibel momentan. Das heißt, ich kann das auf meinem Handy installieren. TouchDB ist im Prinzip eine Datenbank, die läuft auf mein Handy ab. Das, was ich eben am Anfang beschrieben habe, ist das, das läuft wirklich auf dem Gerät, braucht keine Internetverbindung. Da kann ich Daten speichern. Das gibt es bereits für Android und IOS.
Wird eben für beide getrennt entwickelt. Es ist sehr ressourcenschonend und es soll eben schnell starten. Das ist eben das Ziel davon. Da kann ich dann eben auch dieses JSON alles eintragen und so weiter. Und die Replikation läuft eben über das CouchDB-Protokoll ein. Im Prinzip ist es nur einfach über HTTP. Aber das Tolle ist, wenn man CouchDB-kompatibel ist, man kann bereits, wenn man CouchDB macht, dahin replizieren.
Oder eben, wenn man jetzt eine gehostete Couch hat, kann man dahin replizieren und so weiter. Und momentan ist es sogar noch so, dass die anderen Teile, die ich jetzt dann noch vorstelle, die sind gerade in der Entwicklung. Das heißt, momentan tun die Entwickler tatsächlich einfach immer CouchDB-Name dafür. Wenn sie eben Sachen testen wollen.
So, dann haben wir jetzt also CouchDB-Server und TouchDB. CouchDB-Server läuft eben, das ist eben so die serverseitige Komponente. Und TouchDB läuft jetzt nur auf dem kleinen, auf dem mobilen Gerät. CouchDB-Syncpoint ist jetzt eben quasi mehr. Das umschließt dann eben TouchDB.
CouchDB-Syncpoint ist jetzt eine serverseitige und eine kleinseitige Komponente. Das heißt, es geht jetzt um das Zusammenspiel. Weil eine Datenbank, die nur Daten replizieren kann, bringt man nicht viel. Weil man braucht viel mehr. Zum Beispiel so Sachen wie, ich habe jetzt einen Benutzer, der meldet sich bei meinem tollen neuen, also man kann das auch,
also ich mache ein neues Spiel, der meldet sich neu an, will den neuen Account anlegen. Jetzt muss der Server wissen, dass ich einen neuen Account anlege. Wenn ich Daten replizieren will, muss der Account ja schon vorhanden sein. Deswegen muss da ein Schritt dazwischen sein. Und genau das macht CouchDB-Syncpoint. Das heißt, ich kann einfach sagen, lege jetzt mal eine Datenbank an. Oder er kümmert sich um die Authentisierung.
Ein ganz tolles Feature nennt sich Channels. Das bedeutet, ich kann auswählen, welche Daten synchronisiert werden sollen. Das heißt, ich habe jetzt einen großen Datenpool mit Daten und will jetzt aber natürlich auf das mobile Gerät nicht alles überspielen, sondern nur den Teil. Das heißt, ich habe eine Oberfläche, tippe dann ein, was ich haben will.
Und zum Beispiel wieder, das ist Beispiel vom Anfang. Ich habe jetzt Helfer, zum Beispiel, das sind nur Ehrenamtliche. Die dürfen jetzt natürlich keine sensiblen Daten kriegen, sondern nur zum Beispiel die Information, wo können Sie Sunsäcke stapeln? Dann bekommen die eben den Channel, den eigenen, wo sie eben die Daten bekommen, mit wo kann ich Sunsäcke stapeln? Und was ich, der Notarzt, bekommt eben Informationen,
ja, wo gibt es verletzte Personen? Und das wird dann eben über diese Channels gemanagt. Die Heimat also eben Syncpoint, das ist eben Server-seitig und Client-seitig. Und dazwischen stehen eben die Channels. Syncpoint integriert eben mit CouchBase Server. Also auf dem Backend ist ein CouchBase Server, das hat die ganzen großen Daten. Syncpoint macht dann eben einen Teil davon. Und das wird dann eben runtergepliziert in TouchDB.
Dazu ist es eben noch zu sagen, dieses Syncpoint, diese Server-Komponente, ist eben in der Entwicklung, das gibt es noch nicht wirklich. Und dafür werden wir eben momentan CouchDB dafür. So, das Tolle, was viele vielleicht von CouchDB kennen, ist, man kann einfach Apps schreiben, die keine Mittelschicht brauchen. Das heißt, ich nehme nur HTML und Javascript,
weil die API ja eben HTTP ist. Und ich brauch sonst nichts. Das heißt, und da die Daten mal ja auf dem Handy ist und direkt vor Ort verfügbar, kann ich einfach Applikationen schreiben, die funktionieren einfach offline. Ich brauch nichts Zusätzliches. So, und wenn ich jetzt eben so HTML5 Applikationen schreiben will und jetzt im Geo-Bereich arbeite,
will ich natürlich da irgendwie Karten nachstellen. Und dafür bietet sich zum Beispiel MapQuery an. MapQuery ist jetzt eben ein komplett unabhängiges Projekt. Also MapQuery hat mit CouchBase überhaupt nichts zu tun. Das ist ein wenig in meiner Freizeit. Aber das gehört für mich ebenso für die gesamte Vision dazu. Deswegen stelle ich es vor. Also MapQuery, was ist das?
Das ist OpenLayers mit JQuery. Jetzt fragen sich viele, ja, warum wieder was Neues? Im Prinzip ist es ja nichts Neues. Und das ist auch eben, um was es geht. Wir wollen jetzt nicht ein neues Mapping-Dipole bauen, weil da gibt's schon Hunderttausende, die danach, was ich nehme, ein halbes Jahr eingestellt werden. Sondern wir bauen auf OpenLayers, weil das ist schon uralt, funktioniert super gut,
hat viele Entwickler, ja. Deswegen, das Problem ist aber, wenn ich jetzt JQuery verwende, dann muss ich da immer irgendwie so Adapter basteln, dass ich dann irgendwie die Events bekomme und so weiter. Und das machen relativ viele. Und ich habe gedacht, ja, wenn es halt einfach dann ein Projekt geben und es einfach halt JQuery mit OpenLayers verbindet, dann können das einfach alle verwenden und ihr seid zufrieden. Die Entwickler sehen das Ganze eben als sozusagen Geschwister von GeoX.
GeoX verbindet eben XJS mit OpenLayers und wir verbinden eben JQuery mit OpenLayers. Warum? Ich habe es bereits erwähnt, dass man zum Beispiel die Events nativ in JQuery bekommt und dass die API einfacher ist. Weil OpenLayers, wer damit schon mal gewasselt hat, es hat total viel API-Aufrufe,
die Hälfte von ist veraltet und es ist relativ kompliziert für den Einsteiger. Wenn man es mal gemacht hat, so ein paar Jahre lang, dann kommt einem das ganz einfach vor. Aber für Einsteiger ist es immer noch kompliziert. Deswegen einfach eine einfache API. Trotzdem soll man natürlich aber den vollen Zugriff auf OpenLayers haben. Das heißt, wenn es mal was mit JQuery nicht kann, kann ich immer noch das Nativ in OpenLayers machen.
Die API soll einfacher werden, dass man eben schneller einsteigen kann. Die Ziele machen übliche Dinge einfach. Also so was wie, ich habe eine Karte, also die Basemap ist OpenStreetMap, darauf will ich dann meine Features haben und ein Popup, wenn ich draufklicke. Genau darum geht es.
Dann noch ein Punkt des Oberflächenvielfaltes ist, wer schon mal auf eine Webseite kommt und ist irgendwie in ein Geoportal und es verwendet GeoX, man sieht es sofort. Es ist sofort klar, dass es GeoX ist. Und wenn man jetzt in JQuery verwendet, kann man viel leichter eben andere Oberflächen bauen. Also man muss nicht eben dieses typische Aussehen haben.
Und das Wichtigste, was ich bereits erwähnt habe, ich will einfach, dass alle Entwickler, die OpenLayers mit JQuery verbinden, wenn das irgendwer jetzt hier im Auditorium macht, bitte einfach mal anschauen, ob Webquery das ist, was sie vielleicht haben wollen. Sie sparen sich im Code und wenn wir ihnen zusammenhelfen, wird das Ganze eben viel besser. Außerdem ist zu sagen, das Webquery ist noch hier im Anfangsstadium, bald kommt die Version 0.2.
Und wenn sie jetzt irgendwelche Änderungen haben wollen und bessere Ideen haben, einfach sagen, man kann das noch alles umschmeißen. Das ist überhaupt kein Problem. So, jetzt noch kurz ein Beispiel. Ich habe fast ein bisschen Zeit habe ich noch. Ich gehe da ein bisschen schnell durch, aber es ist eben auch super einfach. Deswegen kann ich da auch schnell durchgehen. Und zwar, ich will eine Karte haben. Das ist jetzt typisch JQuery nur.
Ich will jetzt einfach, ich habe das Dom-Objekt von der Karte und sage jetzt, okay, darf ich jetzt eine Karte sehen haben. Also die MapQuery-Funktion starten. Und ich sage jetzt, ich will OpenStreetMap sehen. Das wäre jetzt schon eine vollwertige Karte. Wenn ich jetzt zum Beispiel noch haben will, dass ich da jetzt in Dessau, dass Dessau angezeigt wird, sage ich, okay, Center, also die Position,
gebe ich an, dann Zoom-Level Stufe 12, fertig. Fertig ist die Karte. Wenn ich jetzt zum Beispiel mit dem Events, das habe ich bereits erwähnt, ich habe eben eine Tiefe JQuery-Events, das heißt, ich nehme einfach, da muss ich jetzt das MapQuery-Objekt nehmen. Es ist so, ich kann nicht nur auf dem Dom arbeiten, weil ich brauche mehr Informationen als jetzt nur diesen HTML-Knoten. Und da ist es, das MapQuery-Objekt
ist eben im Data gespeichert. Das hole ich mir einmal raus, kann jetzt Events binden und sagen, wenn ein Layer hinzugefügt wurde, dann mache ich irgendwas. Zum Beispiel mache ich einen Halbtransparent, genau. Oder die API, die Idee dahinter ist, das Mindest einfach zu machen. Das heißt nicht 100.000 Funktionen,
sondern eben eher so JQuery-mäßig. Das heißt, ich bekomme so zum Beispiel alle Ebenen, also MapQuery-Objekt, Punkt Layers, ich bekomme alle Ebenen. Will ich eine Ebene hinzufügen, mache ich einfach Layers und gebe eine Ebene rein. Hier zum Beispiel wieder JSON, ich füge eine neue Ebene hinzu. Die API ist eben relativ einfach zu merken,
weil ich mache einfach immer Punkt, ohne Argumente bekomme ich es, Punkt mit Parameter setze ich es, wie eben bei JQuery auch. So, das letzte Beispiel schneide ich nur kurz an. Wenn ich zum Beispiel noch Zoom-Buttons haben will, weil standardmäßig kann eben MapQuery gar nichts, stellt nichts da, hat nur die Karte.
Wenn ich Zoom-Buttons haben will, kann ich einfach, okay, das Objekt auf ein Dom-Element, wo ich den Zoom-Buttons haben will, da füge ich die hinzu. Natürlich muss ich denen noch sagen, welche Karte das ist, weil ich könnte ja mehr Karten auf meiner Seite haben. Und dann füge ich das so hinzu. So, das Beispiel überspringe ich jetzt, weil es sonst zu lang wird. Und jetzt noch kurz etwas vergesse ich immer zu sagen,
weil für mich ist das vollkommen klar, aber natürlich ist alles open source. Couch-Space-Komponenten verwenden die Apache-Lizenz und MapQuery steht unter der MIT-Lizenz. Vielen Dank für die Aufmerksamkeit.