Client Side Map Rendering
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 71 | |
| 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/14814 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
MappingClient (computing)Web browserCanvas <Programm>SVGWeb browserVector graphicsSmart cardSpeciesOpen setProgramming languagePixelClient (computing)Server (computing)PolygonSVGArtistic renderingOpenGLCanvas <Programm>JavaScriptHTML 5.0Computer animationJSONXMLProgram flowchart
03:27
Canvas <Programm>Single-precision floating-point formatGeometryJavaScriptBefehlsprozessorSmart cardCanvas <Programm>Lecture/ConferenceXMLComputer animation
03:49
GeometryJavaScriptCanvas <Programm>Single-precision floating-point formatLocal area networkArtificial neural network9 (number)Canvas <Programm>Web browserZahlUser interfaceComputer animationJSONXML
04:26
Artificial neural networkBookmark (World Wide Web)InternetArtistic renderingComputer animation
04:49
Canvas <Programm>Single-precision floating-point formatGeometryJavaScriptBefehlsprozessorJavaScriptCodeScripting languageThread (computing)Computer animation
05:35
Artificial neural networkCanvas <Programm>Computer animation
05:58
GeometryJavaScriptData centerCross-site scriptingMappingSVGKompressionUniformer RaumHTTPArtificial neural networkMaxima and minimaWeb browserState of matter
06:42
MappingCross-site scriptingSVGKompressionFactorizationComputer animation
07:09
Computer animation
07:31
OpenGLGraphical user interfaceFirefox <Programm>Device driverMappingArtificial neural networkUniform resource nameSimulationSound <Multimedia>World Wide WebUser interfaceJavaScriptiPhoneGoogle Web ToolkitRandPropositional formulaCodeDemosceneMobile WebArtistic renderingOpenGLWINDOWS <Programm>Internet ExplorerCodeMappingDirectXComputer animation
09:38
MappingMaxima and minimaUser interfaceArtistic renderingOpen sourceComputer animationInternet
10:21
Artificial neural networkUser interfaceRobotInternetVariable (mathematics)Server (computing)Client (computing)Computer animation
11:00
Vector graphicsClient (computing)Normal (geometry)Open sourceProcessing <Programmiersprache>Plug-in (computing)ClippingComputer fileCache (computing)Binary codeBinary fileXML
12:15
JSONXMLUML
12:51
GRADEComputer animationCache (computing)Computer animation
13:16
Texture mappingForm (programming)State of matterPixelComputer hardwareOpenGLComputer fontRaster graphicsComputer animation
14:14
Hidden Markov modelGraphical user interfacePixelFunction (mathematics)EckeComputer animation
14:59
Traffic shapingUnicodeComputer fontCodeComputer fontUnicodeTexture mappingComputer animation
16:22
ALI <Programm>Computer animationLecture/Conference
16:43
Computer animationLecture/Conference
17:04
Artistic renderingMappingXMLComputer animation
17:29
NumberComputer animation
18:10
Client (computing)Server (computing)Alphabet (computer science)Lecture/ConferenceComputer animation
19:07
MappingSmartphoneClient (computing)Motif (narrative)Object (grammar)Server (computing)SoftwareInternetInterface (computing)iPhonePDF <Dateiformat>ImplementationC++Open sourceRoutingVector graphicsMoment (mathematics)Lecture/Conference
23:32
Computer animation
Transcript: German(auto-generated)
00:07
Ja, hallo. Ich bin Konstantin Käfer. Ich arbeite für Mapbox und ich habe mich in den letzten Monaten damit beschäftigt, Karten nicht auf dem Server zu rendern.
00:20
Nicht auf dem Server heißt, im Browser oder auf mobilen Geräten. Und heute will ich hauptsächlich über das Rendering im Browser reden. Weshalb machen wir das überhaupt? Bisher funktioniert das doch ganz gut, wenn wir einfach auf dem Server rendern. Aber es gibt ein paar Vorteile. Ein Vorteil ist, dass die Daten möglicherweise kleiner
00:43
sind, wenn wir keine Pixeldaten vom Server zum Client schicken, sondern nur die Vektordaten. Der zweite Vorteil ist, dass wir uns dann auf dem Client entscheiden können, wie das Ganze aussehen soll, ohne jedes Mal ein neues Bild zu generieren. Und der dritte Vorteil ist, wir haben die Daten auf dem Client. Das heißt also, wir können direkt mit diesen Daten interagieren.
01:02
Also ich kann auf ein Gebäude draufklicken und mir anzeigen lassen, welche Hausnummer dieses Gebäude hat oder ich kann eine Straße markieren und so weiter. Warum hat man das bisher noch nicht gemacht? Gucken wir uns mal die Technologie an. Dazu gibt es zwei Grundarten, wie man Karten oder allgemein Dinge rendern kann.
01:25
Einmal auf der CPU und einmal auf der GPU. Die GPU ist der Graphic Chip, der in fast allen Geräten eingebaut ist. Auf der CPU bedeutet das, man hat einfach eine ganz normale CPU, schreibt C-Code oder was auch immer für eine Programmiersprache,
01:43
die dann nach und nach jedes einzelne Pixel mit einem bestimmten Wert füllt und zeigt das dann am Ende irgendwie auf dem Bildschirm an. Auf der GPU, die funktioniert ein bisschen anders. Da hat sich ein Modell durchgesetzt und zwar ist das OpenGL.
02:03
Und da funktioniert das ein bisschen anders. Man schickt also quasi diese ganzen Geometrien, also Linien, Polygone zur GPU und sagt das dann für jeden Pixel in diesem Polygon, das soll so und so aussehen. Wenn wir uns die verschiedenen Techniken angucken, haben wir einerseits CPU-basierte Renderer, wie zum Beispiel Ag.
02:24
Antigrain Geometry ist das. Das ist auch der Renderer, auf dem MAPNIC basiert. MAPNIC ist der Renderer von OpenStreetMap.org. Aber Ag, MAPNIC kann man eigentlich nicht im Browser verwenden, erstmal. Im Browser gibt es eine API, die nennt sich Canvas.
02:42
Das HTML5 Canvas ermöglicht es einem einfach, beliebige Polygone, Text, Linien, Punkte im Browser zu zeichnen. Man hat einfach eine Pixelfläche und kann dann darauf zeichnen. Aber es gibt eigentlich schon was im Browser, mit dem man Vektordaten, zum Beispiel Kartendaten, zeichnen kann und zwar SVG.
03:02
SVG ist einfach eine XML-Sprache, mit der man Polygone beschreiben kann, die dann im Browser angezeigt werden. Die kann man mit CSS beschreiben und so weiter. Und seit kurzem, seit so zwei, drei Jahren, gibt es WebGL. WebGL ist eine Möglichkeit für den Browser, also aus JavaScript heraus,
03:23
die GPU, den Rendering-Chip, der in jedem Computer eingebaut ist, anzusprechen und direkt zu nutzen, ohne großartige Umwege. Aber wir gucken uns die ganzen einzelnen Sachen langsam nochmal an. Zu Canvas gibt es natürlich ein paar Beispiele. Das haben Leute schon ausprobiert, damit Karten zu zeichnen.
03:41
Das bekannteste ist vielleicht GothicJS. Die zeichnen einfach, dann machen wir das mal so, dann kann ich hier auch sehen, was da los ist. Okay, GothicJS sieht so aus, die renden hier die Karte, das wird alles mit Canvas gezeichnet im Browser.
04:02
Kann man machen, ist aber relativ langsam, weil das Ganze erst mal Single-Threaded ist. Das heißt also, man kann nur eine Zahl gleichzeitig machen. Ich kann entweder mal eine Karte zeigen oder ich kann dem Benutzer erlauben, mit der Benutzeroberfläche zu interagieren. Das heißt also, während er die Karte zeichnet, kann man irgendwie zum Beispiel die Karte nicht verschieben.
04:21
Das funktioniert einfach nicht. Ich habe das auch nochmal ausprobiert, ich habe das auch mal ein bisschen nachprogrammiert. Das Ganze hier ist auch ein Canvas-basierter Renderer. Der lädt einfach Vektor-Dateien aus dem Internet runter. Das ist jetzt irgendwie London City, da sieht man nicht alle Features drauf, aber so ein bisschen kann man schon sehen.
04:40
Und man sieht immer, das geht einigermaßen gut, aber das stockt auch immer schon so ein bisschen. Wenn der hier rumschiebt, funktioniert das also nicht so super perfekt. Eine zweite Möglichkeit, die ich ausprobiert habe, ist einfach Act zu nehmen. Und Act ist erst mal C++, aber mit einem Scripten kann man das nach JavaScript kompilieren, so wie ich es getan habe.
05:02
Und dadurch kann man das auch im Web-Browser laufen lassen. Act ist wie gesagt genau dieser Renderer, den auch Mapnik verwendet, Inter. Der Vorteil davon ist, dass man diesen Code dann nicht mehr die Canvas-API verwendet, sondern der macht einfach nur JavaScript-Kalkulationen und den kann man auch in einen Web-Worker reinschieben.
05:22
In einem Web-Worker, der läuft in einem anderen Thread. Das heißt also, man kann irgendwie fünf verschiedene Threads gleichzeitig aufmachen, die dann mehr Kartenteils gleichzeitig rendern, ohne die UI zu blockieren. Das funktioniert hier auch, das funktioniert aber auch nicht so toll. Man sieht, das ist irgendwie noch langsamer ein bisschen, aber es ruckelt auch,
05:43
weil der eben einfach ganz viele Magie im Hintergrund machen muss, um die Pixel-Daten, die dann in einem Web-Worker entstehen, wieder in ein Canvas rein zu bekommen, weil nur in Canvas kann man solche Pixel-Daten anzeigen. Also es ist auch langsam, es ist ein bisschen blöd.
06:01
SVG ist auch eine valide Option, haben auch schon Leute ausprobiert. Das ist jetzt ein Beispiel. Das sind hier einfach SVG-Bilder in Leaflet. Weil die meisten Browser unterstützen inzwischen auch statt einem PNG-Image oder JPG-Image,
06:22
einfach ein SVG-Image anzugeben, dass dann an dieser selben Stelle einfach gerendert wird. Das heißt also, wenn ich jetzt hier reinzoome, das sind genau dieselben Teils, dann wird das hier angezeigt. Das Styling verändert sich jetzt nicht, deswegen ist es ein bisschen doof, aber man sieht, man kann hier willig weit reinzoomen und muss keine neuen Daten nachladen.
06:43
Da gibt es natürlich auch ein paar Nachteile wieder. Das ist auch relativ langsam, weil es schwierig ist, SVG-Daten zu rendern. Und SVG-Teils sind auch ziemlich groß, weil da ganz viel XML-Markup noch dabei ist und es einfach nicht super effizient zu komprimieren ist. Man kann es einigermaßen komprimieren, im Faktor 18, 15, je nachdem wie die Daten sind,
07:04
aber das sind dann trotzdem noch irgendwie 50, 100, 200 Kilobyte für eine Teil. Der ID-Editor von OpenStreetMap.org verwendet auch SVG, um das Ganze anzuzeigen. Und es haben vielleicht manche Leute von euch schon festgestellt, dass es ein bisschen langsam ist.
07:22
Manchmal hackt das ziemlich. Auch wenn man einen Computer verwendet, der nicht ganz so langsam ist, dann ist das nicht immer super toll zu benutzen. Schließlich WebGL. WebGL ist eine API im Browser, die auf OpenGL ES 2.0 basiert. Das ist so eine Art Subset von OpenGL 2, das besonders auf die Verwendung auf mobilen Geräten optimiert ist.
07:48
Also im Prinzip alle mobilen Geräte, iPhones, Android-Telefone, können OpenGL ES 2.0 rendern. Es funktioniert inzwischen auch in erstaunlich vielen Browsern, sogar im Internet Explorer 11.
08:02
Aber es ist leider deaktiviert auf iOS. Auf vielen Android-Telefonen ist es auch nur so halb aktiviert. Und in Safari ist es auch deaktiviert. Aber das hängt uns erst mal nicht dran, das auszuprobieren, weil es hat ein paar Vorteile. Ich kann eben diese GPU einfach verwenden.
08:22
Es ist nicht ganz einfach zu programmieren. Und der größte Nachteil davon ist wahrscheinlich, dass es ganz, ganz viele unterschiedliche Geräte gibt, auf denen das mehr oder weniger gut läuft. Insbesondere unter Windows ist es immer so ein bisschen problematisch. Die müssen dann noch alle möglichen Tricks reinmachen, wie diese ganzen OpenGL Codes auf die DirectX API zu übersetzen.
08:43
Das funktioniert auch einigermaßen. Aber es ist trotzdem immer so ein bisschen unwerkbar. Besonders wenn man einen Computer hat, der irgendwie zwei, drei, vier Jahre alt ist, dann funktioniert das vielleicht schon nicht mehr so gut. Da gibt es auch ein paar Leute, die das schon ausprobiert haben.
09:00
Die beeindruckendste Demo ist wahrscheinlich Open Science Map. Von dem Lehrstuhl für Kognitionsforschung, glaube ich, in Bremen. Und was sie gemacht haben, sie haben das ganze Ding in Java programmiert und dann mit Google Web Toolkit nach JavaScript kompiliert. Und ich kann hier, das funktioniert mit dem Maustrad immer nicht so gut, aber doch einigermaßen.
09:25
Und was man jetzt hier sieht, das sind alles Vektordaten, die geladen werden und dann angezeigt werden. Ich kann das Ganze auch irgendwie, ja, keine Ahnung. Dann Mike McGursky hat sich damit auch beschäftigt.
09:44
Und wir von Mapbox haben auch einen Renderer gebastelt. Der ist momentan noch nicht Open Source, der wird aber in den nächsten paar Wochen Open Source. Und wir hoffen, dass sich da auch Leute an der Entwicklung beteiligen. Und das Ganze sieht erst mal so aus. Also wir haben hier ähnlich, wir laden hier einfach diese Vector-Teils im Hintergrund runter.
10:07
Und man kann hier also beliebig reinzoomen. Man kann das Ganze auch drehen. Wir haben hier Labels, Beschriftungen. Ich kann hier auch den Style einfach verändern. Mit Animation und so weiter kann ich auch Satellitenbilder stattdessen einblenden.
10:22
Mal, dass das Internet hier einigermaßen funktioniert. Nee, funktioniert offenbar nicht. Und ich kann hier auch die Farben verändern. Zum Beispiel, wenn ich sagen will, das Wasser soll nicht blau sein.
10:42
Ich gehe mal ganz raus dazu. Das Wasser soll nicht blau sein. Kann ich das auch einfach hier machen. Und es wird sofort direkt aktualisiert, ohne dass ich das Ganze auf einem Server neu rendern muss. Dadurch kann man das Ganze auch animieren und so weiter.
11:02
Und um diese Sachen, diese Daten auf dem Client zu rendern, muss man erst mal Daten zum Client hinbekommen. Die erzeugen, und das machen wir mit solchen sogenannten Vector-Kacheln. Also statt ganz normalen Bildkacheln, wie es hier jeder kennt, packen wir eine Datei mit diesen ganz normalen
11:21
Spherical Mercator-ZXY-Beschriftungen bzw. Dateinamen, die Daten einfach rein. Und zwar in einem Protocol-Buffer-Format. Also es ist ein binär codiertes Format, das wir im Browser parsen. Das funktioniert auch super schnell, das ist nicht das Problem. Und erzeugen, tun wir das Ganze mit MAPNIC.
11:42
Und zwar haben wir einfach ein Plugin geschrieben für MAPNIC, das ist auch Open Source. Das kannst du hier auch einfach runterladen und verwenden, installieren. Das statt Bilddaten zu generieren, einfach diese Binärdaten rausschreibt. Und dann hat man eben den Vorteil, dass man MAPNIC verwenden kann, um dieses ganze Processing zu machen.
12:03
Also das Clipping auf die einzelnen Bereiche, dann dieses ganze Datenbankzugriff, die Vereinfachung usw. Also das alles macht MAPNIC für uns und erzeugt diese Vector-Kacheln. Es gibt noch ein paar andere Leute, die es auch probiert haben. Tiles Dash ist zum Beispiel hier so ein Beispiel.
12:25
Zum Text-Rendering. Text-Rendering hört sich erstmal so ein bisschen einfach an. Also wir müssen also Buchstaben anzeigen. Aber das ist es nicht. Und zwar müssen wir diese Buchstaben in allen beliebigen Rotationen anzeigen. Wenn wir eine Straße beschriften entlang dieser Straße, müssen diese Buchstaben ja gedreht sein.
12:45
Wenn man dann die Karte noch weiter drehen kann, dann funktioniert das nicht mehr, dass wir zum Beispiel FreeType verwenden, um das zu rendern. Und dann einfach nur die Pixel-Daten anzeigen. Weil wir das Ganze irgendwie 60 Mal pro Sekunde machen müssen, damit die Animation flüssig ist.
13:01
Und das packt FreeType einfach nicht. Auch wenn das Caching funktioniert in dem Fall nicht wirklich, weil wenn wir einfach einen Grad weiter rotieren, dann müssen wir schon komplett alle Glyphen neu zeichnen. Und das funktioniert einfach nicht in den 16 Millisekunden, die wir Zeit haben, um einen Frame zu rendern. Deswegen verwenden wir eine Technologie.
13:22
Die nennt sich Sign Distance Fields. Die ist von Valve entwickelt worden. Und die funktioniert ungefähr so. Statt einem Pixelbild von einem Glyphon erzeug ich mir so ein Distance Field. Und da wird in jedem Pixel einfach die Distanz zur Outline gespeichert, anstatt der eigentliche Farbwert.
13:44
Das können wir dann, wenn wir das Ganze mit OpenGL skalieren, sieht es ungefähr so aus. Weil es irgendwie interpoliert und dann solche schönen Übergänge uns liefert. Und das ist im Prinzip gratis auf der Hardware. Also es hat keine Performancekosten. Und was wir dann einfach machen, ist ein Alpha-Testing.
14:00
Das heißt also, wir gucken, wo überschreitet der Helligkeitswert, den wir hier haben, einen bestimmten Grenzwert. Und alles, was heller ist, zeigen wir in weiß an. Und alles, was dunkler ist, zeigen wir einfach in schwarz an. Und dadurch bekommen wir diese Glyphen. Sehen wir hier, hier ist der Text.
14:21
Und ich mache das mal andersherum, dass man das ein bisschen... Ach so, das sieht man auch nicht besser. Und wir können den beliebigen skalieren, indem wir einfach hier das hochziehen. Man sieht hier, langsam gibt es ein bisschen Artefakte, weil das alles von Pixeldaten gerendert wird. Und wenn wir das Ganze deaktivieren, sieht das ungefähr so aus.
14:41
Also hier schalten wir einfach den Alpha-Test ab. Und dadurch bekommt man die Möglichkeit, eben einfach Glyphen mit einfach nur zwei, drei Ecken zu zeichnen. Und nicht jedes Mal komplett von dieser Polygon-Beschreibung der Glyphen das Ganze neu zu renderen. Das zweite Problem, was ich auch nicht auf dem Schirm hatte, bevor ich mich damit beschäftigt habe, war das Text-Shaping.
15:08
Jetzt könnte man denken, wir haben hier irgendwie ein Label, irgendwie der Straßenname. Und der besteht aus einer Sequenz an Unicode-Charakteren. Und wir zeigen einfach den entsprechenden Glyphen aus dem Font an, der zu diesem Unicode-Charakter dazu gehört.
15:23
Aber das funktioniert nicht, weil das nämlich gar nicht stimmt. Es gibt nämlich kein 1 zu 1 Mapping zwischen einem Unicode-Zeichen und so einem Font-Glyphen, was in einem Font drinnen ist. Das gibt es vielleicht in den meisten westlichen, in den meisten latein-basierten Sprachen. Aber wenn wir dann zu solchen Sachen kommen wie den hier, dann funktioniert das nicht mehr.
15:47
Wenn wir uns hier dieses Wort Sophos angucken, in Unicode wird das so geschrieben. Dieses erste Symbol, das zweite, dritte, vörte und dann wieder das erste. Weil das erste und das letzte eigentlich das gleiche Symbol. Das ist einfach ein S mehr oder weniger.
16:03
Aber jetzt gibt es die Regel, dass wenn dieses Zeichen an letzter Stelle ist, dann wird das anders angezeigt. Und zwar eben in dieser Art und Weise. Das heißt also, wir haben ein Unicode-Zeichen. Das ist immer genau dasselbe. Aber basierend darauf, wo das in einem Wort vorkommt, müssen wir es unterschiedlich anzeigen.
16:22
Das Ganze geht noch ein bisschen weiter, wenn wir Sprachen haben wie Arabisch. Die werden von rechts nach links geschrieben. Aber der Unicode-Stream ist trotzdem in logischer Reihenfolge. Das heißt also, das erste Zeichen hier, dann kommt das zweite Zeichen im Unicode-Stream.
16:42
Das wird aber so von hier angezeigt. Das heißt also, wir müssen das Ganze erstmal umkehren. Im Lateinischen gibt es dann auch noch kontextabhängige Ersetzungen. Nicht im Lateinischen, im Arabischen gibt es nur noch kontextabhängige Ersetzungen. Das heißt also, wenn ein Buchstabe oder ein Symbol an der ersten, zweiten, dritten Stelle in einem Wort ist,
17:00
dann sieht das immer anders aus oder wird zu so einem Art Skript verbunden. Das nächste Problem ist zum Beispiel bidirektionaler Text. Das heißt also, wir haben nicht immer eine Schreibrichtung. Also wenn wir irgendwo eine Straßenname mit einer Hausnummer haben, dann müssen wir da mehrere Schreibrichtungen unterstützen in unserem Map Renderer.
17:21
Das heißt also, wir müssen einen Teil von dem Text rechts nach links schreiben, dann andere Teile wieder von links nach rechts und dann wieder weiter von rechts nach links. Dann gibt es noch ganz abgefahrene Sachen, wie zum Beispiel diakritische Zeichen, die man stapeln kann. In einem Unicode-Stream ist es auch einfach so linear abgebildet,
17:42
aber dadurch, dass die in einem Kontext von einem anderen Zeichen stehen, wird klar, dass die alle übereinander gestapelt werden. Bei einem ist es immer noch relativ einfach, weil man das Unicode, den Glyphen in dem Fond so basteln kann, dass er dann an der richtigen Stelle erscheint. Aber wenn man schon zwei übereinander stapeln will, dann muss man dieses zweite diakritische Zeichen noch höher oder weiter runter schieben als das erste,
18:04
weil es sonst sich einfach überlagern würde, wie man das zum Beispiel hier sieht. Das heißt also, das hier ist nicht richtig, aber das ist richtig, weil hier dieses Zeichen, dieser Kringel hier einfach nach unten verschoben wird, weil da oben schon was im Weg ist.
18:22
Das machen wir, indem wir das Ganze auf dem Server trotzdem noch verarbeiten. Das heißt also, es stimmt nicht ganz, dass es nur auf dem Client ist, weil wir den Server noch zur Unterstützung brauchen, eben um genau das zu machen, um uns zu sagen, wo kommen welche Glyphen hin. Das heißt also, das können wir nicht auf dem Client machen,
18:41
dafür gibt es Libraries, die auf dem Server funktionieren, die können wir jetzt auch kompilieren nach JavaScript, aber das ist super aufwendig, weil wir dann noch den ganzen Fond parsen müssen. Und wenn es dann in Alphabete geht, wie zum Beispiel Mandarin oder sowas, da gibt es 20.000 Sachen, das Fond ist halt 15 Megabyte groß. Und da müssen wir erstmal 15 Megabyte runterladen vom Server,
19:02
um überhaupt eine Karte anzuzeigen. Das ist auch nicht gut. Deswegen machen wir das noch auf dem Server. Ja, das war es erstmal. Gibt es noch Fragen?
19:21
Ich würde sagen, vor den Fragen kommt der Applaus. Ich habe irgendwie mitgenommen, Buchstaben sind böse. Das habe ich irgendwie schnell mal vermutet. Ja, Fragen? Hier vorne sich eine Frage? Ja, das hört sich ja an, als wenn es ganz gut gereignet wäre für Navis, die offline arbeiten möchten. Daher die Frage, wie verträgt sich das mit Smartphones?
19:46
Die kann ich beantworten, und zwar dahingehend, dass dieses Moment eine Implementierung, die ich auch gezeigt habe, die auch bald veröffentlicht wird in den nächsten Wochen, ist halt eben WebGL basiert.
20:02
Dann brauchen wir erstmal ein Smartphone, das WebGL unterstützt. Wenn man sich die ganzen iOS-Geräte anguckt, die tun das nicht. Das heißt also, die einzige Möglichkeit, das Ganze auf einem Smartphone, wie zum Beispiel einem iPhone, einzusetzen, ist das Ganze in C++ zu schreiben oder in Objective-C.
20:21
Und so weit sind wir noch nicht. Aber das ist prinzipiell schon denkbar. Oder wenn man ein Smartphone findet, da gibt es wahrscheinlich auch einige Android-Smartphones, die das können, ist dann die Frage, wie schnell das Ganze angezeigt wird. Darüber kann ich keine Aussage treffen, weil ich das noch nicht ausprobiert habe. Okay, hier vorne war eine Frage, sonst irgendwo noch.
20:47
Wenn man die Daten jetzt mal wegen die Welt sich anguckt, dann muss er ja irgendwann entscheiden, welche Daten muss ich jetzt übertragen vom Server zum Client, damit die gerendert werden. Er jagt ja nicht die ganze Welt durch, er macht das. Das funktioniert genauso wie bei Pixel-Tiles.
21:03
Das heißt also, wenn ich auf dem Zoom-Level 0 bin, dann holt er sich eine Vektor-Teil für Zoom-Level 0, eben 000. Wenn ich irgendwie auf dem Zoom-Level 13 bin, dann holt er sich die entsprechenden Vektor-Tiles für das Zoom-Level 13 an der Stelle, an der der Benutzer ist.
21:22
Aber anstelle von Pixel-Tiles sind das eben Vektor-Tiles. Das kommt darauf an, wo man die Daten herbekommt. Wir haben intern bei uns einen Vektor-Tile-Server, aber die ganze Software, um das zu produzieren, die liegt auch Open Source auf unserem GitHub-Account.
21:45
Ich weiß nicht, inwiefern das irgendwann mal ein Angebot ist. Es gibt, glaube ich, auch auf OpenStreetMap.org gibt es auch Vektor-Tiles. Ich weiß gar nicht, was das für ein Format ist. Da bin ich mir unsicher. Ja, das ist PBF, aber PBF ist im Prinzip genauso wie XML.
22:00
Da muss man erst mal wissen, wie man das Ganze parsen muss. Ich weiß nicht, inwiefern das kompatibel ist. Aber es gibt mehrere Dienste, die sowas anbieten. Ja, gerade wurde Routing ja schon angesprochen. Was ich mich frage, wenn die Vektordaten gekachelt ausgeliefert werden, dann werden ja Relationen auch aufgeschnitten
22:22
und quasi schon irgendwo verändert. Findet da irgendwo eine Operation noch mal statt, dass Objekte wieder nachher ein sind oder bleiben die zerschnitten, sodass sich nicht wirklich ein Routing auf solchen Daten machen kann? Das ist eine sehr gute Frage. Und die Antwort dazu ist, wir fügen diese Objekte nicht zusammen.
22:41
Das heißt also, die bleiben einfach auseinander geschnitten bzw. gekroppt oder sowas. Und wir verwenden diese Daten nur zur Anzeige. Das heißt also, an einem Rand, wo man diese Schnittstelle sehen würde, da rendern wir einfach schon die nächste Kachel hin, die das dann überlagert. Theoretisch ist es denkbar, dass man diese Objekte wieder zusammenfügt,
23:04
insbesondere bei Straßen, weil ja in diesen Vektordaten auch die OSM-ID drin steht. Das machen wir aber momentan nicht. Aber es ist prinzipiell möglich, das zu tun. Okay, dann würde ich sagen, machen wir erst mal Schluss mit den Fragen. Du bist ja hier noch weiter erreichbar.
23:22
Okay, dann vielen Dank für den Talk.