DE202014010936U1

DE202014010936U1 - Effizientes Abrufen von Kartenkacheldaten

Info

Publication number: DE202014010936U1
Application number: DE202014010936.2U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2013-05-15
Filing date: 2014-05-15
Publication date: 2017-01-23
Anticipated expiration: 2024-05-16
Also published as: US20140344296A1; EP2997503A1; CN105339938A; WO2014186506A1; US9201898B2

Abstract

Computergerät für das effiziente Abrufen von Kartenkacheln, wobei das Computergerät Folgendes umfasst: einen oder mehrere Prozessor(en); und einen Speicher oder mehrere Speicher, der oder die an einen Prozessor oder mehrere Prozessoren gekoppelt ist oder sind; worin der eine oder die mehreren Speicher darin gespeicherte computerausführbare Anweisungen beinhalten, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen: Empfangen, über eine Benutzeroberfläche, einer Anfrage zur Anzeige einer digitalen Karte; Identifikation, mit einem oder mehreren Prozessoren, einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen; Erstellung einer einzelnen Karteninhaltsanfrage einschließlich zahlreicher Kennungen, die der Vielfalt von Kartenkacheln entsprechen; Kommunikation, über ein Computernetzwerk, der Karteninhaltsanfrage an einen Server; Als Antwort auf die Karteninhaltsanfrage Empfangen, über das Computernetzwerk, der Vielfalt von Kartenkacheln vom Server; und Anzeige, über die Benutzeroberfläche, der digitalen Karte auf der Grundlage der Vielfalt von Kartenkacheln.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf die Anzeige digitaler Karten auf Client-Geräten und insbesondere auf das Anfragen und den Abruf von Karteninhalt für das Anzeigen digitaler Karten. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
HINTERGRUND
Die hierin angegebene Hintergrundbeschreibung soll den Kontext der Offenbarung allgemein darstellen. Die Arbeit der vorliegend genannten Erfinder, in dem Umfang, wie sie in diesem Hintergrundabschnitt beschrieben ist, sowie Aspekte der Beschreibung, die zum Zeitpunkt der Anmeldung sonst möglicherweise nicht als Stand der Technik qualifiziert sind, werden weder ausdrücklich noch stillschweigend als Stand der Technik gegenüber der vorliegenden Offenbarung anerkannt.
Digitale Karten werden häufig durch die Anordnung eines Satzes von Kartenkacheln (z. B. Bilder mit 256×256 Pixel) erstellt. Der Inhalt der Kartenkacheln kann Schattierungen, Farben, Straßen, Navigationsstrecken, Kennzeichnungen, Markierungen, Gebäudeumrisse usw. entweder in Raster-, Vektor- oder kombinierten Bildformaten beinhalten. Nach dem Empfangen einer geographischen Abfrage oder einer sonstigen Eingabe von einem Benutzer ermittelt eine Kartenanwendung die relevanten Kartenkacheln, die erforderlich sind, um eine digitale Karte anzuordnen, und fordert die notwendigen Kartenkacheln von einem Server an (d. h. die Kartenanwendung „holt” die Kartenkacheln).
Derzeit rufen ein Browser oder eine Kartenanwendung jede Kartenkachel separat über einzelne Hypertext-Transfer-Protocol(HTTP)-Anfragen für jeden rechteckigen Teil einer digitalen Karte ab, die in einem Kartenansichtsfenster angezeigt wird. Jedoch kann ein typischer Browser nur eine begrenzte Anzahl an gleichzeitig ausstehenden HTTP-Anfragen haben. Außerdem trägt das Senden einer Anfrage für jede Kartenkachel erheblich zum Kommunikationsaufwand der Übertragung von Kartendaten bei.
ZUSAMMENFASSUNG
Die Techniken dieser Offenbarung ermöglichen es, dass die für die Anordnung einer digitalen Karte benötigten Kartenkacheln effizienter von einem Karteninhaltsserver abgerufen werden, indem Anfragen nach verschiedenen Kartenkacheln einer digitalen Karte so gruppiert werden, dass sie in einer einzigen Inhaltsanfrage angezeigt werden, die hier auch als eine „Mehrkachel”-Anfrage bezeichnet wird. Eine einzelne Inhaltsanfrage an den Karteninhaltsserver kann eine Identifikation zahlreicher Kartenkacheln beinhalten, so dass mehrere Kartenkacheln abgerufen werden, ohne dass zahlreiche Inhaltsanfragen notwendig sind. Die in der Mehrkachel-Inhaltsanfrage ermittelten Kartenkacheln machen gewöhnlich einen aneinandergrenzenden Teil der digitalen Karte aus. Jedoch kann jeder Satz von Datenkacheln durch Senden einer Mehrkachel-Anfrage an den Server geholt werden, wobei die Mehrkachel-Anfrage eine Identifikation einer Referenzkartenkachel und eine Identifikation der mit der Referenzkartenkachel verbundenen mehreren anderen Kartenkacheln beinhaltet.
Gemäß einer Implementierung umfasst ein computerimplementiertes Verfahren für das Abrufen von Kartenkacheln für digitale Karten das Empfangen, über eine Benutzeroberfläche, einer Anfrage zur Anzeige einer digitalen Karte, die Identifikation, mit einem Prozessor, einer Vielfalt von Kartenkacheln, wobei jede einen Teil der digitalen Karte darstellt, und die Erstellung einer einzelnen Karteninhaltsanfrage mit zahlreichen Kennungen, die der Vielzahl der Kartenkacheln entsprechen. Des Weiteren umfasst das Verfahren die Kommunikation, über ein Computernetzwerk, der Karteninhaltsanfrage an einen Server, das Empfangen, als Antwort auf die Karteninhaltsanfrage, über das Computernetzwerk, der Vielfalt von Kartenkacheln von dem Server, und die Anzeige, über die Benutzeroberfläche, der digitalen Karte auf der Grundlage der Vielzahl von Kartenkacheln.
Gemäß einer weiteren Implementierung umfasst ein Computergerät für das effiziente Abrufen von Kartenkacheln einen oder mehrere Prozessoren und einen oder mehrere Speicher, die an einen oder mehrere Prozessoren gekoppelt sind, worin der eine oder die mehreren Speicher darin gespeicherte computerausführbare Anweisungen beinhalten, die wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, dazu führen, dass der eine oder die mehreren Prozessoren über eine Benutzeroberfläche eine Anfrage zur Anzeige einer digitalen Karte empfangen. Des Weiteren generieren der eine oder die mehreren Prozessoren eine Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen, erstellen eine einzelne Karteninhaltsanfrage einschließlich zahlreicher Kennungen, die der Vielzahl an Kartenkacheln entsprechen, und kommunizieren über ein Computernetzwerk die Karteninhaltsanfrage an einen Server. Als Antwort auf die Karteninhaltsanfrage empfangen der eine oder die mehreren Prozessoren über das Computernetzwerk die Vielfalt von Kartenkacheln vom Server und zeigen über die Benutzeroberfläche die digitale Karte auf der Grundlage der Vielfalt von Kartenkacheln an
Gemäß noch einer weiteren Implementierung umfasst ein Verfahren in einem Netzgerät für den Abruf von Kartenkacheln das Empfangen von einem Client-Gerät einer Anfrage nach Kartendaten einschließlich einer Vielfalt von Kartenkacheln, worin die Anfrage nach Kartendaten zahlreiche Kennungen beinhaltet, die der Vielzahl von Kartenkacheln entsprechen. Des Weiteren umfasst das Verfahren das Parsen, mit einem oder mehreren Prozessoren, der Anfrage nach Kartendaten zur Identifikation der Vielfalt von Kartenkacheln anhand der eindeutigen Kennungen und dem Satz relativer Kennungen, den Abruf, mit dem einen oder den mehreren Prozessoren, der Vielzahl der Kartenkacheln von einer Karteninhaltsdatenbank und die Bereitstellung der angeforderten Kartenkacheln an das Client-Gerät.
Gemäß einer weiteren Implementierung umfasst ein Computergerät für das effiziente Abrufen von Kartenkacheln einen oder mehrere Prozessoren und einen oder mehrere Speicher, die an einen oder mehrere Prozessoren gekoppelt sind, worin der eine oder die mehreren Speicher darin gespeicherte computerausführbare Anweisungen beinhalten, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, dazu führen, dass der eine oder die mehreren Prozessoren von einem Client-Gerät eine Anfrage nach Kartendaten einschließlich zahlreicher Kennungen empfangen, die der Vielfalt von Kartenkacheln entsprechen. Des Weiteren parsen der eine oder die mehreren Prozessoren die Anfrage nach Kartendaten zur Identifikation der Vielfalt von Kartenkacheln anhand der eindeutigen Kennungen und dem Satz relativer Kennungen, rufen die Vielzahl der Kartenkacheln von einer Karteninhaltsdatenbank ab und stellen die angeforderten Kartenkacheln dem Client-Gerät bereit.
Gemäß noch einer weiteren Implementierung beinhaltet ein Gerät die Möglichkeit zum Empfangen, über eine Benutzeroberfläche, einer Anfrage zur Anzeige einer digitalen Karte ein; die Möglichkeit zur Identifikation, mit einem Prozessor, einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen; die Möglichkeit zur Erstellung einer einzelnen Karteninhaltsanfrage einschließlich zahlreicher Kennungen, die der Vielzahl der Kartenkacheln entsprechen; die Möglichkeit zur Kommunikation, über ein Computernetzwerk, der Karteninhaltsanfrage an einen Server; die Möglichkeit, als Antwort auf die Karteninhaltsanfrage, des Empfangens, über ein Computernetzwerk, der Vielzahl der Kartenkacheln vom Server; und die Möglichkeit zur Anzeige, über die Benutzeroberfläche, der digitalen Karte auf der Grundlage der Vielzahl der Kartenkacheln.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht eine beispielhafte Computerumgebung, in der Kartenkacheln effizient für die Anzeige digitaler Karten abgerufen werden können.
2 veranschaulicht ein beispielhaftes Client-Gerät, das eine Mehrkachel-Anfrage erstellen und als Teil der Computerumgebung implementiert werden kann, die in 1 veranschaulicht wird.
3A und 3B veranschaulichen Beispielimplementierungen bestehender Techniken für das Abrufen von Kartenkacheln.
4 veranschaulicht eine Beispielimplementierung einer Mehrkachel-Anfrage, die in der Computerumgebung ausgeführt werden kann, die in 1 veranschaulicht wird.
5 ist ein Flussdiagramm eines Beispielverfahrens für das effiziente Abrufen von Kartenkacheln, das in der beispielhaften Computerumgebung implementiert werden kann, die in 1 veranschaulicht wird.
6 veranschaulicht ein beispielhaftes Bezeichnungs- oder Indexierungssystem für Kartenkacheln, das als Teil des Beispielverfahrens von 5 umgesetzt werden kann.
7 ist ein Flussdiagramm eines Beispielverfahrens für die Erstellung und das Senden einer Mehrkachel-Anfrage von einem Client-Gerät an einen Server, das in der beispielhaften Computerumgebung implementiert werden kann, die in 1 veranschaulicht wird.
8 ist ein Flussdiagramm eines Beispielverfahrens für die Bearbeitung einer Mehrkachel-Anfrage von einem Client-Gerät, die in der beispielhaften Computerumgebung ausgeführt werden kann, die in 1 veranschaulicht wird.
AUSFÜHRLICHE BESCHREIBUNG
Die Techniken dieser Offenbarung ermöglichen das effiziente Abrufen von Kartenkacheln, die für die Anordnung digitaler Karten benötigt werden, von einem Karteninhaltsserver. Eine einzelne Inhaltsanfrage an den Karteninhaltsserver beinhaltet eine Identifikation zahlreicher Kartenkacheln, so dass mehrere Kartenkacheln abgerufen werden, ohne dass zahlreiche Inhaltsanfragen notwendig sind. Die in der Mehrkachel-Inhaltsanfrage ermittelten Kartenkacheln machen gewöhnlich einen aneinandergrenzenden Teil der digitalen Karte aus. Jedoch kann jeder Satz von Kartenkacheln durch Senden einer Mehrkachel-Anfrage an den Server geholt werden, wobei die Mehrkachel-Anfrage eine Identifikation zahlreicher Kartenkacheln beinhaltet. In einigen Fällen kann jede Kartenkachelidentifikation eine vollständige oder eindeutige Identifikation sein. Jedoch kann die Mehrkachel-Anfrage in anderen Fällen eine vollständige Identifikation einer der Kartenkacheln in der Mehrkachel-Anfrage beinhalten und kann abgekürzte oder indexierte Identifikationen für andere Kartenkacheln in der Mehrkachel-Anfrage beinhalten, worin sich die indexierten Kachelidentifikationen auf die Kachel beziehen, für die eine vollständige Identifikation bereitgestellt wird, beispielsweise, um das Ausmaß der für die Anfrage aller Kartenkacheln benötigte Zeit zu reduzieren.
1 veranschaulicht eine beispielhafte Computerumgebung 100, in der Kartenkacheln effizient über eine Mehrkachel-Anfrage abgerufen werden können. Die beispielhafte Computerumgebung 100 beinhaltet ein Client-Gerät 102 ein, das für die Kommunikation an Netzwerk 104 gekoppelt ist. Das Client-Gerät 102 kann beispielsweise ein Smartphone, Tablet PC, Laptop, Desktop-Computer, ein GPS-Empfänger usw. sein. Weitere Details eines beispielhaften Client-Gerätes werden in Bezug auf 2 besprochen. Das Kommunikationsnetzwerk 104 kann eines oder mehrere, ein lokales Netzwerk (Local Area Network, LAN), ein Drahtlos-LAN, ein Fernnetz (Wide Area Network, WAN), ein mobiles Kommunikationsnetzwerk, das Internet oder jegliche anderen öffentlichen oder privaten fest verdrahteten oder drahtlosen Kommunikationsnetzwerke beinhalten.
In einigen Implementierungen kann das Client-Gerät 102 eine Kartenanwendung ausführen, um einem Benutzer digitale Karten anzuzeigen, wobei die digitalen Karten Karteninhalte beinhalten, die von einem Karteninhaltsserver 106 heruntergeladen wurden. Die Kartenanwendung kann zum Beispiel in einem Online-Anwendungsladen verfügbar sein, der sich im Karteninhaltsserver 106 oder in einem Anwendungsserver (nicht gezeigt) befindet. Ein Benutzer des Client-Geräts 102 kann eine Kopie der Kartenanwendung vom Anwendungsserver abrufen und die abgerufene Kopie der Kartenanwendung auf dem Client-Gerät 102 „installieren”. Alternativ kann das Client-Gerät 102 eine interaktive Kartenanwendung in einer Webbrowser-Anwendung anzeigen.
In einigen Szenarien kann das Client-Gerät 102 digitale Karten anzeigen, die aus einer Vielfalt von Kartenkacheln erstellt wurden (z. B. Bilder mit 256×256 Pixel). Zum Beispiel kann ein Benutzer des Client-Geräts 102 ein Interessengebiet über eine geographische Abfrage identifizieren, und die Kartenanwendung kann eine digitale Karte des Interessenbereiches anzeigen, die auf zahlreichen rechteckigen Kartenkacheln erstellt wurde, die jeweils einen rechteckigen Teil des Interessenbereiches darstellen. Um solche Clientanfragen zu beantworten, kann die Kartenanwendung die relevanten Kartenkacheln über eine Mehrkachel-Anfrage abrufen, wie nachstehend erörtert.
In einer Implementierung kann eine Kartenkachel, die einen Teil einer digitalen Karte bildet, durch Überlagern, Verschmelzen und/oder anderweitiges Kombinieren von Folgendem erstellt werden: (i) Vektorgrafiken, die in einer Vektordatenbank 108 gespeichert sind, und (ii) Hintergrund-Rasterbilder, die in einer Hintergrund-Rasterdatenbank 110 gespeichert sind. Als Beispiel kann die Vektordatenbank 108 geometrische Definitionen von Gebäudeumrissen, Kennzeichnungs-/Markierungspositionen, Straßenabschnitte, Navigationsstrecken usw. beinhalten. Hintergrund-Rasterbilder können beispielsweise Rasterbilder mit Geländeinformationen, kleineren Straßen, Wohnungsunterteilungen usw. beinhalten. In einigen Implementierungen werden Vektorgrafiken, Hintergrund-Rasterbilder und die sich daraus ergebenden Kartenkacheln von einer Inhalterstellungsmaschine 112 erstellt. Zum Beispiel kann die Inhalterstellungsmaschine 112 einen Karteninhalt (z. B. Vektor-/Rasterbilder und Kartenkacheln) über eine Stapelverarbeitung erstellen, und der Karteninhaltsserver 106 kann den Karteninhalt in Echtzeit abrufen, um Clientanfragen zu bearbeiten. In anderen Fällen kann eine Kartenkachel vollständig als Rasterbild oder als Vektorgrafikbild erstellt werden.
2 veranschaulicht ein beispielhaftes Client-Gerät 150, das effizient Kartenkacheln über eine Mehrkachel-Anfrage abrufen kann. Das Client-Gerät 150 beinhaltet ein Anzeigegerät 152, auf dem digitale Karten angezeigt werden können, wie eine Flüssigkristallanzeige (LCD), eine Leuchtdiodenanzeige (LED-Anzeige), eine organische Leuchtdiodenanzeige (OLED-Anzeige) usw. Außerdem beinhaltet das Client-Gerät 150 eine Netzwerkschnittstelle 154, um die Kommunikation über ein Netzwerk wie das Netzwerk 104 zu ermöglichen, eine CPU 156 zum Ausführen computerlesbarer Anweisungen, die in einem Speicher 158 gespeichert sind, und eine Grafikverarbeitungseinheit (GPU) 160 zum Wiedergeben von Bildern, die auf dem Anzeigegerät 152 anzuzeigen sind.
Der Speicher 158 kann in einigen Implementierungen eine Kartenanwendung 164 beinhalten. Zum Beispiel kann die Kartenanwendung 164 ein Kachelanfragenprogramm 168 für die Erstellung von Mehrkachel-Inhaltsanfragen und ein Kartenanzeigeprogramm 170 für den Aufbau und das Anzeigen digitaler Karten auf der Grundlage der empfangenen Kartenkacheln beinhalten. In manchen Implementierungen speichert der Speicher 158 eine Vielzahl von Schattierern (nicht gezeigt) zum Beschreiben und/oder Definieren der Eigenschaften (z. B. Position, Farben usw.) von Teilen von Bildern, die auf dem Anzeigegerät 152 anzuzeigen sind. Die Vielfalt von Schattierern kann zum Beispiel Pixelschattierer, Vertexschattierer, Geometrieschattierer usw. beinhalten, die von der GPU 160 ausgeführt werden können. In anderen Implementierungen kann eine Vielfalt von Schattierern ein Teil einer oder mehrerer Schattierungs-„Pipelines” in der GPU 160 in einer Implementierung sein, wie in der Fachwelt bekannt.
Der Übersichtlichkeit wegen veranschaulichen 3A und 3B eine Beispielimplementierung bestehender Techniken für das Abrufen von Kartenkacheln. In bestehenden Implementierungen wird eine Inhaltsanfrage, wie eine HTTP-Anfrage, von einem Client-Gerät 200 an einen Karteninhaltsserver 202 für jede Kartenkachel gesendet, die für den Aufbau einer digitalen Karte notwendig ist (wie durch die zahlreichen Pfeile mit der Bezeichnung Kachel 1–Kachel N veranschaulicht wird). Danach ruft der Karteninhaltsserver 202 die Kartenkacheln 1–N von einer Inhaltsdatenbank 204 ab und sendet jede der Kartenkacheln 1–N zurück an das Client-Gerät 200, während sie empfangen oder erstellt werden, wie durch die zahlreichen Pfeile mit der Bezeichnung Kachel 1–Kachel N in 3B veranschaulicht wird. Jedoch führt die Verwendung von zahlreichen Inhaltsanfragen bei bestehenden Kartenabruftechniken zu einem großen Ausmaß an Kommunikationsaufwand und/oder vielen anstehenden oder verzögerten Inhaltsanfragen, wenn die Anzahl der Inhaltsanfragen das Limit des Browsers übersteigt.
Im Gegensatz dazu können die Techniken der vorliegenden Offenbarung eine einzelne Inhaltsanfrage nutzen, um zahlreiche Kartenkacheln zu holen. Daher können die Techniken der vorliegenden Offenbarung den Kommunikationsaufwand erheblich verringern und in vielen Szenarios anstehende oder verzögerte Inhaltsanfragen verhindern. Außerdem kann eine einzelne Inhaltsanfrage einen Karteninhaltsserver schneller erreichen als der gesamte Satz der zahlreichen Karteninhaltsanfragen, so dass dem Karteninhaltsserver eine zeitnähere Benachrichtigung des angeforderten Inhalts bereitgestellt werden kann und der Karteninhaltsserver die Möglichkeit hat, alle angeforderten Kartenkacheln schneller zu holen oder zu erstellen, als wenn Anfragen für einzelne Kartenkacheln in nacheinander gesendeten Mitteilungen empfangen werden.
4 veranschaulicht eine Beispielimplementierung der Techniken der vorliegenden Offenbarung, in der eine einzelne Mehrkachel-Anfrage genutzt wird, um zahlreiche Kartenkacheln abzurufen. Ein Client-Gerät 300 kann (z. B. über geographische Anfragen oder Zoombetrieb) zahlreiche Kartenkacheln identifizieren, die notwendig sind, um neue oder unterschiedliche Teile einer digitalen Karte in einem Beispielszenario anzuzeigen. Im Gegenzug kann das Client-Gerät 300 in dem Beispielszenario eine Mehrkachel-Inhaltsanfrage zusammenstellen und die Anfrage an einen Karteninhaltsserver 302 (wie durch einen einzelnen Pfeil mit der Kennzeichnung „Mehrkachel-Anfrage” veranschaulicht) senden.
Der Karteninhaltsserver 302 kann die Mehrkachel-Anfrage parsen, um die einzelnen, von dem Client-Gerät 300 angeforderten Kacheln zu identifizieren und die einzelnen Kacheln (Kachel 1–Kachel N) von einer Inhaltsdatenbank 304 abzurufen, wie durch die zahlreichen Pfeile zwischen dem Karteninhaltsserver 302 und der Inhaltsdatenbank 304 veranschaulicht. Die abgerufenen Kartenkacheln können Rasterbild-Kartenkacheln sein, die zum Beispiel in der Rasterdatenbank 110 gespeichert werden, oder Vektorgrafik-Kartenkacheln, die beispielsweise in Vektordatenbank 108 (von 1 gespeichert werden). So werden in der Implementierung zahlreiche Kartenkacheln abgerufen, ohne dass zahlreiche Inhaltsanfragen notwendig sind. Der Karteninhaltsserver kann immer noch abgerufene oder geholte Kartenkacheln zurück an das Client-Gerät in einer separaten Mitteilung senden, sobald diese Kacheln geholt werden, um sicherzustellen, dass die Kacheln so schnell wie möglich gesendet und von dem Client-Gerät empfangen werden.
5 ist ein Flussdiagramm eines Beispielverfahrens 400 für das Abrufen von Kartenkacheln über die Mehrkachel-Anfrage. Das Verfahren 400 kann beispielsweise in dem Client-Gerät 102 implementiert werden. In Block 402 wird ein Satz von für die Anordnung einer digitalen Karte benötigten Kartenkacheln identifiziert. In einigen Implementierungen wird der Satz von Kartenkacheln als Antwort auf eine geographische Abfrage identifiziert. Zum Beispiel kann der Benutzer von Client-Gerät 102 über eine Tastatur, einen Touchscreen oder eine sonstige Benutzeroberfläche einen Hinweis auf ein Interessengebiet eingeben, und das Client-Gerät 102 kann einen Satz von Kartenkacheln identifizieren, der diesem Interessengebiet entspricht. Alternativ kann der Benutzer von Client-Gerät 102 eine Zoomhandlung, eine sonstige Inhaltsauswahl (z. B. eine Auswahl, die die Anzeige von Verkehrsinformationen angibt) oder eine sonstige Handlung ausführen, die einen zusätzlichen Karteninhalt erfordert, der als ein Satz neuer Kartenkacheln identifiziert wird.
Als Nächstes (in Block 404) erstellt das Client-Gerät eine Mehrkachel-Anfrage, wobei die Mehrkachel-Anfrage eine Kennung für jeden Satz von Kartenkacheln beinhaltet, die notwendig sind, um eine digitale Karte zu erstellen. In einigen Implementierungen kann die Mehrkachel-Anfrage eine Referenzkartenkachel in Konstanten angeben (z. B. mit x- und _y-Koordinaten, Breiten-/Längengradkoordinaten, Kartenkachelkennungen oder irgendeiner anderen vollständigen Identifikationsmethode, die eine Kartenkachel eindeutig identifiziert) und die restlichen Kacheln in relativen Begriffen angeben. Zum Beispiel kann die Mehrkachel-Anfrage die Kachel angeben (132, 124) und als Koordinaten für die daneben liegenden Kacheln (+1, 0), (+2, 0) auflisten, ... (+1, +1), (+2, +1), ...., alle in Relation zu (132, 124) gemessen. Auf Wunsch kann die Mehrkachel-Anfrage auch eine Kartenkachel in Konstanten und eine Begrenzungsbox in jeglichem geeigneten Format (z. B. alle angrenzenden Kacheln, fünf Kacheln nach unten, 10 Kacheln nach rechts) angeben, so dass der Server alle Kacheln bereitstellen kann, die zu der Begrenzungsbox gehören. Auf diese Weise hindert die derzeitige 2000-Zeichen-Begrenzung der bei HTTP-Anfragen verwendeten Internetverknüpfung (Uniform Resource Locator, URL) in einer Implementierung das Client-Gerät nicht daran, eine große Anzahl von Kacheln in einer einzelnen Anfrage anzufordern. Weitere Details des Verfahrens für die Erstellung und das Senden von Mehrkachel-Anfragen werden mit Verweisung auf 7 beschrieben.
Der Übersichtlichkeit wegen veranschaulicht 6 ein Beispiel eines Satzes von Kartenkacheln einschließlich einer Referenzkartenkachel und die von den relativen Koordinaten angegebenen sie umgebenden Kartenkacheln. In dem Beispielsatz Kartenkacheln wird die Referenzkarte durch die Koordinaten (x, y) gekennzeichnet, und die sie umgebenden Kartenkacheln werden in Abstufungen der Kartenkachelgröße gekennzeichnet. Zum Beispiel wird die Kartenkachel direkt auf der rechten Seite der Referenzkartenkachel durch die Koordinaten (+1, 0) gekennzeichnet, wobei die Kartenkachel direkt über der Referenzkartenkachel durch die Koordinaten (0, +1) gekennzeichnet wird. Auf diese Weise kann ein Satz von Kartenkacheln in einer Mehrkachel-Anfrage über relative Koordinaten identifiziert werden. Auch wenn dies nicht in 6 veranschaulicht wird, kann die Kennung der Referenzkartenkachel auch sonstige Informationen beinhalten, wie z. B. das Zoomniveau für die Kartenkachel, eine mit der angeforderten Kartenkachel verbundene Kartenansicht usw. Jedoch brauchen die indexierten Kartenkacheln, d. h. die Kartenkacheln, die durch Indexierung mit der Referenzkartenkachel angegeben werden, in vielen Fällen nicht die Kennung des Zoomniveaus, die Kennung der Kartenansicht oder sonstige Informationen, die typischerweise für alle zur Anzeige gesendeten Kartenkacheln dieselben sind oder die mit einer bestimmten einzelnen Kartenkachel verbunden sind. Diese Eigenschaft verringert des Weiteren die Informationen, die mit der Anforderung zahlreicher Kartenkacheln gesendet werden müssen.
Zwar veranschaulicht 6 einen Satz von Kartenkacheln als einen aneinandergrenzenden Satz von Kartenkacheln, aber der in einer Mehrkachel-Anfrage angegebener Satz von Kartenkacheln kann auch losgelöste oder separate Kartenkacheln beinhalten. Zum Beispiel kann im Fall neuer Kartenkennungen oder neu ausgewählter Kartenschichten neuer Karteninhalt an den verschiedenen getrennten Punkten auf einer digitalen Karte erforderlich sein. In einem solchen Fall kann ein Client-Gerät, wie das Client-Gerät 102, eine Mehrkachel-Anfrage erstellen, die verschiedene, nicht aneinandergrenzende Kartenkacheln angibt. Zum Beispiel kann eine Referenzkartenkachel willkürlich oder ansonsten gewählt werden, und die restlichen nicht aneinandergrenzenden Kartenkacheln können relativ zu den Koordinaten der Referenzkartenkachel gekennzeichnet werden.
Des Weiteren können die in einer Mehrkachel-Anfrage identifizierten Kartenkacheln in einer Implementierung Kartenkacheln verschiedener Größe beinhalten. Zum Beispiel kann die Rasterdatenbank 110 auf Raster basierende Kartenkacheln verschiedener Größe für die Anzeige der Karten mit verschiedenen Maßstäben beinhalten. In solch einem Fall kann eine Mehrkachel-Anfrage eine Angabe des Zoomniveaus oder der Zoomskala zusammen mit der Position einer Referenzkartenkachel und relativen Kartenkachelpositionen beinhalten. Zum Beispiel kann eine bestimmte Kartenanwendung Karten auf einer von achtzehn Kartenzoomniveaus anzeigen, und eine von einer Kartenanwendung erstellte Mehrkachel-Anfrage kann eine Zahl zwischen eins und achtzehn beinhalten, um einen relevanten Zoom oder Maßstab in Verbindung mit einer geographischen Abfrage zu identifizieren.
Um auf 5 zurückzukommen, wird in Block 406 die Mehrkachel-Anfrage von einem Client-Gerät an einen Karteninhaltsserver gesendet, wie ein Karteninhaltsserver 106. Zum Beispiel kann das Client-Gerät 150 die Mehrkachel-Anfrage als eine einzelne HTTP-Anfrage über die Netzschnittstelle 154 senden. Dann werden in einem Block 408 die einzelnen Kartenkacheln, die den in einer Mehrkachel-Anfrage identifizierten Kartenkacheln entsprechen, von dem Karteninhaltsserver empfangen. Die empfangenen Kacheln können in einer Implementierung jegliche oder eine Kombination von Rasterbildkacheln, Vektorbildkacheln und zusätzliche Kacheln beinhalten. Zum Beispiel kann ein Client-Gerät zusätzliche Kacheln empfangen (z. B. einschließlich Unschärfen, Schattierungen, Texturen usw.), die sich mit den Rasterbildkacheln vermischen. In einigen Implementierungen kann das Client-Gerät nur Vektorbildkacheln oder nur Rasterbildkacheln auf der Grundlage der Art der geographischen Abfrage oder der Handlung empfangen, die von der Mehrkachel-Anfrage ausgelöst wurde. Zum Beispiel kann eine Anfrage nach zusätzlichen Gebäudeinformationen eine Anfrage nach vektorbasierten Kacheln und nicht nach rasterbasierten Kacheln auslösen.
In einem Block 410 wird eine digitale Karte zur Anzeige anhand der empfangenen Kartenkacheln wiedergegeben. Zum Beispiel kann das Client-Gerät 102 die empfangenen Kartenkacheln verbinden, mischen, überlagern oder anders kombinieren, um eine digitale Karte zur Anzeige auf dem Anzeigegerät 152 zu erstellen. In einigen Implementierungen kann das Client-Gerät 102 die einzelnen Kartenkacheln zu verschiedenen Zeiten empfangen. In einem solchen Fall kann das Client-Gerät 102 nur Teile einer digitalen Karte auf der Grundlage der Untergruppe empfangener Kartenkacheln anzeigen. Dann kann das Client-Gerät 102 beispielsweise weitere Teile der digitalen Karte anzeigen, wenn mehr Kartenkacheln empfangen werden.
7 ist ein Flussdiagramm eines Beispielverfahrens 450 für die Erstellung und das Senden einer Mehrkachel-Anfrage von einem Client-Gerät an einen Server, der beispielsweise in Block 404 von 5 verwendet werden kann. Das Beispielverfahren 450 kann jedoch in dem Client-Gerät 150 auf jegliche andere Art implementiert werden.
In einem Block 452 wird eine geographische Region bestimmt, für die neue Kartenkacheln benötigt werden. Zum Beispiel kann das Kachelanfrageprogramm 168 eine geographische Abfrage verarbeiten, um ein Interessengebiet festzustellen. Wenn zum Beispiel ein Benutzer von Client-Gerät 150 eine Suchabfrage nach „Chicago” über eine Benutzeroberfläche eingibt, kann die Kartenanwendung 164 die Suchabfrage parsen, wie in der Fachwelt bekannt ist, um die Region mit dem Stadtgebiet von Chicago zu identifizieren. In einem anderen Szenario kann ein Benutzer des Client-Geräts 150 die Ansicht einer Nachbarschaft von Chicago auf eine Ansicht des vollständigen Stadtgebietes von Chicago verschieben oder zoomen. In einem solchen Szenario kann das Kachelanfrageprogramm 168 die für das gesamte Stadtgebiet von Chicago benötigten Kartenkacheln bestimmen, mit Ausnahme des geografischen Gebiets der derzeitig betrachteten Nachbarschaft.
Als Nächstes (in einem Block 454) werden ein bestimmter Satz von Kartenkacheln, der dem geographischen Gebiet entspricht, und das Zoomniveau für die anzuzeigende Karte bestimmt. Zum Beispiel kann das Kachelanfrageprogramm 168 die Anzahl und/oder die Position der neuen Kartenkacheln nach dem Ausmaß des Zooms oder der Verschiebung, einem geographischen Maßstab einer geographischen Abfrage (z. B. Stadtmaßstab, Landmaßstab usw.), einer Begrenzungsbox eines digitalen Kartenansichtsfensters usw. bestimmen. Das Kachelanfrageprogramm 168 kann bestimmen, dass es sich bei allen Kartenkacheln, die völlig oder teilweise in einem Ansichtsfenster zu sehen sind, abzüglich der Kartenkacheln, die derzeit von der Kartenanwendung 164 verwendet werden, um den Satz Kartenkacheln handelt, der von der Kartenanwendung 164 benötigt wird.
In einem Block 456 wird eine aus dem Satz Kartenkacheln, die in Block 454 identifiziert wird, als Referenzkartenkachel ausgewählt, der eine eindeutige Kennung zugewiesen wird. Zum Beispiel kann das Kachelanfrageprogramm 168 die Kartenkachel mit der zentralsten Position in einem aktuellen oder erwarteten Kartenansichtsfenster, die Kartenkachel mit der Position, die sich der Durchschnittsposition des Satzes von Kartenkacheln am nächsten befindet, die Kartenkachel in einer Ecke des gesamten geographischen Gebiets für das Kartenkacheln angefordert werden usw. als die Referenzkartenkachel auswählen. In einigen Implementierungen kann das Kachelanfrageprogramm 168 der Referenzkartenkachel eine eindeutige Kennung mithilfe von Breitengrad und Längengrad oder eines anderen geeigneten Koordinatensystems zuweisen oder bestimmen. Zum Beispiel können die der Referenzkartenkachel entsprechenden Koordinaten den Breiten- und Längengrad des Zentrums der Kartenkachel angeben.
In einem Block 458 werden relative Kennungen der restlichen Kartenkachel in dem betreffenden Satz von Kartenkacheln bestimmt und zugewiesen. Zum Beispiel kann das Kachelanfrageprogramm 168 den restlichen Kartenkacheln positive und negative Ganzzahlwerte zuweisen, die die Position der Kartenkacheln im Verhältnis zu der Referenzkartenkachel darstellen, wie vorstehend mit Bezug auf 5 weiter erörtert. In anderen Implementierungen kann das Kachelanfrageprogramm 168 den restlichen Kartenkacheln relative Koordinaten zuweisen, die relativen Entfernungen in einer geeigneten Maßeinheit entsprechen, wie Meter, Fuß usw. Zum Beispiel kann das Kachelanfrageprogramm 168 einer Kartenkachel die Koordinaten (x_r, y_r) zuweisen, wobei x_r und y_r die Ost-Westentfernung bzw. die Nord-/Südentfernung zwischen dem Zentrum der Referenzkartenkachel und der Kartenkachel sind. In einigen Fällen kann jede der anderen Kartenkacheln (z. B. die indexierten Kartenkacheln) separat angegeben werden. In anderen Fällen können die anderen Kartenkacheln als eine Gruppe mit einem Gruppenindex angegeben werden, wie alle Kartenkacheln innerhalb einer bestimmten Entfernung oder eines Abstandes von der Referenzkartenkachel, alle Kartenkacheln neben der Referenzkartenkachel usw.
In einigen Implementierungen wird jeder Kachel des Satzes von Kartenkacheln eine eindeutige Kennung zugewiesen, die für die unabhängige Identifikation einer Kartenkachel verwendet werden kann. Zum Beispiel kann das Client-Gerät 150 jedem Satz von Kartenkacheln absolute Breiten- und Längengradkoordinaten, eindeutige Kartenkachel-ID-Nummern oder sonstige geeignete eindeutige Kennungen zuweisen. In solchen Implementierungen können die Blöcke 456 und 458 des Verfahrens 450 kombiniert werden, so dass jedem Satz von Kartenkacheln eindeutige Kennungen zugewiesen werden. Zum Beispiel kann das Client-Gerät einen Satz Ganzzahlkennungen wie {(132, 124), (133, 124), ..., (137, 128)} einem Satz von Kartenkacheln zuweisen, wobei jede Ganzzahlkennung einen Satz von Kartenkacheln identifiziert.
Als Nächstes wird (in einem Block 460) eine Mehrkachel-Anfrage einschließlich der Koordinaten der Referenzkartenkachel und der relativen Koordinaten der restlichen Kartenkacheln erstellt, wobei jeder Satz relativer Koordinaten entweder eine einzelne Kartenkachel oder eine Gruppe Kartenkacheln angibt, bzw. einschließlich der eindeutigen Kennungen, die jedem der Sätze von Kartenkacheln entsprechen. Zum Beispiel kann die Mehrkachel-Anfrage eine HTTP-Anfrage sein, die eine Anfragezeile, Kopfzeilen und eine Leerzeile beinhalten kann, wie in der Fachwelt bekannt ist. Die Mehrkachel-Anfrage kann beispielsweise alphanumerische Zeichen, Symbole oder sonstige geeignete Darstellungen der Koordinaten der Referenzkartenkachel und der restlichen Kartenkacheln beinhalten. Dann wird in Block 462 eine Mehrkachel-Anfrage an einen Karteninhaltsserver wie Karteninhaltsserver 106 gesendet. Zum Beispiel kann das Client-Gerät 150 die Mehrkachel-Anfrage über die Netzwerkschnittstelle 154 an den Karteninhaltsserver 106 senden.
8 ist ein Flussdiagramm eines Beispielverfahrens 500 für die Bearbeitung von Mehrkachel-Anfragen, die von einem Karteninhaltsserver empfangen werden. Das Verfahren 500 kann beispielsweise in dem Karteninhaltsserver 106 implementiert werden. Hier, in einem Block 502, wird eine Mehrkachel-Anfrage von einem Client-Gerät empfangen. Zum Beispiel kann der Karteninhaltsserver 106 die Mehrkachel-Anfrage als eine einzelne HTTP-Anfrage über das Netzwerk 104 empfangen. Danach wird, in einem Block 504, die Mehrkachel-Anfrage geparst, um die einzelnen in der Mehrkachel-Anfrage identifizierten Kartenkacheln zu bestimmen. Zum Beispiel kann das Parsen der Mehrkachel-Anfrage jegliche Anzahl von in der Fachwelt bekannten Parsing-Techniken beinhalten, wie die Ermittlung von Trennzeichen, die Erstellung von Unterschriften/Grammatiken usw. In einigen Implementierungen kann der Karteninhaltsserver 504 eine Reihe computerlesbarer Anweisungen, wie einen Parsing-Script, ausführen, um die Mehrkachel-Anfrage über bekannte Regeln für ein Mehrkachel-Anfragenformat zu parsen. Zum Beispiel kann der Karteninhaltsserver 504 einen Script ausführen, der die Mehrkachel-Anfrage anhand der Ganzzahlen parst, die die Breite oder die Erhebungen der Kartenkacheln darstellen, wobei bekannt ist, dass die Ganzzahlen in bestimmten Position einer Mehrkachel-Anfrage existieren.
In einem Block 506 werden die einzelnen Kacheln, die den in der Mehrkachel-Anfrage identifizierten einzelnen Kacheln entsprechen, von einer Inhaltsdatenbank abgerufen. In einigen Implementierungen kann der Karteninhaltsserver 106 eine Datenbankabfrage erstellen, wie eine SQL-Abfrage oder eine MapReduce-Funktion, die jeder der in der Mehrkachel-Anfrage identifizierten Kartenkachel entspricht. Der Karteninhaltsserver 106 kann dann die Datenbankanfragen bei der Rasterdatenbank 110 oder der Vektordatenbank 108 ausführen und die Kartenkacheln als Resultate der Anfragen empfangen.
In einigen Implementierungen kann das Abrufen der einzelnen Kartenkacheln über mehrere Prozessoren verteilt werden. Zum Beispiel kann der Karteninhaltsserver 106 nach dem Parsen der Mehrkachel-Anfrage das Abrufen der einzelnen Kartenkacheln so verteilen, dass jede Kartenkachel von einer Datenbank über einen anderen Prozessor abgerufen wird. Des Weiteren kann ein Karteninhaltsserver das Abrufen von Raster- und Vektorinhalt auf mehrere Prozessoren verteilen, so dass der einer bestimmten Kartenkachel entsprechende Rasterinhalt von einem anderen Prozessor als dem Prozessor abgerufen wird, der für das Abrufen des einer bestimmten Kartenkachel entsprechenden Vektorinhalts verwendet wird.
Als Nächstes (in einem Block 508) werden die einzelnen von der Inhaltsdatenbank abgerufenen Kacheln an das Client-Gerät gesendet. In einigen Implementierungen kann der Karteninhaltsserver 106 Kartenkacheln an das Client-Gerät 102 senden, während sie von der Rasterdatenbank 110 oder von der Vektordatenbank 108 abgerufen werden. Als solches kann das Client-Gerät beispielsweise beginnen, Teile der digitalen Karte anzuzeigen, sobald neue Kartenkacheln vorhanden sind. Alternativ kann der Karteninhaltsserver 102 die Kommunikation der Kartenkacheln in einer Implementierung priorisieren. Zum Beispiel kann der Karteninhaltsserver 102 Rasterinhalt vor dem Vektorinhalt, Kartenkacheln für ein geographisches Gebiet vor Kartenkacheln für ein anderes geographisches Gebiet, die für die Abfrage relevantesten Kartenkacheln vor Kartenkacheln senden, die weniger relevant sind usw.
Die Techniken der vorliegenden Offenbarung nutzen eine einzelne Inhaltsanfrage, um zahlreiche Kartenkacheln zu holen. Daher können die Techniken der vorliegenden Offenbarung den Kommunikationsaufwand erheblich verringern und in vielen Szenarios anstehende oder verzögerte Inhaltsanfragen verhindern. Außerdem kann eine einzelne Inhaltsanfrage dem Karteninhaltsserver eine zeitnähere Benachrichtigung des angeforderten Inhalts bereitstellen, und der Karteninhaltsserver hat dadurch die Möglichkeit, alle angeforderten Kartenkacheln schneller zu holen oder zu erstellen, als wenn Anfragen für einzelne Kartenkacheln in nacheinander gesendeten Mitteilungen empfangen werden.
Zusätzliche Überlegungen
Die folgenden zusätzlichen Überlegungen gelten für die vorstehende Erörterung. In dieser gesamten Spezifikation können mehrere Beispiele Komponenten, Operationen oder Strukturen implementieren, die als einzelnes Beispiels beschreiben sind. Auch wenn einzelne Operationen von einem oder mehreren Verfahren als getrennte Operationen veranschaulicht und beschrieben sind, können eine oder mehrere der einzelnen Operationen gleichzeitig durchgeführt werden, und nichts erfordert, dass die Operationen in der veranschaulichten Reihenfolge durchgeführt werden. Strukturen und Funktionen, die in beispielhaften Konfigurationen als getrennte Komponenten dargestellt werden, können als kombinierte Struktur oder Komponente implementiert werden. In ähnlicher Weise können Strukturen und Funktionen, die als einzelne Komponenten dargestellt werden, als getrennte Komponenten implementiert werden. Diese und andere Varianten, Änderungen, Hinzufügungen und Verbesserungen fallen in den Umfang des Gegenstands der vorliegenden Offenbarung.
Außerdem sind bestimmte Ausführungsformen hierin als Logik oder eine Reihe von Komponenten, Modulen oder Mechanismen umfassend beschrieben. Module können entweder Softwaremodule (z. B. Code, der auf einem maschinenlesbaren Medium gespeichert ist) oder Hardwaremodule darstellen. Ein Hardwaremodul ist ein greifbares Gerät, das bestimmte Operationen durchführen kann, und es kann in einer bestimmten Weise konfiguriert oder angeordnet sein. In exemplarischen Ausführungsformen können eines oder mehrere Computersysteme (z. B. ein eigenständiges, Client- oder Server-Computersystem) oder eines oder mehrere Hardwaremodule eines Computersystems (z. B. ein Prozessor oder eine Gruppe von Prozessoren) von der Software (z. B. einer Anwendung oder einem Anwendungsteil) als Hardwaremodul konfiguriert sein, um bestimmte, hierin beschriebene Operationen durchzuführen.
In verschiedenen Ausführungsformen kann ein Hardwaremodul mechanisch oder elektronisch implementiert werden. Ein Hardwaremodul kann beispielsweise eine spezielle Schaltung oder Logik umfassen, die dauerhaft zur Ausführung bestimmter Operationen konfiguriert ist (z. B. als ein spezieller Prozessor, wie beispielsweise ein Field Programmable Gate Array (FPGA) oder eine anwendungsspezifische integrierte Schaltung (ASIC)). Ein Hardwaremodul kann außerdem programmierbare Logik oder Schaltkreise umfassen (z. B. wie in einem Allzweck-Prozessor oder einem anderen programmierbaren Prozessor eingeschlossen), der von der Software temporär für die Durchführung bestimmter Operationen konfiguriert ist. Es wird darauf hingewiesen, dass die Entscheidung für die mechanische Implementierung eines Hardwaremoduls in spezielle und dauerhaft konfigurierte oder temporär konfigurierte Schaltungen (z. B. per Software konfiguriert) von Kosten- und Zeitüberlegungen abhängig sein kann.
Demgemäß sollte der Begriff Hardware so verstanden werden, dass er eine greifbare Entität umfasst, sei es eine Entität, die physisch konstruiert, permanent konfiguriert (z. B. hartverdrahtet) oder temporär konfiguriert (z. B. programmiert) ist, um auf bestimmte Weise zu arbeiten oder bestimmte, hierin beschriebene Operationen durchzuführen. Bei Berücksichtigung von Ausführungsformen, in denen Hardwaremodule temporär konfiguriert (z. B. programmiert) sind, müssen die jeweiligen Hardwaremodule nicht zu jeder einzelnen zeitlichen Instanz konfiguriert oder instanziiert sein. Wenn die Hardwaremodule zum Beispiel einen Allzweck-Prozessor umfassen, der für die Verwendung von Software konfiguriert ist, kann der Allzweck-Prozessor als entsprechend unterschiedliche Hardwaremodule zu verschiedenen Zeiten konfiguriert sein. Software kann demgemäß einen Prozessor zum Beispiel so konfigurieren, dass er zu einer zeitlichen Instanz ein bestimmtes Hardwaremodul und zu einer anderen zeitlichen Instanz ein anderes Hardwaremodul darstellt.
Hardware- und Softwaremodule können Informationen anderen Hardware- und/oder Softwaremodulen bereitstellen und Informationen von diesen empfangen. Demgemäß können die beschriebenen Hardwaremodule als kommunikativ gekoppelt betrachtet werden. Wenn mehrere solcher Hardware- oder Softwaremodule gleichzeitig vorhanden sind, kann die Kommunikation über Signalübertragung (z. B. über entsprechende Schaltkreise und Busse) erreicht werden, die mit den Hardware- oder Softwaremodulen verbunden sind. In Ausführungsformen, in denen mehrere Hardware- und Softwaremodule zu verschiedenen Zeiten konfiguriert oder instanziiert sind, kann die Kommunikation zwischen solchen Hardware- und Softwaremodulen zum Beispiel durch die Speicherung und das Abrufen von Informationen in Speicherstrukturen erreicht werden, zu denen die mehreren Hardware- und Softwaremodule Zugriff haben. Zum Beispiel kann ein Hardware- oder Softwaremodul eine Operation durchführen und den Ausgang dieser Operation in einem Speichergerät speichern, mit dem es kommunikativ gekoppelt ist. Ein weiteres Hardware- oder Softwaremodul kann dann, zu einem späteren Zeitpunkt, auf das Speichergerät zugreifen, um die gespeicherte Ausgabe abzurufen und zu verarbeiten. Hardware- und Softwaremodule können außerdem die Kommunikation mit Eingabe- und Ausgabegeräten initiieren, und sie können auf einer Ressource (z. B. einer Informationssammlung) betrieben werden.
Die verschiedenen Operationen hierin beschriebener Beispielverfahren können, zumindest teilweise, von einem oder mehreren Prozessoren durchgeführt werden, die temporär (z. B. durch Software) oder permanent für die Durchführung der relevanten Operationen konfiguriert sind. Ganz gleich, ob sie temporär oder permanent konfiguriert sind, stellen solche Prozessoren von Prozessoren implementierte Module dar, die betrieben werden, um eine oder mehrere Operationen oder Funktionen durchzuführen. Module, auf die hierin verwiesen wird, umfassen in einigen exemplarischen Ausführungsformen von Prozessoren implementierte Module.
In ähnlicher Weise können hierin beschriebene Verfahren oder Programme zumindest teilweise von Prozessoren implementiert sein. Zum Beispiel können zumindest einige der Operationen eines Verfahrens von einem oder mehreren Prozessoren oder von durch Prozessoren implementierten Hardwaremodulen durchgeführt werden. Die Durchführung bestimmter Operationen kann unter den ein oder mehreren Prozessoren verteilt sein, die sich nicht in einer einzigen Maschine befinden, sondern über eine Reihe von Maschinen bereitgestellt werden. In einigen exemplarischen Ausführungsformen können sich der Prozessor oder die Prozessoren an einem einzigen Ort (z. B. in einer Wohnungsumgebung, in einer Büroumgebung oder als eine Serverfarm) befinden, während in anderen Ausführungsformen die Prozessoren über eine Reihe von Orten verteilt sein können.
Der eine oder die mehreren Prozessoren können auch so betrieben werden, dass sie die Durchführung der relevanten Operationen in einer „Cloud-Computer”-Umgebung oder als eine SaaS unterstützen. Zum Beispiel können, wie oben angegeben, einige der Operationen durch eine Gruppe von Computer (z. B. von Maschinen einschließlich Prozessoren) durchgeführt werden, wobei diese Operationen über ein Netzwerk (z. B. das Internet) und über eine oder mehrere geeignete Schnittstellen (z. B. APIs) zugänglich sind.
Die Durchführung bestimmter Operationen kann unter dem einen oder den mehreren Prozessoren verteilt sein, die sich nicht in einer einzigen Maschine befinden, sondern über eine Reihe von Maschinen bereitgestellt werden. In einigen exemplarischen Ausführungsformen können sich ein oder mehrere Prozessor(en) oder durch Prozessoren implementierte Module an einem einzigen geografischen Standort (z. B. einer Wohnumgebung, einer Büroumgebung oder einer Serverfarm) befinden. In anderen exemplarischen Ausführungsformen können der eine oder die mehreren Prozessoren oder durch Prozessoren implementierten Module über eine Reihe geografischer Standorte verteilt sein.
Einige Teile dieser Spezifikation werden in Bezug auf Algorithmen oder symbolische Darstellungen von Operationen bei Daten dargestellt, die als Bits oder binäre digitale Signale in einem Maschinenspeicher (z. B. einem Computerspeicher) gespeichert sind. Diese Algorithmen oder symbolischen Darstellungen sind Beispiele von Techniken, die von Fachleuten der Datenverarbeitungstechnik verwendet werden, um anderen Fachleuten die wesentlichen Inhalte ihrer Arbeit zu vermitteln. Wie hierin verwendet, ist ein „Algorithmus” oder eine „Routine” eine eigenkonsistente Sequenz von Operationen oder ähnliche Verarbeitung, die zu einem gewünschten Ergebnis führt. In diesem Kontext beinhalten Algorithmen, Routinen und Operationen die physische Manipulation physischer Mengen. Normalerweise, aber nicht notwendigerweise, können solche Mengen die Form elektrischer, magnetischer oder optischer Signale annehmen, die von einer Maschine gespeichert, aufgerufen, übertragen, kombiniert, verglichen oder sonst manipuliert werden können. Hauptsächlich aus Gründen der allgemeinen Verwendung ist es manchmal praktisch, solche Signale mithilfe von Wörtern wie „Daten”, „Inhalt”, „Bits”, „Werte”, „Elemente”, „Symbole”, „Zeichen”, „Begriffe”, „Zahlen”, „Ziffern” oder dergleichen zu bezeichnen. Diese Wörter sind jedoch lediglich praktische Bezeichnungen und dürfen nicht mit entsprechenden physischen Mengen verbunden werden.
Sofern nicht speziell anders angegeben, können sich Erörterungen hierin, die Wörter wie „Verarbeitung”, „Computing”, „Berechnung”, „Bestimmung”, „Darstellung”, „Anzeige” oder ähnliches verwenden, auf Aktionen oder Prozesse einer Maschine (z. B. eines Computers) beziehen, die Daten bearbeiten oder umwandeln, die als physische (z. B. elektronische, magnetische oder optische) Mengen in einem oder mehreren Speichern (z. B. flüchtiger Speicher, nicht flüchtiger Speicher oder eine Kombination davon), Register oder andere Maschinenkomponenten dargestellt sind, die Informationen empfangen, speichern, übertragen oder anzeigen.
Wie hierin verwendet, bedeuten Verweise auf „eine Ausführungsform” oder „Ausführungsform”, dass ein bestimmtes Element, Merkmal, eine Struktur oder eine Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben wird, zumindest in einer Ausführungsform enthalten ist. Das Erscheinen der Formulierung „in einer Ausführungsform” an verschiedenen Orten in der Spezifikation bezieht sich nicht notwendigerweise immer auf dieselbe Ausführungsform.
Einige Ausführungsformen können mithilfe des Ausdrucks „gekoppelt” und „verbunden” zusammen mit ihren Ableitungen beschrieben werden. Zum Beispiel können einige Ausführungsformen mithilfe des Begriffs „gekoppelt” beschrieben werden, um anzugeben, dass eines oder mehrere Elemente im direkten physischen oder elektrischen Kontakt sind. Der Begriff „gekoppelt” kann jedoch auch bedeuten, dass eines oder mehrere Elemente nicht im direkten Kontakt miteinander sind, aber trotzdem noch miteinander zusammenarbeiten oder interagieren. Die Ausführungsformen sind in diesem Kontext nicht beschränkt.
Wie hierin verwendet, sollen die Begriffe „umfasst”, „umfassend”, „beinhaltet”, „enthält”, „hat”, „haben” und andere Varianten davon eine nicht ausschließliche Einbeziehung abdecken. Zum Beispiel ist ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, der/die eine Liste von Elementen umfasst, nicht notwendigerweise nur auf diese Elemente beschränkt, sondern kann andere Elemente beinhalten, die nicht ausdrücklich aufgelistet oder bei einem solchen Prozess, einem solchen Verfahren, einem solchen Artikel oder einer solchen Vorrichtung inhärent sind. Des Weiteren bezieht sich, sofern nichts Gegenteiliges angegeben ist, „oder” auf ein einschließendes und nicht auf ein ausschließendes Oder. Zum Beispiel ist eine Bedingung A oder B durch eines der folgenden erfüllt: A ist wahr (oder vorhanden) und B ist falsch (oder nicht vorhanden), A ist falsch (oder nicht vorhanden) und B ist wahr (oder vorhanden) und sowohl A als auch B sind wahr (oder vorhanden).
Außerdem wird „eine”, „einer” oder „eines” verwendet, um Elemente und Komponenten der Ausführungsformen hierin zu beschreiben. Dies erfolgt lediglich aus praktischen Gründen und um eine allgemeine Vorstellung der Beschreibung zu vermitteln. Die Beschreibung sollte so gelesen werden, dass sie eines oder mindestens eines enthält, und der Singular umfasst auch den Plural, außer es ist offensichtlich anders gedacht.
Beim Lesen dieser Offenbarung werden Experten immer noch zusätzliche strukturelle oder funktionelle Designs für das effiziente Einholen von Kartenkacheln mittels der hier offenbarten Prinzipien würdigen. Somit sollte, während bestimmte Ausführungsformen und Anwendungen veranschaulicht und beschrieben wurden, es selbstverständlich sein, dass die offenbarten Ausführungsformen nicht auf die genaue Konstruktion und Komponenten beschränkt sind, die hierin offenbart wurden. Verschiedene Modifikationen, Änderungen und Variationen, die für Fachleute auf dem Gebiet ersichtlich werden, können in der Anordnung, dem Betrieb und in den Einzelheiten der Verfahren und der Vorrichtung, die hierin offenbart werden, ohne Abweichung von der Idee und dem Umfang der angehängten Ansprüche erfolgen.

Claims

Computergerät für das effiziente Abrufen von Kartenkacheln, wobei das Computergerät Folgendes umfasst: einen oder mehrere Prozessor(en); und einen Speicher oder mehrere Speicher, der oder die an einen Prozessor oder mehrere Prozessoren gekoppelt ist oder sind; worin der eine oder die mehreren Speicher darin gespeicherte computerausführbare Anweisungen beinhalten, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen: Empfangen, über eine Benutzeroberfläche, einer Anfrage zur Anzeige einer digitalen Karte; Identifikation, mit einem oder mehreren Prozessoren, einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen; Erstellung einer einzelnen Karteninhaltsanfrage einschließlich zahlreicher Kennungen, die der Vielfalt von Kartenkacheln entsprechen; Kommunikation, über ein Computernetzwerk, der Karteninhaltsanfrage an einen Server; Als Antwort auf die Karteninhaltsanfrage Empfangen, über das Computernetzwerk, der Vielfalt von Kartenkacheln vom Server; und Anzeige, über die Benutzeroberfläche, der digitalen Karte auf der Grundlage der Vielfalt von Kartenkacheln.
Computergerät nach Anspruch 1, worin die zahlreichen Kennungen eine eindeutige Kennung einer der Vielfalt von Kartenkacheln und einen Satz relativer Kennungen beinhalten, die anderen der Vielfalt von Kartenkacheln entsprechen.
Computergerät nach Anspruch 2, worin der Satz relativer Kennungen zahlreiche relative Kennungen beinhaltet, wobei jede relative Kennung eine einzige zusätzliche Kartenkachel angibt.
Computergerät nach Anspruch 2 oder 3, worin der Satz relativer Kennungen eine relative Kennung beinhaltet, die eine Gruppe zusätzlicher Kartenkacheln angibt.
Computergerät nach Anspruch 4, worin die Gruppe der zusätzlichen Kartenkacheln als Begrenzungsbox angegeben wird.
Computergerät nach Anspruch 4 oder 5, worin die Gruppe der zusätzlichen Kartenkacheln so angegeben wird, dass sie diejenigen Kartenkacheln neben der Kartenkachel beinhaltet, die durch die eindeutige Kennung angegeben wird.
Computergerät nach Anspruch 4, worin die Gruppe der zusätzlichen Kartenkacheln so angegeben wird, dass sie diejenigen Kartenkacheln innerhalb eines bestimmten relativen Bereichs der Kartenkachel beinhaltet, die durch die eindeutige Kennung angegeben wird.
Greifbares, nicht-flüchtiges computerlesbares Medium mit darauf gespeicherten Anweisungen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, ein computerimplementiertes Verfahren für das Abrufen von Kartenkacheln für digitale Karten, wobei das Verfahren Folgendes umfasst, auszuführen: Empfangen, über eine Benutzeroberfläche, einer Anfrage zur Anzeige einer digitalen Karte; Identifikation, mit einem Prozessor, einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen; Erstellung einer einzelnen Karteninhaltsanfrage einschließlich zahlreicher Kennungen, die der Vielfalt von Kartenkacheln entsprechen; Kommunikation, über ein Computernetzwerk, der Karteninhaltsanfrage an einen Server; Als Antwort auf die Karteninhaltsanfrage Empfang, über das Computernetzwerk, der Vielfalt von Kartenkacheln vom Server; und Anzeige, über die Benutzeroberfläche, der digitalen Karte auf der Vielfalt von Kartenkacheln.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 8, worin die zahlreichen Kennungen eine eindeutige Kennung einer der Vielfalt von Kartenkacheln und einen Satz relativer Kennungen beinhalten, die anderen der Vielfalt von Kartenkacheln entsprechen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 9, worin die eindeutige Kennung der Vielfalt von Kartenkacheln Breiten- und Längengradkoordinaten beinhaltet.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 9 oder 10, worin der Satz der relativen Kennungen die Ganzzahl-Abstufungen beinhaltet, die die Position der anderen der Vielfalt von Kartenkacheln im Verhältnis zu der Position der einen der Vielfalt von Kartenkacheln anzeigen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–11, worin die Vielfalt von Kartenkacheln rechteckige Teile der digitalen Karten beinhaltet, die eine Unterteilung der digitalen Karte bilden.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–12, worin die einzelne Karteninhaltsanfrage eine HTTP-Anfrage ist.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–13, worin die Vielfalt von Kartenkacheln mindestens eines der Rasterbild-Kartenkacheln oder Vektorgrafik-Kartenkacheln beinhaltet.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 14, worin die Vielfalt von Kartenkacheln mindestens eine Rasterbild-Kartenkachel beinhaltet, und die Rasterbild-Kartenkachel mindestens eines der Schattierungen, Texturen, Hintergründe, Straßen oder natürlichen geographischen Eigenschaften beinhaltet.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 14, worin die Vielfalt von Kartenkacheln mindestens eine Vektorgrafik-Kartenkachel beinhaltet, und die Vektorgrafik-Kartenkachel geometrische Darstellungen der Gebäudeumrisse, der Kennzeichnungspositionen, der Markierungen oder der dreidimensionalen Modelle beinhaltet.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–16, worin die Identifikation einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen, die Identifikation von Kartenkacheln beinhaltet, die sich vollständig oder teilweise in einem aktuellen Kartenansichtsfenster befinden.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–17, worin die Identifikation einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen, die Identifikation von Kartenkacheln beinhaltet, die einer geographischen Abfrage entsprechen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–18, worin die Identifikation einer Vielfalt von Kartenkacheln, die jeweils einen Teil der digitalen Karte darstellen, die Identifikation von Kartenkacheln beinhaltet, die mit einer Zoom- oder Verschiebungshandlung verbunden sind.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der vorstehenden Ansprüche 8–19, worin eine der Vielfalt von Kartenkacheln mindestens eine zentrale Position in der Vielfalt von Kartenkacheln oder eine zentrale Position in einem Kartenansichtsfenster hat.
Greifbares, nicht-flüchtiges computerlesbares Medium mit darauf gespeicherten Anweisungen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, ein Verfahren in einem Netzgerät für das Abrufen von Kartenkacheln, wobei das Verfahren Folgendes umfasst, auszuführen, Empfang, von einem Client-Gerät, einer Anfrage nach Kartendaten einschließlich einer Vielfalt von Kartenkacheln, worin die Anfrage nach Kartendaten zahlreiche Kennungen beinhaltet, die der Vielfalt von Kartenkacheln entsprechen; Parsen, mit einem oder mehreren Prozessoren, der Anfrage nach Kartendaten, um die Vielfalt von Kartenkacheln auf der Grundlage der eindeutigen Kennung und des Satzes relativer Kennungen zu identifizieren; Abruf, mit einem oder mehreren Prozessoren, der Vielfalt von Kartenkacheln von einer Karteninhaltsdatenbank; und Bereitstellung der angeforderten Kartenkacheln an das Client-Gerät.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 21, worin die zahlreichen Kennungen eine eindeutige Kennung einer der Vielfalt von Kartenkacheln und einen Satz relativer Kennungen beinhalten, die anderen der Vielfalt von Kartenkacheln entsprechen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 22, worin die eindeutige Kennung einer der Vielfalt von Kartenkacheln Breiten- und Längengradkoordinaten beinhaltet.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 22 oder 23, worin der Satz der relativen Kennungen die Ganzzahl-Abstufungen beinhaltet, die die Position der anderen der Vielfalt von Kartenkacheln im Verhältnis zu der Position der einen der Vielfalt von Kartenkacheln anzeigen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der Ansprüche 21 bis 24, worin das Parsen der Anfrage nach Kartendaten Folgendes beinhaltet: Identifikation einer Vielfalt von Einträgen in der Anfrage nach Kartendaten; und Verbindung jeder der Vielfalt von Einträgen in der Anfrage nach Kartendaten mit einer bestimmten Kartenkachel in der Karteninhaltsdatenbank.
Greifbares, nicht-flüchtiges computerlesbares Medium nach Anspruch 25, worin das Abrufen der Vielfalt von Kartenkacheln Folgendes beinhaltet: Erstellen einer Vielfalt von Datenbankanfragen, von denen jede einer Kartenkachel in der Karteninhaltsdatenbank entspricht; und Ausführen der Vielfalt von Datenbankanfragen, um die Vielfalt von Kartenkacheln aus der Karteninhaltsdatenbank abzurufen.
Greifbares, nicht-flüchtiges computerlesbares Medium nach jeglichem der Ansprüche 21 bis 26, worin das Abrufen der Vielfalt von Kartenkacheln das Abrufen der Vielfalt von Kartenkacheln aus einer Rasterinhaltsdatenbank und einer Vektordatenbank beinhaltet.