DE112013002790T5

DE112013002790T5 - Virtuelle Kamera für 3D-Karten

Info

Publication number: DE112013002790T5
Application number: DE112013002790.9T
Authority: DE
Inventors: c/o Apple Inc. Piemonte Patrick S.; c/o Apple Inc. Pahwa Aroon; c/o Apple Inc. Moore Christopher D.; c/o Apple Inc. Howard James A.
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2012-06-05
Filing date: 2013-05-31
Publication date: 2015-04-02
Also published as: AU2016222501A1; CN113008265A; CN107155342A; AU2013271971A1; CN107155342B; AU2018264015A1; CN113155147A; AU2013271971B2; AU2018264015B2; WO2013184533A3; US20130321401A1; US9269178B2; WO2013184533A2; AU2016222501B2

Abstract

Einige Ausführungsformen stellen eine Kartenanwendung bereit, welche, zu einer ersten und zweiten Instanz in der Zeit, eine entsprechende erste und zweite Position einer virtuellen Kamera in der 3D-Karte bestimmt. Die virtuelle Kamera identifiziert eine spezielle Position in der 3D, von welcher eine Ansicht der 3D-Karte zu rendern ist, und mehrere Referenzpunkten umfasst. Die Kartenanwendung identifiziert auch erste und zweite Gruppen von Orten der Referenzpunkte bei den ersten und zweiten Positionen der virtuellen Kamera. Die Kartenanwendung bestimmt weiterhin mehrere Pfade in der 3D-Karte basierend auf den ersten und zweiten Gruppen der Orte der Referenzpunkte. Die Kartenanwendung bewegt auch die virtuelle Kamera entlang der mehreren Pfade durch Beibehalten der mehreren Referenzpunkte der virtuellen Kamera auf den entsprechenden mehreren Pfaden in der 3D-Karte, während die Ansichten der 3D-Karte gerendert werden, um eine animierte Ansicht der 3D-Karte bereitzustellen.

Description

HINTERGRUND
Viele heute verfügbare kartenbasierte Anwendungen sind für eine Vielzahl verschiedener Vorrichtungen (z. B. Desktops, Laptops, Tablet-Vorrichtungen, Smartphones, Handgehaltene Empfänger für das globale Positionierungssystem (Global Positioning System, GPS), usw.) und für eine Vielzahl verschiedener Zwecke (z. B. Navigation, Durchsuchung, Sport usw.) bestimmt. Die meisten dieser Anwendungen generieren Anzeigen einer Karte basierend auf Kartendaten, welche den relativen Orte von Straßen, Highways, Punkte von Interesse usw. in der Karte beschreiben.
Die Karten, die in solchen Anwendungen verwendet werden, sind normalerweise zweidimensionale (2D) Karten oder dreidimensionale (3D) Karten. Allerdings nutzt eine große Anzahl der Anwendungen 2D-Karten zum Teil wegen der verarbeitungsintensiven Anforderungen der Betrachtung von 3D-Karten. Aus dem gleichen Grund sind Anwendungen, die 3D-Karten verwenden oft langsam, ineffizient, schlicht und/oder einfach, bis zu dem Punkt, der die Anwendung unbrauchbar macht.
KURZE ZUSAMMENFASSUNG
Einige Ausführungsformen der Erfindung stellen neue Verfahren zum Erzeugen und Präsentieren immersiver und nicht-immersiver 3D-Kartendarstellungen bereit zum Browsen und zur Navigation. In einigen Ausführungsformen können die immersiven und nicht-immersiven 3D-Kartendarstellungen alternativ und/oder sequentiell auf einer Vorrichtung angezeigt werden (z. B. auf einer mobilen Vorrichtung), welche einen berührungsempfindlichen Bildschirm und eine Mehrfachberührungsschnittstelle aufweist, welche einem Benutzer erlauben, mit den Darstellungen über Berührungs- und Gesteneingaben auf dem Bildschirm zu interagieren. In anderen Ausführungsformen werden die Darstellungen auf einer Vorrichtung bereitgestellt, welche keinen berührungsempfindlichen Bildschirm aufweist.
In einigen Ausführungsformen, welche unten beschrieben sind, werden diese 3D-Darstellungen bereitgestellt durch eine integrierte Kartenanwendung, welche einige nützliche Modalitäten bereitstellt, wie beispielsweise Orts-Browsen-, Kartensuch-, Routenidentifizierungs- und Routennavigationsoperationen. Jedoch verwendet in anderen Ausführungsformen die Kartenanwendung nicht alle diese Modalitäten. Zum Beispiel in einigen Ausführungsformen stellt die Kartenanwendung keine Routennavigation bereit.
Um immersive und nicht-immersive 3D-Kartendarstellungen anzuzeigen, müssen einige Ausführungsformen eine Vielzahl von Kacheln für Client-Vorrichtungen zum Rendern erzeugen, um Straßen, Gebäude und umgebende Szenerie zu erzeugen. In einigen Ausführungsformen umfassen Beispiele solcher Kacheln Straßen- und Gebäudekacheln, welche für nicht-immersive 3D-Darstellungen verwendet werden, und die Navigations- und Gebäudekacheln, welche für immersive 3D-Darstellungen verwendet werden.
Vor dem Erzeugen dieser Kacheln muss ein Satz von Servern die Beschreibung der Straße, des Gebäudes und anderer Geometrien erzeugen, welche in jede dieser Kacheln platziert werden. Diese Aufgabe umfasst mehrere Unteraufgaben, wie beispielsweise (1) Empfangen von Kartendaten aus einer Vielzahl von Verkäufern, (2) Verarbeiten solcher Daten zum Erzeugen eindimensionaler (1D) Straßen, (3) Glätten der 1-D-Straßengraphen, (4) Definieren von Daten zum Spezifizieren von Kreuzungen, (5) Erzeugen von 2D-Straßengeometrien und Gelände, (6) Glätten der 2D-Straßengeometrien, (7) Erzeugen von Daten (z. B. geschätzte Höhendaten) bezüglich Gebäuden, (8) Verwenden solcher Daten zum Definieren von Gebäudegeometrien, (9) Konstruieren von Straßengeometriedetails (wie beispielsweise Inseln, Fahrbahnmarkierungen und Distanzen und Geländeoberflächen zwischen Straßengeometrien), und (10) Identifizieren von Geometriekantenknotencharakteristiken und Propagieren solcher Charakteristiken.
Sobald sie auf der Kartendienstseite erzeugt wurden, werden die Kacheln verwendet durch eine Kartenanwendung auf einer Client-Vorrichtung zum Präsentieren von 3D-Karten an Benutzer der Client-Vorrichtungen. Die Kartenanwendung einiger Ausführungsformen verwendet eine Vielzahl von neuen Techniken zum Präsentieren einer 3D-Darstellung einer Karte, während die Karte durchsucht wird oder während die Karte eine Navigationspräsentation bereitstellt. Zum Beispiel rendert die Kartenanwendung die 3D-Darstellung aus der Sicht einer virtuellen Kamera und verwendet unterschiedliche Verfahren zum Bewegen der virtuellen Kamera (d. h. Bewegen der Perspektiven-Render-Position) automatisch in bestimmten Situationen zum Erreichen einer gewünschten 3D-Darstellung. Ein solches Beispiel tritt auf, wenn die Kartenanwendung einiger Ausführungsformen die Position der virtuellen Kamera von einer perspektivischen Rendering-Position hinter einer derzeitigen Position einer sich bewegenden Vorrichtung zu einer Top-down-Ansicht der derzeitigen Position bewegt, wenn die Vorrichtung dabei ist, eine Abbiegung entlang einer Route zu machen. Ein anderes Beispiel sind die Hereinzoomen-/Herauszoomen-Animationen, welche bereitgestellt werden, welche Objekte in der Szene zeigen, welche mit der Hereinzoom-Operation und der Herauszoom-Operation größer werden und schrumpfen.
Auch in einigen Ausführungsformen stellt die Kartenanwendung zwei unterschiedliche Typen von 3D-Darstellungen bereit – eine immersive 3D-Darstellung und eine nicht-immersive 3D-Darstellung. Die immersive Darstellung in einigen Ausführungsformen zeigt nicht nur mehrere Geometrien an, sondern zeigt auch mehr Details für die Geometrien an, welche in der nicht-immersiven Darstellung angezeigt werden. Die Kartenanwendung stellt auch weiche Übergänge zwischen den nicht-immersiven und immersiven Darstellungen bereit.
Um solche weiche Übergänge zu erreichen und andere neue Effekte zu erzeugen, verwendet die Kartenanwendung einiger Ausführungsformen eine neue Bildverarbeitungs-Pipeline. Diese Pipeline führt eine Vielzahl von Vorladeoperationen aus, zum Herunterladen, Abrufen und/oder Dekomprimieren von Kartenkacheln, welche für eine Navigationsanwendung notwendig sein können, zum Vorbereiten seiner Rendering-Pipeline für seine Rendering-Operationen und zum Vorbereiten einer Duplikat-Pipeline zum weichen Übergehen zwischen den immersiven und nicht-immersiven 3D-Darstellungen.
Die vorangegangene Zusammenfassung ist beabsichtigt als eine kurze Einleitung zu einigen Ausführungsformen der Erfindung zu dienen. Diese beabsichtigt keine Einleitung oder Übersicht des gesamten in diesem Dokument offenbarten erfinderischen Gegenstands zu sein. Die nachfolgende detaillierte Beschreibung und die Zeichnungen, die in der detaillierten Beschreibung referenziert werden, werden die Ausführungsformen, welche in der Zusammenfassung beschrieben wurden, sowie andere Ausführungsformen weiter beschreiben. Um dementsprechend alle Ausführungsformen, die in diesem Dokument beschrieben sind, zu verstehen, ist eine vollständige Bewertung der Zusammenfassung, der detaillierten Beschreibung und der Zeichnungen notwendig. Außerdem sind die beanspruchten Gegenstände nicht durch die erklärenden Details in der Zusammenfassung der detaillierten Beschreibung und den Zeichnungen einzuschränken, sind jedoch eher durch die angehängten Ansprüche zu definieren, weil die beanspruchten Gegenstände in anderen spezifischen Formen verkörpert werden können, ohne vom Geist der Gegenstände abzuweichen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die neuen Merkmale der Erfindung werden in den angehängten Ansprüchen dargelegt. Jedoch zum Zwecke der Erklärung werden einige Ausführungsformen der Erfindung in den folgenden Figuren dargelegt.
1 zeigt ein Beispiel einer Vorrichtung, welche eine integrierte Kartenanwendung einiger Ausführungsformen der Erfindung ausführt.
2 zeigt, wie die Navigationsanwendung einiger Ausführungsformen eine 3D-Steuerung als einen schnellen Mechanismus zum Eintreten in einen 3D-Navigationsmodus bereitstellt.
3 stellt ein vereinfachtes Beispiel dar zum Zeigen des Konzepts einer virtuellen Kamera.
4 zeigt die Anpassung der Distanz einer virtuellen Kamera durch Zusammenzieh- und Erweiterungsgesten.
5 zeigt eine Ausführungsform einer Kamera, deren Winkel durch Gesten angepasst werden kann.
6 zeigt konzeptionell das Kartendienstverarbeiten einiger Ausführungsformen.
7 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Erzeugen eines Straßengraphen.
8 zeigt unterschiedliche Datenstrukturen einiger Ausführungsformen für die Straßen innerhalb einer Kartenregion.
9 zeigt ein Beispiel einer Modifikation für zwei Straßensegmente, welche an einer Kreuzung zusammentreffen.
10 zeigt ein Beispiel dreier Straßensegmente, welche Kandidaten sind zur Aggregation in eine Straße bei einer Kreuzung.
11 zeigt eine Situation, in welcher ein erstes Straßensegment gekreuzt wird (in einer Ebene) von einem zweiten Straßensegment und einem dritten Straßensegment.
12 zeigt zwei Straßensegmente, welche eine Distanz X voneinander entfernt sind, parallel in entgegengesetzten Richtungen laufen, und den gleichen Namen haben.
13 und 14 zeigen ähnlich geknickte Straßen, welche Geschwindigkeitsbeschränkungen von 25 mph und 60 mph haben.
15 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Erzeugen der Straßengeometrie, welche zu verwenden ist zum Erzeugen von Straßenpolygonen auf der Client-Kartenanwendung.
16 zeigt eine Operation, welche ausgeführt wird zum Glätten einer Spurexpansionskreuzung, in welcher eine der Seiten der Straßen gerade bleibt (d. h. „justiert” wird).
17 zeigt das Ergebnis der geglätteten Spurerweiterung aus 16, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
18 veranschaulicht eine Operation, welche ausgeführt wird zum Glätten einer Spurerweiterungskreuzung, in welcher sich die Straße an beiden Seiten erweitert.
19 zeigt das Ergebnis der geglätteten Spurerweiterung aus 18, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
20 zeigt eine Abschrägungsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien, wenn der Winkel zwischen den Segmenten größer als ein erster Schwellenwinkel ist.
21 zeigt das Ergebnis der geglätteten Kreuzung aus 20, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
22 zeigt eine Projektionsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien, wenn der Winkel zwischen den Segmenten geringer als ein erster Schwellenwinkel ist und größer als ein zweiter Schwellenwinkel ist.
23 zeigt das Ergebnis der geglätteten Kreuzung aus 22, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
24 zeigt eine Clipping-Operation, welche ausgeführt wird zum Eliminieren von überschüssigen Straße-zu-Straße-Segmentgeometrien, wenn der Winkel zwischen den Segmenten geringer als ein erster Schwellenwinkel ist und größer als ein zweiter Schwellenwinkel ist.
25 zeigt eine Schnittoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen zwei Straßensegmentgeometrien.
26 zeigt das Ergebnis der geglätteten Kreuzung aus 24 und 25, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
27 zeigt eine Abschrägungsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien in Situationen, welche zu Charakteristiken von Autobahnauffahrten passen, in einigen Ausführungsformen.
28 zeigt das Ergebnis der geglätteten Autobahnzusammenführungskreuzung aus 27, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
29 zeigt die Erzeugung von zusätzlichen Geometrien bei einer Kreuzung, um realistischere, gerundete Ecken bei der Kreuzung zu erzeugen.
30 zeigt das Ergebnis der geglätteten Straßenkreuzung aus 29, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
31 zeigt Wegdrücken zweier Straßen, wenn sie sich überlappen.
32 zeigt Reduzieren der Breiten zweier Straßensegmente, wenn die Straßensegmente sich überlappen.
33 und 34 zeigen doppelspurige Fahrbahnen mit zwei unterschiedlichen Typen von Medianen.
35 zeigt ein Beispiel von Geometrien für eine Kreuzung zweier Hauptverkehrsstraßen.
36 zeigt das Ergebnis der Kreuzung aus 35, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
37 zeigt ein Beispiel der Verwendung von Knoten-Beschriftung zum Spezifizieren von Brückenumhüllung für eine Straßenüberführung, wo eine Straße über einer anderen Straße läuft und die Straßen nicht eine Kreuzung bilden.
38 zeigt das Ergebnis der Straßensegmente aus 37, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
39 zeigt ein Beispiel der Verwendung von Knoten-Beschriftungen zum Spezifizieren einer Kante einer Straßensegmentgeometrie als eine innere Kante, was darauf hindeutet, dass keine Umhüllung für die gerichtete Kante aus dem beschrifteten Knoten gezeichnet werden sollte.
40 zeigt das Ergebnis der Straßensegmente aus 39, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
41 zeigt ein Beispiel der Verwendung von Knoten-Beschriftung zum Spezifizieren eines Tunnels für ein Straßensegment, was darauf hindeutet, dass der Tunnel über dem Straßensegment gezeichnet werden sollte.
42 zeigt das Ergebnis der Straßensegmente aus 41, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen
43 zeigt ein Beispiel der Verwendung von Knoten-Beschriftung zum Spezifizieren eines Fußwegs für eine Seite eines Straßensegments.
44 zeigt das Ergebnis des Straßensegments von 43, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
45 zeigt ein Beispiel der Verwendung von mehreren Beschriftungen für einen einzelnen Knoten einiger Ausführungsformen.
46 zeigt das Ergebnis der Straßensegmente von 45, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
47 zeigt ein Beispiel der Verwendung von Knoten-Beschriftungsdaten zum Variieren einer Eigenschaft der Straßenumhüllung für eine Straßengeometrie.
48 zeigt das Ergebnis des Straßensegments aus 47, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen.
49 zeigt konzeptionell eine Operation, welche durch einen Kartendienst einiger Ausführungsformen ausgeführt wird zum Erzeugen einer Route für eine anfragende Vorrichtung und Bereitstellen der Route, mit Navigationsinstruktionen, an die anfragende Vorrichtung.
50 zeigt konzeptionell einen Prozess, welche durch den Kartendienst einiger Ausführungsformen ausgeführt wird, um Routen- und Verkehrskreuzungsdaten an einen Benutzer zu erzeugen und zu übertragen.
51 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Bestimmen von Pfadsegmenten zwischen Sätzen von Kreuzungen, welche zusammen als einzelne Verkehrskreuzungen behandelt werden sollten.
52 zeigt ein Beispiel einer Kreuzung einiger Ausführungsformen und zeigt, dass es keine Notwendigkeit gibt, dass die Pfadsegmente bei rechten Winkeln aufeinandertreffen oder dass die Pfade in einer geraden Linie durch die Kreuzung fortfahren.
53 zeigt eine Verkehrskreuzung einiger Ausführungsformen, welche zwei doppelspurige Fahrbahnpfade und eine Einbahnstraße umfasst.
54 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Verbinden einiger Kreuzungen in eine einzelne Verkehrskreuzung und Identifizieren der Zweige der Verkehrskreuzung.
55 zeigt eine üblicherweise existierende Verkehrskreuzung einiger Ausführungsformen zwischen einer zweispurigen Fahrbahn mit zwei Pfaden und einer zweispurigen Fahrbahn mit zwei Pfaden.
56 zeigt eine Verkehrskreuzung einiger Ausführungsformen, in welcher Linksabbiegerkanäle als separate Pfadsegmente definiert sind.
57 zeigt eine Autobahnauffahrt in einer Verkehrskreuzung einiger Ausführungsformen.
58 zeigt eine Verkehrskreuzung einiger Ausführungsformen mit sowohl einer Autobahnauffahrt als auch Linksabbiegerkanälen.
59 zeigt einen zusätzlichen Zwei-Wege-Pfad in einer Verkehrskreuzung in einigen Ausführungsformen.
60 zeigt die Reduktion einer achtpfadigen Verkehrskreuzung in vier Abzweigungen in einigen Ausführungsformen.
61 zeigt die Reduktion von einer unterschiedlichen achtpfadigen Verkehrskreuzung in fünf Abzweigungen in einigen Ausführungsformen.
62 zeigt konzeptionell ein Beispiel einer Datenstruktur einiger Ausführungsformen für eine Punkttyp-Verkehrskreuzung.
63 zeigt konzeptionell eine Datenstruktur einiger Ausführungsformen für eine Kreisverkehrskreuzung.
64 zeigt konzeptionell die Reduktion einer Kreisverkehrskreuzung zu Verkehrskreuzungsdaten in einigen Ausführungsformen.
65 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Modifizieren von Verkehrskreuzungsdaten, um Navigationsinformation für eine Route bereitzustellen.
66 zeigt eine konzeptionelle Zeichnung einer Route, welche durch eine Verkehrskreuzung genommen wird, eine Datenstruktur für die Verkehrskreuzung und die Modifikation der Datenstruktur zum Erzeugen einer neuen Datenstruktur für Punkt-zu-Punkt-Navigationsinstruktionen.
67 zeigt konzeptionell einen Prozess, welche durch einige Ausführungsformen der Erfindung ausgeführt wird, ausgeführt zum Zusammenführen von Geländeoberflächenpolygonen zu Straßenpolygonen.
68 zeigt ein Beispiel des Zusammenführens von Geländeoberflächen zu Straßenpolygonen.
69 zeigt konzeptionell einen Prozess, welcher Grenzen zwischen benachbarten Polygonen zusammenführt, welche empfangen wurden aus zwei unterschiedlichen Quellen, in einigen Ausführungsformen.
70 zeigt zwei Stufen einiger Ausführungsformen der Erfindung, welche identifizierte Lücken auflösen durch Zusammenführen von Grenzkoordinaten zwischen benachbarten Polygonen.
71 zeigt zwei Stufen einiger Ausführungsformen der Erfindung, welche die Grenzkoordinaten der Polygone um identifizierte Überlappungen zusammenführen.
72 zeigt konzeptionell einen Prozess, welcher durch einige Ausführungsformen der Erfindung ausgeführt wird, zum Auflösen von für Grenzkonflikten zwischen Regionen.
73 zeigt ein Beispiel des Auflösens eines Grenzkonflikts zwischen zwei benachbarten Regionen.
74 zeigt konzeptionell ein Beispiel einer virtuellen Kamera, welche sich automatisiert um eine Region einer 3D-Karte bewegt, basierend auf einer Routennavigation, gemäß einigen Ausführungsformen der Erfindung.
75 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Animieren von Kartenansichten während einer Routennavigation.
76 zeigt konzeptionell ein Beispiel einer virtuellen Kamera, welche automatisiert eine Abbiegung in einer 3D-Karte manövriert, während sie auf einer Routennavigation ist, gemäß einigen Ausführungsformen der Erfindung.
77 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Animieren einer Kartenansicht während einer Abbiegung einer Routennavigation.
78 zeigt konzeptionell ein Beispiel einer virtuellen Kamera, welche um eine 3D-Karte während einer Routennavigation herumschwenkt, gemäß einigen Ausführungsformen der Erfindung.
79 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Schwenken auf die Seite einer Kartenansicht, basierend auf Gesteneingabe.
80 zeigt konzeptionell ein perspektivisches Anpassungsmerkmal, welches durch eine Kartenanwendung einiger Ausführungsformen bereitgestellt wird.
81 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Anpassen der Position einer virtuellen Kamera, welche verwendet wird zum Rendern einer Kartenansicht in Antwort auf eine perspektivische Anpassung.
82 zeigt konzeptionell eine virtuelle Kamera, welche entlang unterschiedlicher Bögen bei unterschiedlichen Zoom-Leveln gemäß einigen Ausführungsformen der Erfindung bewegbar ist.
83 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Bestimmen eines Bogens, entlang welchem eine virtuelle Kamera bewegbar ist.
84 zeigt konzeptionell ein Merkmal, welches durch die Kartenanwendung einiger Ausführungsformen bereitgestellt wird zum Beibehalten der Position einer virtuellen Kamera innerhalb eines definierten Bereichs entlang eines Bogens.
85 zeigt ein Zoom-Anpassungsmerkmal, welches durch die Kartenanwendung einiger Ausführungsformen bereitgestellt wird.
86 zeigt konzeptionell einen Prozess einiger Ausführungsformen, welcher die Position einer virtuellen Kamera anpasst, welche verwendet wird zum Rendern einer Kartenansicht in Antwort auf eine Zoom-Level-Anpassung.
87 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht gemäß einiger Ausführungsformen der Erfindung.
88 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht nach einer Aktivierung eines Positionsindikatormerkmals gemäß einiger Ausführungsformen der Erfindung.
89 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht von einer 2D-perspektivischen Ansicht der 3D-Karte gemäß einigen Ausführungsformen der Erfindung.
90 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Rotieren einer Kartenansicht basierend auf Gesteneingabe.
91 zeigt konzeptionell ein Beispiel einer Kartenanwendung einiger Ausführungsformen, welche 3D-Kartenansichten für unterschiedliche Zoom-Level unterschiedlicher Ansichtsmodi rendert.
92 zeigt die Bewegung der virtuellen Kamera um die Region einer 3D-Karte herum, welche definiert ist, durch einen immersiven Ansichtsmodus einiger Ausführungsformen betrachtet zu werden.
93 zeigt die Bewegung der virtuellen Kamera um die Region einer 3D-Karte herum, welche definiert ist, durch einen nicht-immersiven Betrachtungsmodus einiger Ausführungsformen betrachtet zu werden.
94 zeigt konzeptionell ein Beispiel einer Kartenanwendung einiger Ausführungsformen, welche 3D-Kartenansichten für unterschiedliche Zoom-Level unterschiedlicher Betrachtungsmodi rendert.
95 zeigt konzeptionell eine Verarbeitungs-Pipeline, welche durch die Kartenanwendung einiger Ausführungsformen ausgeführt wird zum Rendern von 3D-Kartenansichten basierend auf unterschiedlichen 3D-Kartenkacheln.
96 zeigt konzeptionell eine Datenstruktur, welche durch die Verarbeitungs-Pipeline einiger Ausführungsformen verwendet wird.
97 zeigt konzeptionell ein Zustandsdiagramm einer Kartenanwendung einiger Ausführungsformen.
98 zeigt konzeptionell eine Verarbeitungs-Pipeline, welche durch die Kartenanwendung einiger Ausführungsformen ausgeführt wird, um eine Karte zur Anzeige an der Client-Vorrichtung zu rendern.
99 zeigt die Anwendung unterschiedlicher Texturen auf unterschiedliche Typen von Straßen, für einige Ausführungsformen.
100 zeigt eine Kartendarstellung, welche eine Hauptstraße und zwei Verbindungsstraßen umfasst.
101 zeigt eine nicht-immersive Kartendarstellung, welche das Rendern von Straßen in einer Kartenkachel der Karten-Browsing-Ansicht zeigt.
102 zeigt konzeptionell eine Steuereinheit, welche zwei virtuelle Kameras für zwei unterschiedliche Ansichten der Kartenregionen instanziiert.
103 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Vorladen von Navigationskacheln zum Eintreten in Navigation.
104 zeigt eine Vorrichtung, welche eine Kartenanwendung anzeigt, während die Anwendung von einer nicht-immersiven Kartenansicht zum Karten-Browsen in eine immersive Kartenansicht zur Navigation übergeht.
105 zeigt konzeptionell ein Zustandsdiagramm 10500, welches unterschiedliche Zustände beschreibt und zwischen diesen Zuständen des integrierten Abbildens, Suchen und der Navigationsanwendung einiger Ausführungsformen übergeht.
106 ist ein Beispiel einer Architektur einer mobilen Rechnervorrichtung.
107 zeigt konzeptionell ein Beispiel eines elektronischen Systems, mit welchem einige Ausführungsformen der Erfindung implementiert werden.
108 zeigt eine Kartendienstbetriebsumgebung, gemäß einigen Ausführungsformen.
DETAILLIERTE BESCHREIBUNG
Einige Ausführungsformen der Erfindung stellen neue Verfahren zum Erzeugen und Präsentieren von immersiven und nicht-immersiven 3D-Kartendarstellungen zum Browsen und Navigation bereit. In einigen Ausführungsformen können die immersiven und nicht-immersiven 3D-Kartendarstellungen alternativ und/oder sequentiell auf einer Vorrichtung angezeigt werden (z. B. einer mobilen Vorrichtung), welche einen berührungsempfindlichen Bildschirm und eine Multitouch-Schnittstelle aufweist, welche einem Benutzer erlauben, mit den Darstellungen über Berührungs- und Gesteneingaben auf dem Bildschirm zu interagieren. In anderen Ausführungsformen werden die Darstellungen auf einer Vorrichtung bereitgestellt, welche keinen berührungsempfindlichen Bildschirm aufweist.
In einigen Ausführungsformen, welche unten beschrieben sind, werden diese 3D-Darstellungen bereitgestellt durch eine integrierte Kartenanwendung, welche einige nützliche Modalitäten bereitstellt, wie beispielsweise Orts-Browsen-, Kartensuch-, Routenidentifizieren- und Routennavigationsoperationen. Jedoch verwendet in anderen Ausführungsformen die Kartenanwendung nicht alle diese Modalitäten. Zum Beispiel in einigen Ausführungsformen stellt die Kartenanwendung keine Routennavigation bereit.
Um immersive und nicht-immersive 3D-Kartendarstellungen anzuzeigen, müssen einige Ausführungsformen eine Vielzahl von Kacheln für Client-Vorrichtungen zum Rendern erzeugen, um Straßen, Gebäude und umgebende Szenerie zu erzeugen. In einigen Ausführungsformen umfassen Beispiele solcher Kacheln Straßen- und Gebäudekacheln, welche für nicht-immersive 3D-Darstellungen verwendet werden, und die Navigations- und Gebäudekacheln, welche für immersive 3D-Darstellungen verwendet werden.
Vor dem Erzeugen dieser Kacheln muss ein Satz von Servern die Beschreibung der Straße, des Gebäudes und anderer Geometrien erzeugen, welche in jede dieser Kacheln platziert werden. Diese Aufgabe umfasst mehrere Unteraufgaben, wie beispielsweise (1) Empfangen von Kartendaten von einer Vielzahl von Verkäufern, (2) Verarbeiten solcher Daten zum Erzeugen eindimensionaler (1D) Straßen, (3) Glätten der 1-D-Straßengraphen, (4) Definieren von Daten zum Spezifizieren von Kreuzungen, (5) Erzeugen von 2D-Straßengeometrien und Geländeoberfläche, (6) Glätten der 2D-Straßengeometrien, (7) Erzeugen von Daten (z. B. geschätzte Höhendaten) bezüglich der Gebäude, (8) Verwenden solcher Daten zum Definieren von Gebäudegeometrien, (9) Konstruieren von Straßengeometriedetails (wie beispielsweise Inseln, Fahrbahnmarkierungen und Distanzen und Geländeoberflächen zwischen Straßengeometrien), und (10) Identifizieren von Geometriekantenknotencharakteristiken und Propagieren solcher Charakteristiken.
Sobald sie auf der Kartendienstseite erzeugt wurden, werden die Kacheln verwendet durch eine Kartenanwendung auf einer Client-Vorrichtung zum Präsentieren von 3D-Karten an Benutzer der Client-Vorrichtungen. Die Kartenanwendung einiger Ausführungsformen verwendet eine Vielzahl von neuen Techniken zum Präsentieren einer 3D-Darstellung einer Karte, während die Karte durchsucht (browsed) wird oder während die Karte eine Navigationspräsentation bereitstellt. Zum Beispiel rendert die Kartenanwendung die 3D-Darstellung aus der Sicht einer virtuellen Kamera und verwendet verschiedene Verfahren zum Bewegen der virtuellen Kamera (d. h. Bewegen der Perspektiven-Rendering-Position) automatisch in bestimmten Situationen zum Erreichen einer gewünschten 3D-Darstellung. Ein solches Beispiel tritt auf, wenn die Kartenanwendung einiger Ausführungsformen die Position der virtuellen Kamera von einer perspektivischen Rendering-Position hinter eine derzeitige Position einer sich bewegenden Vorrichtung zu einer Top-down-Ansicht der derzeitigen Position bewegt, wenn die Vorrichtung dabei ist, eine Abbiegung entlang einer Route zu machen. Ein anderes Beispiel sind die Hereinzoomen/Herauszoomen-Animationen, welche bereitgestellt werden, welche Objekte in der Szene zeigen, welche mit der Hereinzoom-Operation und der Herauszoom-Operation größer werden und schrumpfen.
Auch in einigen Ausführungsformen stellt die Kartenanwendung zwei unterschiedliche Typen von 3D-Darstellungen bereit – eine immersive 3D-Darstellung und eine nicht-immersive 3D-Darstellung. Die immersive Darstellung in einigen Ausführungsformen zeigt nicht nur mehrere Geometrien an, sondern zeigt auch mehr Details für die Geometrien an, welche in der nicht-immersiven Darstellung angezeigt werden. Die Kartenanwendung stellt auch weiche Übergänge zwischen den nicht-immersiven und immersive Darstellungen bereit.
Um solche weichen Übergänge zu erreichen und andere neue Effekte zu erzeugen, verwendet die Kartenanwendung einiger Ausführungsformen eine neue Bildverarbeitungs-Pipeline. Diese Pipeline führt eine Vielzahl von Vorladeoperationen aus, zum Herunterladen, Abrufen und/oder Dekomprimieren von Kartenkacheln, welche für eine Navigationsanwendung notwendig sein können, zum Vorbereiten seiner Rendering-Pipeline für seine Rendering-Operationen und zum Vorbereiten einer Duplikat-Pipeline zum weichen Übergehen zwischen der immersiven und nicht-immersiven 3D-Darstellungen.
Abschnitt I unten beschreibt die Kartenanwendung einiger Ausführungsformen der Erfindung. Abschnitt II beschreibt dann Server-seitige Operationen zum Erzeugen der Kacheln, welche benötigt werden zum Erzeugen von immersiven und nicht-immersiven 3D-Darstellungen. Abschnitt III beschreibt dann Client-seitige Operationen zum Erzeugen von immersiven und nicht-immersiven 3D-Darstellungen. Abschnitt IV beschreibt dann elektronische Vorrichtungen, welche die Kartenanwendung einiger Ausführungsformen verwenden. Abschnitt V beschreibt schließlich Ortsdienste, welche durch einige Ausführungsformen der Erfindung verwendet werden.
In der folgenden detaillierten Beschreibung der Erfindung sind zahlreiche Details, Beispiele und Ausführungsformen der Erfindung dargelegt und beschrieben. Allerdings wird einem Fachmann klar und offensichtlich sein, dass die Erfindung nicht auf die dargelegten Ausführungsformen limitiert ist und dass die Erfindung ohne einige der spezifischen Details und diskutierten Beispiele ausgeübt werden kann.
I. Navigationsbenutzerschnittstelle
A. Start
Die Navigationsanwendung einiger Ausführungsformen ist Teil einer integrierten Kartenanwendung, die mehrere nützliche Modalitäten beinhaltet, einschließlich Ortsdurchsuchungs-, Kartensuch-, Routenidentifizierungs- und Routennavigationsoperationen. Diese integrierte Anwendung (im Folgenden als Kartenanwendung, die Navigationsanwendung oder integrierte Anwendung bezeichnet) ist in einigen Ausführungsformen definiert durch eine Vorrichtung ausgeführt zu werden, die einen berührungsempfindlichen Bildschirm aufweist, welcher die Ausgabe der Anwendung anzeigt. In einigen Ausführungsformen hat diese Vorrichtung eine Mehrfachberührungsschnittstelle, um einem Benutzer zu erlauben, mit der Anwendung durch die Bereitstellung von Berührungs- und gestischen Eingaben über den Bildschirm zu interagieren. Beispiele solcher Vorrichtungen sind Smartphones (z. B. iPhone^®, verkauft von Apple Inc., Telefone, die das Android^®-Betriebssystem betreiben, Telefone, die das Windows 8^®-Betriebssystem betreiben usw.).
1 veranschaulicht ein Beispiel einer Vorrichtung 100, die eine integrierte Kartenanwendung einiger Ausführungsformen der Erfindung ausführt. Diese Figur veranschaulicht auch ein Beispiel vom Starten einer Routennavigation in dieser Anwendung. Diese Anwendung hat ein neuartiges Design einer Benutzerschnittstelle (UI), das nahtlos und zusammenhängend die Steuerungen für jede ihrer unterschiedlichen Modalitäten durch Nutzung einer minimalen Menge von sich auf dem Bildschirm befindenden Steuerungen integriert, welche über dem Inhalt schweben, um so viel wie möglich vom Inhalt anzuzeigen. Zusätzlich passt sich dieses Cluster der vorliegenden Aufgabe an, ihren Inhalt in einer animierten Weise einzustellen, wenn ein Benutzer sich zwischen den unterschiedlichen Modalitäten bewegt (z. B. zwischen Durchsuchen, Suchen, Leiten und Navigieren). Dieses gemeinsame Element mit einer adaptiven Natur ermöglicht der Kartenanwendung, sich für unterschiedliche Aufgaben zu optimieren, während ein konsistentes Aussehen und ein Interaktionsmodell während des Bewegens zwischen diesen Aufgaben, beibehalten wird.
1 zeigt sechs Stufen 105, 110, 115, 117, 119, 121 von Interaktionen mit der Kartenanwendung. Die erste Stufe 105 zeigt die UI 120 einer Vorrichtung, welche mehrere Symbole von mehreren Anwendungen in einem Dockbereich 125 und auf einer Seite der UI beinhaltet. Eines der Symbole auf dieser Seite ist das Symbol für die Kartenanwendung 130. Die erste Stufe zeigt eine Benutzerauswahl von der Kartenanwendung durch einen Berührungskontakt mit dem Vorrichtungsbildschirm an dem Ort dieser Anwendung auf dem Bildschirm.
Die zweite Stufe 110 zeigt die Vorrichtung nachdem die Kartenanwendung geöffnet ist. Wie in dieser Stufe gezeigt, hat die UI der Kartenanwendung eine Startseite, welche in einigen Ausführungsformen (1) eine Karte des aktuellen Orts der Vorrichtung und (2) mehrere, in einem oberen Balken 140 und als schwebende Steuerungen angeordnete UI-Steuerungen, zeigt. Wie 1 zeigt, beinhalten schwebende Steuerungen einen Indikator 145, eine 3D-Steuerung 150 und eine Seitenrollsteuerung 155, während der obere Balken 140 eine Anweisungssteuerung 160, ein Suchfeld 165 und eine Lesezeichensteuerung 170 beinhaltet.
In einigen Ausführungsformen kann ein Benutzer eine Suche durch Tippen in das Suchfeld 165 initiieren. Dies führt die Anwendung dazu, eine Animation darzustellen, die (1) eine sich auf dem Bildschirm befindende Tastatur darstellt und (2) eine Suchtabelle gefüllt mit überaus wertvollen Vervollständigungen öffnet. Diese Tabelle hat einige wichtige Feinheiten. Wenn das Suchfeld angetippt wird und bevor die Begriffe bearbeitet werden, oder wenn das Suchfeld leer ist, enthält die Tabelle eine Liste von ”Letzten”, welche in einigen Ausführungsformen letzte Suchen und Routenanweisungen, die der Benutzer angefragt hat, sind. Dies macht es sehr einfach, um zuletzt zugegriffene Resultate hervorzubringen.
Nach einer beliebigen Bearbeitung in dem Suchfeld ist die Tabelle gefüllt mit Suchvervollständigungen sowohl von lokalen Quellen (z. B. Lesezeichen, Kontakte, letzte Suchen, letzte Routenanweisungen usw.) als auch Fernservern. Die Eingliederung der Kontaktkarte des Benutzers in die Suchschnittstelle fügt dem Design zusätzliche Flexibilität hinzu. Wenn Letzte anzeigt werden, wird eine Route vom aktuellen Ort zu dem Zuhause des Benutzers immer in einigen Ausführungsformen angeboten, während sie in anderen Zusammenhängen, die für ”angemessen” gehalten werden, in anderen Ausführungsformen angeboten werden. Auch wenn der Suchbegriff wenigstens einen Teil einer Adressbezeichnung (z. B. ”Wo” oder ”ork” für ”Work”) entspricht, stellt die Anwendung die bezeichnete Adresse des Benutzers als eine Vervollständigung in der Suchtabelle in einigen Ausführungsformen dar. Zusammen machen diese Verhalten die Such-UI zu einer sehr mächtigen Art, um Resultate auf einer Karte von einer Vielzahl an Quellen zu erhalten. Zusätzlich zum einem Benutzer Erlauben, eine Suche zu initiieren, erlaubt die Anwesenheit des Textfeldes in der primären Kartenansicht in einigen Ausführungsformen auch Benutzern die Anfrage entsprechend der Suchresultate auf der Karte zu sehen und diese Suchresultate durch Löschen der Anfrage zu entfernen.
Die Lesezeichensteuerung 170 (z. B. Knopf) erlaubt Orten und Routen, von der Anwendung markiert zu werden. Der Positionsindikator 145 erlaubt es, die aktuelle Position der Vorrichtung speziell auf der Karte zu vermerken. Sobald dieser Indikator einmal ausgewählt ist, behält die Anwendung die aktuelle Position der Vorrichtung im Zentrum der Karte bei. In einigen Ausführungsformen kann es auch die Richtung identifizieren, in welche die Vorrichtung aktuell zeigt.
Die 3D-Steuerung 150 ist eine Steuerung zum Betrachten einer Karte oder zum Ansehen einer Route in drei Dimensionen (3D). Die Kartenanwendung stellt die 3D-Steuerung als einen schnellen Mechanismus zum Hinein- und Hinauskommen aus 3D bereit. Diese Steuerung dient auch als (1) ein Indikator, dass die aktuelle Ansicht eine 3D-Ansicht ist, (2) ein Indikator, dass eine 3D-Perspektive für eine gegebene Kartenansicht verfügbar ist (z. B. eine Kartenansicht, die herausgezoomt ist, hat womöglich eine 3D-Ansicht verfügbar), (3) ein Indikator, dass eine 3D-Perspektive nicht verfügbar ist (z. B. die 3D-Daten sind für die Kartenregion nicht verfügbar) und (4) ein Indikator, dass eine Überfluganimation an der gegebenen Zoomstufe verfügbar ist. Die 3D-Steuerung kann eine unterschiedliche Erscheinung entsprechend jeder Angabe bereitstellen. Zum Beispiel kann die 3D-Steuerung grau eingefärbt sein, wenn die 3D-Ansicht nicht verfügbar ist, schwarz, wenn die 3D-Ansicht verfügbar, aber die Karte in der 2D-Ansicht ist und blau, wenn die Karte in der 3D-Ansicht ist. In einigen Ausführungsformen ändert sich die 3D-Steuerung zu einem Bild von einem Gebäude, wenn die Überfluganimation für die gegebene Zoomstufe und den Ort auf der Karte des Benutzers verfügbar ist.
Die Seitenrollsteuerung 155 ist eine Steuerung, die es der Anwendung erlaubt, die Anzahl von sich auf dem Bildschirm befindenden Steuerungen zu minimieren, durch Platzierung von einigen weniger häufig benutzten Aktionen in einen sekundären UI-Bildschirm, der durch die Seitenrollsteuerung, die auf der Karte angezeigt ist, zugreifbar ist. In einigen Ausführungsformen wird die Seitenrolle permanent auf wenigstens einigen der Kartenansichten, die die Anwendung bereitstellt, angezeigt. Zum Beispiel zeigt in einigen Ausführungsformen die Anwendung die Seitenrolle permanent auf der Startseite an (veranschaulicht in der zweiten Stufe 110), die es bereitstellt, einem Benutzer zu erlauben zu durchsuchen oder einen Ort zu suchen oder eine Route zu identifizieren.
Die Anweisungssteuerung 160 öffnet eine Anweisungseintragsseite 180 durch welche ein Benutzer eine Route anfragen kann, welche zwischen einem Startort und einem Endort zu identifizieren ist. Die dritte Stufe 115 von 1 veranschaulicht, dass die Auswahl der Anweisungssteuerung 160 die Anweisungseintragsseite 180 öffnet, welche in der vierten Stufe 117 gezeigt wird. Die Anweisungssteuerung ist einer von drei Mechanismen, durch welchen die Kartenanwendung dazu geführt werden kann, eine Route zwischen zwei Orten zu identifizieren und anzuzeigen; die zwei anderen Mechanismen sind (1) eine Steuerung in einem Informationsbanner, welcher für ein selektiertes Element in der Karte angezeigt wird, und (2) letzte, durch die Vorrichtung identifizierte Routen, die in dem Suchfeld 165 angezeigt werden. Dementsprechend sind die Informationsbannersteuerung und das Suchfeld 165 zwei UI-Werkzeuge, die die Anwendung einsetzt, um den Übergang zwischen den unterschiedlichen Modalitäten nahtlos zu machen.
Die vierte Stufe 117 zeigt, dass die Anweisungseintragsseite 180 Start- und Endfelder beinhaltet, um Start- und Endort für eine Route bereitzustellen und eine Tabelle, welche letzte Routen, die die Anwendung dem Benutzer bereitgestellt hat, auflistet. Andere Steuerungen auf dieser Seite sind Steuerungen zum Starten einer Route, zum Umkehren der Reihenfolge von Start- und Endort, zum Abbrechen der Anweisungsanfrage, und zum Auswählen von Gehen, Auto, oder öffentlichen Verkehrsmittelrouten. Diese Steuerungen und andere Aspekte der Kartenanwendung werden beschrieben in der vorläufigen US-Patentanmeldung 61/656,080 mit dem Titel „Integrated Location Browsing, Map Searching, Route Identifying, and Route Navigating Application”, eingereicht am 06.06.2012; vorläufigen US-Patentanmeldung 61/699,841 mit dem Titel „Problem Reporting”, eingereicht am 11.09.2012; und US-Patentanmeldung 13/632,102 mit dem Titel „Problem Reporting in Maps”, eingereicht am 30.09.2012. Die vorläufigen Anmeldungen 61/656,080 und 61/699,841, sowie die Patentanmeldung 13/632,102 werden hierin durch Verweis aufgenommen.
Die vierte Stufe veranschaulicht die Benutzerauswahl einer der letzten Richtungen, die in der Tabelle 182 automatisch befüllt waren. Die fünfte Stufe 119 zeigt anschließend drei Routen auf einer 2D-Kartenansicht zwischen den spezifizierten Start- und Endorten, welche durch die Seite 180 spezifiziert werden. Es zeigt auch die Auswahl der zweiten Route und einige Informationen über diese Route in einem Balken an dem oberen Ende des Aufbaus. Dieser Balken wird gezeigt, um Start- und Beenden-Knöpfe zu beinhalten. Der Start-Knopf wird selektierend in der fünften Stufe gezeigt.
Wie durch die sechste Stufe gezeigt wird, leitet die Auswahl des Start-Knopfes die Anwendung dazu, einen Punkt-zu-Punkt-Navigationsmodus zu betreten. In diesem Beispiel hat die Anwendung einen 2D-Punkt-zu-Punkt-Navigationsmodus betreten. In anderen Ausführungsformen wird die Anwendung standardmäßig einen 3D-Punkt-zu-Punkt-Navigationsmodus betreten. In diesem Modus zeigt die Anwendung ein realistisches Schild 184, das die Distanz vom aktuellen Ort der Vorrichtung zu dem nächsten Manöver in der zu navigierenden Route identifiziert, und einige andere sachdienliche Informationen. Die Anwendung zeigt auch einen oberen Balken, der einige Informationen über die Navigation sowie auch Beenden- und Übersichts-Knöpfe zum Beenden der Navigation bzw. Erhalten einer Übersicht von dem verbleibenden Anteil der zu navigierenden Route oder den ganzen Anteil von der zu navigierenden Route in anderen Ausführungsformen, beinhaltet.
Die Kartenanwendung identifiziert in einigen Ausführungsformen den Ort der Vorrichtung, indem sie die Koordinaten (z. B. Längs-, Höhen- und Breitenkoordinaten) in dem GPS-Signal verwendet, welches die Vorrichtung an dem Ort der Vorrichtung empfängt. Alternativ oder verbindend verwendet die Kartenanwendung andere Methoden (z. B. Mobilfunkmast-Triangulation), um den aktuellen Ort zu berechnen. Wenn der Benutzer, der die Vorrichtung trägt, von der Route abweicht, verfolgt die Kartenanwendung in einigen Ausführungsformen den Ort der Vorrichtung und berechnet eine neue Route von dem abgewichenen Ort neu, um den Benutzer zu dem Zielort vom abgewichenen Ort zurückzuführen. Mit anderen Worten benötigt die Kartenanwendung einiger Ausführungsformen, betrieben im Navigationsmodus, dass die Vorrichtung sich zu jeder Zeit entlang der Route befindet ist.
Die Anwendung zeigt weiterhin die schwebende 3D-Steuerung und die schwebende Listensteuerung an, welche oben beschrieben wurden. Es sollte angemerkt werden, dass die Listensteuerung anpassungsfähig zu dem schwebenden Steuerungscluster hinzugefügt wurde beim Hineinkommen in die Routenbesichtigungs- und Routennavigationsmodalitäten, während der Positionsindikator von der schwebenden Steuerung bei Eintritt in die Routennavigationsmodalität entfernt wurde. Auch beim Übergang vom Routenbesichtigungsmodus zu dem Routennavigationsmodus führt die Anwendung in einigen Ausführungsformen eine Animation durch, die ein komplettes Ausrollen der Seitenrolle involviert, bevor die Anwendung in die Navigationsdarstellung übergeht.
In einigen Ausführungsformen umfasst der Animationsübergang Entfernen des oberen Balkens, seiner assoziierten Steuerungen und der schwebenden Steuerungen aus der Navigationsdarstellung und Bewegen des Zeichens 184 zu der oberen Kante der Darstellung, eine kurze Zeitperiode nach Starten der Navigationsdarstellung. In einigen Ausführungsformen erfordert die Anwendung, dass der Benutzer auf die navigierte Karte tippt, um den oberen Balken, seine Steuerungen und die schwebenden Steuerungen zurückzubringen, und erfordert ein weiteres Tippen, um diese Steuerungen wieder aus der Karte zu entfernen. Andere Ausführungsformen stellen andere Mechanismen zum Betrachten und Entfernen dieser Steuerungen bereit. Die Navigationsbenutzerschnittstelle und andere Aspekte der Navigationsmodus einiger Ausführungsformen werden detaillierter beschrieben in der vorläufigen US-Patentanmeldung 61/655,997 mit dem Titel „Route Navigating Method and Apparatus”, eingereicht am 05.06.2012; der vorläufigen US-Patentanmeldung 61/657,864 mit dem Titel „Route Navigating Method and Apparatus”, eingereicht am 10.06.2012; der vorläufigen US-Patentanmeldung 61/699,851 mit dem Titel „Voice Instructions during Navigation”, eingereicht 11.09.2012; und der US-Patentanmeldung 13/632,121 mit dem Titel „Context-Aware Voice Guidance”, eingereicht 30.09.2012. Die vorläufigen Anmeldungen 61/655,997, 61/657,864 und 61/699,851, sowie die Patentanmeldung 13/632,121 werden hiermit durch Verweis aufgenommen.
B. 2D- und 3D-Navigation
In einigen Ausführungsformen kann die Navigationsanwendung eine Karte für Navigation entweder in einem 2D-Modus oder in einem 3D-Modus anzeigen. Wie oben erwähnt, ist eine der schwebenden Steuerungen die 3D-Steuerung 150, die es einem Benutzer erlaubt, eine Navigationsdarstellung in drei Dimensionen (3D) zu sehen. 2 veranschaulicht, wie die Navigationsanwendung in einigen Ausführungsformen die 3D-Steuerung 150 als einen schnellen Mechanismus eines Hineingehens in einen 3D-Navigationsmodus bereitstellt. Diese Figur veranschaulicht diese Operation in drei Stufen 205–215. Die erste Stufe 205 veranschaulicht den Benutzer beim Auswählen der 3D-Steuerung 150 während eines Anschauens einer zweidimensionalen Navigationsdarstellung.
Die zweite Stufe 210 veranschaulicht die Navigationsdarstellung inmitten ihres Übergangs in eine 3D-Darstellung. Wie in dieser Figur gezeigt, erscheint die 3D-Steuerung hervorgehoben in dieser Stufe, um anzugeben, dass die Navigationsdarstellung einen 3D-Modus betreten hat. In einigen Ausführungsformen generiert die Navigationsanwendung die 3D-Ansicht der navigierten Karte durch Rendern der Kartenansicht aus einer bestimmten Position in der dreidimensionalen Szene, die konzeptionell als die Position einer virtuellen Kamera, die die Kartenansicht aufnimmt, gedacht werden kann. Dieses Rendern wird weiter unten beschrieben werden mit Bezug zu 3.
Die dritte Stufe 215 veranschaulicht dann die Navigationsdarstellung am Ende ihres Übergangs in ihre 3D-Erscheinung. Wie durch die Differenz zwischen den Höhen der Gebäude in der zweiten und dritten Stufe gezeigt, schließt der Übergang von 2D- nach 3D-Navigation in einigen Ausführungsformen eine Animation, die dreidimensionale Objekte in der navigierten Karte größer werdend zeigt, ein.
1. Virtuelle Kamera
Die Navigationsanwendung in einigen Ausführungsformen ist fähig, Navigationskarten aus mehreren Perspektiven anzuzeigen. Die Anwendung kann Karten in drei Dimensionen (3D) oder in zwei Dimensionen (2D) zeigen. Die 3D-Karten sind generierte Simulationen von einer virtuellen Szene wie sie von einer virtuellen Kamera gesehen wird. 3 stellt ein vereinfachtes Beispiel dar, um das Konzept einer virtuellen Kamera 312 zu veranschaulichten. Wenn eine 3D-Navigationskarte gerendert wird, ist eine virtuelle Kamera eine Konzeptionalisierung der Position in der 3D-Kartenszene, von welcher die Vorrichtung eine 3D-Ansicht der Szene rendert. 3 veranschaulicht einen Ort in einer 3D-Navigationskartenszene 310, die vier Objekte beinhaltet, welche zwei Gebäude und zwei kreuzende Straßen sind. Um das Konzept der virtuellen Kamera zu veranschaulichen, veranschaulicht diese Figur drei Szenarien, wovon jedes einem unterschiedlichen virtuellen Kameraort (d. h. einer unterschiedlichen Rendering-Position) und einer unterschiedlichen resultierenden Ansicht, die auf der Vorrichtung angezeigt wird, entspricht.
Die erste Stufe 301 zeigt die virtuelle Kamera 312 bei einer ersten Position, die abwärts bei einem Winkel (z. B. ein 30 Grad Winkel), z. B. in Richtung der 3D-Szene 310 zeigt. Durch Rendern der 3D-Szene von der Position und dem Winkel, die in Stufe 301 gezeigt sind, generiert die Anwendung die 3D-Kartenansicht 318. Von dieser Position zeigt die Kamera zu einem Ort, der eine bewegende Position vor der Vorrichtung ist. Die virtuelle Kamera 312 wird hinter dem aktuellen Ort der Vorrichtung gehalten. In diesem Fall bedeutet ”hinter dem aktuellen Ort” rückwärts entlang des definierten Pfades der Navigationsanwendung in der entgegengesetzten Richtung von der aktuellen Richtung, in der sich die Vorrichtung bewegt.
Die Navigationskartenansicht 318 sieht aus als ob sie von einer Kamera von oben und hinter dem Ortsindikator 316 der Vorrichtung gefilmt wird. Der Ort und Winkel der virtuellen Kamera platziert den Ortsindikator 316 nahe dem unteren Ende der Navigationskartenansicht 318. Dies führt auch zu einer Befüllung der Mehrheit des Bildschirms mit den Straßen und den Gebäuden, die vor dem aktuellen Ort von der Vorrichtung sind. Im Gegensatz dazu ist in einigen Ausführungsformen der Ortsindikator 316 im Zentrum des Bildschirms mit einer Hälfte des Bildschirms Gegenstände vor der Vorrichtung darstellend, und mit der anderen Hälfte Gegenstände hinter der Vorrichtung darstellend. Um diese Figur zu vereinfachen, sind keine Straßenschilder für die Ansichten 318, 328 und 338 abgebildet.
Die zweite Stufe 302 zeigt die virtuelle Kamera 312 an einer unterschiedlichen Position abwärts in Richtung der Szene 310 mit einem größeren zweiten Winkel (z. B. einem 45° Winkel) zeigend. Die Anwendung rendert die Szene 310 aus diesem Winkel, in der 3D-Navigationskartenansicht 328 resultierend. Die Gebäude und die Straßen sind kleiner als ihre Veranschaulichung in der ersten Navigationskartenansicht 318. Wieder ist die virtuelle Kamera 312 über und hinter dem Ortsindikator 326 in der Szene 310. Dies führt wieder zu einem Erscheinen des Ortsindikators in dem unteren Teil der 3D-Kartenansicht 328. Der Ort und die Ausrichtung der Kamera führen auch wieder zu einer Anzeige von Gegenständen vor dem Autoin der Majorität des Bildschirms, dies ist was man zum Navigieren wissen muss.
Die dritte Stufe 303 zeigt die virtuelle Kamera 312 in Ansicht von oben nach unten, die abwärts auf einen Ort auf einer 2D-Karte 345, welcher dem Ort in der 3D-Kartenszene 310 entspricht, sieht, die verwendet wurde, um die 3D-Ansichten 318 und 328 zu rendern. Die Szene, die aus dieser Perspektive gerendert wird, ist die 2D-Kartenansicht 338. Anders als die 3D-Rendering-Operationen der ersten und zweiten Stufe, welche in einigen Ausführungsformen perspektivische 3D-Rendering-Operationen sind, ist die Rendering-Operation in der dritten Stufe relativ einfach, da es nur einen Teil aus der 2D-Karte ausschneiden muss, die durch eine von der Anwendung oder dem Benutzer spezifizierten Zoomstufe identifiziert wird. Dementsprechend verkompliziert die Charakterisierung der virtuellen Kamera in dieser Situation etwas unnötigerweise die Beschreibung der Operation der Anwendung, da das Abschneiden eines Teils einer 2D-Karte keine perspektivische Rendering-Operation ist.
In der dritten Stufe 303 wechselt die Kartenanwendung in einigen Ausführungsformen von einem Rendern einer 3D-Szene aus einer bestimmten perspektivischen Richtung zu einem Abschneiden einer 2D-Szene, wenn die Kamera von der 3D-perspektivischen Ansicht zu einer 2D-Ansicht von oben nach unten wechselt. Dies ist weil in diesen Ausführungsformen die Anwendung dazu bestimmt ist, eine vereinfachte Rendering-Operation, welche einfacher ist und keine unnötigen perspektivischen Artefakte generiert, zu nutzen. In anderen Ausführungsformen hingegen verwendet die Kartenanwendung eine perspektivische Rendering-Operation, um eine 3D-Szene von einer virtuellen Kameraposition von oben nach unten zu rendern. In diesen Ausführungsformen ist die generierte 2D-Kartenansicht etwas unterschiedlich zu der in der dritten Stufe 303 veranschaulichten Kartenansicht 338, weil jedes Objekt, das vom Zentrum der Ansicht entfernt ist, verzerrt ist, mit einer größer werdenden Verzerrung je weiter die Objektdistanz vom Zentrum der Ansicht entfernt ist.
Die virtuelle Kamera 312 bewegt sich entlang unterschiedlichen Trajektorien in unterschiedlichen Ausführungsformen. Zwei solcher Trajektorien 350 und 355 sind in 3 veranschaulicht. In beiden dieser Trajektorien bewegt sich die Kamera in einem Bogen und rotiert mehr abwärts während die Kamera sich aufwärts auf dem Bogen bewegt. Die Trajektorie 355 unterscheidet sich von der Trajektorie 350, indem sich in der Trajektorie 355 die Kamera weiter weg von ihrem Fokuspunkt (und dem aktuellen Ort des Benutzers) bewegt, während sie sich den Bogen hinauf bewegt.
Während der Bewegung entlang eines der Bögen rotiert die Kamera, um einen Punkt vor dem Ortsindikator am Brennpunkt der Kamera zu behalten. In einigen Ausführungsformen kann der Benutzer die dreidimensionale Ansicht ausschalten und mit einer reinen zweidimensionalen Ansicht weiter zu machen. Zum Beispiel erlauben die Anwendungen in einigen Ausführungsformen einen durch Verwenden eines 3D-Knopfes 360 einschaltbaren und ausschaltbaren dreidimensionalen Modus. Der 3D-Knopf 360 ist sehr nützlich für das Punkt-zu-Punkt-Navigationsmerkmal, in welchem es eine Rolle als ein Indikator und eines Umschalters hat. Wenn 3D ausgeschaltet ist, wird die Kamera eine 2D-Navigationserfahrung beibehalten, aber wenn 3D einschaltet ist, könnte es weiterhin einige Perspektiven von oben nach unten geben, wenn 3D-Ansichtswinkel keinen Sinn machen (z. B. wenn man um eine Ecke geht, welche im 3D-Modus versperrt wäre).
II. Server-seitige Erzeugung von Kartenkacheln
Um sowohl immersive als auch nicht-immersive 3D-Kartendarstellungen anzuzeigen, müssen einige Ausführungsformen eine Vielzahl von Kacheln für Client-Vorrichtungen zum Rendern erzeugen, um Straßen, Gebäude und umgebende Szenerie zu erzeugen. In einigen Ausführungsformen umfassen Beispiele solcher Kacheln Straßen- und Gebäudekacheln, welche für nicht immersive 3D-Darstellungen verwendet werden, und Navigations- und Gebäudekacheln, welche für immersive 3D-Darstellungen verwendet werden.
Vor dem Erzeugen dieser Kacheln muss ein Satz von Servern die Beschreibung der Straße, des Gebäudes und anderer Geometrien erzeugen, welche in jede dieser Kacheln platziert werden. Diese Aufgabe umfasst mehrere Unteraufgaben, wie beispielsweise (1) Empfangen von Kartendaten aus einer Vielzahl von Verkäufern, (2) Verarbeiten solcher Daten zum Erzeugen eindimensionaler (1D) Straßen, (3) Glätten der 1-D-Straßengraphen, (4) Definieren von Daten zum Spezifizieren von Kreuzungen, (5) Erzeugen von 2D-Straßengeometrien und Gelände, (6) Glätten der 2D-Straßengeometrien, (7) Erzeugen von Daten (z. B. geschätzte Höhendaten) bezüglich Gebäuden, (8) Verwenden solcher Daten zum Definieren von Gebäudegeometrien, (9) Konstruieren von Straßengeometriedetails (wie beispielsweise Inseln, Fahrbahnmarkierungen und Distanzen und Geländeoberflächen zwischen Straßengeometrien), und (10) Identifizieren von Geometriekantenknotencharakteristiken und Propagieren solcher Charakteristiken.
Der Kartendienst einiger Ausführungsformen erzeugt herunterladbare Kartenkacheldaten über Offline-Verarbeitung von Kartendaten (z. B. Daten, welche von Kartenverkäufern empfangen werden). In einigen Ausführungsformen nimmt diese Offline-Verarbeitung Kartenobjektortseingabe an (z. B. Breiten-/Längendaten für Straßen, administrative Grenzen, natürliche Grenzen, usw.) und erzeugt aggregierte Straßen und Beziehungen zwischen den aggregierten Straßen. Aus den aggregierten Straßen und ihren Beziehungen erzeugt die Kartendienstverarbeitung Straßengeometrien. Der Kartendienst erzeugt auch Geometrien für Geländeoberfläche (z. B. Parks, Ozeane, Staaten, usw.) unter Verwendung von Kartenobjektortseingabe. Einige Ausführungsformen verwenden skalierbare verteilte Verarbeitung zum Erzeugen von herunterladbaren Kartenkacheln aus den geometrischen Vektordaten. Der Fachmann wird erkennen, dass die „Offline”-Verarbeitung, welche in dieser Anmeldung beschrieben ist, durch Kartendienstrechnervorrichtungen ausgeführt werden kann, welche tatsächlich mit dem Netzwerk verbunden sind, über welches die Kartenanwendung Kacheldaten anfragt, aber verwendet wird zum Darstellen, dass die Verarbeitung nicht ausgeführt wird in Antwort auf Benutzeranfragen für Kacheln.
6 zeigt konzeptionell die Kartendienstverarbeitung 600 einiger Ausführungsformen. Wie erwähnt, führen einige Ausführungsformen diese Verarbeitung offline aus zum Erzeugen von verschiedenen Kartenkacheln, welche dann an Client-Vorrichtungen gesendet werden können in Antwort auf Echtzeit-Anfragen. Die Verarbeitung kann auf einer regulären Basis ausgeführt werden (z. B. stündlich, täglich, wöchentlich) oder kann ausgeführt werden zu jeder Zeit, zu welcher neue Daten verfügbar werden (z. B. Aktualisierungen, welche über Provider von Kartendaten empfangen werden, Korrekturen, welche von Benutzern empfangen werden, usw.).
Die Kartendienstverarbeitung 600 umfasst einen 1-D-Straßenprozessor 605, einen Straßengeometriegenerator 610, einen Geländeoberflächengeometriegenerator 615, einen Gebäudegeometriegenerator 617 und einen Kachelgenerator 620. Der Fachmann wird erkennen, dass die verschiedenen modularen Operationen, welche in 6 gezeigt sind, alle auf einem einzelnen Server ausgeführt werden können oder entlang einiger Rechnervorrichtungen verteilt werden können. Tatsächlich können einige der Operationen (z. B. Kachelerzeugung) als verteilte Verarbeitungsoperationen ausgeführt werden, welche mehrere Rechnervorrichtungen umfassen.
Zusätzlich zu den Verarbeitungsoperationen zeigt 6 Straßensegmentdaten 625, Geländeoberflächendaten 630 und Gebäudedaten 633. Straßensegmentdaten 625 speichern Daten, welche den Ort und die Eigenschaften der Straße definieren. In einigen Ausführungsformen werden jedem Straßensegment ein oder mehrere Namen (z. B. „Lincoln Blvd.”, „CA-1”), Ortsdaten, welche den Pfad des Straßensegments anzeigen, und Attribute des Straßensegments (z. B. Geschwindigkeitsbeschränkung, Breite, Zahl der Spuren, Straßentyp, usw.) zugewiesen. In einigen Ausführungsformen sind die Orte der Kreuzungen (auch bezeichnet als Kreuzungen) Teil der Straßensegmentdaten. Die Geländeoberflächendaten 630 speichern Daten, welche den Ort und die Eigenschaften verschiedener Typen von Nicht-Straßen-Geländeoberflächen definieren. Die Geländeoberfläche kann Gewässer (z. B. Flüsse, Ozeane, Seen, Schwimmbäder, usw.), administrative Körper (z. B. Grenzen von Staaten, Ländern, Städten, Parks, usw.), Bereichsdesignierungen (z. B. ländlich/städtisch/suburban, Wüste/Gebirge/Wald, usw.) oder andere Daten umfassen, welche das Gelände zwischen den Straßen beschreiben. Die Gebäudedaten 633 einiger Ausführungsformen speichern den Ort der Gebäude sowie Daten über die Gebäude. Zum Beispiel können die Gebäudedaten Erdoberflächenhöhendaten und Oberflächenhöhen umfassen, aus welchen die Gebäudehöhe berechnet werden kann.
Die Straßensegmentdaten 625, Geländeoberflächendaten 630 und Gebäudedaten 635 können von einer einzelnen Quelle (z. B. einem einzelnen Anbieter von Kartendaten) oder mehreren Quellen (z. B. mehreren unterschiedlichen Verkäufern) empfangen werden. Zum Beispiel könnte ein erster Verkäufer Straßendaten für eine erste Region bereitstellen, während ein zweiter Verkäufer Straßendaten für eine zweite Region bereitstellt, ein dritter Verkäufer Geländeoberflächendaten für die ersten und zweiten Regionen bereitstellt, und ein vierter Verkäufer Höhendaten bereitstellt (oder andere Kombinationen, wie beispielsweise mehrere unterschiedliche Verkäufer von Geländeoberflächendaten für unterschiedlich Typen von Informationen).
Der 1-D-Straßenprozessor 605 empfängt Straßensegmentdaten 625 und erzeugt ein oder mehrere Straßengraphen aus den Daten. Ein Straßengraph in einigen Ausführungsformen verbindet einen Satz von Straßensegmenten und Kreuzungen von Straßensegmenten. Um den Straßengraphen zu erzeugen, identifiziert der 1-D-Straßenprozessor 605 Straßensegmente, welche in aggregierte Straßen kombiniert werden sollten (d. h. basierend auf den Namen, Start- und Endpunkten und gemeinsamen Attributen der Segmente). Beispielsweise, wenn das Ende eines ersten Segments einen Ort mit dem Start eines zweiten Segments teilt, die Segmente zumindest einen Namen gemeinsam haben und die Segmente zumindest einige Attribute teilen, dann kombiniert der Straßenprozessor 605 die Segmente in eine aggregierte Straße. Der 1-D-Straßenprozessor ergänzt zusätzlich Daten, welche für zusätzliche Verarbeitung erforderlich sind (z. B. Höhendaten, Geschwindigkeitsbeschränkungsdaten, Zahl von Spuren), wenn dies aus den Straßensegmentdaten fehlt.
Zusätzlich zum Bilden der aggregierten Straßen identifiziert und erzeugt der 1-D-Straßenprozessor 605 Winkelinformation für Kreuzungen der Straßen (z. B. wie unten beschrieben) und identifiziert andere Beziehungen zwischen den Straßen (z. B. Zusammenführen von zweispurigen Fahrbahnen, Herstellen von Überlappungsbeziehungen). Ein verbundener Satz von Kreuzungen und Segmenten bildet einen Straßengraphen.
Der Straßengeometriegenerator 610 erzeugt Geometrien für die Straßen (d. h. Sätze von Knoten zum Zeichnen der Straßen an den Client-Vorrichtungen) basierend auf dem Straßengrafen unter Verwendung von verschiedenen Prozessen. In einigen Ausführungsformen lässt der Straßengeometriegenerator 610 Straßengeometrien aus den Straßenmittellinien entstehen (z. B. unter Verwendung von Spur #, Breite und Offset-Daten), führt dann verschiedene Operationen aus zum Verfeinern der Geometrien. Als Beispiele glättet der Straßengeometriegenerator 610 Übergänge zwischen Straßensegmenten mit unterschiedlichen Anzahlen von Spuren, erzeugt realistischere gerundete Eckpunkte bei Verkehrskreuzungen, glättet Straßenzusammenführungen zum Entfernen von überschüssigen Straßenstücken und Lücken zwischen den Straßen, und entfernt Überlappungen zwischen getrennten Straßen, welche sich nicht kreuzen. Zusätzlich in einigen Ausführungsformen weist der Straßengeometriegenerator 610 spezifische Charakteristika an die Polygonknoten und/oder -kanten zu, wie beispielsweise Markieren von Tunneleingängen, Markieren von Straßeninnenecken (z. B. zwischen Segmenten), Markieren von Bürgersteigen, und Markieren von Brückenumhüllungen, wo Schatten gezeichnet werden sollten.
Der Geländeoberflächengeometriegenerator 615 verwendet sowohl die Geländeoberflächendaten 630 als auch die Straßensegmentdaten 625 in einigen Ausführungsformen zum Erzeugen der Geometrien (d. h. Sätze von Knoten, welche Polygone definieren) für die Geländeoberfläche. Nach dem Entstehen-Lassen von Geometrien für die Geländeoberfläche, verwenden einige Ausführungsformen verschiedene Operationen zum Auflösen der Grenzen zwischen den Geometrien. Zum Beispiel beim Kombinieren von Daten aus unterschiedlichen Quellen, können die Ortsdaten, welche Objektgrenzen anzeigen, nicht perfekt ausgerichtet werden und können daher entweder Lücken zwischen den Objektgeometrien sein oder die Geometrien überlappen. Einige Ausführungsformen verwenden unterschiedliche Operationen zum Auflösen von Grenzen zwischen unterschiedlichen Geometrien, abhängig von den Typen von Objekten.
Zusätzlich verwendet der Geländeoberflächengeometriegenerator 615 die Straßensegmentdaten zum Auffüllen der Geländeoberflächengeometrie und Sicherstellen, dass die Lücken nicht zwischen der Geländeoberfläche und den Straßen belassen werden. Einige Ausführungsformen ergänzen die Geländeoberflächengeometrien außerhalb ihrer markierten Grenzen hin zu den Straßen, was die Geometrien bei Straßenmittellinienorten stoppt. Während dies eine Überlappung zwischen der Geländeoberflächengeometrie und der Straßengeometrie erzeugt, umfassen in einigen Ausführungen die Client-Kartenanwendungen Instruktionen zum Rendern der Straßengeometrie oberhalb der Geländeoberflächengeometrie.
Der Gebäudegeometriegenerator 617 einiger Ausführungsformen erzeugt Gebäudegeometrien unter Verwendung der Gebäudedaten 633. In einigen Ausführungsformen, wie erwähnt, umfassen die Gebäudedaten 633 Geländehöhen- und Oberflächenhöhendaten, zusätzlich zu Orten der Gebäude. Um Gebäudegeometrie zu erzeugen, berechnen einige Ausführungsformen die Gebäudehöhe für verschiedene Punkte innerhalb des Orts des Gebäudes. Der Gebäudegeometriegenerator 617 ruft die Geländehöhe ab und zieht diese von den Oberflächenhöhendaten ab, zum Berechnen der Gebäudehöhe. In anderen Ausführungsformen verwendet der Gebäudegeometriegenerator 617 (oder anderes Modul) 3D-Satellitendaten zum Berechnen der Höhendaten. Um eine Höhe für das Gebäude als ein Ganzes zu berechnen, berechnet der Gebäudegeometriegenerator 617 eine Gesamthöhe als den Mittelwert der verschiedenen berechneten Höhen bei unterschiedlichen Punkten, plus eine Verzerrungsfaktorkonstante, welche mit der Standardabweichung der Punkthöhen multipliziert wird. Der Verzerrungsfaktor in einigen Ausführungsformen ist eine Konstante, welche aus der ground truth (z. B. Daten, welche bei dem tatsächlichen Ort bestimmt werden) und Experimenten bestimmt wird.
Einige Ausführungsformen bestimmen auch, ob das Gebäude flach oder nicht flach ist (z. B. mit einem spitzen Dach). Wenn die Standardabweichung der Punkthöhen oberhalb einer Schwelle ist (welche auch auf der ground truth und Experimenten basieren kann), bezeichnet der Gebäudegeometriegenerator 617 das Dach als nicht flach. Wenn die Standardabweichung der Punkthöhen unterhalb der Schwelle ist, bezeichnet der Gebäudegeometriegenerator 617 das Dach als flach. Beim Erzeugen der Geometrieeckpunkte erzeugen einige Ausführungsformen spitze Dächer (z. B. dreieckige Prismen oder Pyramiden) für nicht-flache Gebäude.
Die Straße, die Geländeoberfläche und Gebäudegeometrien werden an den Kachelgenerator 620 gesendet. In einigen Ausführungsformen erzeugt der Kachelgenerator 620 einige Kacheln für eine Kartenregion bei unterschiedlichen Detail-Leveln (d. h. Zoom-Level). Einige Ausführungsformen definieren die Kachelortgrenzen für die unterschiedlichen Zoom-Level (z. B. wobei eine Kachel bei einem ersten Zoom-Level vier Kacheln bei dem nächsten Zoom-Level enthält), verwenden dann verteilte Verarbeitungstechniken zum Zuweisen der unterschiedlichen Geometrien (sowohl Straßen- als auch Geländeoberflächen) an die verschiedenen Kacheln. Nach dem Zuweisen der Geometrien an die Kacheln (jede Geometrie kann an eine oder mehrere Kacheln bei jedem Zoom-Level zugewiesen werden), verwendet der Kachelgenerator 620 zusätzliche verteilte Verarbeitung zum Erzeugen und Komprimieren der Kacheln. In einigen Ausführungsformen enthalten die Kartenkacheln Vektordaten, welche die zu erzeugenden Polygone beschreiben, zum Rendern der Daten als eine 2D- oder 3D-Karte. Um die Menge von Vektordaten zu reduzieren (und damit die Größe der Dateien zur einfacheren Übertragung zu reduzieren), verwenden einige Ausführungsformen einen flüchtigen Rasterungsprozess, welcher die Vektordaten zu Rasterinformation reduziert, dann die Daten erneut vektorisiert mit weniger bezeichnet.
Wie gezeigt, gibt der Kachelgenerator 620 Kacheldaten 635 an den Speicher aus. Die gespeicherten Kacheldaten 635 sind die Daten, auf welche durch die Client-Kartenanwendungen zugegriffen wird, um für die Anwendungen Karten zur Betrachtung durch einen Benutzer zu erzeugen. Wie gezeigt, umfassen die Kacheldaten einiger Ausführungsformen nicht-immersive Kartenkacheln 640, immersive Kartenkacheln 645, Gebäudekacheln 650, und Verkehrskacheln 655. Die nicht-immersiven Kartenkacheln 640 und immersiven Kartenkacheln 645 stellen unterschiedliche Level von Daten bereit. In einigen Ausführungsformen umfasst die Kartenanwendung eine immersive 3D-Ansicht und eine nicht-immersive 3D-Ansicht, wobei die immersive 3D-Ansicht zusätzliches Detail bereitstellt (z. B. Asphaltansicht von Straßen, realistischere Geländeoberfläche und Gebäude, nähere Simulation der Fahrtansicht, usw.). Einige Ausführungsformen verwenden separate Kachelsätze für die unterschiedlichen Ansichten, wobei die immersiven Kartenkacheln 645 einen größeren Detail-Level über die Straßen und die Geländeoberfläche umfassen. Zusätzlich zu den Straßensegments- und Geländeoberflächendaten, können die Kartenkacheln zusätzliche Daten enthalten. Zum Beispiel können die Kacheln verschiedene Sätze von Bezeichnungsdaten umfassen (z. B. Straßenbezeichnungen, Platzbezeichnungen, Geländeoberflächenbezeichnungen, usw.). Wie gezeigt, umfassen die Kacheldaten 635 auch Gebäudekacheln, welche Geometrie zum Zeichnen von Gebäuden anzeigen (basierend auf den Höhen- und Ortsinformationen) in einigen Ausführungsformen, sowie Verkehrskacheln 655, welche regelmäßig mit der Verkehrsinformation aktualisiert werden. Einige Ausführungsformen verwenden die Gebäudekacheln für sowohl die immersive als auch die nicht-immersive 3D-Ansicht.
A. Straßendaten- und Straßengrapherzeugung
Wie oben genannt, empfangen einige Ausführungsformen Straßensegmentdaten (d. h. von einer oder mehreren Quellen) und erzeugen einen Straßengraphen aus den Straßensegmenten. 7 zeigt konzeptionell einen Prozess 700 einiger Ausführungsformen zum Erzeugen eines Straßengraphen. Der Prozess 700 wird mit Verweis auf 8 beschrieben werden, welche verschiedene Datenstrukturen einiger Ausführungsformen für die Straßen innerhalb einer Kartenregion zeigt. Diese Datenstrukturen, welche detaillierter unten beschrieben werden, umfassen Straßensegmente 800, Kanten 805, Straßen 810, Kreuzungen 815 und einen Straßengraphen 820.
Wie gezeigt, beginnt der Prozess 700 durch Empfangen (bei 710) eines Satzes von Straßensegmenten und Kreuzungen für eine Kartenregion. In einigen Ausführungsformen läuft der Prozess 700 (oder ein ähnlicher Straßengraphenerzeugungsprozess) separat für unterschiedliche Kartenregionen (z. B. für Staaten, rechteckige geographische Bereiche, Landmassen, usw.). Die Straßensegmente für eine Kartenregion können von einer einzelnen Quelle oder von mehreren unterschiedlichen Quellen empfangen werden. In einigen Ausführungsformen ist ein Straßensegment eine gleichmäßige Strecke der Straße, welche einen einzelnen gleichmäßigen Satz von Attributen aufweist (d. h. gleiche Anzahl von Spuren, Geschwindigkeitsbeschränkungen, usw.). Wenn ein Straßenattribut sich ändert (z. B. Geschwindigkeitsbeschränkung von 45 mph auf 35 mph, oder eine Spur wird hinzugefügt), wird ein neues Straßensegment definiert.
Die Kreuzungen für eine Kartenregion werden im Allgemeinen von der gleichen Quelle wie die Straßen empfangen, welche sich bei den Kreuzungen treffen. In einigen Ausführungsformen definiert eine Kreuzung eine Verkehrskreuzung von zumindest zwei Straßen – d. h., dass zwei oder mehrere Straßensegmente sich nicht nur an dem gleichen Ort kreuzen (welcher aus den Straßensegmentdaten bestimmt werden kann), sondern auch, dass die Straßensegmente sich tatsächlich gegenseitig überschneiden, so dass ein Fahrzeug von einem Straßensegment zu dem anderen bei der Kreuzung übergehen kann.
8 zeigt die Datenstruktur 800 einiger Ausführungsformen für ein Straßensegment sowie die Datenstruktur 815 für eine Kreuzung. Wie gezeigt, umfasst das Straßensegment eine Segment-ID (d. h. eine einzigartige Identifizierung), einen oder mehrere Namen, Geometrieinformationen und Attributinformationen. Die Geometrieinformationen (welche unterschiedlich zu den Straßengeometrien ist, welche zum Definieren von Vektordaten erzeugt werden), definiert den Pfad und andere geometrische Informationen über ein Straßensegment. Wie gezeigt, umfasst die Geometrieinformation Mittelpfaddaten (z. B. einen geordneten String von Koordinaten, welche den Mittelpunkt der Straße definieren), Starten und Beenden der Kreuzungsinformation, Parameter zum Anzeigen der Breite und des Offsets in Bezug auf die Mittellinie, und Funktionalität, welche Evaluation der Seiten der Straße zu irgendeinem Punkt entlang des Straßensegments ermöglicht. In einigen Ausführungsformen ist dies eine Funktion auf der Straßensegmentklasse, welche die Mittellinie, Offset, und Breiteninformationen verwendet zum Berechnen des Orts der Seiten der Straße. Während dieses Diagramm die Straßenzeichendaten zeigt, welche einschließlich Start- und End-Kreuzungen umfassen, definieren einige Ausführungen nicht einen als den Start und einen als das Ende, sondern vielmehr zeigen sie einfach zwei Kreuzungs-IDs an als Endpunkte (oder eine einzelne Kreuzungs-ID, wenn das Straßensegment eine Sackgasse ist).
Die Attributinformation beschreibt Metadaten über das Straßensegment, wie beispielsweise den Straßentyp (oder funktionale Straßenklasse, welche den Level von Wichtigkeit einer Straße definiert, von Autobahn herunter zu Pseudopfad), die Anzahl von Spuren, die Geschwindigkeitsbeschränkung, die relative Höhe der Straße (welche Referenzen zu einem oder mehreren anderen Straßensegmenten und/oder Kreuzungen enthalten kann, welche anzeigen, dass das gegenwärtige Straßensegment unterhalb oder oberhalb des referenzierten Objekts läuft), die Höhe der Straße (relevant zum Identifizieren der Höhe), die Form des Wegs (welches einen Pfad als eine zweispurige Fahrbahn, einspurige Fahrbahn, Fußgängerweg, Treppe, Verbindungsstraße, Auffahrt usw. definiert), Restriktionen (z. B. Zollrestriktionen, Fahrzeugtyprestriktionen, Hinweise, dass eine Straße privat ist, usw.).
Zusätzlich, wie in 8 gezeigt, definieren einige Ausführungsformen eine Kante 805 für jedes Straßensegment. Eine Kantendatenstruktur enthält eine Referenz (z. B. einen Zeiger) auf ein Straßensegment, dem die Kante entspricht, ein Orientierungs-Flag, welches anzeigt, ob die Kante in der gleichen Richtung wie das Straßensegment orientiert ist, und eine Funktionalität zum Berechnen der rechten und linken Seite der Kante unter Verwendung der Breiten- und Mittelliniendaten des referenzierten Straßensegments. In einigen Ausführungsformen existiert diese Funktionalität als eine Funktion auf der Kantenklasse. Die Kanten, in einigen Ausführungsformen, sind Datenkonstrukte, welche verwendet werden zum Erzeugen des Straßengraphen. Für ein Straßensegment, welches sowohl eine Start- als auch eine End-Kreuzung aufweist, definieren einige Ausführungsformen zwei Kanten (eine in jeder Richtung), so dass jede Kreuzung eine Kante referenzieren kann, welche aus der Kreuzung herausführt.
Wie gezeigt in 8, umfasst die Kreuzungsdatenstruktur 815 eine eindeutige Kreuzungs-ID, eine geordnete Liste von Kanten mit assoziierten Winkeln, einen Ort und eine Höhenreihenfolge. Während diese Datenstruktur eine Kantenliste zeigt, umfassen einige Ausführungsformen zusätzlich eine Liste von Straßensegmenten, auf die durch die Segment-IDs Bezug genommen wird, aus welchen die Kantenliste erzeugt wird. In einigen Ausführungsformen werden die Kreuzungs-ID, Liste von Segment-IDs und Höhenreihenfolge empfangen von der Straßendatenquelle, während die Winkel- und Kantenliste durch den Kartendienst berechnet wird. Während jedes Straßensegment mit einer oder mehreren Kanten assoziiert ist, kann die Kartendienstverarbeitung die geeigneten gerichteten Kanten bestimmen zum Auflisten für die Kreuzung (die Kanten, welche von der Kreuzung weg gerichtet sind). Für viele Oberflächenstraßenkreuzungen ist die relative Höhe nicht besonders bedeutungsvoll, da die Kreuzung und alle Straßen an dem Ort auf dem gleichen Level sein werden. Jedoch bei Verkehrskreuzungen, wie beispielsweise Autobahnkreuzen, oder wenn ein Straßensegment unterhalb oder oberhalb einer Autobahn durchläuft, zeigt die Höhenreihenfolge an, welche Kreuzungen oberhalb anderer Kreuzungen und/oder Straßensegmente sind.
Nach Empfang der Straßensegmente definiert (bei 710) der Prozess einen Straßengraphen für die Kartenregion aus den Straßensegmenten und Kreuzungen. Wie in 8 gezeigt, umfasst die Straßengraphendatenstruktur 820 einen Satz von Straßensegmenten und einen Satz von Kreuzungen. In einigen Ausführungsformen durchläuft die Anwendung die Kanten und Kreuzungen zum Identifizieren von verbundenen Sätzen von Kanten, bildet diese Kanten dann auf die Straßensegmente ab. Andere Ausführungsformen verwenden die Start- und End-Kreuzungen, welche in jedem der Straßensegmente gespeichert sind, und die Liste von Segmenten, welche für jede Kreuzung gespeichert sind, zum Definieren der Konnektivität der Segmente und Kreuzungen. Einige Ausführungsformen definieren einen einzelnen Straßengraphen für eine Kartenregion. Jedoch werden einige Ausführungsformen mehrere Straßengraphen definieren, wenn es mehrere verbundene Sätze gibt, welche sich nicht kreuzen.
Als Nächstes führt (bei 715) der Prozess 700 Vorverarbeitung auf dem Straßengraphen aus, zum Ausrichten der Straßensegmente bei Kreuzungen. Um Winkel der Straßen bei Kreuzungen geeignet zu identifizieren und zum Erzeugen von Polygongeometrien für die Straßen, sollten die Straßen, welche sich bei einer Kreuzung kreuzen, alle bei exakt dem gleichen Ort enden/starten. Jedoch kann die Straßenmittellinie für jedes der Segmente, welche sich bei einer speziellen Kreuzung treffen, nicht bei dem exakt gleichen Ort in den empfangenen Kartendaten enden. Somit berechnen einige Ausführungsformen für jede Kreuzung eine durchschnittliche Position der Segmentpfadenden und weisen diese Position der Kreuzung für ihren Ort zu. Zusätzlich modifiziert die Kartendienstverarbeitung die Straßensegmentpfaddaten für jedes der Segmente, welche sich bei der Kreuzung treffen, so dass die Mittellinien alle an der berechneten durchschnittlichen Position enden.
9 zeigt ein Beispiel solch einer Modifikation für zwei Straßensegmente 905 und 910, welche sich bei einer Kreuzung treffen, über zwei Stufen 920 und 930. Wie gezeigt, umfasst jedes Straßensegment eine Start-Kreuzung und eine End-Kreuzung, wobei die End-Kreuzung des ersten Straßensegments 905 und die Start-Kreuzung des zweiten Straßensegments 910 die gleiche sind (beide beziehen sich auf eine Kreuzung mit einer ID von 16). Jedoch, wie gezeigt in der ersten Stufe 920, starten/enden die Mittellinienpfade des ersten Straßensegments 905 und des zweiten Straßensegments 910 nicht an dem gleichen Ort (und tatsächlich kreuzen sie sich überhaupt nicht). Somit identifizieren einige Ausführungsformen die Durchschnittsposition der Enden, welche sich treffen sollten. Für eine Kreuzung mit nur zwei Straßensegmenten wird dieser Ort auf halber Strecke entlang einer Linie zwischen den zwei Pfadendpunkten sein, wie gezeigt durch den Ort 915 in der Figur. Jede der endenden Eckpunkte der Mittellinien hat ein Paar von Koordinatenwerten (z. B. (x, y)-Koordinatenwerte oder Geoortskoordinaten (Breite, Länge)). Einige Ausführungsformen berechnen einen Durchschnitt unter allen der endenden Knoten für jede Koordinate, und verwenden diesen als den Durchschnittsort für die Kreuzung.
Nach Identifizieren des Kreuzungsorts modifiziert die Kartendienstverarbeitung die Straßensegmente, so dass die Mittellinien alle an dem identifizierten Ort enden. Die zweite Stufe 930 zeigt ein Beispiel solch eines Ergebnisses. In einigen Ausführungsformen, wenn die Straßensegmente empfangen werden, können die Mittellinienpfade nicht Knoten bei festen Distanzen haben. Die Kartendienstverarbeitung einiger Ausführungsformen standardisiert die Straßensegmentknoten, so dass jeder Knoten bei einem festen Abstand ist (z. B. 10 Meter), was glattere (weniger geknickte) Straßenpolygone ermöglicht. Einige Ausführungsformen für ein spezielles Straßensegment identifizieren einen Knoten in einem festen Abstand von dem Ende (z. B. 50 m, 100 m, usw.) und halten diesen Punkt fixiert, während sie die anderen Knoten zwischen diesem Punkt und dem Endknoten modifizieren. In einigen Ausführungsformen werden die Knoten durch eine geringere Menge bewegt, wenn sie weiter weg von dem Knoten kommen. Das heißt, ein Vektor wird für die Bewegung des Endknoten zu dem identifizierten Ort berechnet und die anderen Knoten werden durch kleinere Iterationen dieses Vektors bewegt.
Mit der fertiggestellten Vorverarbeitung kombiniert (bei 720) der Prozess die Straßensegmente in aggregierte Straßen. Einige Ausführungsformen bestimmen, wann Straßensegmente tatsächlich unterschiedliche Abschnitte der gleichen Straße sind, so dass die Segmente als eine einzelne Straße für die Zwecke des Definierens einer Karte (z. B. zum Erzeugen von Bezeichnungen) und für bestimmte Aspekte des Erzeugens von Polygonen für die Straßen behandelt werden können. In einigen Ausführungsformen verwendet der Prozess verschiedene Attribute und Geometriedaten der Segmente zum Bestimmen, ob zwei Segmente kombiniert werden sollten.
Einige Ausführungsformen durchlaufen den Straßengraphen zum Kombinieren der Straßensegmente in aggregierte Straßen. Während des Durchlaufens des Graphen, des Eintretens in eine Kreuzung von einem speziellen Straßensegment, bestimmt die Kartendienstverarbeitung, welches der anderen Segmente eine beste Übereinstimmung, eine Fortsetzung des derzeitigen Straßensegments zu sein, ist. Einige Ausführungsformen bewerten jedes der Segmente und aggregieren die Straßen auf eine gierige Weise.
Um eine Bewertung für ein spezielles Segment zu berechnen, bewertet die Kartendienstverarbeitung den Unterschied im Winkel zwischen dem eingehenden Straßensegment und dem speziellen Segment, der Kompatibilität der Straßensegmentnamen und vergleicht die Straßenattribute. Für den Winkel gilt, je näher das Segment bei 180° ist (d. h. eine Fortsetzung gerade durch die Kreuzung), desto höher wird das Segment im Allgemeinen bewertet; typischerweise wird eine Straße gerade oder nahezu gerade durch eine Kreuzung fortlaufen, eher als abbiegen. Einige Ausführungsformen führen einen Fuzzy-Vergleich zwischen den Straßennamen, welche mit jedem Segment assoziiert sind, aus. Das heißt, die Verarbeitung vergleicht den String für das eingehende Straßensegment mit dem speziellen Straßensegment unter Verwendung von Näherungs-String-Übereinstimmungstechniken. In einigen Fällen können eines oder mehrere der Straßensegmente mehrere Namen haben, und die Verarbeitung führt Vergleiche jedes dieser aus, um die beste Übereinstimmung oder Übereinstimmungen zu finden, und verwendet diese besten Übereinstimmungen beim Berechnen der Bewertung (z. B. unter Verwendung des Vergleichs von „San Diego Autobahn Süd” zu „San Diego Autobahn Süd” eher als „I-405 Süd”).
Zusätzlich werden zumindest einige der Straßenattribute verglichen zum Berechnen der Vergleichsbewertung in einigen Ausführungsformen. Zum Beispiel vergleicht die Kartendienstverarbeitung einiger Ausführungsformen den Straßentyp (d. h. Autobahn, Hauptstraße, Nebenstraße, usw.), die Anzahl der Spuren, Geschwindigkeitsbeschränkung, Art des Wegs (d. h. einspurige Fahrbahn, zweispurige Fahrbahn, usw.). Sobald die Bewertungen berechnet sind, wählen einige Ausführungsformen das Segment mit der höchsten Bewertung aus und bestimmen, ob es oberhalb einer Schwelle zum Fortsetzen der Straße liegt. Zusätzlich identifizieren einige Ausführungsformen das ausgewählte beste Straßensegment und führen einen Vergleich zwischen dem ausgewählten Straßensegment und jedem der anderen Segmente aus. Nur wenn ein erstes Segment die beste Übereinstimmung für ein zweites Segment ist und das zweite Segment die beste Übereinstimmung für das erste Segment ist, aggregiert die Verarbeitung die Straße. Dies verhindert, dass ein eingehendes Straßensegment, welches tatsächlich an einer „T”-Verkehrskreuzung endet, mit einem der Straßensegmente verbunden wird, welches tatsächlich durch die Verkehrskreuzung fortläuft.
10 zeigt ein Beispiel dreier Straßensegmente 1005, 1010, und 1015, welche Kandidaten zur Aggregation in einer Straße bei einer Kreuzung 1020 sind. Wie gezeigt, hat das erste Segment 1005 den Namen „Wilshire Blvd”, eine Geschwindigkeitsbegrenzung von 40 mph und drei Spuren und ist eine Hauptstraße. Das zweite Segment 1010 hat auch den Namen „Wilshire Blvd” und drei Spuren und ist auch eine Hauptstraße, aber hat eine Geschwindigkeitsbeschränkung von 35 mph. Das dritte Segment 1015 hat den Namen „Saltair Ave”, eine Geschwindigkeitsbeschränkung von 35 mph und 2 Spuren, und ist als eine Nebenstraße charakterisiert. Wenn das ursprünglich eingehende Segment das dritte Segment 1015 ist, dann würde das Segment 1010 das höher bewertete Straßensegment der zwei möglichen Fortsetzungen sein. Jedoch für das zweite Segment 1010 wird das dritte Segment 1015 nicht die optimale Straßenfortsetzung sein, weil das erste Segment 1005 eine viel höhere Fortsetzungsbewertung haben wird (der Winkel, Straßenname, Straßentyp und die Anzahl von Spuren sind die gleichen, und der einzige Unterschied ist die 5 mph in der Geschwindigkeitsbeschränkung). Als solches ist für die Straße das optimale Ergebnis bei dieser Kreuzung 1020, für welche das dritte Segment 1015 ein Teil zum Abschließen ist, mit dem ersten Segment 1005 und dem zweiten Segment 1010 zusammen verbunden als eine einzelne Straße. Andere Ausführungsformen führen nicht den Reziprozitätstest aus, sondern stellen stattdessen eine genügend hohe Schwelle ein, dass schlechte Übereinstimmungen unwahrscheinlich sind. Des Weiteren, während des Durchlaufens des Straßengraphen erlauben einige Ausführungsformen einem Segment von einer aggregierten Straße zu einer anderen bewegt zu werden, wenn eine bessere Übereinstimmung später in dem Durchlaufen auftritt (z. B. wenn festgestellt wird, dass das Straßensegment 1015 in das Straßensegment 1010 fortsetzt, aber dann die Kreuzung 1020 wieder über das Straßensegment 1005 erreicht wird, kann das Segment 1010 von der ersten Straße zu einer neuen Straße bewegt werden, welche auch das Straßensegment 1005 enthält.
8 zeigt eine Straßendatenstruktur 810 einiger Ausführungsformen. Wie gezeigt, umfasst die Straßendatenstruktur 810 eine geordnete Liste von Kanten (über welche das Straßenobjekt Referenzen zu seinen einzelnen Segmenten enthält). Zusätzlich enthält die Straßenstruktur Funktionalität zum Evaluieren der Straßenmittellinie und der Seiten der Straße zu irgendeinem Punkt entlang der Straße. In einigen Ausführungsformen existiert die Mittellinienfunktionalität als eine Funktion der Straßenklasse, welche sich auf die Mittellinieninformation der einzelnen Segmente bezieht (und kann auch zwischen irgendwelchen geringfügig nicht zusammenpassenden Mittellinien interpoliert werden). Die Seite der Straßenfunktionalität existiert auch als eine Funktion der Straßenklasse, welche die Seite der Straßenfunktion von den Straßensegmentobjekten verwendet, welche durch das Straßenobjekt enthalten sind.
Zurückkehrend zu 7, nach Kombinieren der Straßensegmente, leitet (bei 725) der Prozess 700 zusätzliche Straßenbeschreibungsdaten ab. In einigen Ausführungsformen umfasst dies Ergänzen von fehlenden Daten in der Straßensegmentinformation. Während einige Ausführungsformen die Straßensegmente (und andere Daten) als Objekte implementieren, werden in einigen Fällen die Objektvariablen Nullwerte aufweisen, weil die Daten nicht durch den Kartendaten-Provider bereitgestellt worden sind. Zum Beispiel können Geschwindigkeitsbeschränkungen, Straßenbreite, Anzahl von Spuren oder andere Parameter fehlen. Einige Ausführungsformen ergänzen automatisch Werte für zumindest einige der fehlenden Daten eines Straßensegments, wenn möglich, entweder unter Verwendung anderer Informationen aus dem Straßensegment oder Informationen von benachbarten Straßensegmenten. Zum Beispiel könnten einige Ausführungsformen fehlende Geschwindigkeitsbeschränkungsinformation für ein Straßensegment ergänzen, basierend auf den Geschwindigkeitsbegrenzungen der benachbarten Segmente (z. B. wenn ein erstes Segment eine Geschwindigkeitsbeschränkung von 55 mph und ein drittes Segment eine Geschwindigkeitsbeschränkung von 35 mph hat, dann könnte das mittlere Segment ergänzt werden mit einer 45 mph Geschwindigkeitsbeschränkung).
Andere Ausführungsformen ergänzen nur Daten, welche notwendig sind zum Erzeugen der Straßengeometrie, wie beispielsweise die Anzahl von Spuren und Straßenbreiteninformation. Zum Beispiel können einige Ausführungsformen benachbarte Straßensegmente innerhalb einer aggregierten Straße verwenden zum Erzeugen der Anzahl von Spuren (z. B. wenn Segmente auf beiden Seiten eines speziellen Segments eine spezielle Anzahl von Spuren haben, kann diese spezielle Anzahl von Spuren dem speziellen Segment auch zugewiesen werden). Für die Straßenbreite verwenden einige Ausführungsformen die Anzahl von Spuren (wenn sie existiert) zum Zuweisen einer Breite an die Straße (z. B. Annehmen, dass jede Spur 4 m breit ist). Andererseits weisen einige Ausführungsformen Straßenbreiten basierend auf dem Straßentyp zu (d. h. Autobahnen haben eine erste Breite, Hauptstraßen haben eine zweite Breite, usw.). Tatsächlich leiten einige Ausführungsformen die Anzahl von Spuren aus dem Straßentyp ab (z. B. werden Autobahnen immer drei Spuren zugewiesen, usw.), erzeugen dann die Breite basierend auf der Anzahl von Spuren.
Zusätzlich ergänzen einige Ausführungsformen fehlende Daten für Höhe oder Erhebungsinformation. Wie oben beschrieben, zeigen in einigen Fällen die Kartendaten spezifisch an, dass ein spezielles Straßensegment über (oder unter) einem anderen Straßensegment durchläuft, oder über (oder unter) einer Kreuzung, oder dass eine spezielle Kreuzung über (oder unter) einer anderen Kreuzung durchläuft. Jedoch können diese relativen Höhendaten in einigen Fällen fehlen. Wenn ein erstes Segment (oder Kreuzung) und zweites Segment (oder Kreuzung) Mittellinienpfade haben, welche sich in einer flachen Ebene kreuzen, aber für welche keine Kreuzung definiert ist, dann müssen die Pfade bei unterschiedlichen Höhen sein. Wenn die absoluten Höhendaten von dem Kartendaten-Provider umfasst sind, können diese Daten verwendet werden zum Ermitteln der relativen Höhendaten (d. h. Definieren einer Beziehung, dass ein erstes Segment mit niedrigerer absoluter Höhe unter einem zweiten Segment mit einer höheren absoluten Höhe durchläuft.
Wenn die relativen Höhendaten für einen speziellen Satz von Straßensegmenten nicht ermittelt werden können, welche sich in der Ebene kreuzen, aber sich nicht bei einer Kreuzung treffen, erzeugen einige Ausführungsformen eine zufällige relative Reihenfolge für die Segmente. In anderen Ausführungsformen kann eine wahrscheinliche relative Reihenfolge aus den Straßentypen der sich nicht kreuzenden Straßen abgeleitet werden, kann aber auch Attribute anderer naher Straßensegmente verwenden. 11 zeigt eine Situation, in welcher ein erstes Straßensegment 1105 („I-405N”) (in einer Ebene) durch ein zweites Straßensegment 1110 („Wilshire Blvd.”) und ein drittes Straßensegment 1115 („Hauptstraße”) gekreuzt wird. Jedoch in diesem Fall zeigen die Kartendaten keine Kreuzungen zwischen diesen Straßensegmenten an. Das I-405N-Segment hat eine Höhe von 1, während das Wilshire-Segment eine Höhe von 0 hat. Jedoch hat das Hauptstraßen-Segment eine Nullhöhe (d. h. diese Information wird nicht bereitgestellt). Basierend auf der Tatsache, dass das I-405N-Segment über dem Wilshire Blvd.-Segment durchläuft, nehmen einige Ausführungsnehmen auch an, dass das I-405N über der Hauptstraße verläuft. Als solches ergänzen die Kartendienstoperationen automatisch die Höhe der Straßensegmentdatenstruktur für die Hauptstraße mit einem Wert von 0, oder werden eine relative Reihenfolge ergänzen, welche anzeigt, dass das Segment der Hauptstraße unter dem Segment des I-405N verläuft.
Zusätzlich stellt (bei 730) der Prozess 700 Beziehungen zwischen Straßen und Straßensegmenten her. In einigen Ausführungsformen umfasst das Herstellen von Beziehungen Identifizieren von semantischen Daten, wie beispielsweise gegenüberliegenden Seiten einer zweispurigen Fahrbahn, und definieren von Verbindungen zwischen den in Beziehung stehenden Straßen. In einigen Ausführungsformen identifiziert der Prozess Straßen, welche Straßensegmente mit dem gleichen oder ähnlichen Namen enthalten (z. B. „ 1–5 N” und „1–5 S”), welche als zweispurige Fahrbahnen markiert sind (d. h. in einer Form von Wegfeld) und welche innerhalb einer Schwellendistanz voneinander und einem Schwellenwinkel des zueinander parallel seins sind. 12 zeigt zwei Straßensegmente 1205 und 1210, welche eine Distanz X entfernt liegen, parallel in entgegengesetzten Richtungen verlaufen, und beide mit „Hauptstraße” benannt sind. Angenommen, dass die Distanz X weniger als die Schwellendistanz für Straßen mit dem gleichen Namen ist, dann werden diese Straßen verbunden als assoziierte zweispurige Fahrbahnen, und Abbiegungen zwischen den Straßen können als Kehrtwenden anstatt separater Linksabbiegungen klassifiziert werden. Zusätzliche semantische Daten, welche weitergegeben werden können, umfassen Zuweisen von Namen an Verbindungsstraßen/Auffahrten (z. B. Autobahneinfahrten, Autobahnkreuze, Rechtsabbiegungsauffahrten, usw.).
Schließlich erzeugt (bei 735) der Prozess 700 eine geglättete Version der Straßen. In einigen Ausführungsformen können Mittelliniendaten Rauschen aufweisen. Zum Beispiel kann eine Fünf-Meilen-Strecke einer Autobahn tatsächlich gerade sein, aber die Daten können ein leichtes Hin-und-Her an Stellen aufweisen. Zusätzlich, während die Straßen als Linien zwischen Mittellinienknoten definiert sind, können Knicke erscheinen, wo die Straße in der Realität eine gleichmäßige Abbiegung aufweist. Des Weiteren, wenn Straßensegmente bei Kreuzungen verbunden werden, kann dies scharfe Abbiegungen erzeugen, welche in der Realität gleichmäßiger sein sollten. Da diese Art von Rauschen nicht gewollt ist, wenden einige Ausführungsformen eine Glättungsoperation auf die Straßen an, welche durch Straßeneigenschaften gesteuert wird (z. B. entweder ein Straßensegment zu einer Zeit, oder auf aggregierte Straßen) in dem Straßengraphen. Um das Glätten auszuführen, können verschiedene unterschiedliche Operationen durch unterschiedliche Ausführungsformen ausgeführt werden. Einige Ausführungsformen verwenden Glättungsoperationen, welche jeden Knoten in der Straße eine Distanz bewegen, basierend auf den Orten ihrer Nachbarknoten (z. B. Laplace'sches Glätten).
Einige Ausführungsformen erlauben mehr Glätten für schnellere Straßen, wegen der Erwartung, dass diese Straßen (z. B. Autobahnen) gleichmäßiger sein werden und weniger wahrscheinlich scharfe Winkel aufweisen. Einige Ausführungsformen verwenden die Geschwindigkeitsbeschränkungsdaten zum Steuern der Glättung. Zum Beispiel erlauben einige Ausführungsformen unterschiedliche Abweichungen der Mittellinie von den empfangenen Knotendaten für Straßen mit unterschiedlichen Geschwindigkeitsbeschränkungen (z. B. erlauben von bis zu einer 5 Meter Abweichung für Straßen mit Geschwindigkeitsbeschränkung 65, und einer 2 Meter Abweichung für Straßen mit 30 mph). 13 zeigt eine geknickte Straße 1310, welche eine Geschwindigkeitsbeschränkung von 25 mph aufweist. Das Ergebnis des Anwendens der Glättungsoperation auf die Straße wird als modifizierte Straße 1320 gezeigt. 14, auf der anderen Seite, zeigt eine in ähnlicher Weise geknickte Straße 1410 mit einer Geschwindigkeitsbeschränkung von 60 mph. Das Ergebnis des Anwendens einer ähnlichen Glättungsoperation auf die Straße wird als modifizierte Straße 1420 gezeigt. Wie gezeigt, zeigt die modifizierte Straße 1420 einen größeren Level von Kurvenglättung, weil die Geschwindigkeitsbeschränkung der Straße größer ist. Einige Ausführungsformen verwenden andere Eigenschaften zum Modifizieren des Levels von erlaubter Glättung, wie beispielsweise Straßentypen (welche als ein Vertreter für Geschwindigkeitsbeschränkung dienen können).
Zusätzlich beschränken einige Ausführungsformen das Glätten in Spezialfällen. Zum Beispiel könnte eine Straße eine 90°-Abbiegung machen (z. B. wo zwei Straßen beide an einer Kreuzung in einer Wohngegend enden, und miteinander verbunden worden sind). In solch einem Fall fixieren einige Ausführungsformen, statt die Straße zu sehr zu glätten, zwei Punkte nahe der Kreuzung (einer auf jeder Seite der 90°-Abbiegung) und Glätten einen kleinen Winkel zwischen diesen zwei Punkten).
B. Erzeugen von Straßengeometrie
Nach Erzeugen des Straßengraphen aus den Straßensegmenten und Kreuzungen, dem Aggregieren von Straßen in dem Straßengraphen, Ergänzen von fehlenden Daten, Glätten der aggregierten Straßen usw., erzeugt die Offline-Verarbeitung des Kartendienstes einiger Ausführungsformen Geometrie für die Straßen in dem Straßengraphen. In einigen Ausführungsformen weist die Geometrie einen Satz von Knoten auf, welche die Kanten von Polygonen, welche durch die Client-Kartenanwendung zu rendern sind, definieren. Diese Geometrien sind in den Vektorkartenkacheln umfasst, welche an die Vorrichtungen gesendet werden, welche die Kartenanwendungen ausführen, um für die Kartenanwendungen die resultierenden Polygone zu rendern. Die Kartendienstverarbeitung basiert anfänglich die Geometrie weg von den Straßensegmentdefinitionen (d. h. die Mittellinienknoten und Breitendaten), aber führt auch verschiedene Anpassungsoperationen auf der Geometrie aus, wie beispielsweise Glätten der Polygone zum Erzeugen von realistischeren gerenderten Straßen und Verkehrskreuzungen, Eliminieren von Überlappungen und Beschriften von Knoten mit Daten, welche Merkmale zum Zeichnen markieren (z. B. Schatten, Brückenumhüllungen, Bordsteine, Bürgersteige, Tunnel usw.).
15 zeigt konzeptionell einen Prozess 1500 einiger Ausführungsformen zum Erzeugen der Straßengeometrie, welche zum Erzeugen von Straßenpolygonen auf der Client-Kartenanwendung zu verwenden ist. Wie bei dem Prozess 700, führen verschiedene Ausführungsformen den Prozess 1500 als einen Offline-Prozess aus, welcher auf einer einzigen Rechnervorrichtung oder verteilt über mehrere Rechnervorrichtungen ausgeführt werden kann.
Wie gezeigt, beginnt der Prozess 1500 durch Empfangen (bei 1505) eines Straßengraphen für eine Kartenregion. Der Straßengraph, wie oben beschrieben und gezeigt in 8, ist ein verbundener Satz von Straßensegmenten und Kreuzungen. In einigen Ausführungsformen wird der Prozess 700 (oder ein ähnlicher Straßengraph-Erzeugungsprozess) separat für unterschiedliche Kartenregionen ausgeführt (z. B. für Staaten, rechteckige geographische Bereiche, Landmassen, usw.).
Der Geometrie-Erzeugungsprozess 1500 erzeugt (bei 1510) eine initiale Polygondarstellung der Straßensegmente in dem Straßengraphen. Einige Ausführungsformen erweitern die stückweise lineare Mittelliniendarstellung (welche ziemlich glatt sein sollte, nach Einfügen von Knoten bei einer regulären Distanz und dann Glätten dieser Knoten, in einem Prozess, wie beispielsweise Prozess 700 wie oben beschrieben) in ein Polygon, welches dem Pfad der Straße folgt, mit der Breite, welche durch seine Straßensegmentdatenstruktur spezifiziert ist. Das resultierende Polygon ist im Wesentlichen eine Struktur mit parallelen Seiten, welche als gebogen erscheinen können. Jedoch werden diese Polygone in vielen Situationen angepasst werden müssen, um eine realistischere Straßenanimation zu erzeugen.
Die Polygonanpassung in einigen Ausführungsformen umfasst Glätten der Polygone, zum Erzeugen realistischerer gerenderter Straßen und Kreuzungen, Eliminieren von Überlappungen und Beschriften von Knoten mit Daten, welche zu zeichnende Merkmale markieren (z. B. Schatten, Brückenumhüllungen, Bordsteine, Tunnel, usw.). Die nächsten, mehreren Operationen in Prozess 1500 beschreiben diese Anpassungsoperationen in einer speziellen Reihenfolge. Jedoch wird der Fachmann erkennen, dass sobald die initialen Polygone aufgebaut sind, diese Operationen in unterschiedlichen Reihenfolgen ausgeführt werden können.
Der Prozess 1500 passt (bei 1515) die Geometrien bei den Kreuzungen an. Im Allgemeinen, mit Ausnahme der Überlappungen zwischen zwei oder mehreren Geometrien, ist das Glätten primär notwendig bei den Kreuzungen des Straßengraphen. Innerhalb eines Straßensegments sollte das Glätten der Knoten, die oben beschrieben sind, jede Art von Aufdrängen oder Unregelmäßigkeiten verhindern. Einige Ausführungsformen durchlaufen den Straßengraphen und bestimmen bei jeder Kreuzung, ob irgendwelche Modifikationen der Geometrie notwendig sind, um eine glatte, ansprechende gerenderte Straße an der Client-Kartenanwendung sicherzustellen (und dann diese Modifikationen zu machen). Diese Kreuzungen können nicht mehr als eine Straße, welche in einer geraden Linie fortgesetzt wird, umfassen, wo die Geschwindigkeitsbeschränkungen sich ändern (was nicht irgendwelches Glätten in einigen Ausführungsformen umfassen wird, wenn die Straßenbreite konstant bleibt), aber kann auch Autobahnzusammenführungen umfassen, Straßen, die sich bei unterschiedlichen Winkeln kreuzen, Verkehrskreuzungen zwischen großen und kleinen Straßen (von welchen eine Autobahnzusammenführung ein Beispiel ist) Spurerweiterungen, usw.
Das Folgende wird verschiedene Typen dieser Kreuzungsglättungsbeispiele beschreiben, zusammen mit Figuren für einige der Beispiele. Wenn eine Straße ihre Anzahl von Spuren erweitert oder verringert, führen einige Ausführungsformen eine spezielle Glättungsoperation aus. In einigen Ausführungsformen bestimmt die Kartendienstverarbeitung zuerst, ob eine Kreuzung nur zwei Kanten umfasst, und dann, dass diese zwei Kanten innerhalb einer Straße verbunden sind. Wenn dies der Fall ist, und die Anzahl der Spuren sich ändert, führen dann einige Ausführungsformen eine der folgenden Übergangsglättungsoperationen aus, um unnatürlich aussehende scharfe Winkel zu verhindern.
16 zeigt eine erste Operation, welche ausgeführt wird zum Glätten einer Spurerweiterungskreuzung, in welcher eine der Seiten der Straße gerade bleibt (d. h. „ausgerichtet” ist), über drei Stufen 1610–1630. Wie in der ersten Stufe 1610 gezeigt, verbindet in diesem Beispiel ein erstes Straßensegment 1605 in ein zweites Straßensegment 1615. Das erste Straßensegment 1605 weist Daten auf, welche anzeigen, dass es zwei Spuren hat, während das zweite Straßensegment 1615 Daten aufweist, welche anzeigen, dass es drei Spuren hat. In einigen Fällen werden diese Daten in den Straßensegmentdaten angezeigt, welche von dem Kartendaten-Provider empfangen werden. Wenn der Kartendaten-Provider Spurinformationen umfasst, umfasst in einigen Fällen der Provider zusätzlich Spurkonnektivitätsdaten. In einigen Fällen sind die Spuren nummeriert (z. B. von links nach rechts), und die Konnektivitätsdaten zeigen an, welche Spur in einem ersten Segment (z. B. Segment 1605) in welche Spur in einem zweiten Segment fortfährt (z. B. Segment 1615). Wie in der ersten Stufe 1610 gezeigt, fährt in diesem Fall Spur 1 des ersten Segments 1605 in Spur 1 des zweiten Segments 1615 fort, während Spur 2 des ersten Segments in sowohl Spuren 2 als auch 3 des zweiten Segments fortfährt. Dies zeigt an, dass die Spurerweiterung auf der rechten Seite der Straße auftritt („rechts” basierend auf der Fahrtrichtung der Straße). Diese Spurkonnektivitätsdaten können mit der Kreuzung gespeichert werden oder mit einem oder beiden der Segmente in verschiedenen Ausführungsformen.
Die zweite Stufe 1620 zeigt die ursprünglich aufgebauten Segmentgeometrien 1625 und 1635 für die ersten und zweiten Straßensegmente. Wie gesehen werden kann, ist die zweite Segmentgeometrie 1635 breiter als die erste Segmentgeometrie 1625 und die gesamte dieser zusätzlichen Breite ist an der rechten Seite der Straße, wobei die linke Seite der Straße ausgerichtet ist. Wenn Spurkonnektivitätsdaten bereitgestellt werden, erzeugen einige Ausführungsformen die Geometrie mit der zusätzlichen Spur, welche in dem korrekten Ort erscheint. Jedoch, wenn unter Verwendung dieser Geometrie gerendert, würde der Asphalt als einen 90°-Winkel aufweisend erscheinen, wobei die Spur aus dem Nichts erscheint. Während gelegentlich Autobahnspuren auf diese Weise starten, erstrecken sie sich typischerweise gleichmäßig aus der existierenden Spur.
Somit schrägen einige Ausführungsformen automatisch die Spurerweiterung ab, wie gezeigt in der dritten Stufe 1630. Einige Ausführungsformen identifizieren einen Punkt entlang der Kante der engeren Segmentgeometrie (die Geometrie mit weniger Spuren) und schrägen (taper) von diesem Punkt zu dem Start der Kante des breiteren Segments ab. Einige Ausführungsformen verwenden eine feste Distanz zum Identifizieren des Punkts (z. B. 25 Meter, 50 Meter, usw.). Das Abschrägen kann eine gerade Linie sein, wie gezeigt, oder eine Kurve. Zusätzlich verwenden einige Ausführungsformen den Übergang innerhalb der breiteren Geometrie oder verteilen den Übergang entlang der zwei Geometrien.
17 zeigt das Ergebnis 1700 der geglätteten Spurerweiterung, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Für diese Figur, sowie eine Anzahl von Figuren innerhalb dieses Abschnitts, wird das Ergebnis von spezifischen Straßensegmenten, wie gerendert auf einer Client-Kartenanwendung gezeigt. In diesen Figuren werden verschiedene Steuerungen und Merkmale, welche typischerweise in der Kartenanwendungsanzeige präsent wären (z. B. ein Benutzer-Ortsindikator (oder Navigations-Puck), eine Routenlinie, zusätzliche Geländeoberfläche und Gebäudemerkmale, UI-Steuerungen, usw.) nicht angezeigt, um die verschiedenen Aspekte der Straßensegmente hervorzuheben. In 17 macht der Asphalt einen gleichmäßigen Übergang von zwei zu drei Spuren, und Spurmarkierungen beginnen kurz bevor die Spur vollständig gebildet ist. Wie unten beschrieben werden wird, fügen einige Ausführungsformen Straßenumhüllungen (z. B. Bordsteine, Leitplanken, usw.) und Spurmarkierungen hinzu. In unterschiedlichen Ausführungsformen können die Instruktionen zum Zeichnen der Straßenumhüllung an die Client-Kartenanwendungen als zusätzliche Geometrien oder als Beschriftungen für die Geometrie kommuniziert werden, mit Instruktionen zum Rendern basierend auf den Beschriftungen, welche an der Client-Vorrichtung gespeichert werden.
18 zeigt eine zweite Operation, welche ausgeführt wird zum Glätten einer Spurerweiterungskreuzung, in welcher die Straße sich an beiden Seiten erweitert, über drei Stufen 1810–1830. Wie in der ersten Stufe 1810 gezeigt, verbindet in diesem Beispiel ein erstes Straßensegment 1805 in ein zweites Straßensegment 1815. In diesem Fall gibt es keine Spurkonnektivitätsdaten, aber das erste Straßensegment 1805 hat zwei Spuren, während das zweite Straßensegment 1815 drei Spuren hat. Die Spurzähldaten können direkt von dem Karten-Provider bereitgestellt werden, oder entweder von der bereitgestellten Straßenbreite oder dem Straßentyp hergeleitet werden.
Die zweite Stufe 1820 zeigt die ursprünglich aufgebauten Segmentgeometrien 1825 und 1835 für die ersten und zweiten Straßensegmente. Wie gesehen werden kann, ist die zweite Segmentgeometrie 1835 breiter als die erste Segmentgeometrie 1825, mit der zusätzlichen Breite aufgeteilt zwischen den zwei Seiten der Straße. Wenn keine Spurkonnektivitätsdaten verfügbar sind, verwenden einige Ausführungsformen eine Default-Spurerweiterung, welche den Unterschied zwischen den zwei Seiten der Straße aufteilt. Jedoch, wenn gerendert unter Verwendung dieser Geometrie, würde der Asphalt als einen 90°-Winkel auf jeder Seite aufweisend erscheinen. Während Autobahnspuren gelegentlich auf diese Weise starten könnten, erweitern sie sich typischerweise gleichmäßig aus der existierenden Spur.
Somit schrägen einige Ausführungsformen automatisch die Spurerweiterung auf jeder Seite ab, wie gezeigt in der dritten Stufe 1830. Einige Ausführungsformen identifizieren für jede Seite der Straße einen Punkt entlang der Kante der engeren Segmentgeometrie und schrägen von diesem Punkt zu dem Start der Kante des weiteren Segments ab. Einige Ausführungsformen verwenden eine feste Distanz zum Identifizieren des Punkts (z. B. 25 Meter, 50 Meter, usw.). Das Abschrägen kann eine gerade Linie sein, wie gezeigt, oder eine Kurve. Zusätzlich verwenden einige Ausführungsformen den Übergang innerhalb der breiteren Geometrie oder verteilen den Übergang über die zwei Geometrien.
19 zeigt das Ergebnis 1900 der geglätteten Spurerweiterung, wie gerendert durch eine Client-Kartenanwendung (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt macht einen gleichmäßigen Übergang von zwei zu drei Spuren. Einige Ausführungsformen biegen zwei der Spuren in eine Richtung und fügen die neue Spur auf der anderen Seite hinzu, um die Spurmarkierungen kontinuierlich zu halten, in einigen Ausführungsformen (z. B. Wählen einer zufälligen Seite der neuen Spur, oder Verwenden eines Defaults.
Die obigen Beispiele sind Situationen, in welchen die in Frage stehende Kreuzung nur zwei Straßensegmente aufweist. Für Kreuzungen mit drei oder mehr Straßensegmenten identifizieren einige Ausführungsformen Spezialfälle, und für andere Fälle schreiten sie durch die Liste von Straßensegmenten in der Kreuzung und führen Korrekturen auf den Geometrien für nachfolgende Paare von Straßen aus. Ein solcher Spezialfall tritt auf, wenn eine bidirektionale einspurige Fahrbahnstraße sich aufteilt in ein Paar von entsprechenden zweispurigen Fahrbahnen. Dies tritt oft auf, wenn ein Median in eine zweispurige Straße eingeführt wird (eine Spur in jeder Richtung). Einige Ausführungsformen schrägen die Straße nach außen ab (von der einspurigen Fahrbahn zu der zweispurigen Fahrbahn) an den äußeren Kanten und identifizieren einen Zusammenführungspunkt für die internen Kanten der zweispurigen Fahrbahnen. Einige Ausführungsformen verwenden Spurinformation zum Bestimmen des Zusammenführungspunkts (z. B. wenn eine der zweispurigen Fahrbahnen eine Spur ist, während die andere zwei Spuren ist), während andere Ausführungsformen einen Default eines Punkts an dem Mittelpunkt der einspurigen Fahrbahn verwenden, an seinem Ende.
Beim Durchschreiten durch die Liste von Straßensegmenten bei einer Kreuzung führen einige Ausführungsformen unterschiedliche Korrekturen basierend auf dem Winkel zwischen zwei Segmenten aus. Einige Ausführungsformen wählen ein erstes Straßensegment der Kreuzung aus, korrigieren dann die Ecke, welche durch die linke Seite der Segmentgeometrie (wie betrachtet beim Austreten aus der Kreuzung) mit der rechten Seite der Segmentgeometrie (wie betrachtet beim Verlassen der Kreuzung) für ein zweites Segment, direkt entgegen dem Uhrzeigersinn von dem ersten Segment gebildet wird. Das zweite Segment wird dann als das erste Segment eingestellt, und der Prozess wird für die nächste Ecke wiederholt, bis alle der Ecken korrigiert worden sind.
Das Folgende wird verschiedene Korrekturen beschreiben, welche für verschiedene Kreuzungswinkel ausgeführt werden, zusammen mit Figuren für einige der Beispiele. Diese Figuren zeigen, obwohl sie Kreuzungen mit mehreren Straßensegmenten zeigen, die Geometrien für nur die zwei Segmente, welche einander im Beispiel entsprechen.
20 zeigt eine Abschrägungsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien, wenn der Winkel zwischen den Segmenten größer als ein erster Schwellenwinkel ist (z. B. 170°), über drei Stufen 2010–2030. In einem solchen Fall schrägen einige Ausführungsformen automatisch die Seite einer der Straßen ab, um die Seite der anderen Straße zu treffen. Wie in der ersten Stufe 2010 gezeigt, kreuzt in diesem Beispiel ein erstes Straßensegment 2005 sich mit einem zweiten Straßensegment 2015 bei einer Kreuzung, sowie mit zwei zusätzlichen Straßensegmenten 2025 und 2035.
Die zweite Stufe 2020 zeigt die ursprünglich aufgebauten Segmentgeometrien 2040 und 2045 für die zwei Straßensegmente 2005 und 2015. Die Geometrien der anderen zwei Straßensegmente sind in dieser Figur nicht gezeigt, da die Kartendienstverarbeitung einiger Ausführungsformen jeweils eine Ecke der Kreuzung korrigiert, und dieses Beispiel die Korrektur zwischen den Segmenten 2005 und 2015 zeigt. Die Kartendienstverarbeitung einiger Ausführungsformen würde dann eine Korrektur auf der Ecke zwischen dem Segment 2015 und dem Segment 2025 ausführen, eine Korrektur auf der Ecke zwischen dem Segment 2025 und dem Segment 2035, und schließlich eine Korrektur auf der Ecke zwischen dem Segment 2035 und dem Segment 2005. Wie bei dieser zweiten Stufe 2020 gezeigt, umfasst die ursprüngliche Ecke zwischen der Geometrie 2040 und der Geometrie 2045 eine visuell nicht zusammenpassende (und unrealistische) Diskontinuität, teilweise aufgrund der Straßen, welche unterschiedliche Breiten aufweisen (obwohl einige Ausführungsformen den gleichen Prozess für Straßen der gleichen Breite ausführen).
Somit schrägen einige Ausführungsformen automatisch die Seite des engeren Straßensegments zu der Seite des breiteren Straßensegments ab, wie gezeigt durch die modifizierte Geometrie 2040 in der dritten Stufe 2030. In diesem Fall, weil das breitere Segment dasjenige der zwei Straßensegmente ist, welches mehr entgegen dem Uhrzeigersinn ist, schrägt die Verarbeitung die linke Seite des engeren Segments zu der rechten Seite des breiteren Segments ab (für dieses und nachfolgende Beispiele werden die „rechten” und „linken” Seiten eines speziellen Straßensegments von der Perspektive eines Fahrzeugs betrachtet, welches die Kreuzung entlang des speziellen Straßensegments verlässt). Wenn das breitere Segment dasjenige der zwei Segmente ist, welches mehr im Uhrzeigersinn ist, schrägt die Verarbeitung die rechte Seite des engeren Segments zu der linken Seite des breiteren Segments ab. Um die Abschrägungsoperation auszuführen, fixieren einige Ausführungsformen einen Punkt entlang der Seite der engeren Segmentgeometrie und schrägen von diesem Punkt zum Start der Seite der breiteren Geometrie ab. Einige Ausführungsformen verwenden einen feste Abstand zum Identifizieren des Punkts (z. B. 25 Meter, 50 Meter, usw.). Die Abschrägung kann eine gerade Linie sein, wie gezeigt, oder eine Kurve. Diese Operation ist ähnlich zu dem Abschrägen, welches in 16 gezeigt ist, und kann auch ausgeführt werden, wenn nur zwei Straßen unterschiedlicher Breite sich an einer Kreuzung treffen.
21 zeigt das Ergebnis 2100 der geglätteten Kreuzung, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt zeigt eine weiche Rechtsabbiegung von dem ersten Straßensegment an (wie gezeigt an der Unterseite der Anzeige) zu dem zweiten, breiteren Segment (wie gezeigt an der oberen rechten Seite der Anzeige). Zusätzlich umfasst die Anzeige Asphalt (und Spurmarkierungen, Straßenumhüllungen, usw.) für die anderen beiden Segmente, welche die Kreuzung bilden. In unterschiedlichen Ausführungsformen können die Instruktionen zum Zeichnen der Straßenumhüllung an die Client-Kartenanwendungen als zusätzliche Geometrien oder als Beschriftungen für die Geometrie kommuniziert werden, mit Instruktionen zum Rendern basierend auf der Beschriftung, welche an der Client-Vorrichtung gespeichert wird.
22 zeigt eine Projektionsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien, wenn der Winkel zwischen den Segmenten geringer als ein erster Schwellenwinkel und größer als ein zweiter Schwellenwinkel ist (z. B. zwischen 120° und 170°), über drei Stufen 2210–2230. In einem solchen Fall lassen einige Ausführungsformen automatisch die Seite einer der Straßen herausragen, um die Seite der anderen Straße zu treffen. Wie in der ersten Stufe 2210 gezeigt, kreuzt in diesem Beispiel ein erstes Straßensegment 2205 sich mit einem zweiten Straßensegment 2215 bei einer Kreuzung, sowie mit zwei zusätzlichen Straßensegmenten 2225 und 2235.
Die zweite Stufe 2220 zeigt die ursprünglich aufgebauten Segmentgeometrien 2240 und 2245 für die zwei Straßensegmente 2205 und 2215. Die Geometrien der anderen zwei Straßensegmente sind in dieser Figur nicht gezeigt, da die Kartendienstverarbeitung einiger Ausführungsformen jeweils eine Ecke der Kreuzung korrigiert, und dieses Beispiel die Korrektur zwischen den Segmenten 2205 und 2215 zeigt. Die Kartendienstverarbeitung einiger Ausführungsformen würde dann eine Korrektur auf der Ecke zwischen dem Segment 2215 und dem Segment 2225 ausführen, eine Korrektur auf der Ecke zwischen dem Segment 2225 und dem Segment 2235, und schließlich eine Korrektur auf der Ecke zwischen dem Segment 2235 und dem Segment 2205. Wie bei dieser zweiten Stufe 2220 gezeigt, umfasst die ursprüngliche Ecke zwischen der Geometrie 2240 und der Geometrie 2245 eine visuell nicht zusammenpassende (und unrealistische) Diskontinuität, teilweise aufgrund der Straßen, welche unterschiedliche Breiten aufweisen (obwohl einige Ausführungsformen den gleichen Prozess für Straßen der gleichen Breite ausführen).
Während für den Winkel zwischen den Geometrien, welche in 20 gezeigt sind, die Kartendatenverarbeitung einiger Ausführungsformen die engere Straße zu der breiteren Straße abschrägt, projiziert in diesem Beispiel die Kartendienstverarbeitung die Seite der breiteren Straße auf die engere Straße, wie gezeigt durch die modifizierte Geometrie 2240 in der dritten Stufe 2230. In diesem Fall, weil das breitere Segment dasjenige der zwei Straßensegmente ist, welches mehr gegen den Uhrzeigersinn ist, projiziert die Verarbeitung die rechte Seite der Geometrie 2245 auf die Mittellinie (oder die linke Seite, in einigen Ausführungsformen) der Geometrie 2240. Wenn das breitere Segment dasjenige der zwei Straßensegmente ist, welches mehr im Uhrzeigersinn ist, projiziert die Verarbeitung die linke Seite des breiteren Segments auf die Mittellinie (oder die rechte Seite, in einigen Ausführungsformen) des engeren Segments. Während die Abschrägungsoperation Ändern des Winkels der Seite einer der Segmente umfasst, erweitert die Projektion einfach die projizierte Seite in einigen Ausführungsformen, wie gezeigt in Stufe 2230.
23 zeigt das Ergebnis 2300 der geglätteten Kreuzung, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt zeigt eine weiche Rechtsabbiegung von dem ersten Straßensegment an (wie gezeigt an der Unterseite der Anzeige) zu dem zweiten, breiteren Segment (wie gezeigt an der oberen rechten Seite der Anzeige). Zusätzlich umfasst die Anzeige Asphalt (und Spurmarkierungen, Straßenumhüllungen, usw.) für die anderen beiden Segmente, welche die Kreuzung bilden. In unterschiedlichen Ausführungsformen können die Instruktionen zum Zeichnen der Straßenumhüllung an die Client-Kartenanwendungen als zusätzliche Geometrien oder als Beschriftungen für die Geometrie kommuniziert werden, mit Instruktionen zum Rendern basierend auf der Beschriftung, welche an der Client-Vorrichtung gespeichert wird.
24 zeigt eine Beschneidungsoperation (clipping Operation), welche ausgeführt wird zum Eliminieren von überschüssiger Straße für die Straßensegmentgeometrien, wenn der Winkel zwischen den Segmenten geringer als ein erster Schwellenwinkel und größer als ein zweiter Schwellenwinkel ist (z. B. zwischen 30° und 80°), über drei Stufen 2410–2430. In einem solchen Fall schneiden einige Ausführungsformen automatisch die Seite einer oder beider Straßen ab, um Überschreiten der anderen Straße zu verhindern. Wie in der ersten Stufe 2410 gezeigt, kreuzt in diesem Beispiel ein erstes Straßensegment 2405 sich mit einem zweiten Straßensegment 2415 bei einer Kreuzung, sowie mit einem zusätzlichen Straßensegment 2425.
Die zweite Stufe 2420 zeigt die ursprünglich aufgebauten Segmentgeometrien 2440 und 2445 für die zwei Straßensegmente 2405 und 2415. Die Geometrie für das andere Straßensegment ist in dieser Figur nicht gezeigt, da die Kartendienstverarbeitung einiger Ausführungsformen jeweils eine Ecke der Kreuzung korrigiert, und dieses Beispiel die Korrektur zwischen den Segmenten 2405 und 2415 zeigt. 25, wie unten beschrieben, zeigt die Korrektur zwischen Segmenten 2415 und 2425. Wie gezeigt bei dieser zweiten Stufe 2420, ist die ursprüngliche Ecke zwischen der Geometrie 2440 und 2445 nicht problematisch, aber die rechte Seite der Geometrie 2445 überschreitet die rechte Seite der Geometrie 2440, teilweise aufgrund dessen, dass die Geometrie 2440 enger als die Geometrie 2445 ist.
Somit schneidet die Kartendienstverarbeitung einiger Ausführungsformen die linke Seite des Segments, welche mehr im Uhrzeigersinn ist, zurück zu der Mittellinie desjenigen der zwei Segmente, welches mehr gegen den Uhrzeigersinn ist, und schneidet entsprechend die rechte Seite des Segments, welches mehr gegen den Uhrzeigersinn ist, zurück zu der Mittellinie des Segments, welches mehr im Uhrzeigersinn ist, wie gezeigt durch die modifizierten Geometrien 2440 und 2445 in der dritten Stufe 2430. In einigen Ausführungsformen wird nur die Seite des breiteren Straßensegments abgeschnitten, aber andere Ausführungsformen schneiden beide Geometrien ab, wie gezeigt. Wie gezeigt in der dritten Stufe 2430, entfernt dies das überschüssige „Ohr” der Straße, welches ansonsten unrealistisch aus der Kreuzung herausragen würde.
25 zeigt eine Kreuzungsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen der Straßensegmentgeometrie 2445 und einer Straßensegmentgeometrie 2505 für das Straßensegment 2425, über drei Stufen 2510–2530. Einige Ausführungsformen führen die Kreuzungsoperation für Winkel größer als 180° aus, aufgrund der Lücke, welche zwischen den Straßensegmentgeometrien bei solch großen Winkeln hinterlassen wird. In solch einem Fall identifizieren einige Ausführungsformen eine einen Schnittpunkt zwischen den Tangenten der Straßenseiten und erweitern oder schneiden die Straßengeometrien ab, so dass die Seiten an diesem Schnittpunkt enden.
Die zweite Stufe 2520 zeigt die Segmentgeometrie 2445, wie modifiziert in der Operation, welche in 24 gezeigt ist, sowie die ursprünglich aufgebaute Segmentgeometrie 2505 für das Straßensegment 2425. Wie gezeigt, (i) hinterlässt dies eine Lücke zwischen den zwei Geometrien und (2) resultiert darin, dass das breitere Segment 2445 das Segment 2505 überschreitet. Die zweite Stufe zeigt auch eine gestrichelte Linie, welche den Schnittpunkt der Projektion der linken Seite der Geometrie, welche mehr im Uhrzeigersinn ist 2445 mit der Projektion der rechten Seite der Geometrie, welche mehr gegen den Uhrzeigersinn ist 2505 darstellt.
Wie in der dritten Stufe 2530 gezeigt, schneiden einige Ausführungsformen die Seiten der Geometrien ab oder projizieren diese auf diesen Schnittpunkt. In dem Fall des engeren Segments 2505 wird die Seite erweitert, um die Lücke auszufüllen, während in dem Fall des breiteren Segments 2445 die Seite abgeschnitten wird, um ein Überschreiten der Geometrie 2505 zu verhindern.
26 zeigt das Ergebnis 2600 der geglätteten Kreuzung aus den vorherigen zwei Figuren, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt zeigt weiche Abbiegungen zwischen jeder der nachfolgenden Straßen an, ohne fehlende Abschnitte oder überschüssige Teile des Asphalts.
27 zeigt eine Abschrägungsoperation, welche ausgeführt wird zum Glätten einer Ecke zwischen Straßensegmentgeometrien in Situationen, welche zu Charakteristika von Autobahnauffahrten in einigen Ausführungsformen passen, über drei Stufen 2710–2730. In diesem Beispiel fährt ein erstes Segment 2705 gerade in ein drittes Segment 2725 bei einer Kreuzung fort, wobei ein zweites Segment 2715 bei einem flachen Winkel relativ zu dem ersten Segment 2705 in die Kreuzung eintritt. Diese Situation passt zu dem Profil einer Autobahnzusammenführung in einigen Ausführungsformen: Das erste und dritte Segment sind eine verbundene Straße, breiter als das zweite Segment, und der Winkel zwischen dem ersten und dem zweiten Segment ist geringer als ein Schwellenwinkel (z. B. 30°).
Die zweite Stufe 2720 zeigt die ursprünglich aufgebauten Segmentgeometrien 2735–2745 für die drei Straßensegmente 2705–2725. Die zwei Autobahnsegmentgeometrien 2735 und 2745 sind signifikant breiter als die Auffahrt-Segmentgeometrie 2740. Zusätzlich ist die dritte Segmentgeometrie 2745 breiter als die erste Segmentgeometrie 2745, um die Zusammenführungsspur unterzubringen. Jedoch als ein Ergebnis hinterlassen die ursprünglichen Geometrien eine Lücke zwischen der Auffahrtgeometrie 2740 und der dritten Segmentgeometrie 2745.
Somit schrägt die Kartendienstverarbeitung einiger Ausführungsformen die Außenseite (linke Seite) der zweiten Geometrie 2740 zu der rechten Seite der dritten Geometrie 2745 ab, wie in der dritten Stufe 2730 gezeigt. In diesem Fall wird die Abschrägung als ein gekurvter Straßenrand gezeigt, obwohl unterschiedliche Ausführungsformen andere Verfahren verwenden können (z. B. unter Verwendung einer geraden Linie zum Verbinden der Segmente). Einige Ausführungsformen verwenden auch eine Abschrägung von der linken Seite der ersten Geometrie 2735 zu der rechten Seite der dritten Geometrie 2745, wie in dem gerenderten Ergebnis unten gezeigt.
28 zeigt das Ergebnis 2800 der geglätteten Autobahnzusammenführungskreuzung, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt zeigt eine weiche Zusammenführung an, statt die ungleichmäßige Anzeige, welche gerendert werden würde als ein Ergebnis der ursprünglichen rechteckigen Geometrie. Des Weiteren zeigt diese Figur, dass einige Ausführungsformen unterschiedliche Straßen unterschiedlich rendern. Zum Beispiel rendern einige Ausführungen Autobahnen mit einer unterschiedlichen Farbe (oder Schatten) als andere Straßen, einschließlich der Autobahnauffahrten.
Zusätzlich zum Modifizieren der Geometrien mit Abschrägungs-, Projektions-, Abschneide-, usw. Operationen, verwenden einige Ausführungsformen Techniken zum Erzeugen stärker gerundeter Ecken bei bestimmten Typen von Kreuzungen. Statt des Verwendens von Techniken zum Modifizieren der bereits erzeugten Straßensegmentgeometrien, um gerundete Ecken zu erzeugen, erzeugen einige Ausführungsformen neue Geometrien, welche diese runden Ecken erzeugen. In einigen Ausführungsformen wäre Modifizieren der bereits erzeugten Segmentgeometrien extrem verarbeitungsintensiv.
29 zeigt die Erzeugung solcher zusätzlicher Geometrien bei einer Kreuzung, um realistischere, gerundete Ecken bei der Kreuzung zu erzeugen, über drei Stufen 2910–2930. Die erste Stufe 2910 zeigt eine Kreuzung mit vier Straßensegmenten 2905–2935, welche sich bei rechten Winkeln kreuzen. Die zweite Stufe 2920 zeigt die ursprünglichen Geometrien für diese Straßensegmente. In diesem Fall haben alle der Straßensegmente die gleiche Breite, so dass die Geometrien alle die gleiche Form und Größe haben. Weil die Winkel zwischen den Segmenten alle rechte Winkel sind, gibt es keine Notwendigkeit für irgendeines der Projektion, Abschneiden oder Abschrägung, wie oben beschrieben.
Die dritte Stufe 2930 zeigt die Erzeugung von zusätzlichen Geometrien, welche die Straßensegmentgeometrien überlappen und die gerundeten Ecken für die Verkehrskreuzung erzeugen. Insbesondere haben die zusätzlichen Geometrien 2940 (gezeigt als durchgezogene Linien, während die Straßensegmentgeometrien durch gestrichelte Linien bei dieser Stufe dargestellt sind) Kanten, welche von dem Kreuzungsort hin zu den Punkten in einer festen Distanz von den 90°-Ecken, welche durch die Segmentgeometrien gebildet sind, ausstrahlen. Die zusätzlichen Geometrien 2940 haben auch gekurvte Linien zwischen diesen Punkten (oder gerade Linien zwischen genug Knoten, um eine gekurvte Linie zu approximieren, so dass die Verkehrskreuzung mit einer realistischeren, gekurvten Erscheinung gerendert werden wird.
30 zeigt das Ergebnis 3000 der geglätteten Verkehrskreuzung, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Der Asphalt macht keine nicht-zusammenpassenden 90°-Abbiegungen zwischen den Straßensegmenten, sondern hat stattdessen eine kurvigere, ansprechendere Erscheinung. Zusätzlich umfasst die Verkehrskreuzung Stopplinien- und Mittellinienmarkierungen, deren Erzeugung unten beschrieben wird.
Zurückkehrend zu 15, eliminiert (bei 1520) der Prozess 1500 auch Straßenüberlappungen. In einigen Fällen werden sich zwei (oder mehr) ursprünglich aufgebaute Straßengeometrien fehlerhaft überlappen. Geometrien für Straßensegmente, welche sich kreuzen bei Kreuzungen, sollten sich überlappen, und wenn zwei Straßensegmente, welche nicht eine Kreuzung bilden, aber die gleichen Breiten-/Längenkoordinaten durchqueren (z. B. eine Straße mit gestapelten Ebenen, Straßen, welche über-/untereinander verlaufen, usw.), werden ihre Geometrien überlappen (wie projiziert auf eine flache Ebene, welche die Oberfläche der Erde darstellt). Jedoch, wenn die meisten anderen Geometrien überlappen, liegt dies höchstwahrscheinlich an falschen Daten und dies sollte korrigiert werden. Ohne Korrektur würde die gerenderte Karte einem Benutzer der Kartenanwendung anzeigen, dass zwei Straßen sich kreuzen, wenn diese Straßen dies in Wirklichkeit nicht tun.
Die üblichsten Fälle für solch eine Überlappung liegen vor, wenn zwei entsprechende zweispurige Fahrbahnen sich überlappen (z. B. Autobahnen Richtung Norden und Süden oder Richtung Osten und Westen, gegenüberliegende Seiten der Hauptstraßen, welche durch einen Median geteilt sind, usw.). In den meisten Fällen sollten die Geometrien für solche entsprechenden zweispurige Fahrbahnen sehr nahe zueinander kommen, ohne tatsächlich zu überlappen. Jedoch, da die Segmentgeometrie auf den Mittellinien- und Breitendaten für das Segment basiert, wenn irgendeine dieser Informationen leicht ungenau ist, dann können die Geometrien sich nicht korrekt ausrichten. Zum Beispiel, wenn weder eine Spuranzahl noch Breite für eine Straße bereitgestellt ist, leiten einige Ausführungsformen die Breite basierend auf dem Straßentyp her. Jedoch, wenn die Straße tatsächlich enger als gewöhnlich für ihren Straßentyp ist, dann kann die Straßengeometrie am Ende größer sein als die tatsächliche Straße in der Realität. Andere Situationen, welche solch eine Überlappung verursachen können, umfassen eine Autobahn und ihre Nebenfahrbahn, Straßen, welche an einer Autobahn enden, statt über oder unter der Autobahn zu verlaufen, usw.
Unterschiedliche Ausführungsformen verwenden unterschiedliche Techniken zum Entfernen dieser Überlappungen der Straßensegmentgeometrie. Zum Beispiel drücken einige Ausführungsformen zwei Straßen weg voneinander an dem Ort der Überlappung, während andere Ausführungsformen die Breite der Straße bei der Überlappung reduzieren. Zusätzlich, nach Voneinander-Wegbewegen der Straßen, wenn die Straßen entsprechende zweispurige Fahrbahnen sind, fügen einige Ausführungsformen Geometrie für einen Median zwischen den Straßengeometrien hinzu.
31 zeigt Wegdrücken von zwei Straßen, wenn sie überlappen, über drei Stufen 3110–3130. Die erste Stufe 3110 zeigt ein erstes Straßensegment 3105 und ein zweites Straßensegment 3115, jedes als eine Sequenz von Knoten. Wie oben beschrieben, verwenden einige Ausführungsformen eine konstante Distanz zwischen den Mittellinieneckpunkten für Straßen, um Operationen, welche unter Verwendung der Knoten ausgeführt werden, zu standardisieren. Wenn die Straßensegmentdaten durch den Kartendienst von einem Datenprovider empfangen werden, können in einigen Fällen die Knotendaten, welche die Straßensegmentmittellinien darstellen, bei variierenden Distanzen definiert werden (z. B. mit Lücken von 10 m, 25 m, 50 m, usw.). Einige Ausführungsformen definieren Knoten automatisch bei einem vordefinierten Intervall (z. B. alle 10 Meter) nach Aufnehmen der Straßensegmentdaten. Dies stellt sicher, dass (i) die Straßen eine kurvigere, realistischere Erscheinung haben, als wenn die Knoten weit verteilt werden würden, weil die Kartendatenverarbeitung einiger Ausführungsformen geradlinige Kanten zwischen den Eckpunkten definiert. Des Weiteren macht es die Glättungsoperationen, welche oben beschrieben sind, erfolgreicher durch Bereitstellen mehr zu bewegender Punkte in der Operation. Des Weiteren ermöglicht das Definieren der Eckpunkte bei regulären Intervallen nützlichere Tests für Straßenüberlappungen.
Die erste Stufe 3110 zeigt zusätzlich die Straßenseiten, welche für die Straßengeometrien für die Segmente 3105 und 3115 erzeugt werden. Wie klar gesehen werden kann, überlappen sich die zwei erzeugten Straßengeometrien für einen Abschnitt. Um solche Überlappung zu detektieren, erzeugen einige Ausführungsformen Kapseln um jede der Kanten einer Straßenmittellinie (die Linien zwischen aufeinanderfolgenden Eckpunkten) und testen die Kapseln auf Überlappungen. Die erste Stufe 3110 zeigt vier solcher Kapseln: Kapseln 3125 und 3135 für das erste Straßensegment 3105, und Kapseln 3140 und 3145 für das zweite Straßensegment 3115. Die Kapseln in einigen Ausführungsformen werden definiert, die Kante zwischen zwei aufeinanderfolgenden Knoten zu umgeben, und erstrecken sich zu der Breite der Straße (unter Verwendung der Mittellinien- und Breitendaten für das Straßensegment). Während sie als Ovale (d. h. Ellipsen) in diesem Beispiel gezeigt sind, verwenden unterschiedliche Ausführungsformen unterschiedliche Formen für die Kapseln, wie beispielsweise Rechtecke oder andere Parallelogramme, andere Ellipsoide, usw.
Wie bei der ersten Stufe gezeigt, überlappt die Kapsel 3125 für eine erste Kante des ersten Straßensegments 3105 mit der Kapsel 3140 für eine erste Kante des zweiten Straßensegments 3115. Zusätzlich überlappt die Kapsel 3135 für eine zweite Kante des ersten Straßensegments 3105 nicht mit der Kapsel 3145 für eine zweite Kante des zweiten Straßensegments 3115. Zusätzlich, obwohl nicht in dieser Figur gezeigt, würden sich Kapseln für die zwei Kanten jedes Straßensegments zwischen diesen, welche mit Kapseln gezeigt sind, höchstwahrscheinlich auch überlappen. Der Einfachheit halber, beim Zeigen der Modifikation der Straßensegmente, werden diese zusätzlichen Überlappungen nicht gezeigt oder diesen nicht Rechnung getragen in 31.
In einigen Ausführungsformen, wenn eine Überlappung zwischen Kapseln zweier Straßensegmente detektiert wird, wendet die Kartendienstverarbeitung eine „Kraft” auf die Knoten an, welche durch die Kapsel umgeben sind, um die Straßensegmente weg voneinander zu drücken. Einige Ausführungsformen verwenden eine Feder-Masse-Gleichung zum Bestimmen dieser Kraft, wobei größere Überlappungen zwischen den Kapseln in einer größeren Kraft nach außen resultieren. Das heißt, je größer die Überlappung, desto mehr „komprimiert” die Masse die konzeptionelle Feder, was in einer größeren Kraft nach außen resultiert. Einige Ausführungsformen wenden diese Kraft auf jeden der vier Knoten innerhalb der beiden überlappenden Kapseln an, lassen die Kraft dann ebenfalls auf nahegelegene Knoten auslaufen. Die zweite Stufe 3120 zeigt die Anwendung dieser Kräfte, wobei die größten Kraftpfeile auf die zwei Knoten innerhalb jeder der Kapseln 3125 und 3140 angewendet werden, und kleinere Kraftpfeile auf die Knoten auf den beiden Seiten angewendet werden.
In einigen Ausführungsformen identifiziert die Kartendienstverarbeitung jeden Satz von überlappenden Kapseln und identifiziert eine Kraft zum Anwenden auf jeden Knoten als ein Ergebnis dieses individuellen Überlappens. Nach dem Identifizieren der Kräfte auf die unterschiedlichen Knoten integriert die Kartendienstverarbeitung die Kräfte auf jeden Knoten, um an einem neuen Mittellinienpfad für die Straßensegmente anzukommen. Die Verarbeitung führt dann den gleichen Kapseltest aus zum Bestimmen, ob irgendwelche Überlappungen zwischen dem Straßensegment verbleiben. Wenn es immer noch Überlappungen gibt, wendet die Kartendienstverarbeitung zusätzliche Kraft auf die Knoten an und drückt sie erneut voneinander weg. Die dritte Stufe 3130 zeigt, dass die zwei Straßensegmente 3105 und 3115 voneinander weggedrückt worden sind, so dass die Kapseln um die Kanten des ersten Segments überhaupt nicht mit den Kapseln um die Kanten des zweiten Segments überlappen. Wie gezeigt, sind die Straßenseiten für die zwei Straßensegmentgeometrien nun unabhängig und überlappen überhaupt nicht.
Andere Ausführungsformen verwenden unterschiedliche Mechanismen zum Voneinander-Wegbewegen der Knoten. Zum Beispiel, sogar mit mehreren überlappenden Kapseln, bewegen einige Ausführungsformen die Knoten, sobald die erste Überlappung detektiert wurde, gehen dann über zu dem nächsten Satz von Knoten, sobald die ersten identifizierten Sätze weit genug weg voneinander gedrückt worden sind, um irgendwelche Überlappungen zu vermeiden. Zusätzlich, während das Beispiel zeigt, dass Kräfte auf die Knoten um diese, welche überlappen, angewendet werden, bewegen einige Ausführungsformen nur die Knoten der Kante, welche tatsächlich die Überlappung verursacht (d. h. nur die Knoten innerhalb der Kapseln 3125 und 3140). Des Weiteren können unterschiedliche Ausführungsformen unterschiedliche Gleichungen verwenden (d. h. Variieren von der Feder-Masse-Gleichung), um zu bestimmen, wie viel die Knoten voneinander weggedrückt werden müssen, sowie unterschiedliche Gleichungen zur Berechnung, wie weit die umgebenden Knoten zu bewegen sind.
Das Bewegen der Mittellinienpunkte der Straßensegmente ist eine Option, welche von einigen Ausführungsformen verwendet wird zum Handhaben von überlappenden Straßengeometrien. Einige Ausführungsformen andererseits reduzieren die Breite der Straße in der Nähe der Überlappung, statt die Mittellinie zu bewegen (d. h. Reduzieren der Größe der Straßengeometrie).
32 zeigt Reduzieren der Breiten zweier Straßensegmente, wenn die Straßensegmente sich überlappen, über drei Stufen 3210–3230. Die erste Stufe 3210 zeigt ein erstes Straßensegment 3205 und ein zweites Straßensegment 3215, jedes als eine Sequenz von Knoten (ähnlich zu den Straßensegmenten gezeigt in 31). Wie oben beschrieben, verwenden einige Ausführungsformen eine konstante Distanz zwischen Mittellinienknoten für Straßen, um Operationen zu standardisieren, welche unter Verwendung der Knoten ausgeführt werden. Wenn die Straßensegmentdaten durch den Kartendienst von einem Datenprovider empfangen werden, können in einigen Fällen die Knotendaten, welche die Straßensegmentmittellinien darstellen, bei variierenden Distanzen definiert werden (z. B. mit Lücken von 10 m, 25 m, 50 m, usw.). Einige Ausführungsformen definieren Knoten automatisch bei einem vordefinierten Intervall (z. B. alle 10 Meter) nach Aufnehmen der Straßensegmentdaten.
Die erste Stufe 3210 zeigt zusätzlich die Straßenseiten, welche für die Straßengeometrien für die Segmente 3205 und 3215 erzeugt werden.
Wie klar gesehen werden kann, überlappen sich die zwei erzeugten Straßengeometrien für einen Abschnitt. Um solche Überlappung zu detektieren, erzeugen einige Ausführungsformen Kapseln um jede der Kanten einer Straßenmittellinie (die Linien zwischen aufeinanderfolgenden Eckpunkten) und testen die Kapseln auf Überlappungen. Die erste Stufe 3210 zeigt zwei solcher Kapseln: Kapseln 3225 für das erste Straßensegment 3205, und Kapsel 3235 für das zweite Straßensegment 3215. Die Kapseln in einigen Ausführungsformen werden definiert, die Kante zwischen zwei aufeinanderfolgenden Knoten zu umgeben, und erstrecken sich zu der Breite der Straße (unter Verwendung der Mittellinien- und Breitendaten für das Straßensegment). Während sie als Ovale (d. h. Ellipsen) in diesem Beispiel gezeigt sind, verwenden unterschiedliche Ausführungsformen unterschiedliche Formen für die Kapseln, wie beispielsweise Rechtecke oder andere Parallelogramme, andere Ellipsoide, usw. Einige Ausführungsformen können sowohl die Lösung, welche in 31 gezeigt ist, als auch jene, welche in 32 gezeigt ist, verwenden und dieselben Kapseln für jede Lösung verwenden.
Wie bei der ersten Stufe gezeigt, überlappt die Kapsel 3225 für eine Kante des ersten Straßensegments 3205 mit der Kapsel 3235 für eine Kante des zweiten Straßensegments 3215. Zusätzlich, obwohl nicht in dieser Figur gezeigt, würden sich Kapseln für die zwei Kanten jedes Straßensegments unterhalb jener, welche mit überlappenden Kapseln gezeigt sind, höchstwahrscheinlich auch überlappen. Der Einfachheit halber, beim Zeigen der Modifikation der Straßensegmente, werden diese zusätzlichen Überlappungen nicht gezeigt oder diesen nicht Rechnung getragen in 32.
In einigen Ausführungsformen, wenn eine Überlappung zwischen Kapseln zweier Straßensegmente detektiert wird, reduziert die Kartendienstverarbeitung die Breite der Straßensegmente an dem Ort der überlappenden Kapseln. Wie gezeigt in der zweiten Stufe 3220, bewegen einige Ausführungsformen die Straßenseiten an dem Ort der Überlappung nach innen hin zu der Mittellinie, um eine spezielle Distanz. Einige Ausführungsformen bewegen diesen Abschnitt der Straßenseite für ein spezielles Segment eine Distanz proportional zu dem Betrag der Überlappung. Die Distanz kann gerade genug sein, um die Überlappung an dem Ort zu reduzieren, oder dieser Betrag plus zusätzlicher Spielraum sein, so dass es eine Lücke zwischen zwei Straßensegmentgeometrien gibt. Zusätzlich bewegen einige Ausführungsformen nur die Straßenseite, welche die Überlappung verursacht, nach innen, während andere Ausführungsformen symmetrisch die andere Seite jeder Straße ebenso modifizieren (so dass die Mittellinie in der Mitte der Straße verbleibt).
Um zu verhindern, dass die gerenderten Straßen auf einer Client-Kartenanwendung so erscheinen, als ob ein unerwartetes Stück von der Straße entfernt wurde, wählen einige Ausführungsformen einen Punkt entlang des Straßenrands in beiden Richtungen (z. B. 100 Meter, 500 Meter, usw. von den betroffenen Knoten) aus und halten diese Punkte fixiert. Die Kartendienstverarbeitung schrägt dann die Breitenreduzierung heraus aus dem überlappenden Abschnitt zu den fixierten Punkten ab. Die dritte Stufe 3230 zeigt die Straßengeometrien für die Segmente 3205 und 3215, nachdem die Breiten der Straßen reduziert worden sind. Wie gezeigt, überlappen die Straßengeometrien nicht länger (zumindest in den Abschnitten, welche in der Figur gezeigt sind). Einige Ausführungsformen, nach Detektieren einer Überlappung zwischen irgendwelchen zwei Kapseln, führen den Prozess zum Reduzieren der Breite an diesem Ort aus und schrägen die Breitenreduktion heraus. Die Verarbeitung testet dann erneut dieses Paar von Kanten und fährt fort mit dem Identifizieren, ob irgendwelche überlappenden Straßenabschnitte verbleiben. Auf der anderen Seite identifizieren andere Ausführungsformen zuerst alle der überlappenden Abschnitte, reduzieren die Breiten an jedem solchen Abschnitt und berechnen die unterschiedlichen Abschrägungen, welche notwendig sind für jede der Breitenreduktionen.
Zusätzlich zu den Geometriekorrekturen, welche bei 1515 und 1520 ausgeführt werden zum Glätten von Kreuzungen und Eliminieren von Straßenüberlappungen, erzeugt (bei 1525) der Prozess 1500 auch Straßenmarkierungen zur Anzeige auf den Straßen. Diese Straßenmarkierungen können in einigen Ausführungsformen Spurmarkierungen, Mediane, Stopplinien und/oder Fußgängerübergänge bei Verkehrskreuzungen, usw. umfassen.
Zum Beispiel fügen einige Ausführungsformen automatisch Mediane zwischen zweispurigen Fahrbahnen hinzu. Wie beschrieben in dem vorherigen Unterabschnitt, identifizieren einige Ausführungsformen Straßensegmente (oder aggregierte Straßen) als korrespondierende Seiten einer Straße (z. B. gegenüberliegende Richtungen einer Autobahn oder Seiten einer Hauptstraße, welche durch einen Median getrennt sind, usw.) unter Verwendung der Straßensegmentdaten. In einigen Ausführungsformen zeigen diese Straßensegmentdaten an, dass eine Straße eine zweispurige Fahrbahn ist (manchmal bezeichnet als eine geteilte Autobahn, im Gegensatz zu einer einspurigen Fahrbahn, welche Verkehr in beiden Richtungen trägt), und andere Eigenschaften (sowohl geometrische als auch Attributdaten für die Straßensegmente) zeigen eine Wahrscheinlichkeit an, dass die zwei Straßen korrespondierende zweispurige Fahrbahnen sind.
Bei solchen zweispurigen Fahrbahnen sind oft die zwei Seiten durch verschiedene unterschiedliche Arten von Medianen getrennt. Zum Beispiel können unterschiedliche Bereiche aus Beton gebaute Mediane, Gras-Mediane, gezeichnete Mediane (z. B. unterschiedliche Kombinationen von gelben Linien), Teiler (Divider) usw. verwenden. Einige Ausführungsformen erzeugen Geometrien, welche die Lücken zwischen entsprechenden zweispurigen Fahrbahnstraßen füllen, und dann diese Geometrieeigenschaften zuweisen, so dass sie als Mediane gerendert werden. Einige Ausführungsformen verwenden die Orte der Knoten der Straßenseiten zum Bestimmen der Orte für die Medianknoten, so dass der Median exakt mit der Seite der Straße ausgerichtet ist.
Unterschiedliche Ausführungsformen rendern die Mediane unterschiedlich. Zum Beispiel verwenden einige Ausführungsformen einen einzelnen Mediantyp für alle zweispurigen Fahrbahnen, während andere Ausführungsformen unterschiedliche Typen haben. Sehr ähnlich wie Straßen, Geländeoberflächen, usw., können Stylesheets, welche an dem Client gespeichert sind, unterschiedliche Medianstile definieren, welche unterschiedlich gezeichnet werden. Die Mediangeometrien aus dem Kartendienst werden mit unterschiedlichen Stilen gekennzeichnet (z. B. Hauptstraßenmedian, Autobahnmedian, usw.), welche unterschiedlich gerenderten Grafiken entsprechen, durch die Client-Kartenanwendung.
33 und 34 zeigen zweispurige Fahrbahnen mit zwei unterschiedlichen Typen von Medianen. 33 zeigt zwei gerenderte Straßen 3305 und 3315, welche korrespondierende zweispurige Fahrbahnen sind. Zusätzlich zeigt die Anwendung ein Design von gelben Linien an, welche einen Median 3310 zwischen zwei Straßen darstellen (insbesondere ein Paar von doppelten gelben Linien, mit diagonalen Linien, welche diese verbinden. 34 zeigt einen Betonmedian 3405, welcher zwischen zwei zweispurigen Fahrbahnen 3305 und 3315 gezeichnet ist.
Zusätzlich zu Medianen erzeugen einige Ausführungsformen Geometrien für verschiedene Typen von Straßenmarkierungsfarbe (z. B. Spurtrenner, Stopplinien, usw.). In einigen Ausführungsformen umfasst dies die Spurmarkierungen, welche in den oben beschriebenen gerenderten Ergebnissen gezeigt sind. Um die Spurenmarkierungen für ein Straßensegment zu erzeugen, verwenden einige Ausführungsformen die Spurzählinformation, welche in der Straßensegmentdatenstruktur gespeichert ist (welche entweder aus den Breitendaten oder den Straßentypdaten hergeleitet werden kann). Zusätzlich können Spezialspuren, wie beispielsweise Fahrgemeinschaftsspuren in den Straßensegmentdaten angezeigt werden und können erzeugte Geometrie aufweisen.
Zusätzlich erkennen einige Ausführungsformen Kreuzungen, an welchen ein Fahrer wahrscheinlich an einem Stoppschild oder einer Ampel stoppen muss. Der Kartendienst einiger Ausführungsformen empfängt diese Daten von den Karten-Providern (z. B. als in den Kreuzungsdaten gespeicherte Information). Somit könnte eine spezielle Kreuzung eine Kreuzung von vier Straßen (four-way stop), eine Kreuzung von zwei Straßen (two-way stop) (Auswählen spezieller Straßensegmente als die Stoppschilder aufweisend), eine Verkehrsampel, usw. anzeigen.
In einigen Ausführungsformen leitet die Kartendienstverarbeitung diese Informationen basierend auf den Straßentypen bei der Kreuzung her. Zum Beispiel, wenn eine Verbindungsstraße eine Hauptstraße kreuzt, nehmen einige Ausführungsformen an, dass die Verbindungsstraße ein Stoppschild hat, wobei die Hauptstraße klar die Vorfahrt hat. Wenn sich zwei Hauptstraßen kreuzen, nimmt die Kartendienstverarbeitung an, dass die Verkehrskreuzung durch eine Ampelanlage gesteuert werden wird, und fügt Stopplinienmarkierungen für alle der Straßensegmente bei der Kreuzung hinzu.
35 zeigt ein Beispiel von Geometrien für solch eine Kreuzung 3500. Wenn alle Straßensegmentgeometrien bei der Verkehrskreuzung die gleiche Breite haben und bei 90°-Winkeln ausgerichtet sind, dann ist das Erzeugen der Stopplinien einfach (wie unten gezeigt). Jedoch sind die vier Straßensegmente 3505–3520 nicht so gut ausgerichtet. Stattdessen haben die Segmente unterschiedliche Breiten, und das Segment 3510 kreuzt die Kreuzung bei einem unterschiedlichen (nicht-rechten) Winkel. In solch einer Situation identifiziert die Kartendienstverarbeitung für jedes spezielle Straßensegment die Linie, welche senkrecht zu der Mittellinie des speziellen Straßensegments ist, welche die nächste an der Verkehrskreuzung ist und beide Seiten der Geometrie des speziellen Straßensegments berührt, ohne auch die anderen Straßensegmentgeometrien zu schneiden. Während für eine komplexere Kreuzung gezeigt, verwenden einige Ausführungsformen auch diesen Prozess zum Identifizieren der Stopplinienorte in den einfacheren Fällen.
Die gestrichelten Linien 3525 in 35 zeigen diese Linien für die Kreuzung 3500. Die Kartendienstverarbeitung erzeugt dann Geometrien für die Stopplinien, welche an diesen identifizierten Linien enden (die gestrichelten Linien 3525). Für einspurige Fahrbahnstraßensegmente (welche Verkehr in beiden Richtungen haben) erzeugt die Verarbeitung nur die Stopplinie zum Erstrecken zur Hälfte entlang des Straßensegments. Zusätzlich drücken einige Ausführungsformen die Stopplinien von der Kante der Verkehrskreuzung (die Kante, welche durch die gestrichelte Linie in dieser Figur dargestellt ist) um eine spezielle Distanz zurück (z. B. zwei Fuß, fünf Fuß, usw.).
36 zeigt das Ergebnis 3600 der Kreuzung 3500, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Wie gezeigt, ist eine dicke weiße Linie auf halber Route entlang jedem der Straßensegmente an dem Ort gezeichnet, welcher durch die gestrichelten Linien von 35 identifiziert ist. Die innere (zu der Verkehrskreuzung hin) Kante der Stoppliniengeometrie wird an der angezeigten Linie gezeichnet, wobei die Stopplinie sich ein Stück in das Straßensegment erstreckt (weg von der Verkehrskreuzung). Einige Ausführungsformen drücken die Stopplinie ebenso um eine feste Distanz weg von der Verkehrskreuzung. Zusätzlich werden Spurmarkierungen erzeugt, so dass sie an der Stopplinie stoppen, oder kurz davor.
Wieder zurückkehrend zu 15, spezifiziert (bei 1530) der Segmentgeometrie-Erzeugungsprozess 1500 als Nächstes die Beschriftungsinformation auf der Segmentgeometrie, und endet dann. In einigen Ausführungsformen wird diese Beschriftungsinformation auf den Polygonknoten gespeichert (oder Kanten, da die beiden im Wesentlichen austauschbar sind), welche die Netzerzeugungsmodule und/oder Rendering-Engine der Client-Kartenanwendung anweist, spezielle Charakteristika auf die gerenderte Ausgabe anzuwenden. Zum Beispiel spezifizieren einige Ausführungsformen unterschiedliche Typen von Straßenumhüllung (d. h. die Objekte, welche an den Seiten der Straße angeordnet sind) über die Segmentgeometrieknoten, die Kartenanwendung instruierend, Bordsteine, Bürgersteige, Brückenumhüllungen (und entsprechende Schatten), Tunnel, übereinander verlaufende Straßen usw. zu zeichnen. In einigen Ausführungsformen werden die Instruktionen zum Zeichnen dieser Umhüllungen auf der Client-Vorrichtung als Teil der Kartenanwendung gespeichert. Die Client-Kartenanwendung liest dann die Information aus, welche auf einem speziellen Knoten gespeichert ist, und erzeugt die geeignete Straßenumhüllung für die Kante, welche dem Knoten entspricht.
Das Folgende zeigt einige Beispiele unterschiedlicher Beschriftungen einiger Ausführungsformen für Straßenknoten, um Typen von zu zeichnenden Umhüllungen anzuzeigen. 37 zeigt ein Beispiel der Verwendung der Knotenbeschriftung zum Spezifizieren von Brückenumhüllung für eine Überführung, wo eine Straße über einer anderen Straße verläuft und die Straßen keine Kreuzung bilden. Wie in 37 gezeigt, schneiden sich die zwei Straßengeometrien 3705 und 3710 im flachen Raum. Jedoch spezifizieren die Straßensegmentdaten, dass das Straßensegment, für welches die Geometrie 3705 erzeugt ist, eine höhere Höhe als das Straßensegment hat, für welches die Geometrie 3710 erzeugt ist (entweder unter Verwendung von absoluten Höhendaten oder relativen Höhendaten). Zusätzlich, während als ein Segment für jede der zwei Straßen gezeigt, würden in einigen Ausführungsformen die Straßen definiert werden unter Verwendung von mehreren Segmenten (z. B. für die Straße 3705, ein erstes Segment von einer Höhe von 0 zu einer Höhe von 1, ein zweites Segment mit einer Höhe von 1, und ein drittes Segment aus einer Höhe von 1 zu einer Höhe von 0.
37 zeigt auch mehrere Knoten 3715–3735, welche verwendet werden zum Definieren der Seiten der Straßengeometrien 3705 und 3710. Jeder spezielle Knoten definiert eine gerichtete Kante von dem speziellen Knoten zu einem nächsten Knoten in einer Sequenz. Somit definiert zum Beispiel die Beschriftung für den Knoten 3735, wie die Client-Kartenanwendung die Kante von dem Knoten 3735 zu dem Knoten 3730 zeichnen wird, die Beschriftung für den Knoten 3730 definiert, wie die Client-Kartenanwendung die Kante von dem Knoten 3730 zu dem Knoten 3725 zeichnen wird, usw. Unterschiedliche Knoten entlang eines einzelnen Straßensegments können unterschiedliche Beschriftungen haben, so dass Abschnitte eines einzelnen Straßensegments mit unterschiedlichen Merkmalen gezeichnet werden (z. B. unterschiedliche Straßenumhüllungen).
In diesem Fall spezifiziert der Knoten 3715 (sowie die anderen Knoten für die Straßensegmentgeometrie 3710), dass er ein Knoten einer Verbindungsstraße ist, und die Default-Umhüllung zu verwenden. In einigen Ausführungsformen können unterschiedliche Typen von Straßen (z. B. Verbindung, Hauptstraße, Autobahn, usw.) nicht nur unterschiedlich gezeichnet sein (z. B. unterschiedliche Farbe/Textur für den Asphalt, unterschiedliche Breiten, usw.), sondern können auch unterschiedliche Umhüllungen haben (z. B. einen Bordstein für eine Verbindungsstraße). Während dies eine tatsächliche Spezifikation einer Default-Umhüllung zeigt, haben einige Ausführungsformen keine spezifische Beschriftung auf Knoten für die Default-Umhüllung (oder irgendeine andere Eigenschaft, für welche der Knoten Beschriftung bereitstellt).
Drei der gezeigten Knoten 3725–3735 zeigen insbesondere eine Brückenumhüllung für ihre Kanten der Geometrie 3705 an, während der Knoten 3720 eine Default-Hauptstraßenumhüllung anzeigt. Ebenso wie unterschiedliche Typen von Straßen unterschiedliche Default-Umhüllungen haben können, können unterschiedliche Typen von Straßen auch unterschiedliche Brückenumhüllungen haben. Das heißt, die Client-Kartenanwendungen können Instruktionen enthalten zum Zeichnen unterschiedlicher Überführungen für Hauptstraßen, Autobahnen usw. Der Knoten 3720, während an der Kante des Überführungsbereichs angeordnet, spezifiziert nicht die Brückenumhüllung, sondern spezifiziert vielmehr eine Default-Straßenumhüllung für ihre Kante. Dies ist der Fall, weil ihre Kante weg von der Überführung gerichtet ist, hin zu dem nächsten Knoten zu der Linken (nicht gezeigt) für die Seite der Straßengeometrie 3705.
38 zeigt das Ergebnis 3800 der Straßensegmente 3705 und 3710, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). In diesem Fall wird der Asphalt für die Verbindungsstraße gerendert unter Verwendung der gleichen Farbe/Textur wie der Asphalt für die Hauptstraße, obwohl einige Ausführungsformen die Straßen unterschiedlich rendern können. Zusätzlich werden heller gefärbte Bordsteine entlang der Kanten der zwei Straßen für Orte gezeichnet, für welche die Knoten eine Default-Straßenumhüllung spezifizieren. Jedoch für den Überführungsabschnitt zeichnet die Client-Anwendung eine Überführungsbrücke entsprechend einiger Ausführungen. Des Weiteren rendert die Anwendung einen Schatten auf den Asphalt der Verbindungsstraße, um realistischer die Überführung zu zeigen. Wenn ein Benutzer die Ansicht der Karte für diese Straßen rotieren würde, dann würde eine ähnliche Brückenumhüllung für die andere Seite der Überführung gerendert werden. Zusätzlich, während die Schatten nur für die Überführung der Verbindungsstraße erscheinen, rendern einige Ausführungsformen auch Schatten unterhalb der Hauptstraße, während sie nach oben von dem Boden zu der Überführung bewegt wird.
39 zeigt ein Beispiel der Verwendung von Knotenbeschriftung zum Spezifizieren einer Kante einer Straßensegmentgeometrie als eine innere Kante, was anzeigt, dass keine Umhüllung für die gerichtete Kante aus dem beschrifteten Knoten gezeichnet werden sollte. Einige Ausführungsformen verwenden solch eine Beschriftung, wo Straßen sich bei Kreuzungen treffen, um die Client-Kartenanwendung zu hindern, einen Bordstein in der Mitte der Straße zu zeichnen. Wie in 39 gezeigt, treffen sich zwei Straßensegmentgeometrien 3905 und 3910 an einer Kreuzung. In diesem Fall werden die Straßensegmente als aufeinanderfolgende Abschnitte einer aggregierten Straße verbunden; jedoch kann die gleiche Straßenumhüllungsbeschriftung auch verwendet werden bei Kreuzungen, welche Verkehrskreuzungen von mehr als einer Straße darstellen, in einigen Ausführungsformen.
39 zeigt auch einige Knoten 3915–3925, welche verwendet werden zum Definieren der Seiten der Straßengeometrie 3905. Die andere Straßengeometrie 3910 wird auch durch die Knoten definiert, einschließlich Knoten, welche an dem gleichen Punkt wie die Knoten 3915 und 3920 angeordnet sind. Wie in der vorherigen Figur, definiert jeder spezielle Knoten eine gerichtete Kante von dem speziellen Knoten zu einem nächsten Knoten in einer Sequenz. Somit definiert zum Beispiel die Beschriftung für den Knoten 3915, wie die Client-Kartenanwendung die Kante von dem Knoten 3915 zu dem Knoten 3920 zeichnen wird, die Beschriftung für den Knoten 3920 definiert, wie die Client-Kartenanwendung die Kante von dem Knoten 3920 zu dem Knoten 3925 zeichnen wird, usw.
In diesem Fall spezifizieren alle der Knoten 3915–3925 (sowie andere Knoten für die Straßensegmentgeometrie 3910), dass sie Knoten einer Verbindungsstraße sind. Zusätzlich spezifizieren die Knoten 3925 und 3920, Default-Umhüllung zu verwenden. Während dies eine tatsächliche Beschreibung einer Default-Umhüllung zeigt, haben einige Ausführungsformen keine spezifische Beschriftung auf Knoten für die Default-Umhüllung (oder irgendeine andere Eigenschaft, für welche der Knoten Beschriftung bereitstellt). Zusätzlich zeigt der Knoten 3915 insbesondere an, die innere Umhüllung zu verwenden (d. h. dass die gerichtete Kante, welche mit dem Knoten 3915 assoziiert ist, eine innere Kante der Straße ist. In einigen Ausführungsformen weist die innere Umhüllungsbeschriftung die Client-Kartenanwendung an, überhaupt keine Straßenumhüllung für diese Kanten zu zeichnen.
Der Knoten 3920, während an der Ecke der Straßengeometrie neben der inneren Kante angeordnet, spezifiziert die Default-Umhüllung statt der inneren Umhüllung. Dies ist der Fall, weil seine Kante hin zu dem Knoten 3925 gerichtet ist. Des Weiteren, in einigen Ausführungsformen würden die Knoten für die Straßengeometrie 3910 an den gleichen Punkten wie die Knoten 3915 und 3920 angeordnet werden, wobei der Knoten, welcher mit dem Knoten 3920 zusammen angeordnet ist, die innere Umhüllung spezifiziert (unter der Annahme, dass die Richtung der Kanten die gleiche für die Geometrie 3910 wie für 3905 war).
40 zeigt das Ergebnis 4000 der Straßensegmente 3905 und 3910, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). In diesem Fall geht der Asphalt für das erste Straßensegment weich in den Asphalt für das nächste Straßensegment über, ohne visuelle Anzeige eines Übergangs von einem Straßensegment zu dem nächsten. Die Anwendung zeichnet auch Bordsteine entlang der beiden Seiten der Straße, als die Default-Umhüllung. Zusätzlich zu Polygonen für heller gefärbte Bordsteine, zeichnen einige Ausführungsformen auch Details, wie beispielsweise die kleinen Schatten, welche durch die Bordsteine erzeugt werden, um ein dreidimensionaleres Gefühl für die Anzeige bereitzustellen, zumindest in einigen Modi der Client-Kartenanwendung. Während die inneren (d. h. den anderen Straßensegmenten zugewandten) Kanten der Straßen als solche spezifiziert sind, so dass Bordsteine und andere Straßenumhüllung nicht in der Mitte einer Straße gezeichnet werden, verwenden einige Ausführungsformen auch die innere Beschriftung für Straßen, welche keine Umhüllung auf ihren äußeren Kanten haben, wie beispielsweise Landstraßen, welche auf der gleichen Ebene wie das Gras neben der Straße liegen, ohne Bordstein oder andere Umhüllung.
41 zeigt ein Beispiel der Verwendung von Knotenbeschriftung zum Spezifizieren eines Tunnels für ein Straßensegment, was anzeigt, dass der Tunnel über dem Straßensegment gezeichnet werden sollte. Einige Ausführungsformen verwenden solch eine Beschriftung zum Anzeigen des Eingangs/Ausgangs für einen Tunnel, sowie die Mitte des Tunnels, so dass die Client-Kartenanwendung den Tunnel zeichnen wird, beim Rendern des Straßensegments. Wie in 41 gezeigt, treffen sich zwei Straßensegmentgeometrien 4105 und 4110 an einer Kreuzung. In diesem Fall werden die Straßensegmente als aufeinanderfolgende Abschnitte einer aggregierten Straße verbunden; jedoch kann die gleiche Straßenumhüllungsbeschriftung auch verwendet werden bei den Kreuzungen, welche Verkehrskreuzungen von mehr als einer Straße darstellen, in einigen Ausführungsformen.
41 zeigt auch einige Eckpunkte 4115–4130, welche verwendet werden zum Definieren der Seiten der Straßengeometrie 4110. Die andere Straßengeometrie 4105 wird auch durch Knoten definiert, einschließlich Knoten, welche an demselben Punkt wie die Knoten 4115 und 4130 angeordnet sind. Diese Knoten würden in einigen Ausführungsformen beschriftet werden zum Spezifizieren der Default-Umhüllung oder inneren Umhüllung, für die unterschiedlichen Knoten. Wie in den vorherigen Figuren, definiert jeder spezielle Knoten eine gerichtete Kante von dem speziellen Knoten zu einem nächsten Knoten in einer Sequenz. Somit definiert zum Beispiel die Beschriftung für den Knoten 4115, wie die Client-Kartenanwendung die Kante von dem Knoten 4115 zu dem Knoten 4120 zeichnen wird, die Beschriftung für den Knoten 4125 definiert, wie die Client-Kartenanwendung die Kante von dem Knoten 4125 zu dem Knoten 4130 zeichnen wird, usw.
In diesem Fall spezifizieren alle der Knoten 4115–4130 (sowie die Knoten für die Straßensegmentgeometrie 4105), dass sie Teil einer Hauptstraße sind. Zusätzlich spezifiziert der Knoten 4130, Tunneleingangsumhüllung zu verwenden, während die Knoten 4115–4125 spezifizieren, Tunnelumhüllung zu verwenden. Die Tunneleingangsumhüllungsbeschriftung spezifiziert in einigen Ausführungsformen, dass die spezielle Kante (die Kante der Segmentgeometrie 4110, welche die Fahrbahn kreuzt, der Eingang zu einem Tunnel ist und als solcher gezeichnet werden sollte. Die Tunnelumhüllungsbeschriftung einiger Ausführungsformen spezifiziert, dass die Kanten Seiten eines Tunnels sind, und somit ein Tunnel entlang der Straße gezeichnet werden sollte. an den Orten dieser Kanten.
42 zeigt das Ergebnis 4200 der Straßensegmente 4105 und 4110, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). In diesem Fall wird das erste Straßensegment mit Asphalt und Bordstein angezeigt, dies ist das Default-Rendering einiger Ausführungsformen. Für das zweite Straßensegment jedoch zeichnet die Anwendung den gekurvten Tunneleingang, und dann eine gerundete Umhüllung des Straßensegments. An dem anderen Ende des Straßensegments würde die Anwendung einen Tunnelausgang rendern. Zusätzlich rendert die Anwendung einen Schatten unterhalb des Eingangs, was dazu führt, dass der Asphalt an diesem Ort abgedunkelt ist.
43 zeigt ein Beispiel der Verwendung von Knotenbeschriftung zum Spezifizieren eines Bürgersteigs für eine Seite eines Straßensegments. Diese Figur zeigt eine einspurige Straßengeometrie 4305 für ein Straßensegment, welches in einer geraden Linie verläuft. Wie gezeigt, werden einige Knoten 4310–4325 verwendet zum Definieren der Seiten der Straßengeometrie 4305. Jeder spezielle Knoten definiert eine gerichtete Kante von dem speziellen Knoten zu einem nächsten Knoten in einer Sequenz. Somit definiert zum Beispiel die Beschriftung für den Knoten 4310, wie die Client-Kartenanwendung die Kante von dem Knoten 4310 zu dem Knoten 4315 zeichnen wird, die Beschriftung für den Knoten 4320 definiert, wie die Client-Kartenanwendung die Kante von dem Knoten 4320 zu dem Knoten 4325 zeichnen wird, usw. Unterschiedliche Knoten entlang eines einspurigen Straßensegments können unterschiedliche Beschriftungen haben, so dass die Abschnitte eines einspurigen Straßensegments mit unterschiedlichen Merkmalen gezeichnet werden (z. B. unterschiedliche Straßenumhüllung).
In diesem Fall spezifizieren die Knoten 4310 und 4315, dass sie Knoten einer Verbindungsstraße sind, und die Default-Umhüllung zu verwenden. Wie oben erklärt, können unterschiedliche Typen von Straßen unterschiedliche Default-Umhüllungen haben (z. B. Bordstein für eine Verbindungsstraße oder Hauptstraße, Leitplanke für bestimmte andere Typen von Straßen, usw.). Während dies eine tatsächliche Beschriftung einer Default-Umhüllung zeigt, können einige Ausführungsformen keine spezifische Beschriftung auf Knoten für die Default-Umhüllung haben (oder irgendwelche andere Eigenschaft, für welche der Knoten Beschriftung bereitstellt).
Die Knoten 4320 und 4325 zeigen spezifisch Bürgersteigstraßenumhüllung für ihre Kanten der Geometrie 4305 an. Ebenso wie unterschiedliche Typen von Straßen unterschiedliche Default-Umhüllungen haben können, können unterschiedliche Typen von Straßen unterschiedliche Bürgersteige haben. Das heißt, die Client-Kartenanwendung kann Instruktionen enthalten, zum Zeichnen unterschiedlicher Bürgersteige für Verbindungsstraßen, Hauptstraßen usw. (z. B. breitere Bürgersteige für Hauptstraßen).
44 zeigt das Ergebnis 4400 des Straßensegments 4305, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). In diesem Fall wird der Asphalt für die Hauptstraße in der gleichen Weise wie oben gezeigt gerendert, und die linke Seite (mit der Default-Straßenumhüllung) hat einfach einen gezeichneten Bordstein. Für die rechte Seite der Straße jedoch rendert die Anwendung einen Bürgersteig zusätzlich zu dem Bordstein. Zusätzlich zu Polygonen für die heller gefärbten Bordsteine zeichnen einige Ausführungsformen auch Details, wie beispielsweise kleine Schatten, welche durch die Bordsteine erzeugt werden, um ein dreidimensionaleres Gefühl für die Anzeige bereitzustellen, zumindest in einigen Modi der Client-Kartenanwendung.
Die obigen Beispiele zeigten unterschiedliche Typen von Beschriftungen, welche auf die Straßensegmentgeometrien angewendet werden können. In einigen Ausführungsformen können mehrere Typen von Straßenumhüllungen angewendet werden auf eine einzelne Kante durch Beschriften des Knotens der Kante mit einigen Typen von Beschriftung. In dem obigen Beispiel von 43, impliziert die Bürgersteigbeschriftung, dass die Client-Anwendung sowohl einen Bordstein als auch einen Bürgersteig rendern sollte.
45 zeigt ein Beispiel der Verwendung von mehreren Beschriftungen für einen einzelnen Knoten einiger Ausführungsformen. Insbesondere zeigt 45 ein Beispiel des Verwendens von Knotenbeschriftung zum Spezifizieren einer Überführung, welche einen Bürgersteig auf einer Seite der Brücke umfasst. Die Geometrien 4505 und 4510 sind ähnlich zu den Geometrien 3705 und 3710 der 37, wobei die letztere, eine Verbindungsstraße unterhalb der ersteren, einer Hauptstraße, verläuft. Tatsächlich ist der Unterschied von 37, dass die Knoten 4515–4525 Beschriftungen umfassen, welche sowohl eine Brückenumhüllung als auch eine Bürgersteigumhüllung spezifizieren.
46 zeigt das Ergebnis 4600 der Straßensegmente 4505 und 4510, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Wie in 45, wird der Asphalt für die Verbindungsstraße gerendert unter Verwendung der gleichen Farbe/Textur wie der Asphalt für die Hauptstraße, und die Anwendung zeichnet die heller gefärbten Bordsteine entlang der Kanten der zwei Straßen. Für den Überführungsabschnitt rendert die Client-Anwendung nicht nur die Überführung und ihre Schatten, sondern einen Bürgersteig oberhalb der Überführung auf der Seite der Straße, welche mit dem Bürgersteig beschriftet ist. In diesem Fall wird die andere Seite des Straßensegments 3705 nicht vermerkt, einen Bürgersteig zu spezifizieren, somit rendert die Anwendung keinen.
In den vorherigen Beispielen spezifizierte die Kartendienstverarbeitung einfach einen Umhüllungstyp für die Knoten. In einigen Ausführungsformen kann der Kartendienst auch verschiedene unterschiedliche Variablen für unterschiedliche Typen von Umhüllungen spezifizieren, was modifiziert, wie die Umhüllungen gerendert werden. Zum Beispiel kann die Höhe für Brückenumhüllungen in den Beschriftungsdaten spezifiziert werden (d. h. basierend auf der Straßensegmenthöheninformation). Zusätzlich können die Bürgersteigbreite, Bordsteinhöhe, Leitplankenhöhe, Tunneldicke, Bordsteinfarbe usw. in unterschiedlichen Ausführungsformen variiert werden.
47 zeigt ein Beispiel der Verwendung der Eckpunktbeschriftungsdaten zum Variieren einer Eigenschaft der Straßenumhüllung für eine Straßengeometrie 4705. Insbesondere umfasst die Straßengeometrie 4705 zwei Knoten 4710 und 4715 auf einer Seite und zwei Knoten 4720 und 4725 auf der anderen Seite. Die zwei Knoten 4710 und 4715 spezifizieren für die Client-Anwendung, eine Bürgersteigumhüllung zu rendern, und umfassen eine Breite von 1 Meter für diesen Bürgersteig. Auf der anderen Seite der Straße spezifizieren die zwei Knoten 4720 und 4725 auch für die Client-Anwendung, eine Bürgersteigumhüllung zu rendern, dieses Mal mit einer Breite von 1,5 Metern.
48 zeigt das Ergebnis 4800 des Straßensegments 4705, wie gerendert durch eine Client-Kartenanwendung einiger Ausführungsformen (z. B. auf der Anzeige einer tragbaren Vorrichtung). Das Rendern ist ähnlich zu dem, welches in 44 gezeigt ist. Jedoch hat die gerenderte Straße nun Bürgersteige auf beiden Seiten, und die Bürgersteige sind von einer unterschiedlichen Breite (wie spezifiziert in den Beschriftungsdaten).
Die obigen Beispiele zeigen die Verwendung von Knotenbeschriftungsdaten zum Spezifizieren von Straßenumhüllungsdaten für einige Ausführungsformen. Jedoch, während andere Kartenobjekte (z. B. Gebäude, Geländeoberflächenpolygone, usw.) in Kartenkacheln unter Verwendung von Knoten in einigen Ausführungsformen beschrieben sind, können diese anderen Objekte auch Knotenbeschriftungen in ihren Beschreibungen enthalten. Zum Beispiel können Gebäudedetails unter Verwendung solcher Beschriftung spezifiziert werden (z. B. unterschiedliche Farbflächen, unterschiedliche Typen von Formen, usw.) ebenso wie dies Aspekte der Geländeoberfläche können (z. B. wie unterschiedliche Grenzen der Geländeoberflächenpolygone zu zeichnen sind).
Nach Spezifizieren der Beschriftungsinformation endet der Segmentgeometrie-Erzeugungsprozess. Wie oben erwähnt, können in einigen Ausführungsformen die spezifische Reihenfolge der Operationen zum Erzeugen der Straßengeometrie unterschiedlich sein. Des Weiteren können einige Ausführungsformen Parallelverarbeitung verwenden zum Ausführen einiger oder aller der Straßengeometrieoperationen auf einige Straßensegmente (oder Sätze von Straßensegmenten) zur gleichen Zeit.
C. Server-seitige Erzeugung von Verkehrskreuzungsdaten
Nach dem Beschreiben der Server-Operationen, welche direkt zu den Straßengeometrien führen (z. B. Definieren von aggregierten Straßen und die Erzeugung von Straßengeometrie), wird nun die Erzeugung von Verkehrskreuzungsdaten unter Verwendung der Kreuzungsdaten, auf welche oben verwiesen wird, diskutiert werden. Beim Anfragen einer Route empfängt die Client-Kartenanwendung in einigen Ausführungsformen Daten über jede der Verkehrskreuzungen, welche die Route durchquert, welche die unterschiedlichen Zweige der Verkehrskreuzung anzeigen und feststellen, durch welche Zweige die Route in die Verkehrskreuzung eintritt und austritt. In einigen Ausführungsformen wird diese Verkehrskreuzungsinformation durch einen Kartendienst gespeichert, auf den die Kartenanwendung zugreift, um Kartendaten sowie Routen- und Navigationsinformationen abzurufen.
Wie oben erwähnt, empfängt der Kartendienst einiger Ausführungsformen Daten, welche jede Kreuzung der Straßensegmente spezifizieren. In einigen Ausführungsformen erzeugt der Kartendienst automatisch zusätzliche Daten für jede dieser Kreuzungen, welche in den Kartendaten gespeichert werden, und in einigen Ausführungen konvertiert er die Kreuzungsdaten in Verkehrskreuzungsdaten. Diese Kreuzungsinformation vereinfacht jede empfangene Kreuzung (oder einen Satz von verwandten Kreuzungen, welche in der Realität als eine einzelne Verkehrskreuzung angesehen werden) in einen Satz von Zweigen, welche die Kreuzung bei unterschiedlichen Winkeln verlassen.
Wenn ein Benutzer eine Route über eine Kartenanwendung, welche auf einer Vorrichtung betrieben wird, anfragt, sendet die Vorrichtung die Anfrage an den Kartendienst, welcher eine Route von einem Startort zu einem Endort erzeugt. Der Kartendienst erzeugt auch Punkt-zu-Punkt-Navigationsinstruktionen für die Route in einigen Ausführungsformen unter Verwendung der Verkehrskreuzungsdaten. Der Kartendienst identifiziert die Verkehrskreuzungen, an welchen Manöver gemacht werden, und modifiziert die Verkehrskreuzungsdaten, spezifisch für das Manöver zu sein, welches während der Route gemacht wird. Diese Daten werden dann an die Benutzervorrichtung gesendet, auf welcher die Client-Anwendung läuft. Die folgenden Unterabschnitte führen zunächst die Erzeugung der Navigationsdaten für eine Route ein, diskutieren dann die Vorberechnung von Kreuzungsdaten durch den Kartendienst (so dass die Daten zur Verwendung verfügbar sind beim Erzeugen von Navigationsdaten) und beschreiben dann schließlich spezifische Typen von Modifikationen, welche auf den Verkehrskreuzungsdaten für eine angefragte Route gemacht werden.
1. Navigationsdatenerzeugung
49 zeigt konzeptionell eine Operation, welche durch einen Kartendienst einiger Ausführungsformen ausgeführt wird, zum Erzeugen einer Route für eine anfragende Vorrichtung und Bereitstellen einer Route mit Navigationsinstruktionen an die anfragende Vorrichtung. 49 zeigt diese Operation über sechs Stufen 4910–4960, in welchen der Kartendienst eine Anfrage für die Route empfängt, die Route erzeugt, Verkehrskreuzungsdaten für die Route erzeugt und die Route an die Vorrichtung bereitstellt, welche die Information zum Anzeigen von Navigationsinstruktionen verwendet.
Wie gezeigt, zeigt jede Stufe von 49 eine Vorrichtung 4905 und einen Kartendienst 4900. Die Vorrichtung 4905 kann eine handgehaltene Vorrichtung in einigen Ausführungsformen sein (z. B. ein Smartphone, eine Tablet-Vorrichtung, usw.) oder kann eine dedizierte Navigationsvorrichtung sein (z. B. ein Navigationssystem, welches in ein Auto eingebaut ist, eine tragbare Navigationsvorrichtung usw.). Zusätzlich in einigen Ausführungsformen kann die Vorrichtung 4905 eine nicht tragbare Vorrichtung sein, wie beispielsweise ein Desktop-Computer oder andere nicht-tragbare Rechenvorrichtung.
Der Kartendienst 4900 ist ein Dienst, mit welchem sich die Vorrichtung 4905 verbindet (z. B. über eine kabelgebundene Verbindung, drahtlose Verbindung, wie beispielsweise ein Zellnetzwerk, Wi-Fi usw.), um Kartendaten, Routendaten, Punkt-zu-Punkt-Navigationsdaten sowie zusätzliche Informationen anzufragen und zu empfangen (z. B. Informationen über Plätze, welche auf der Karte angeordnet sind, usw.). Wie gezeigt, speichert der Kartendienst 4900 die Kartendaten 4915 und Verkehrskreuzungsdaten 4925 und umfasst einen Kartengenerator 4935 und einen Routengenerator 4945, neben anderen Modulen (nicht gezeigt).
Die Kartendaten 4915 stellen Daten bereit, aus welchen betrachtbare Kartenregionen und Routen erzeugt werden können. Diese Kartendaten umfassen in einigen Ausführungsformen Breiten- und Längendaten, Namensdaten sowie beschreibende Daten über Straßen und andere Pfade (z. B. Fußgängerwege, Fährrouten, Fahrradpfade usw.), natürliche Merkmale (z. B. Flüsse, Seen, Gebirgsketten, usw.), Punkte von Interesse (z. B. Gebäude, Geschäfte, Parks, usw.), und andere Kartenelemente. In einigen Ausführungsformen wird ein Pfad zum Beispiel definiert als eine Serie von Längen/Breiten-Knoten, einem Namen und beschreibenden Daten. Diese beschreibenden Daten können eine Art von Weg (d. h., ob der Pfad eine einspurige Fahrbahn ist oder ein Teil einer zweispurigen Fahrbahn, ob der Pfad eine Einbahnstraße ist); die Klasse von Straße, zu welcher der Pfad gehört (z. B. Fernstraße, lokale Straße, Privatstraße, Fahrradweg, usw.) sowie andere Informationen) umfassen. In einigen Ausführungsformen werden diese Kartendaten durch eine externe Quelle kompiliert (d. h. einen Karten-Provider) und dem Kartendienst bereitgestellt, während in anderen Ausführungsformen der Kartendienst seine eigenen Kartendaten bereitstellt. Die Kartendaten können auch ein Hybrid von von außen bereitgestellten und intern erzeugten Daten sein. Zusätzlich können die Kartendaten Geometriedaten für verschiedene Kartenkonstrukte umfassen, wie beispielsweise Straßen, Geländeoberflächen, usw.
Die Verkehrskreuzungsdaten 4925 stellen vor-tabellarisierte Daten für die Verkehrskreuzungen von Straßenpfaden in den Kartendaten bereit. In einigen Ausführungsformen, wie unten beschrieben, berechnet der Kartendienst automatisch Verkehrskreuzungsdaten für Straßenpfadverkehrskreuzungen unter Verwendung der Kartendaten. Diese Verkehrskreuzungsdaten 4925 können gespeichert werden durch Bezeichnen eines Verkehrskreuzungstyps (z. B. Punkt, Kreisverkehr) und eine Serie von Zweigen, welche bei unterschiedlichen Winkeln in und aus der Verkehrskreuzung kommen. Während die Kartendaten 4915 und die Verkehrskreuzungsdaten 4925 als separate Speicherungen gezeigt werden, können diese zusammen auf der gleichen physischen Speicherung oder auf separaten physischen Speicherungen gespeichert werden, und die Verkehrskreuzungsdaten 4925 können tatsächlich Teil der Kartendaten 4915 sein. Zusätzlich können eine oder beide der Karten- und Verkehrskreuzungsdaten über mehrere physische Speicherungen verteilt sein (z. B. eine Serie von Disks zum Speichern der Kartendaten).
Der Kartengenerator 4935 einiger Ausführungsformen erzeugt Karteninformationen (z. B. Kartenkacheln) zum Senden an die Anfragevorrichtung. Die Anfragevorrichtung fragt eine Karte für eine spezielle Region an (z. B. unter Verwendung von Längen-/Breiten-Informationen) und der Kartengenerator 4935 erzeugt (oder verwendet vorerzeugte) Kartenkacheln für die Region, sendet die Daten für diese Kacheln dann (z. B. als codierter Vektor und/oder Kartendaten) an die Vorrichtung. Der Routengenerator 4945 berechnet optimale Routen zwischen zwei oder mehreren Punkten in Antwort auf die Benutzeranfragen. In einigen Ausführungsformen berechnet der Routengenerator 4945 die Routen basierend auf den Kartendaten, unter Verwendung von Optimierungsalgorithmen. Die Route kann definiert werden als eine Serie von Verkehrskreuzungen, eine Serie von Straßenpfaden, oder auf andere Weisen. Zusätzlich, wenn ein Benutzer eine Route anfragt, stellt der Routengenerator 4945 Verkehrskreuzungsdaten zur Verwendung durch die Vorrichtung bei Punkt-zu-Punkt-Navigation bereit. In einigen Ausführungsformen ruft der Verkehrskreuzungsanalysierer 4955 Kreuzungsdaten 4925 ab und modifiziert diese Daten zur Navigation der Route, wie unten beschrieben.
Wie gezeigt, sendet bei Stufe 4910 die Vorrichtung 4905 eine Anfrage für eine Route an den Kartendienst 4900. In einigen Ausführungsformen gibt der Benutzer eine Startadresse (oder -ort) und eine Endadresse (oder -ort) ein, möglicherweise einschließlich zusätzlicher Mittelpunktorte (z. B. Starten bei A, Fahren zu B, dann fahren zu C von B). Die Vorrichtung überträgt dann Ortsinformationen an den Kartendienst. In einigen Ausführungsformen übersetzt die Vorrichtung die Orte in Breiten- und Längendaten, während in anderen Ausführungsformen diese Konversion durch den Kartendienst ausgeführt wird.
Bei Stufe 4920 greift der Routengenerator 4945 auf die Kartendaten 4915 zu, um eine oder mehrere Routen für die Serie von Orten zu erzeugen. In einigen Ausführungsformen verwendet der Routengenerator 4945 einen Optimierungsalgorithmus, um die beste (und zweitbeste, drittbeste usw.) Route zu finden, welche die Serie von Orten verbindet.
Bei Stufe 4930 identifiziert der Verkehrskreuzungsanalysierer 4955 Manöver entlang der Route, für welche Navigationsanweisungen erzeugt werden müssen, und ruft Verkehrskreuzungsinformation für diese Manöver ab. Einige Ausführungsformen erzeugen Punkt-zu-Punkt-Navigationsanweisungen, um diese der Vorrichtung zusammen mit der Route bereitzustellen. Um diese Anweisungen zu erzeugen, identifiziert der Kartendienst 4900 jedes Mal, wenn die Route Pfade wechselt, an welchem Punkt der Benutzer den Anweisungen folgend ein Manöver ausführen muss (z. B. rechts abbiegen, leicht nach links abbiegen, U-Turn, Einfädeln, usw.). In einigen Ausführungsformen entspricht jede dieser Pfadänderungen einer vor-tabellarisierten Verkehrskreuzung, welche in den Verkehrskreuzungsdaten 4925 gespeichert sind. Der Verkehrskreuzungsanalysierer 4955 ruft diese Verkehrskreuzungsdaten ab. In einigen Ausführungsformen wird jede Verkehrskreuzung als eine Serie von Zweigen gespeichert, welche aus der Verkehrskreuzung bei verschiedenen Winkeln kommen (z. B. ausgehend von Norden = 0°). In einigen Ausführungsformen zusätzlich zu den Verkehrskreuzungsdaten erzeugt der Routengenerator Routenanweisungen, welche im Allgemeinen die Manöver, welche auszuführen sind, beschreiben. Beispiele solcher Beschreibungen umfassen „nach links abbiegen”, „Autobahnausfahrt”, „U-Turn” usw. In anderen Ausführungsformen wird diese Beschreibung hergeleitet durch die Client Kartenanwendung, basierend auf den empfangenen Verkehrskreuzungsdaten.
Als Nächstes, bei Stufe 4940, erzeugt der Verkehrskreuzungsanalysierer 4955 Verkehrskreuzungsinformation, welche für die Route gestaltet ist. In einigen Ausführungsformen umfasst dies Modifizieren der Winkel, um die Fahrtrichtung in die Kreuzung zu 0° einzustellen (d. h. Einstellen des Zweigs, auf welchem die Route die Kreuzung betritt, auf 180°). Dies rotiert effektiv die Verkehrskreuzungsbeschreibung durch den Unterschied zwischen genau nördlich und der eingehenden Fahrtrichtung der Route. Zusätzlich kennzeichnet der Verkehrskreuzungsanalysierer 4955 einen der Zweige als den Ausgangszweig. Einige Ausführungsformen kennzeichnen auch einen Eingangszweig, während andere Ausführungsformen darauf angewiesen sind, dass die Vorrichtung den 180°-Zweig als den Eingangszweig identifiziert.
Stufe 4950 zeigt, dass der Kartendienst 4900 dann die Routendaten (d. h. Routendaten und Verkehrskreuzungsdaten für Navigation) an die Vorrichtung 4905 überträgt (z. B. über das gleiche Netzwerk, welches die Vorrichtung verwendet hat zum Übertragen der Routenanfrage). Wie bei Stufe 4960 gezeigt, verwendet die Vorrichtung 4905 dann die Verkehrskreuzungs- und Routendaten, welche durch den Kartendienst erzeugt wurden, um Navigationsinstruktionen für den Benutzer der Vorrichtung anzuzeigen. In einigen Ausführungsformen umfassen die Navigationsinstruktionen eine Anzeige der Verkehrskreuzung zusammen mit einem stilisierten Pfeil, welcher das Manöver (in diesem Fall ein Rechtsabbiegen) durch die Verkehrskreuzung zeigt.
Während der Kartendienst 4900 angezeigt wird als ein Kartengeneratormodul und ein Routengeneratormodul umfassend, wird der Fachmann erkennen, dass der Kartendienst zusätzliche Module umfassen kann oder unterschiedliche Aufteilungen von Modulen. Der Kartendienst kann bestehen aus einer einzelnen Rechenvorrichtung (z. B. einem Server), welcher alle Funktionalitäten und Daten speichert, oder die Funktionalität kann zwischen mehreren Servern verteilt sein (z. B. ein Prozess auf einem ersten Server und ein zweiter Prozess auf einem zweiten Server, zahlreiche Server, welche die gleiche Operation parallel für unterschiedliche Benutzer ausführen, oder andere Konfigurationen von Rechenvorrichtungen, welche die Funktionalität, welche hierin beschrieben ist, ausführen).
50 zeigt konzeptionell einen Prozess 5000, welcher durch den Kartendienst einiger Ausführungsformen ausgeführt wird, um Routen- und Verkehrskreuzungsdaten zu erzeugen und an einen Benutzer zu übertragen. Wie gezeigt, beginnt der Prozess 5000 durch Empfangen (bei 5005) einer Anfrage für eine Route zwischen zwei Orten auf einer Karte. In einigen Ausführungsformen, wenn der Benutzer eine Serie von mehr als zwei Orten anfragt, wird jedes Segment als eine separate Route behandelt (d. h. von Punkt A zu Punkt B ist eine erste Route, dann Punkt B zu Punkt C ist eine zweite Route).
Der Prozess erzeugt (bei 5010) dann zumindest eine Route zwischen den Orten unter Verwendung der Kartendaten. In einigen Ausführungsformen verwendet der Prozess einen Optimierungsalgorithmus zum Identifizieren der besten (oder zwei besten, drei besten, usw.) Routen zwischen zwei Orten. Diese Routen können beschrieben werden als eine Serie von Knoten entlang von Pfaden, eine Serie von Verkehrskreuzungen zwischen Pfaden, oder mit einer anderen Beschreibung.
Mit den Routen, welche für die Start- und Endorte erzeugt wurden, wählt (bei 5015) der Prozess 5000 eine der erzeugten Routen aus, um Punkt-zu-Punkt-Instruktionen für die Route zu erzeugen. Der Prozess identifiziert (bei 5020) dann Manöver, welche entlang der Route zu machen sind. In einigen Ausführungsformen identifiziert der Kartendienst jedes Mal, wenn die Route Pfade ändert, an welchem Punkt der Benutzer den Anweisungen folgend, ein Manöver ausführen werden muss (z. B. rechts abbiegen, leicht nach links abbiegen, U-Turn, einfädeln, usw.).
Als Nächstes ruft (bei 5025) der Prozess Verkehrskreuzungen für jedes der Manöver ab. In einigen Ausführungsformen entspricht jede dieser Pfadänderungen vor-tabellarisierten Verkehrskreuzungen, welche durch den Kartendienst gespeichert werden. Die Erzeugung dieser Verkehrskreuzungen ist unten im Detail beschrieben. In einigen Ausführungsformen wird jede Verkehrskreuzung als eine Serie von Zweigen gespeichert, welche aus der Kreuzung bei verschiedenen Winkeln kommen. (z. B. ausgehend von Norden = 0°). Zusätzlich speichern die Verkehrskreuzungsdaten den Typ von Verkehrskreuzung in einigen Ausführungsformen (z. B. Punkt, Kreisverkehr, Verkehrsplatz, usw.).
Der Prozess modifiziert (bei 5030) dann die Verkehrskreuzungsinformationen für jedes der Manöver. In einigen Ausführungsformen umfasst dies Modifizieren der Winkel, um die Fahrtrichtung in die Kreuzung auf 0° einzustellen (d. h. Einstellen des Zweigs, auf welchem die Route die Kreuzung betritt, auf 180°). Dies rotiert effektiv die Verkehrskreuzungsbeschreibung durch die Differenz zwischen genau nördlich und der eingehenden Fahrtrichtung der Route. Zusätzlich kennzeichnen einige Ausführungsformen einen der Zweige als den Ausgangszweig. Einige Ausführungsformen kennzeichnen auch einen Eingangszweig, während andere Ausführungsformen darauf angewiesen sind, dass die Vorrichtung den 180°-Zweig als den Eingangszweig identifiziert.
Der Prozess 5000 bestimmt (bei 5035) als Nächstes, ob zusätzliche Routen verbleiben, für welche Manöver/Verkehrskreuzungsinformationen zu erzeugen sind. Wenn zusätzliche Routen verbleiben, kehrt der Prozess zu 5015 zurück, um die nächste Route auszuwählen. Unterschiedliche Variationen von Routen von einem Startort und einem Endort können teilweise überlappen, in welchen Fällen einige Ausführungsformen den bereits erzeugten Satz von Verkehrskreuzungen für die überlappenden Teile wiederverwenden.
Sobald Verkehrskreuzungen für alle Routen erzeugt sind, überträgt (bei 5040) der Prozess die Routen- und Verkehrskreuzungsinformation an den Anfrager (z. B. eine anfragende Vorrichtung). Wie bereits erwähnt, verwendet die anfragende Vorrichtung diese Informationen in einigen Ausführungsformen, um Punkt-zu-Punkt-Navigation zu erzeugen, einschließlich stilisierter Kreuzungs-/Manöverpfeile.
2. Vorberechnung von Verkehrskreuzungsdaten
Wie oben erwähnt, berechnen einige Ausführungsformen die Verkehrskreuzungsdaten aus den gespeicherten Kartendaten vor (z. B. Straßensegment- und Kreuzungsdaten). Der Kartendienst speichert dann diese Verkehrskreuzungsdaten zur Verwendung beim Erzeugen von Punkt-zu-Punkt-Navigationsinstruktionen. Der folgende Abschnitt beschreibt einige Prozesse, welche verwendet werden zum Erzeugen dieser Verkehrskreuzungsdaten, in welchen der Kartendienst Verkäuferbereitgestellte Kreuzungen empfängt, identifiziert, ob irgendwelche Sätze der empfangenen Kreuzungen in eine einzelne Verkehrskreuzung konsolidiert werden sollten, identifiziert Paare von Straßensegmenten, welche innerhalb einer Verkehrskreuzung miteinander verbunden werden sollten, und erzeugt Winkel für die Verkehrskreuzung. Innerhalb dieses Abschnitts wird der Ausdruck Kreuzung im Allgemeinen verwendet, sich auf Verkäufer-bereitgestellte Information zu beziehen, bei welcher zwei Pfadsegmente sich kreuzen, während der Ausdruck Verkehrskreuzung sich auf Daten beziehen wird, welche aus den Kreuzungen erzeugt werden, welche darstellen, wo zwei oder mehrere Straßen sich in der realen Welt treffen. Somit könnten mehrere Kreuzungen in eine Verkehrskreuzung konsolidiert werden, und Kreuzungen zwischen zwei Straßensegmenten, welche tatsächlich nur eine Fortsetzung einer einzelnen Straße sind, könnten in einigen Ausführungsformen überhaupt nicht als Verkehrskreuzungen betrachtet werden.
Das Folgende stellt Pseudocode einiger Ausführungsformen dar zum Erzeugen von Verkehrskreuzungsdaten für Punkt-Verkehrskreuzungen:
Identifizieren aller internen Segmente;
Identifizieren aller internen Abbiegungskanäle und sie als interne Segmente markieren;
Für jedes interne Segment:
Erfassen aller zusammenhängenden internen Segmente;
Markieren der erfassten internen Segmente als verarbeitet;
Bilden einer Verkehrskreuzung aus dieser Sammlung von internen Segmenten;
Zusätzlich zu anderen Daten (z. B. Orte von Parks, Wasserwege, Geschäfte, usw.), speichern die Kartendaten Informationen über Pfade (d. h. Straßen, Gehwege, Fahrradwege, usw.). Jeder Pfad wird in einigen Ausführungsformen empfangen von einem Karten-Provider als eine Serie von Segmenten (z. B. Straßensegmente). Für ein gegebenes Segment umfassen in einigen Ausführungsformen die gespeicherten Daten Start- und End-Kreuzungen für das Segment, Geometriedaten, welche den Verlauf definieren, welcher durch den Pfad zwischen den Start- und End-Kreuzungen genommen wird, eine Pfadcharakterisierung (oder „Form des Weges”), eine Fahrtrichtung (welche in einigen Ausführungsformen eine Einbahn-Kennzeichnung umfassen kann), einen oder mehrere Namen für den Pfad (z. B. „1–405 S”, „San Diego Freeway”, usw.), eine Klasse, welche den Stellenwert des Pfades anzeigt, und eine Netzklasse (einen verbundenen Graph von Pfaden, zu welchem der Pfad gehört). In einigen Ausführungsformen weist die Geometrieinformatione eine Serie von Breiten-/Längen-Knoten auf, durch welche der Pfad verläuft. Das Form-des-Wegs-Attribut umfasst in einigen Ausführungsformen die folgenden Charakterisierungen: einspurige Fahrbahn, zweispurige Fahrbahn, Fernstraße, Auffahrt, Verbindungsstraße, Gehweg, Treppe. Einige Ausführungsformen können zusätzliche Charakterisierungen umfassen.
51 zeigt konzeptionell einen Prozess 5100 einiger Ausführungsformen zum Bestimmen von Pfadsegmenten zwischen den Sätzen von Kreuzungen, welche zusammen als eine einzelne Verkehrskreuzung behandelt werden sollten. Wie gezeigt, beginnt der Prozess 5100 durch Empfangen (bei 5105) einer Kreuzung zwischen zumindest zwei Pfadsegmenten (z. B. Straßensegmenten). In einigen Ausführungsformen empfängt der Kartendienst (z. B. als vorberechnete Daten von einem Kartenverkäufer) einen Satz von Straßensegmenten und einen Satz von Kreuzungen. Jedes Straßensegment folgt einem Pfad zwischen zwei solchen Kreuzungen, und jede Kreuzung referenziert zumindest zwei Straßensegmente, welche in die Kreuzung eintreten und/oder diese verlassen. Andererseits werden in einigen Ausführungsformen die Kreuzungen nicht von den Kartendaten-Verkäufern empfangen, und der Kartendienst durchläuft die Pfaddaten zum Identifizieren der Verkehrskreuzungen zwischen Pfaden und analysiert diese Verkehrskreuzungen, um die Kreuzungen vorzutabellarisieren.
Der Prozess bestimmt (bei 5110) dann, ob irgendwelche der Pfadsegmente bei der empfangenen Kreuzung zweispurige Fahrbahnen sind. Wie erwähnt, ist eine zweispurige Fahrbahn eine Pfadcharakterisierung, welche in einigen Formen von Kartendaten verwendet wird. Viele Straßen, welche geteilt sind (z. B. durch einen Median, eine doppelte gelbe Linie, usw.), werden als zwei separate Pfadsegmente, einer für jede Richtung, empfangen (und gezeichnet). Jedes der Pfadsegmente wird dann mit einer Fahrtrichtung markiert und als eine Hälfte einer zweispurigen Fahrbahn markiert. Weil ein Benutzer typischerweise bei einer Verkehrskreuzung von zwei Straßen ausgehen wird, welche beide durch Mediane als eine einzelne Verkehrskreuzung geteilt sind (statt vier separate Verkehrskreuzungen), versucht der Kreuzungserzeugungsprozess, diese vier empfangenen Kreuzungen als eine einzelne Verkehrskreuzung zu vereinigen, um einem Benutzer diesen für Navigationszwecke darzustellen.
Wenn keines der Pfadsegmente als zweispurige Fahrbahn markiert wird, berechnet (bei 5115) der Prozess die Verkehrskreuzungszweige unter Verwendung von nur den Pfadsegmenten, welche in der empfangenen Kreuzung spezifiziert sind (d. h. die Verkehrskreuzung wird nur die eine empfangene Kreuzung umfassen). In einigen Ausführungsformen umfasst die Berechnung der Kreuzungszweige Berechnen des Winkels, bei welchem jedes der Segmente, welches für die Kreuzung spezifiziert ist, den Kreuzungsort verlässt. Der Prozess endet dann. 52 zeigt ein Beispiel solch einer Kreuzung 5200, auch zeigend, dass es keine Notwendigkeit gibt, dass die Pfadsegmente sich bei rechten Winkeln treffen, oder dass die Pfade in einer geraden Linie durch die Kreuzung fortlaufen.
Wenn zumindest ein Pfadsegment, welches durch die empfangene Kreuzung spezifiziert wird, eine zweispurige Fahrbahn ist, bestimmt (bei 5120) der Prozess, ob es eine Querverkehr-Abbiegung einer zweispurigen Fahrbahn an der Kreuzung gibt. Eine Querverkehr-Abbiegung ist eine Abbiegung der zweispurigen Fahrbahn in eine Richtung, welche durch die übereinstimmende Hälfte der zweispurigen Fahrbahn kreuzt (d. h. die andere Richtung der Straße), unter der Annahme, dass diese existiert. In den USA ist eine Linksabbiegung eine Querverkehr-Abbiegung. Während die Beispiele, welche in diesem Dokument gezeigt sind, Rechtsverkehr umfassen (d. h. Fahren auf der rechten Seite der Straße), wird ein Fachmann erkennen, dass die Beispiele gleichwertig anwendbar sind auf Linksverkehr-Regionen (z. B. England). 53 zeigt eine Verkehrskreuzung 5300, welche zwei zweispurige Fahrbahnpfade 5305 und 5306 und eine Einbahnstraße 5310 umfasst. An der Kreuzung 5315 gibt es keine Querverkehr-Abbiegung einer zweispurigen Fahrbahn, weil die einzigen Optionen eine Rechtsabbiegung des zweispurigen Fahrbahnpfades 5305 oder eine Linksabbiegung der Einbahnstraße 5310 sind. Wenn keine solchen Abbiegungen existieren, speichert (bei 5125) der Prozess 5100 die empfangene Kreuzung, während er erkennt, dass sie noch Teil einer größeren Verkehrskreuzung sein kann, um zu bestimmen, ob die empfangene Kreuzung mit anderen empfangenen Kreuzungen (z. B. die Kreuzung 5320 zwischen der Einbahnstraße 5310 und dem zweispurigen Fahrbahnpfad 5306) in einer größeren Verkehrskreuzung einzubeziehen sind. Zum Beispiel in der Verkehrskreuzung 5300 wird der Prozess die empfangene Kreuzung 5320 mit der empfangenen Kreuzung 5315 in eine einzelne größere Verkehrskreuzung verbinden wollen. Der Prozess endet dann.
Wenn eine Querverkehr-Abbiegung einer zweispurigen Fahrbahn an der Kreuzung existiert (z. B. bei der Kreuzung 5320), bewegt sich (bei 5130) der Prozess in der Richtung der Querverkehr-Abbiegung, bis der nächste zweispurige Fahrbahnpfad erreicht ist. In einigen Ausführungsformen, weil die Pfadsegmente bei den Kreuzungen starten und stoppen, wird der nächste zweispurige Fahrbahnpfad bei einer unterschiedlichen empfangenen Kreuzung erreicht werden (obwohl nicht notwendigerweise die nächste Kreuzung, wenn eine Straße, wie beispielsweise eine Linksabbiegerspur, als ein separates Pfadsegment empfangen wird). Zum Beispiel von der Kreuzung 5320 würde der Prozess den Pfad 5310 weg von der Kreuzung 5320 überqueren, bis die nächste zweispurige Fahrbahn erreicht wird, bei der Kreuzung 5315.
Der Prozess 5100 bestimmt (bei 5135) dann, ob der zweispurige Fahrbahnpfad, welcher bei 5130 erreicht wurde, eine Fahrtrichtung in der entgegengesetzten Richtung des ursprünglichen zweispurigen Fahrbahnpfads hat. Dies ist im Wesentlichen ein schneller Bestimmungsfaktor darüber, ob die zweite zweispurige Fahrbahn der übereinstimmende Pfad für die erste zweispurige Fahrbahn sein könnte (d. h. ob es wahrscheinlich ist, dass sie zwei Seiten der gleichen Straße sind). In den meisten Fällen wird diese nächste zweispurige Fahrbahn der übereinstimmende Pfad sein, aufgrund der Natur, wie Straßen typischerweise gebaut werden).
In dem Fall, wenn die zweite zweispurige Fahrbahn nicht in der entgegengesetzten Richtung des ursprünglichen Pfades ist, geht der Prozess zu 5125 über, um die neu erreichte Kreuzung für spätere Verwendung bei der Bestimmung, ob sie mit irgendwelchen anderen empfangenen Kreuzungen einzubeziehen ist, zu speichern. Zum Beispiel, wenn die Linksabbiegung des Pfades 5306 eine andere zweispurige Fahrbahn mit einer Fahrtrichtung nach unten erreicht, dann könnte angenommen werden, dass der Pfad 5306 keine Übereinstimmung in den Daten hat (zumindest was die Kreuzungen betrifft), jedoch könnte der neu identifizierte Pfad selbst eine Übereinstimmung haben.
Andererseits, wenn zwei zweispurige Fahrbahnen entgegengesetzte Fahrtrichtungen haben, identifiziert und speichert (bei 5140) der Prozess das Segment, welches durch die Querverkehr-Abbiegung durchquert wird. In dem Beispiel von 53 würde das Segment von der Kreuzung 5320 zu der Kreuzung 5315 gespeichert werden. Dieses Segment wird verwendet als Teil der zusätzlichen Kreuzungskonsolidierungsprozesse in einigen Ausführungsformen. Der Prozess endet dann.
Der obige Prozess 5100, wenn angewendet auf all die Kreuzungen innerhalb einer Kartenregion, wird einen Satz von Segmenten zwischen zweispurigen Fahrbahnen erzeugen. Einige Ausführungsformen verwenden diese Segmente, um empfangene Kreuzungen miteinander zu verbinden und zusätzliche empfangene Kreuzungen zu identifizieren zum Einbeziehen in eine einzelne Verkehrskreuzungsdefinition. Das Folgende repräsentiert Pseudocode einiger Ausführungsformen zum Identifizieren all solcher „interner” Segmente für eine komplexe Verkehrskreuzung:
Für jedes Segment, welches eine zweispurige Fahrbahn ist;
Für jede Verbindung mit Querverkehr-Abbiegung, wo ein Pfad zu der anderen Seite der Verkehrskreuzung zusammengefügt werden kann;
Markieren aller Segmente auf dem Pfad zu der anderen Seite als interne Segmente;
Dieser Pseudocode umfasst eine Bestimmung, ob ein Pfad zu der anderen Seite einer Verkehrskreuzung von einem Segment zusammengefügt werden kann. Das Folgende umfasst Pseudocode einiger Ausführungsformen für solch eine Bestimmung:
Hinzufügen des ersten Segments zum Pfad;
Holen von Verbindungen von dem letzten Segment auf dem Pfad;
Iterieren durch jede Verbindung entweder zum Finden einer Verbindung zu der anderen Seite oder Finden einer Verbindung, welche die beste Fortsetzung ist;
Wenn die Verbindung auf der anderen Seite ist, Feststellen des Erfolgs und Enden;
Wenn keine Verbindung auf der anderen Seite ist und keine Verbindung die beste Fortsetzung ist, Feststellen des Fehlschlagens und Enden;
Ansonsten:
Hinzufügen des Segments zu dem Ende des Pfads;
Wenn der Pfad zu weit entfernt ist, Feststellen des Fehlschlagens und Enden;
Wenn zu viele Kreuzungen, Feststellen des Fehlschlagens und Enden;
Ansonsten Zurückkehren zum Holen von Verbindungen für hinzugefügtes Segment und Iterieren durch die Verbindungen;
54 zeigt konzeptionell einen Prozess 5400 zum Miteinander-Verbinden von mehreren Kreuzungen in eine einzelne Verkehrskreuzung und Identifizieren der Zweige der Verkehrskreuzung. Der Prozess 5400 beginnt durch Empfangen (bei 5405) eines Satzes von sich kreuzenden Segmenten zwischen zweispurigen Fahrbahnen. Diese Segmente können identifiziert werden unter Verwendung eines Prozesses, wie beispielsweise jener, welcher in 51 gezeigt ist, in einigen Ausführungsformen. Der Kartendienst gruppiert dann die Sätze solcher Segmente zusammen, welche sich kreuzen (d. h. bei empfangenen Kreuzungen). 55 zeigt eine gewöhnlich existierende Verkehrskreuzung 5500, zwischen einer zweispurigen Fahrbahn mit Pfaden 5505 und 5506 und einer zweispurigen Fahrbahn mit Pfaden 5510 und 5511. Der Satz von sich kreuzenden Segmenten wird in dieser Figur als dickere Linien gezeigt.
Der Prozess identifiziert bei (bei 5410) dann alle Kreuzungen und Pfadsegmente, welche direkt mit dem Satz von sich kreuzenden Segmenten bei den Kreuzungen verbinden. Das heißt, der Satz von sich kreuzenden Pfaden kreuzt bei Kreuzungen, aber diese Kreuzungen können zusätzliche Pfadsegmente enthalten. Zum Beispiel in dem Beispiel der Verkehrskreuzung 5500 kreuzen sich die acht zweispurigen Fahrbahnpfadsegmente, welche die Verkehrskreuzung verlassen, alle mit den inneren (dickeren) Pfadsegmenten bei den vier Kreuzungen. Somit werden die vier Kreuzungen und acht externen Pfadsegmente alle in die Verkehrskreuzung einbezogen.
56 andererseits zeigt eine Verkehrskreuzung 5600, in welcher Linksabbiegungskanäle als separate Pfadsegmente definiert sind. In diesem Fall, weil die Linksabbiegungskanäle die internen Segmente bei den Kreuzungen kreuzen, welche in den ursprünglichen Kartendaten empfangen werden, werden diese Kanäle durch den Prozess 5400 identifiziert. Die Linksabbiegungskanäle können in den Kartendaten als Auffahrten oder einspurige Fahrbahnen in den meisten Fällen charakterisiert werden.
Das Folgende stellt Pseudocode einiger Ausführungsformen dar zum Identifizieren aller Abbiegungskanäle, die als „intern” für eine Verkehrskreuzung zu behandeln sind:
Für jedes Segment, welches eine zweispurige Fahrbahn ist;
Für jede Verbindung mit Querverkehr-Abbiegung, wo ein Pfad zu internen Segmenten zusammengefügt werden kann;
Markieren aller Segmente auf dem Pfad zu den internen Segmenten selbst als interne Segmente;
Dieser Pseudocode umfasst eine Bestimmung, ob ein Pfad zu den internen Segmenten von einem Segment (z. B. einem Abbiegungskanal) zusammengefügt werden kann. Das Folgende umfasst Pseudocode für solch eine Bestimmung:
Hinzufügen des ersten Segments zum Pfad;
Holen von Verbindungen von dem letzten Segment auf dem Pfad (d. h. Segmente, die mit dem letzten Segment bei der Kreuzung verbunden sind);
Iterieren durch jede Verbindung zum entweder Finden eines internen Segments oder Finden einer Verbindung, welche die beste Fortsetzung ist;
Wenn Verbindung ein internes Segment ist, Feststellen des Erfolgs und Enden;
Wenn keine Verbindung ein internes Segment ist und keine Verbindung die beste Fortsetzung ist, Feststellen des Fehlschlagens und Enden;
Ansonsten:
Hinzufügen des Segments zu dem Ende des Pfads;
Wenn der Pfad zu weit entfernt ist, Feststellen des Fehlschlagens und Enden;
Wenn zu viele Kreuzungen, Feststellen des Fehlschlagens und Enden;
Ansonsten Zurückkehren zum Holen von Verbindungen für hinzugefügtes Segment und Iterieren durch die Verbindungen;
Als Nächstes definiert (bei 5415) der Prozess 5400 eine neue Verkehrskreuzung als alle die identifizierten Kreuzungen und Pfadsegmente umfassend, einschließlich jener, welche direkt den ursprünglichen Satz von Pfadsegmenten kreuzen. In einigen Ausführungsformen in dem Fall, welcher in 56 gezeigt, ist, würden die Kreuzungen, wo die Linksabbiegungskanäle ihre ursprünglichen zweispurigen Fahrbahnsegmente verlassen, umfasst werden, ebenso wie die Linksabbiegungskanäle, welche die ursprünglichen Segmente kreuzen. In dieser Situation identifizieren einige Ausführungsformen die andere Kreuzung (d. h. die Start-Kreuzung) für die Auffahrt oder einspuriges Fahrbahnpfadsegment, welches dort sein wird, wo sich das Pfadsegment mit einem der zweispurigen Fahrbahnpfadsegmente kreuzt, vor Eintreten in die Verkehrskreuzung. Wenn das einspurige Fahrbahnpfadsegment intern für ein (vermutetes) Paar von zweispurigen Fahrbahnpfaden für eine Schwellendistanz (z. B. 1 km) bleibt, nehmen einige Ausführungsformen an, dass das Pfadsegment ein Teil der Straße ist, welche durch die zweispurigen Fahrbahnpfade definiert ist, und eliminiert die Kreuzung aus der Betrachtung.
Beim Verarbeiten einer Auffahrt oder einer anderen Verbindungsstraße außerhalb der zweispurigen Fahrbahnen (z. B. der Auffahrt 5705, welche in der Verkehrskreuzung 5700 der 57 gezeigt ist), behandeln einige Ausführungsformen die Auffahrt nicht als einen Pfad in die zweispurige Fahrbahn-Verkehrskreuzung. Stattdessen identifizieren einige Ausführungsformen die Pfadcharakterisierung als eine Auffahrt und versuchen, eine geschlossene Schleife zu bilden, welche die Start- und End-Kreuzungen der Auffahrt umfasst. Wenn diese geschlossene Schleife eine gemeinsame Kreuzung mit der neu definierten Verkehrskreuzung teilt (was typischerweise der Fall sein wird), kann die Auffahrt mit der Verkehrskreuzung assoziiert werden, aber nicht als ein interner Pfad dieser Verkehrskreuzung behandelt werden. Andererseits, wenn die neu definierte zweispurige Fahrbahn-Verkehrskreuzung aufgrund der Präsenz von zum Beispiel Linksabbiegungskanälen aufgebaut worden ist, so dass die Auffahrtkreuzungen durch die Verkehrskreuzung umgeben sind, welche nun die kreuzenden einspurigen Fahrbahnen umfasst (wie für die Auffahrt 5805 in der Verkehrskreuzung 5800 der 58), behandeln einige Ausführungsformen die Auffahrt als intern zu der neu definierten Verkehrskreuzung. In der Beschreibung der Verkehrskreuzung werden diese Linksabbiegungskanäle, Auffahrten, usw. typischerweise eliminiert werden, da ein Benutzer im Allgemeinen nicht komplexe Instruktionen will, aber stattdessen eine Instruktion von „Mache eine Rechtsabbiegung auf San Vicente Blvd” oder etwas Ähnliches wollen wird.
Mit dem Satz von Segmenten und Kreuzungen, welche die Verkehrskreuzung, welche definiert ist, bilden, muss der Prozess zweispurige Fahrbahnen in einzelne Kreuzungszweige zusammenführen. Der Prozess 5400 definiert (bei 5420) als Nächstes den Satz aller Pfade, welche in die Verkehrskreuzung eintreten, und definiert (bei 5425) den Satz aller Pfade, die die Verkehrskreuzung verlassen. Für eine zweispurige Fahrbahn, welche ein Einbahnpfad (die Hälfte einer Zweiwegestraße) ist, wird der Pfad typischerweise eine Ausgangsseite und eine Eingangsseite haben. Zum Zwecke des Zusammenführens behandeln einige Ausführungsformen jedes Segment (das Segment, welches die Verkehrskreuzung verlässt, und das Segment, welches die Verkehrskreuzung betritt) als separate Pfade. Einspurige Fahrbahnen, welche nicht intern für zweispurige Fahrbahnen sind (z. B. der zusätzliche Zweiwegepfad 5905 in der Verkehrskreuzung 5900 der 59), werden typischerweise behandelt als separate Zweige und sind nicht Teil der Zusammenführungsanalyse in einigen Ausführungsformen.
Als Nächstes bestimmt (bei 5430) der Prozess, ob der Satz von Eingangspfaden irgendwelche nicht-gepaarten zweispurigen Fahrbahnpfade umfasst. Wenn keine solchen Pfade in dem Satz verbleiben (oder tatsächlich keine existiert haben), speichert (bei 5435) der Prozess irgendwelche nicht-gepaarten zweispurigen Fahrbahnen, welche in dem Satz von Ausgangspfaden übrig sind, als separate Zweige der Kreuzung. Im Allgemeinen wird dies in dem Fall von falsch bezeichneten Kartendaten (die Straße ist tatsächlich eine Einbahnstraße) oder Zusammenführungskriterien, welche zu streng sind (ein Paar von Eingangs- und Ausgangspfaden ohne Zusammenführung lassen) passieren.
Wenn ein nicht-gepaarter Eingangspfad existiert, wählt (bei 5440) der Prozess einen der Eingangspfade aus. Der Prozess bestimmt (bei 5445) dann, ob eine potenzielle Übereinstimmung in dem Ausgangssatz existiert. Eine potenzielle Übereinstimmung ist in einigen Ausführungsformen eine zweispurige Fahrbahn, welche gefunden wird durch Durchlaufen des vorherig identifizierten Segments zu der linken (zu der rechten, in dem Fall von Linksverkehr-Regionen), oder Durchlaufen der Verkehrskreuzung im Uhrzeigersinn.
Wenn keine potenzielle Übereinstimmung existiert (z. B. die nächste identifizierte zweispurige Fahrbahn in dem Übergang ist auch ein Eingangspfad, oder der Ausgangssatz ist leer), speichert (bei 5450) der Prozess den Eingangspfad als einen separaten Zweig der Verkehrskreuzung und kehrt dann zurück zu 5430, um den nächsten nicht-gepaarten Eingangspfad zu finden. Andererseits, wenn eine potenzielle Übereinstimmung existiert, bestimmen (bei 5455) einige Ausführungsformen, ob das potentielle Paar einen Satz von zweispurigen Fahrbahn-Übereinstimmungskriterien erfüllt. Dies sind Kriterien in einigen Ausführungsformen zum Bestimmen, ob ein Paar von zweispurigen Fahrbahnen tatsächlich die zwei Seiten der gleichen Straße sind. Einige Ausführungsformen bestimmen, ob die zwei Pfade (1) innerhalb einer Schwellendistanz sind (z. B. 25 m, 50 m, usw.), wo die Pfade die Verkehrskreuzung betreten/verlassen, und (2) ob die Winkel, bei welchen die Pfade ihre Kreuzungen innerhalb der Verkehrskreuzung treffen, innerhalb eines Schwellenbereichs zueinander liegen (z. B. 5°, 10°, usw.). Um den Winkel zu berechnen, verwenden einige Ausführungsformen den Knoten, welcher der nächste zu der Kante der Verkehrskreuzung ist (oder dem Ort der Kreuzung, an welchem das Pfadsegment die anderen Segmente innerhalb der Verkehrskreuzung kreuzt) und einen Knoten, welcher eine spezielle vordefinierte Distanz entfernt angeordnet ist (z. B. 50 m). Der Prozess berechnet dann den Winkel weg von Norden für die Linie zwischen den zwei Knoten.
In einigen Ausführungsformen betrachtet der Kartendienst zusätzlich die Namen der Pfade zum Bestimmen, ob diese übereinstimmen. Wenn die Namen übereinstimmen, können solche Ausführungsformen die Geometriekriterien für ein übereinstimmendes Paar lockern (d. h. Erlauben einer größeren Distanz zwischen den Pfaden oder einer größeren Differenz der Winkel zwischen den Pfaden). Übereinstimmende Namen könnten zum Beispiel sein „CA-1 South” und „CA-1 North”, oder wenn beide Pfade umfassen „Wilshire Blvd.” als einen ihrer Namen. Einige Ausführungsformen betrachten auch die Straßenklassendaten zur Sicherheit beim Abgleichen von zweispurigen Fahrbahnen.
Wenn die zwei Pfade übereinstimmen, führt (bei 5460) der Prozess die Pfade in einen einzelnen Zweig der neu definierten Verkehrskreuzung zusammen. Wie oben gezeigt, werden Verkehrskreuzungen als ein Satz von Zweigen bei unterschiedlichen Winkeln gespeichert. Für einen zusammengeführten Pfad speichern einige Ausführungsformen den Winkel als den Durchschnitt der Winkel der zwei Pfade, welche den Zweig ausmachen. 60 zeigt die Reduktion von einer Acht-Pfad-Verkehrskreuzung 6000 in vier Zweige, in welchen der Winkel des rechten Zweigs 6010 bei der Hälfte des Offsets von der Horizontalen ist, als der rechte Ausgangspfad 6005, weil der rechte Eingangspfad auf der Horizontalen ist. Wie konzeptionell gezeigt, werden Richtungen (Eingang/Ausgang) nicht für Verkehrskreuzungszweige in einigen Ausführungsformen gespeichert. Der Kartendienst erzeugt die Routen unter Verwendung von Kartendaten, welche die Verkehrskreuzungen sowie Fahrtrichtungen für die Straßen umfassen, so dass eine Route nicht den falschen Weg auf einem Zweig der Verkehrskreuzung durchlaufen wird.
Auf der anderen Seite, wenn die Pfade nicht übereinstimmen, speichert (bei 5465) der Prozess jeden der Pfade als separate Zweige der Verkehrskreuzung. 61 zeigt die Reduktion einer unterschiedlichen Acht-Pfad-Verkehrskreuzung 6100 in fünf Zweige. In diesem Fall verschmelzen die zweispurigen Fahrbahnpfade 6105 und 6106 auf der rechten Seite nicht und werden daher behandelt als separate Zweige 6110 und 6111 der reduzierten Verkehrskreuzung. In diesem Beispiel ist der Winkel, bei welchem jeder dieser Zweige die Verkehrskreuzung verlässt, der Winkel, welcher für den Zweig gespeichert wird (ohne Durchschnittsbildung). Der Prozess 5400 kehrt dann zu 5430 zurück, um zu bestimmen, ob irgendwelche Eingangspfade verbleiben. Wie genannt, sobald der Eingangspfadsatz leer ist, fährt der Prozess zu 5435 fort und endet danach.
Das Folgende stellt Pseudocode einiger Ausführungsformen zum Erzeugen der Daten für eine Verkehrskreuzung dar, sobald die internen Segmente für die Verkehrskreuzung identifiziert worden sind (z. B. Operationen, welche durch einige oder alle des Prozesses 5400 ausgeführt werden):
Erfassen aller externen Segmente, welche interne Segmente für eine Verkehrskreuzung berühren;
Identifizieren externer Segmente, welche durch interne Segmente in der Verkehrskreuzung umgeben sind, und diese als intern markieren;
Zusammengruppieren von Paaren eingehender und ausgehender Segmente, welche die gleiche Straße repräsentieren;
Berechnen eines Ausgangswinkels für jedes Paar und für jede nicht-gepaarte Straße;
Konstruieren eines Template-Verkehrskreuzungsmusters mit einem Zweig für jeden Winkel;
Wenn das Muster für vorher erzeugte Verkehrskreuzungen existiert, verwenden des existierenden Musters zum Sparen von Speicherplatz (Verweisen der Verkehrskreuzung zu dem existierenden Muster);
Ansonsten, wenn das Muster nicht existiert, Erzeugen und Speichern eines neuen Eintrags für das Muster;
Wie angezeigt, speichern einige Ausführungsformen jede Verkehrskreuzung als eine Datenstruktur. Diese Datenstruktur zeigt die Zweige der Verkehrskreuzung und die Winkel an, bei welchen die Zweige in die Kreuzung eintreten und/oder diese verlassen. 62 zeigt konzeptionell ein Beispiel solch einer Datenstruktur 6200 einiger Ausführungsformen für eine Punkttyp-Verkehrskreuzung. Wie gezeigt, umfasst die Verkehrskreuzung eine Verkehrskreuzungs-ID (welche in einigen Ausführungsformen ein eindeutiger Bezeichner ist), eine Kartendatenassoziation, und einen Satz von Zweigen mit Winkeln und Typen. Die Kartendatenassoziation assoziiert in einigen Ausführungsformen die Verkehrskreuzungsdatenstruktur mit einem tatsächlichen Ort innerhalb der Karte. In einigen Ausführungsformen ist dies einfach ein Breiten-/Längenpunkt, aber kann auch bestehen aus anderen Daten in anderen Ausführungsformen (z. B. eine Liste der Pfadsegmente oder aggregierte Pfade, welche sich an der Verkehrskreuzung treffen). Jeder Zweig umfasst einen Typ und einen Winkel. Der Typ ist in einigen Ausführungsformen ein Verkehrskreuzungstyp. Einige Ausführungsformen definieren zwei Verkehrskreuzungstypen: Punkt und Kreisverkehr. Jedoch können andere Ausführungsformen zusätzliche Verkehrskreuzungstypen umfassen, wie beispielsweise Verkehrsplätze (traffic square). Einige Ausführungsformen speichern den Verkehrskreuzungstyp als eine Eigenschaft der Verkehrskreuzung, statt separat für jeden Zweig, aber andere Ausführungsformen erkennen die Möglichkeit, dass eine Verkehrskreuzung teilweise ein Kreisverkehr sein kann, aber teilweise eine Punkt-Verkehrskreuzung sein kann. Die Datenstruktur 6200 umfasst vier Zweige, an den kardinalen Richtungen von 0° (Nord), 90° (Ost), 180° (Süd) und –90° (West). In einigen Ausführungsformen umfasst die Verkehrskreuzungsdatenstruktur auch Referenzen auf irgendwelche Kreuzungen (d. h. Daten, welche von dem Kartendaten-Provider empfangen werden) und, welche innerhalb der definierten Verkehrskreuzung enthalten sind. Für eine typische Verkehrskreuzung von zwei zweispurigen Fahrbahnen werden vier Kreuzungen durch solch eine Datenstruktur referenziert.
63 zeigt eine Datenstruktur 6300 einiger Ausführungsformen für eine Kreisverkehr-Verkehrskreuzung. Einige Ausführungsformen stellen spezialisierte Verarbeitung für eine Kreisverkehr-Verkehrskreuzung bereit. Das Folgende stellt Pseudocode einiger Ausführungsformen dar zum Erzeugen von Verkehrskreuzungsdaten für Kreisverkehr-Verkehrskreuzungen:
Identifizieren aller Kreisverkehrsegmente;
Für jedes Kreisverkehrsegment:
Erfassen aller zusammenhängender Kreisverkehrsegmente;
Markieren der erfassten Kreisverkehrsegmente als verarbeitet;
Bilden einer Kreisverkehr-Verkehrskreuzung aus dieser Sammlung der Kreisverkehrsegmente;
In einigen Fällen identifizieren die Kartendaten einen Kreisverkehr (z. B. als eine Form des Wegs oder über einen anderen Indikator). Dies erlaubt dem Kartendienst-Verkehrskreuzungsrechner, seine spezialisierte automatisierte Kreisverkehrverarbeitung zu beginnen. Insbesondere beim Ausführen der Kreisverkehrverarbeitung versucht der Kartendienst, Paare von Ausweitungs(flare)-Verbindungsstraßen (d. h. die Abschnitte einer Straße, welche sich in und aus einem Kreisverkehr ausweiten) zu identifizieren. In einigen Ausführungsformen durchläuft der Verkehrskreuzungsrechner den Kreisverkehr (z. B. gegen den Uhrzeigersinn für Rechtsverkehr) auf der Suche nach einem Ausgangspfad, welchem gefolgt wird, innerhalb einer speziellen Distanz (z. B. Winkeldistanz), durch einen Eingangspfad. Der Prozess bestimmt dann, ob diese Pfade zu kombinieren sind, auf der Suche nach Faktoren ähnlich zu jenen zum Verschmelzen von zweispurigen Fahrbahnen bei Punkt-Verkehrskreuzungen. Zum Beispiel könnten die verwendeten Faktoren umfassen, ob die Namen ähnlich sind, ob die Distanz zwischen den Ausgangs-/Eingangspfaden klein genug ist, und potenziell anderen Faktoren. Als ein Ergebnis dieser Verarbeitung, wenn eine zufällige Straße den Kreisverkehr in der Mitte von dem kreuzt, was ansonsten als eine Eingangs-/Ausgangskombination erscheint, behandeln einige Ausführungsformen dies als drei separate Zweige.
Um die Winkel der Zweige zu berechnen, bestimmen einige Ausführungsformen, wo der Zweig den Kreisverkehr kreuzt, statt den Winkel der Annäherung der Straße. Für Eingangs-/Ausgangskombinationen übernimmt der Prozess den Durchschnitt der zwei Pfade. 64 zeigt konzeptionell die Reduktion einer Kreisverkehr-Verkehrskreuzung 6400 zu Verkehrskreuzungsdaten. Der obere Pfad unabhängig von dem Annähern bei ungefähr einem 30°-Winkel weg von Nord, wird designiert als ein 0°-Zweig – der Benutzer ist primär an der Distanz interessiert um den Verkehrskreis für die Verkehrskreuzungen, statt an dem Winkel, in welchem sie eintreten und austreten. Die anderen drei Zweige sind auch designierte kardinale Richtungen, weil ihre Ausweitungen den Durchschnitt zu diesen Richtungen ermitteln. Die Datenstruktur 6300 zeigt die Datenstruktur für die Kreisverkehr-Kreuzung 6400. Andere Ausführungsformen jedoch verwenden den Winkel, in welchem der Pfad den Kreisverkehr betritt oder verlässt, statt die Distanz um den Kreisverkehr, an welchem die Pfade ihn kreuzen.
Das Folgende stellt Pseudocode einiger Ausführungsformen dar zum Erzeugen der Daten für eine Kreisverkehr-Verkehrskreuzung, sobald die Kreisverkehrsegmente für die Verkehrskreuzung identifiziert worden sind:
Für einen Satz von Kreisverkehrsegmenten, welche eine einfache Schleife bilden:
Erfassen aller Nicht-Kreisverkehrsegmente, welche die Schleife berühren, geordnet durch die Richtung der Fahrt um die Schleife; Zusammengruppieren der Paare von aufeinanderfolgenden Kreisverkehrausgangs-/eingangssegmenten, welche die gleiche Straße repräsentieren;
Zuweisen eines Winkels zu jedem Paar und jedem nicht-gepaarten Segment;
Subtrahieren des kleinsten Winkels von allen Winkeln (somit der kleinste Winkel = 0);
Konstruieren eines Template-Verkehrskreuzungsmusters mit einem Zweig für jeden Winkel;
Wenn das Muster für eine vorher erzeugte Verkehrskreuzung existiert, Verwenden des existierenden Musters, um Speicherplatz zu sparen (Referenzieren der Verkehrskreuzung zu dem existierenden Muster);
Ansonsten, wenn das Muster nicht existiert, Erzeugen und Speichern des neuen Eintrags für das Muster;
Wie in den obigen Beispielen des Pseudocodes angezeigt, führen einige Ausführungsformen zusätzliche Komprimierung beim Speichern der Verkehrskreuzungen aus. Die reale Welt enthält Millionen (oder Hunderte von Millionen) von individuellen Verkehrskreuzungen, aber viele dieser Verkehrskreuzungen haben die gleiche Konfiguration (insbesondere, wenn sehr kleine Winkelvariationen toleriert werden). Somit, statt Speichern der separaten Daten für jede der Hunderte von Millionen von Verkehrskreuzungen, verwenden einige Ausführungsformen Kompression beim Speichern der Verkehrskreuzungen. Während jede Verkehrskreuzung verarbeitet wird, speichern einige Ausführungsformen ein Template-Muster für diese Verkehrskreuzung. Wenn zusätzliche Verkehrskreuzungen mit dem Template-Muster identifiziert werden, speichern solche Ausführungsformen eine Referenz zu diesem Muster (während sie weiter eine separate Datenstruktur erzeugen, weil die Ortsinformation unterschiedlich für zwei Verkehrskreuzungen ist, welche dem gleichen Muster folgen).
3. Änderung von Kreuzungsdaten für Navigation
Der obige Abschnitt beschrieb die Erzeugung der komplexen Verkehrskreuzungsdaten, typischerweise gemacht als ein Offline-Prozess vor der Routenerzeugung. Jedoch zum Zeitpunkt der Routenerzeugung modifizieren einige Ausführungsformen die Verkehrskreuzungsdaten zur Übertragung an den Benutzer. Der Kartendienst, welcher die Routendaten bereitstellt, modifiziert die Winkel, um sie relativ zu der Richtung des Eintrags zu machen und markiert einen der Zweige als einen Ausgangszweig.
65 zeigt konzeptionell einen Prozess 6500 einiger Ausführungsformen zum Modifizieren von Verkehrskreuzungsdaten, um Navigationsinformationen für eine Route bereitzustellen. Wie gezeigt, beginnt der Prozess durch Empfangen (bei 6505) einer Route, für welche Verkehrskreuzungsinformation erzeugt werden soll. Wie oben erwähnt, erzeugen einige Ausführungsformen eine oder mehrere Routen für jeden Satz von startenden und endenden Orten, welche durch eine Benutzervorrichtung angefragt wurden. Jede dieser Routen besteht aus einer Serie von Manövern bei verschiedenen Pfadverkehrskreuzungen (d. h. bei Straßenverkehrskreuzungen).
Wie gezeigt mit der identifizierten Route, wählt (bei 6510) der Prozess 6500 die nächste Verkehrskreuzung entlang der Route aus. Einige Ausführungsformen beginnen mit der ersten Verkehrskreuzung (d. h. dem ersten Manöver, welches ein Benutzer der Route folgend machen wird), startend von dem Startpunkt der Route. Viele Routen umfassen lange Strecken entlang einer speziellen Straße, geradeaus fahrend durch zahlreiche Verkehrskreuzungen (möglicherweise umfassend Kreuzungen von zwei Straßensegmenten, welche Teil der gleichen Straße sind und bei welchen keine anderen Straßen kreuzen). In einigen Ausführungsformen umfassen die Navigationsinstruktionen nicht Informationen über die Verkehrskreuzungen, bei welchen kein Abbiegemanöver gemacht wird. Dementsprechend ist die nächste Verkehrskreuzung tatsächlich die nächste Verkehrskreuzung entlang der Route, bei welcher ein Manöver gemacht werden wird.
Der Prozess ruft (bei 6515) dann vorberechnete Verkehrskreuzungsdaten als einen Satz von Zweigen mit assoziierten Winkeln ab. Wie oben beschrieben, speichern einige Ausführungsformen eine Datenstruktur für jede Verkehrskreuzung, welche die Zweige der Verkehrskreuzung zusammen mit Winkeln für jeden Zweig auflistet. 62 und 63 zeigen Beispiele solcher Datenstrukturen, für sowohl eine Punkt Verkehrskreuzung als auch eine Kreisverkehr-Verkehrskreuzung.
Nach Abrufen der Datenstruktur für die ausgewählte Verkehrskreuzung, rotiert der Kartendienst die Verkehrskreuzungsdefinition, um die Definition zu der Richtung zu normalisieren, bei welcher die Route in die Verkehrskreuzung eintritt. Dementsprechend identifiziert (bei 6520) der Prozess 6500 den Eintrittszweig der Verkehrskreuzung und stellt den Eintrittszweig auf einen vorbestimmten Winkel ein. Einige Ausführungsformen stellen die Richtung der Bewegung in die Verkehrskreuzung als 0° ein und stellen daher den Eintrittszweig der Verkehrskreuzung auf 180° ein.
Der Prozess rotiert dann die anderen Zweige der Verkehrskreuzung. Wie gezeigt, wählt (bei 6525) der Prozess einen nächsten Zweig der Verkehrskreuzung aus. In einigen Ausführungsformen werden die Zweige und Winkel in einem Array, einer Liste oder einer ähnlichen Datenstruktur gespeichert, und der Prozess durchläuft diese Datenstruktur. Der Prozess stellt (bei 6530) den Winkel des ausgewählten Zweigs basierend auf einer Winkeldistanz von dem Eingangszweig ein. Zum Beispiel, wenn der Eingangszweig bei 0° gespeichert wurde (d. h. nach Norden zeigend), dann wird ein Zweig, welcher bei 95° gespeichert wurde, um 180° auf –85° geändert. Zusätzlich bestimmt (bei 6535) der Prozess, ob der ausgewählte Zweig der Ausgangszweig der Kreuzung ist (d. h. der Zweig, bei welchem die Route die Verkehrskreuzung verlässt). Um für die Punkt-zu-Punkt-Navigationsinstruktionen auf der Client-Karten-/Navigationsanwendung die Manöver geeignet anzuzeigen, muss die Vorrichtung wissen, entlang welchem Zweig die Verkehrskreuzung die Route verlässt. Somit, wenn der ausgewählte Zweig der Ausgangszweig ist, markiert (bei 6540) der Prozess 6500 den ausgewählten Zweig als solchen. Der Prozess (bei 6545) bestimmt dann, ob irgendwelche zusätzlichen Zweige der Verkehrskreuzung für die Route zu konvertieren verbleiben. Wenn zusätzliche Zweige verbleiben, kehrt der Prozess zu 6525 zurück, um den nächsten Zweig der Kreuzung auszuwählen. Wenn alle Zweige für die derzeitige Verkehrskreuzung verarbeitet worden sind, bestimmt (bei 6560) der Prozess 6500, ob zusätzliche Verkehrskreuzungen entlang der Route verbleiben, welche modifiziert werden müssen. Wenn zusätzliche Verkehrskreuzungen verbleiben, kehrt der Prozess zu 6510 zurück, um die nächste Verkehrskreuzung auszuwählen. Wenn die letzte Verkehrskreuzung modifiziert wird, endet der Prozess.
66 zeigt eine konzeptionelle Zeichnung einer Route, welche durch eine Verkehrskreuzung 6600 genommen wird, eine Datenstruktur 6605 für die Verkehrskreuzung, und die Modifikation der Datenstruktur, um eine neue Datenstruktur 6610 für Punkt-zu-Punkt-Navigationsinstruktionen zu erzeugen. Wie gezeigt, tritt die Route von der rechten Seite (dem 90°-Zweig) in die Verkehrskreuzung ein und verlässt diese an der unteren Seite (dem –162°-Zweig). In der modifizierten Datenstruktur ist der Eingangszweig zu 180° rotiert worden, was eine 90°-Rotation der anderen Zweige verursacht. Der Zweig bei 18° rotiert zu 108°, der Zweig bei –65° rotiert zu 25°, und der Zweig bei –162° rotiert zu –72°. Zusätzlich zu den Rotationswinkeln, hat die Datenstruktur 6610 den letzten Zweig markiert als den Ausgang für die Navigation.
Einige Ausführungsformen umfassen ein binäres Ausgangsfeld, wobei der Ausgangszweig mit einer „1” und alle anderen Zweige mit einer „0” markiert sind.
D. Erzeugung von Geländeoberflächengeometrie
Zusätzlich zum Erzeugen von Straßengeometrie für Kartenkacheln, erzeugen einige Ausführungsformen auch Geländeoberflächengeometrie. Sehr ähnlich zu den Straßensegmentdaten, welche von verschiedenen Quellen empfangen werden, können Daten, welche Geländeoberfläche beschreiben, empfangen werden (z. B. als eine Serie von Knoten, welche die Grenze eines speziellen Geländeoberflächenkörpers anzeigen). Die Geländeoberfläche kann Gewässer (z. B. Flüsse, Ozeane, Seen, Schwimmbäder, usw.), Verwaltungskörper (z. B. Grenzen von Staaten, Ländern, Städten, Parks, usw.), Bereichsdesignationen (z. B. ländlich/urban/suburban, Wüste/Gebirge/Wald, usw.) oder andere Daten, welche das Gelände zwischen den Straßen beschreiben, umfassen. Anfänglich verwenden einige Ausführungsformen diese Koordinaten, um die Geometrien für die Geländeoberflächenelemente aufzubauen.
Nach dem Aufbauen der Geometrien für die Geländeoberfläche, verwenden einige Ausführungsformen verschiedene Operationen zum Auflösen der Grenzen zwischen den Geometrien. Zum Beispiel beim Kombinieren von Daten aus unterschiedlichen Quellen können die Ortsdaten, welche Objektgrenzen anzeigen, nicht perfekt ausgerichtet sein und daher kann es entweder Lücken zwischen den Objektgeometrien oder Überlappungen der Geometrien geben. Einige Ausführungsformen verwenden unterschiedliche Operationen zum Auflösen von Grenzen zwischen unterschiedlichen Geometrien, abhängig von den Typen von Objekten. Zusätzlich verwendet die Geländeoberflächengeometrieverarbeitung die Straßesegmentdaten zum Auffüllen der Geländeoberflächengeometrie und Sicherstellen, dass Lücken nicht zwischen der Geländeoberfläche und den Straßen zurückbleiben. Einige Ausführungsformen bauen die Geländeoberflächengeometrien außerhalb ihrer markierten Grenzen hin zu den Straßen auf, die Geometrien bei Straßenmittellinienorten stoppend. Während dies eine Überlappung zwischen der Geländeoberflächengeometrie und der Straßengeometrie erzeugt, umfassen die Client-Kartenanwendungen in einigen Ausführungen Instruktionen zum Rendern der Straßengeometrie oberhalb der Geländeoberflächengeometrie. Die folgenden Unterabschnitte beschreiben einige dieser unterschiedlichen Verfahren zum Auflösen von Diskrepanzen oder Nicht-Übereinstimmungen zwischen verschiedenen Geländeoberflächengrenzen.
1. Zusammenfassen von Geländeoberflächen zu Straßen
67 zeigt konzeptionell einen Prozess 6700, welchen einige Ausführungsformen der Erfindung ausführen zum Zusammenfassen von Geländeoberflächenpolygonen zu Straßenpolygonen. In einigen Ausführungsformen wird der Prozess des Zusammenfassens der Geländeoberflächenpolygone ausgeführt, um Daten-Nichtübereinstimmungen, welche auftreten aus Empfangen von Geländeoberflächenpolygondaten und Straßenpolygondaten aus unterschiedlichen Datenquellen, aufzulösen. Der Prozess des Zusammenfassens von Geländeoberflächen wird mit Verweis auf 68 beschrieben werden, welche ein Beispiel des Zusammenfassens von Geländeoberflächen zu Straßenpolygonen in drei Stufen 6801–6803 zeigt.
Wie in 67 gezeigt, empfängt (bei 6705) der Prozess 6700 ein Straßenpolygon. Der Prozess 6700 empfängt (bei 6710) dann zumindest zwei Geländeoberflächenpolygone. In einigen Ausführungsformen werden die Straßenpolygone und die Geländeoberflächenpolygone von zwei unterschiedlichen Datenquellen empfangen, während sie in anderen Ausführungsformen von der gleichen Datenquelle empfangen werden. Die Stufe 6801 in 68 zeigt ein Beispiel von zwei solchen Geländeoberflächenpolygonen 6810 und 6820. In diesem Beispiel werden unterschiedliche Geländeoberflächentypen durch jedes Geländeoberflächenpolygon gezeigt. Zum Beispiel kann die Geländeoberfläche 6820 ein See und die Geländeoberfläche 6810 ein Park sein. Jedoch könnten in anderen Ausführungsformen die Geländeoberflächenpolygone 6810 und 6820 von dem gleichen Typ sein. Des Weiteren kann der Prozess mehr als zwei Geländeoberflächenpolygone empfangen, welche der Einfachheit wegen nicht gezeigt werden. Die erste Stufe 6801 zeigt auch einen leeren Raum zwischen den zwei Geländeoberflächenpolygonen. Da die Geländeoberflächen alle Bereiche außer den Straßen darstellen, wird angenommen, dass der leere Raum den Ort darstellt, wo eine Straße normalerweise verläuft. Jedoch aufgrund der Irregularität des Raums zwischen den zwei Geländeoberflächen 6810 und 6820, wenn eine Straße zwischen den zwei Geländeoberflächenpolygonen gezeichnet wird, würde es einen irregulären leeren Raum zwischen der Straße und den Geländeoberflächen geben, welcher nicht visuell ansprechend wäre, wenn die Karte auf einer Benutzervorrichtung gerendert wird. Der Prozess 6700 fasst daher die Geländeoberflächen zu der Straße zusammen, wie unten beschrieben.
Der Prozess 6700 zeichnet (bei 6715) das Straßenpolygon in dem leeren Raum zwischen den zwei Geländeoberflächenpolygonen, wie gezeigt durch das Straßenpolygon 6830 in Stufe 6810 der 68. In einigen Ausführungsformen stellt dieses Straßenpolygon die Straße dar, welche zwischen den zwei Geländeoberflächenpolygonen angeordnet ist. In einigen Ausführungsformen kann eine Straße nicht sauber in die Mitte des leeren Raums passen. Teile der Straße oder die gesamte Straße können mit einem oder beiden Polygonen überlappen. Der Einfachheit halber wird der Prozess 6700 beschrieben unter der Annahme, dass die Straße in dem Raum zwischen den Geländeoberflächenpolygonen angeordnet ist.
Als Nächstes baut (bei 6720) der Prozess 6700 die Geländeoberflächenpolygone bis zu dem Straßenpolygon auf. Zum Beispiel wie gezeigt in Stufe 6802 in 68, erweitert der Prozess die linke Seite des Geländeoberflächenpolygons 6710, bis das Polygon die rechte Seite des Straßenpolygons 6830 erreicht. Der Prozess erweitert auch die rechte Seite des Polygons 6820, bis es die linke Seite des Straßenpolygons 6830 erreicht. In einigen Ausführungsformen, wenn das Straßenpolygon nicht komplett in dem Mittelraum zwischen den Geländeoberflächenpolygonen liegt, baut der Prozess alternativ die Geländeoberflächenpolygone bis in die Mitte der Lücke auf. In anderen Ausführungsformen bauen die Geländeoberflächenpolygone über die Straßengeometrie hinaus auf, und bedecken Teile oder die gesamte Straßengeometrie.
Um diese Erweiterung des Schritts 6720 auszuführen, rastert der Prozess in einigen Ausführungsformen die Polygone vor der Erweiterung. Durch Rastern der Polygone erzeugt der Prozess Pixeldaten für die Pixel innerhalb jedes Geländeoberflächenpolygons. Der Verschmelzungsprozess verwendet diese Pixeldaten zum Auffüllen benachbarter Pixel mit ähnlichen Daten. Zum Beispiel, wenn ein leeres Pixel benachbart zu einem Pixel eines Geländeoberflächenpolygons ist, welches von einem Typ ist, welcher einen gepflasterten Bereich darstellt, wird das gesamte Pixel auch zu einem Typ, welcher den gesamten gepflasterten Bereich darstellt. Der Prozess baut die leeren Pixel auf diese Weise auf, bis sie das Straßenpolygon 6830 erreichen, welches als eine Grenze agiert, um den Polygonerweiterungsprozess zu beenden.
Obwohl 68 ein Beispiel zeigt, wo nur ein Straßenpolygon gezeichnet wird, umfassen andere Ausführungsformen mehrere Straßenpolygone, welche mehr als eine Straße zwischen den zwei Geländeoberflächenpolygonen darstellen. In solchen Fällen kann der leere Raum zwischen zwei Straßen verbleiben, weil die Geländeoberflächenpolygone nicht in den Raum zwischen den zwei Straßen erweitert werden (d. h. die Straßen agieren als Grenzen für die Polygonerweiterungen).
Wenn der leere Raum zwischen den zwei Straßen verbleibt, markiert (bei 6725) der Prozess 6700 den leeren Raum zwischen den Straßen als Füller. In einigen Ausführungsformen werden die markierten Füller gemäß unterschiedlichen Instruktionen auf einer Client-Anwendung interpretiert und gerendert. Zum Beispiel in einigen Ausführungsformen rendert die Benutzervorrichtung diese leeren Räume als Straßenteiler. In anderen Ausführungsformen rendert die Benutzervorrichtung diese leeren Räume als Grünflächen, Asphalt usw.
Nach dem Markieren irgendeines leeren Raums, welcher zwischen zwei Straßen existieren kann, konvertieren einige Ausführungsformen die neu aufgebauten Pixel in Vektoren zum Reduzieren der Anzahl von Knoten von den Geländeoberflächenpolygonen und der Vereinigung der aufgebauten Pixel mit den ursprünglich empfangenen Polygonen von Schritt 6710 des Prozesses 6700. Der Prozess zeichnet (bei 6730) dann die Straße über dem Straßenpolygon. Die gezeichnete Straße kann auch die Polygone neben dem Straßenpolygon in einigen Ausführungsformen überlappen. Die dritte Stufe 6803 der 68 zeigt die Operation 6730 des Prozesses 6700, wo der Prozess eine Straße 6840 über dem Straßenpolygon zwischen den zwei Polygonen 6820 und 6810 zeichnet. In diesem Beispiel bedeckt die Straße 6840 das Straßenpolygon und überlappt Teile der Polygone 6810 und 6820.
Als Nächstes führt (bei 6735) der Prozess optional Polygonoptimierung auf bestimmten Geländeoberflächenpolygontypen aus, zum Reduzieren der Anzahl von Knoten in dem Geländeoberflächenpolygon. In einigen Ausführungsformen umfasst dieser Prozess Entfernen von bestimmten Geländeoberflächenpolygonen eines speziellen Typs und Zeichnen von Geländeoberflächenpolygonen auf einer separaten Schicht. Zum Beispiel könnte diese Optimierungstechnik ausgeführt werden auf kleinen Gewässern, wie beispielsweise Swimmingpools (oder Teiche), welche eine große Anzahl von Knoten innerhalb des Polygons erzeugen, welche dem Pool und dem Bereich darum herum entsprechen. Zum Beispiel werden vier Swimmingpools, welche durch einen gepflasterten Bereich umgeben sind, als vier Polygone dargestellt, um die Pools selbst darzustellen. Zusätzlich wird der gepflasterte Bereich als ein Polygon mit vier Löchern darin dargestellt. In einigen Ausführungsformen werden die Polygone, welche den Swimmingpools entsprechen, und ihre entsprechenden Löcher entfernt und in einer separaten Schicht platziert. Der gepflasterte Bereich wird gezeichnet und die Pools werden darüber gezeichnet. Auf diese Weise wird die Anzahl von Punkten, welche sich auf die Pools beziehen, reduziert.
2. Zusammenfassen von Grenzen basierend auf Zuverlässigkeit oder Qualität der Quelldaten
69 zeigt konzeptionell einen Prozess 6900, welcher Grenzen zwischen benachbarten Polygonen zusammenfasst, welche aus zwei unterschiedlichen Quellen in einigen Ausführungsformen empfangen werden. Der Prozess 6900 wird in einigen Ausführungsformen ausgeführt zum Auflösen von nicht-übereinstimmenden Grenzkoordinaten, welche aus unterschiedlichen Quellen empfangen werden, wo eine Datenquelle als zuverlässiger als die andere betrachtet wird. Der Prozess des Zusammenfassens der Grenzkoordinaten wird mit Verweis auf 70 und 71 beschrieben werden. 70 zeigt zwei Stufen 7001 und 7002 einiger Ausführungsformen der Erfindung, welche identifizierte Lücken 700, 7040 und 7060 auflösen durch Zusammenfassen von Grenzkoordinaten zwischen benachbarten Polygonen 7020 und 7030.
71 zeigt zwei Stufen 7101 und 7102 in einigen Ausführungsformen der Erfindung, welche die Grenzkoordinaten der Polygone 7120 und 7130 um die identifizierten Überlappungen 7110 und 7140 zusammenfassen.
Wie in 69 gezeigt, empfängt (bei 6905) der Prozess 6900 zwei Polygone für zwei unterschiedliche Geländeoberflächentypen, welche benachbart zueinander sind. Zum Beispiel können die zwei Geländeoberflächentypen repräsentativ für Ozeane und Parks sein. Der Prozess kann auch einige andere Geländeoberflächentypen empfangen, welche repräsentativ für andere Kartenmerkmale sind. Als Nächstes identifiziert (bei 6910) der Prozess irgendwelche Lücken und überlappt zwischen den Grenzen der zwei Polygone.
Wie in Stufe 7001 in 70 gezeigt, gibt es Lücken 7010, 7040 und 7060 zwischen Polygonen 7020 und 7030. Wie in 71 gezeigt, gibt es Überlappungsbereiche 7110 und 7140 zwischen den Polygonen 7120 und 7130. Obwohl als separate Figuren zur Vereinfachung gezeigt, können einige Ausführungsformen der Erfindung die Polygongrenzkoordinaten um sowohl Lücken als auch Überlappungen herum, welche zwischen den gleichen zwei Polygonen während des Zusammenfassenprozesses auftreten, zusammenfassen.
Bezug nehmend auf 69, nach Identifizieren der Lücken und Überlappungen zwischen den Polygongrenzen, bestimmt (bei 6915) der Prozess 6900, welches Polygon Grenzkoordinaten hat, welche von einer zuverlässigeren Quelle gekommen sind, somit zuverlässigere Grenzkoordinaten hat. Zum Beispiel, wenn das Polygon 7120 Ozean darstellt und Polygon 7130 einen Park darstellt, und der Verkäufer oder die Quelle, welche/r die Ozean-Polygone bereitstellt, als eine zuverlässigere Quelle oder Quelle besserer Qualität betrachtet wird, löst der Prozess die Überlappungen (bei 6920) zugunsten der zuverlässigeren Daten auf. In einigen Ausführungsformen löst der Prozess die Überlappungen zugunsten der Daten auf, welche einen speziellen Typ von Polygon darstellen. Zum Beispiel in dem obigen Ozean/Park-Beispiel kann der Prozess bestimmen, dass die Ozean-Polygone zuverlässiger als die Park-Polygone sind und die Überlappungen zugunsten der zuverlässigeren Ozean-Polygondaten auflösen. Andere Ausführungsformen lösen die Überlappungen zugunsten der Polygone einer größeren oder kleineren Größe auf. Zum Beispiel lösen einige Ausführungsformen die Überlappungen zugunsten des Polygons mit dem größten Umfang oder dem größten Oberflächenbereich auf, während andere Ausführungsformen die Überlappungen zugunsten des Polygons mit dem kürzesten Umfang oder dem kleinsten Oberflächenbereich auflösen. Wie in Stufe 7102 der 71 gezeigt, werden die Überlappungsbereiche 7110 und 7140 entfernt durch die Abgleichen der Grenzen des weniger zuverlässigen Polygons 7120, um sie mit den Grenzen des zuverlässigeren Polygons 7130 auszurichten. In anderen Worten, werden die Koordinaten des zuverlässigeren Polygons 7130 verwendet zum Bestimmen der Grenze zwischen den zwei Regionen.
Um Lücken aufzulösen, für das Polygon mit den weniger zuverlässigen Grenzkoordinaten (oder Daten geringerer Qualität), berechnet (bei 6925) der Prozess einen Schwellenwert basierend auf der Form des Polygons. In einigen Ausführungsformen ist die Form des Polygons basiert auf dem Bereich des Polygons, welcher durch den Umfang des Polygons unterteilt ist, multipliziert mit einem skalierten Faktor. Wenn mehr als eine vorbestimmte Anzahl von Grenzpunkten auf dem Polygon mit weniger zuverlässigen Koordinaten näher an dem zuverlässigeren Polygon als der Schwellenwert sind, verwendet der Prozess (bei 6930) die Grenzkoordinaten des zuverlässigeren Polygons und dehnt die weniger zuverlässige Region aus, um sie mit der zuverlässigeren Region zusammenzuführen. Sobald die Distanz zwischen den zwei Polygonen mehr als die Schwelle ist, werden die zwei Polygone getrennt gelassen. Zum Beispiel, wenn das Polygon 7030 in 70 von einer zuverlässigeren Quelle ist (oder eine bessere Datenqualität hat), werden die Lücken 7010 und 7060 (welche in diesem Beispiel geringer als die berechnete Schwelle sind) geschlossen durch Ausdehnen der Grenzen der weniger zuverlässigen Region 7020 zu den Grenzen der Region 7030. In anderen Worten, werden die Grenzkoordinaten der Region 7030 für beide Regionen in den Bereichen der Lücken 7010 und 7060 verwendet. Auf der anderen Seite, beträgt die Distanz zwischen den zwei Regionen in einem Teil der Lücke 7040 in diesem Beispiel mehr als die berechnete Schwelle. Die Lücke 7040 ist daher nur teilweise geschlossen.
In diesen Beispielen werden Lücken und Überlappungen zugunsten der zuverlässigeren Grenzdaten zusammengefasst. Jedoch können andere Ausführungsformen Grenzkoordinaten um Lücken und Überlappungen auf andere Weisen zusammenfassen, einschließlich Zusammenfassen zugunsten der Polygone oder Grenzdaten mit der größten Genauigkeit.
3. Zusammenfassen der Regionsgrenzen basierend auf Analyse von Grenzdaten
72 zeigt konzeptionell einen Prozess 7200, welcher durch einige Ausführungsformen der Erfindung ausgeführt wird zum Auflösen von Grenzkonflikten zwischen den Regionen. Die Regionen können irgendwelche Geländeoberflächenregionen sein, wie beispielsweise Gewässer, Parks, Gebäude, usw. Die Regionen können auch administrative Regionen sein, wie beispielsweise Staaten, Städte, Landkreise, internationale Länder, usw. Der Prozess extrahiert die Grenzen, um Nicht-Übereinstimmungen aufzulösen, wenn zwei Sätze von Daten für eine gemeinsame Grenze gegeben sind. Solche Nicht-Übereinstimmungen können zum Beispiel auftreten, wenn regionale Grenzdaten für eine gemeinsame Grenze aus unterschiedlichen Quellen erhalten werden. Der Prozess 7200 versucht, die Nicht-Übereinstimmung zugunsten einer einzelnen Grenze aufzulösen.
Wie in 72 gezeigt, empfängt (bei 7205) der Prozess 7200 Polygone entsprechend unterschiedlichen Regionen. Der Prozess identifiziert (bei 7210) dann eine Überlappung zwischen den Regionen. Der Prozess löst die Überlappung auf durch Einbeziehen bei (bei 7215) des überlappenden Bereichs in die Region mit der Grenze, welche die meisten Grenzdatenpunkte bewahrt. In einigen Ausführungsformen umfasst der Schritt 7215 Subtrahieren eines ersten Polygons von einem zweiten Polygon, oder umgekehrt. Einige Ausführungsformen lösen die Überlappung auf basierend darauf, welche der vorgenannten Operationen mehr Grenzdatenpunkte aufweist, um mehr Grenzdetails zu bewahren.
Als Nächstes bestimmt (bei 7220) der Prozess 7200, ob alle überlappenden Bereiche untersucht worden sind. Wenn nicht, kehrt der Prozess zu Schritt 7210 zurück, um einen anderen Überlappungsbereich zwischen unterschiedlichen Regionen zu identifizieren.
Nachdem alle überlappenden Bereiche untersucht worden sind, fährt der Prozess 7200 zu Schritt 7225 fort, zum Identifizieren einer Lücke zwischen benachbarten Regionen. Einige Ausführungsformen der Erfindung erhalten eine Liste von Lücken zwischen benachbarten Grenzen durch Übernehmen der Vereinigung aller Regionen und Subtrahieren aller Regionen, wo Überlappungen bereits untersucht worden sind.
Sobald der Prozess eine Lücke zwischen benachbarten Regionen identifiziert, bestimmt (bei 7230) der Prozess 7200, ob die Lücke zwischen nur zwei Regionen vorliegt. Wenn ja, verwendet (bei 7235) der Prozess die Grenze der Region, welche die meiste Anzahl von Punkten entlang der Grenze bewahrt. Ansonsten liegt die Lücke zwischen drei oder mehr Regionen vor. In diesem Fall verwendet (bei 7240) der Prozess die Grenze der Region, welche die längste Grenze hat. Jedoch in einigen Ausführungsformen, wenn die Lücke zwischen 4 oder mehr Staaten vorliegt, kann der Prozess die Lücke zur Analyse durch einen Menschen kennzeichnen. Der Prozess bestimmt (bei 7245) dann, ob alle Lücken untersucht worden sind. Wenn nicht, kehrt der Prozess zu Schritt 7225 zurück, zum Identifizieren einer anderen Lücke. Wenn ja, endet der Prozess dann.
73 zeigt ein Beispiel des Auflösens eines Grenzkonflikts zwischen zwei benachbarten Regionen 7350 und 7360 durch Ausführen des Prozesses 7200. Obwohl nur zwei Regionen durch die 73 der Einfachheit halber gezeigt werden, könnte der Prozess 7200 auf einer nicht-übereinstimmenden Grenze zwischen mehreren Regionen ausgeführt werden. Wie gezeigt, teilen die Regionen 7350 und 7360 eine gemeinsame Grenze 7390. Jedoch existieren Grenzkonflikte zwischen den zwei Regionen. Die erste Stufe 7301 der 73 zeigt einen aufgeblasenen Teil 7340 der Grenze 7390 zwischen den Regionen 7350 und 7360. Der aufgeblasene Teil 7340 zeigt Beispiele von Grenzkonflikten, wie beispielsweise eine Überlappung 7310 und eine Lücke 7330, welche durch das Ausführen des Prozesses 7200 aufgelöst werden könnten.
Die zweite Stufe 7302 der 73 zeigt einen aufgeblasenen Teil davon, wie die Grenze 7370 aussehen könnte, nachdem der Prozess 7200 auf der Grenze 7390 ausgeführt wurde. Zurückverweisend auf 72, würde der Prozess 7200 zuerst die Überlappung 7310 identifizieren (bei 7210) und den Konflikt auflösen durch Einbeziehen (bei 7215) des Teils der Region, welcher die meisten Grenzdatenpunkte bewahrt. In dem Beispiel, welches durch 73 gezeigt ist, bestimmte der Prozess 7200, dass die Grenze 7395 um die Region 7360 mehr Grenzdatenpunkte bewahrt und bezog diese Grenze ein, wie gezeigt in Stufe 7302. Der Prozess 7200 identifiziert (bei 7225) dann, dass die Lücke 7330 aufgelöst werden muss. Der Prozess versucht, die Lücke 7330 zwischen den Regionen 7350 und 7360 auch zu entfernen durch Verwenden (bei 7235) der Grenze, welche mehr Grenzdatenpunkte bewahrt. In dem Beispiel, welches in 73 gezeigt ist, bestimmte der Prozess 7200, dass für diesen Teil der Grenze, die Grenze 7397 um die Region 7350 mehr Grenzdatenpunkte bewahrte, und bezog diese Grenze ein, wie gezeigt in Stufe 7302. In einigen Ausführungsformen werden einige oder alle der Operationen, welche in den Prozessen 67, 69 und 72 definiert sind, durch ein oder mehrere Software-Module ausgeführt.
E. Kachelerzeugung
Eine der letzten Operationen, welche durch den Satz von Servern ausgeführt wird, welche die Kartenkacheln erzeugen, ist die Kachelschnittoperation, welche die Kartenkacheln erzeugt und die geometrischen und Vektordaten in diesen Kacheln codiert. In einigen Ausführungsformen definiert der Satz von Servern eine Karte mittels eines Kachelbaums mit mehreren Ebenen, welche mehreren Zoom-Leveln zum Betrachten der Karte entsprechen. Zum Beispiel ist die Kachelbaumdatenstruktur in einigen Ausführungsformen ein Quadtree mit einundzwanzig Ebenen, welche einundzwanzig Zoom-Leveln zum Betrachten der Karte entsprechen. In dem Quadtree ist jeder Knoten eine Kartenkachel und jeder Nicht-Blattknoten hat vier Kind-Kachelknoten.
Die Kachelschnittoperation hat mehrere Neuheiten. Eine Neuheit ist der schnelle Mechanismus, welchen sie verwendet zum Assoziieren jeder Geometrie, welche für eine Karte erzeugt wurde, mit ein oder mehreren Kacheln in dem Kachel-Quadtree. Dieser schnelle Mechanismus verwendet in einigen Ausführungsformen verteiltes Rechnen zum schnellen Assoziieren der großen Anzahl von Geometrien in der Karte mit der großen Anzahl von Kartenkacheln. Die Aufgabe des Bestimmens, ob jede Geometrie mit einer Kachel assoziiert werden sollte, wird als eine Aufgabe unabhängig von anderen ähnlichen Aufgaben behandelt, von denen jede unterschiedlichen Rechenressourcen in einer verteilten Rechnerumgebung zugewiesen werden kann.
Zum Beispiel kann eine Rechenressource bestimmen, ob eine Geometrie eine Kachel schneidet. Wenn sie dies tut, dann wird für die Kinder jeder Kachel eine separate Kreuzungsoperation ausgeführt, um zu bestimmen, ob die Geometrie die Kind-Kachel kreuzt. Eine separate Rechenressource kann jede unterschiedliche Kreuzungsoperation unabhängig von den anderen Rechenressourcen ausführen. Dieser Prozess kann betrachtet werden als eine Geometrie einen Kachel-Quadtree hinab ”werfend”, jeden Kachelknoten identifizierend, welcher die Geometrie kreuzt und dann Senden eines gekreuzten Teils der Geometrie an jeden Kind-Knoten jedes gekreuzten Knotens, um zu bestimmen, ob der Kind-Knoten die Geometrie kreuzt. Die Geometrien, welche für jeden Kachelknoten identifiziert werden, werden dann in dem Kachelschnittprozess verwendet zum Erzeugen der Kachel.
Eine weitere Neuheit bezieht sich auf den schnellen Mechanismus, welchen sie verwendet zum Neucodieren der Straßenvektordaten in den Kartenkacheln zum Entfernen von unnötigen Daten. Wieder verwendet die Kachelschnittoperation verteiltes Rechnen zum Verteilen dieser Aufgabe des Neucodierens der Vektordaten. Jede verteilte Aufgabe umfasst anfängliches Aufzeichnen der Straßendaten (welche überlappen können) jeder Kachel auf der gleichen Arbeitsfläche, um überlappende Straßengeometrien zusammenzuführen. Die Aufgabe umfasst dann Neu-Vektorcodieren dieser Daten zum Erzeugen der Vektordaten, welche nicht doppelt sind.
Diese Kachelschnittoperation einiger Ausführungsformen wird weiter beschrieben in der vorläufigen US-Patentanmeldung 61/657,872 mit dem Titel „Scalable and Efficient Cutting of Map Tiles”, eingereicht am 10.06.2012; der US-Patentanmeldung 13/632,003 mit dem Titel „Scalable Processing for Associating Geometries with Map Tiles”, eingereicht am 30.09.2012; und der US-Patentanmeldung 13/632,004 mit dem Titel „Scalable and Efficient Cutting of Map Tiles”, eingereicht am 30.09.2012. Die vorläufige Anmeldung 61/657,872 und die nicht-vorläufigen Anmeldungen 13/632,003 und 13/632,004 sind hiermit durch Verweis aufgenommen.
III. Client-seitige Erzeugung von 3D-Darstellungen
Die Kartenanwendung einiger Ausführungsformen verwendet eine Vielzahl von neuen Techniken zum Darstellen einer 3D-Darstellung einer Karte, während die Karte durchsucht wird oder während die Karte eine Navigationspräsentation bereitstellt. Zum Beispiel wie oben erwähnt, rendert die Kartenanwendung die 3D-Darstellung aus der Sicht einer virtuellen Kamera, und verwendet verschiedene Verfahren zum automatischen Bewegen der virtuellen Kamera (d. h. Bewegen der perspektivischen Render-Position) in bestimmten Situationen zum Erreichen einer gewünschten 3D-Darstellung. Ein Beispiel tritt auf, wenn die Kartenanwendung einiger Ausführungsformen die Position der virtuellen Kamera von einer perspektivischen Render-Position hinter eine derzeitige Position einer sich bewegenden Vorrichtung zu einer Top-down-Ansicht der derzeitigen Position bewegt, wenn die Vorrichtung dabei ist, eine Abbiegung entlang einer Route zu machen. Ein anderes Beispiel sind die Hereinzoom-/Herauszoom-Animationen, welche bereitgestellt werden, welche Objekte zeigen, welche in der Szene mit der Hereinzoom-Operation und der Herauszoom-Operation wachsen und schrumpfen.
Auch in einigen Ausführungsformen stellt die Kartenanwendung zwei unterschiedliche Typen von 3D-Darstellungen bereit – eine immersive 3D-Darstellung und eine nicht-immersive 3D-Darstellung. Die immersive Darstellung in einigen Ausführungsformen zeigt nicht nur mehr Geometrien an, sondern zeigt auch mehr Details für die Geometrien an, welche in der nicht-immersiven Darstellung angezeigt werden. Die Kartenanwendung stellt auch weiche Übergänge zwischen den nicht-immersiven und immersiven Darstellungen bereit.
Um solche weichen Übergänge zu erreichen und andere neue Effekte zu erzeugen, verwendet die Kartenanwendung einiger Ausführungsformen eine neue Bildverarbeitungs-Pipeline. Diese Pipeline führt eine Vielzahl von Vor-Ladeoperationen aus zum Herunterladen, Abrufen und/oder Dekomprimieren von Kartenkacheln, welche für eine Navigationsdarstellung benötigt werden können, um ihre Rendering-Pipeline für ihre Rendering-Operationen vorzubereiten und zum Vorbereiten einer Duplikat-Pipeline zum weichen Übergehen zwischen den immersiven und nicht-immersiven 3D-Darstellungen.
Der Unterabschnitt A unten beschreibt die automatische Bewegung der virtuellen Kamera, welche verwendet wird zum Rendern der 3D-Darstellung. Der Unterabschnitt B beschreibt dann weiter die immersive und nicht-immersive 3D-Darstellung der Kartenanwendung. Der Unterabschnitt C beschreibt dann als Nächstes die Bildverarbeitungs-Pipeline der Kartenanwendung und ihre assoziierte Netzerzeugungs-Pipeline, virtuelle Kamera und Rendering-Engine.
A. Automatisierte virtuelle Kamerabewegung
Wie oben beschrieben, ist die virtuelle Kamera eine Konzeptualisierung der Position in der 3D-Karte, welche die Kartenanwendung rendert zum Erzeugen einer 3D-Kartenansicht. Das Folgende stellt Beschreibungen einiger unterschiedlicher Beispiele der automatisierten Bewegung solch einer virtuellen Kamera bereit.
1. Virtuelle Kamerabewegung während der Routennavigation
74 zeigt konzeptionell ein Beispiel einer virtuellen Kamera 7400, welche sich automatisch um eine Region einer 3D-Karte 7435 basierend auf einer Routennavigation bewegt. 74 zeigt die Bewegung der virtuellen Kamera 7400 um die Region der 3D-Karte 7435 bei drei unterschiedlichen Stufen 7405–7415. In einigen Ausführungsformen führt die Kartenanwendung den Prozess 7500, welcher unten mit Verweis auf 75 beschrieben wird, aus zum Rendern der 3D-Kartenansichten, welche in dieser Figur beschrieben sind. Wie in dieser Figur gezeigt, umfasst die Region der 3D-Karte 7435 eine Straße, welche über eine Brücke verläuft.
Die erste Stufe 7405 zeigt die virtuelle Kamera 7400 bei einem speziellen Ort und einer Position in der 3D-Karte 7435. In einigen Ausführungsformen wird der Punkt, bei welchem die virtuelle Kamera 7400 fokussiert (d. h. der Punkt, bei welchem eine Linie aus der Vorderseite der virtuellen Kamera herausragend die Straße kreuzt) in der 3D-Karte 7435 bezeichnet als ein Fokuspunkt. In einigen Ausführungsformen verwendet die Kartenanwendung einen Punkt entlang der Route, welcher eine definierte Distanz (z. B. 5 Fuß, 10 Fuß, 25 Fuß, 50 Fuß, usw.) vor dem Ort des Benutzers ist (dargestellt durch einen Kreis mit einem Dreieck darauf, in diesem Beispiel) als der Fokuspunkt der virtuellen Kamera 7400. Die Kartenanwendung einiger Ausführungsformen verwendet unterschiedliche Distanzen vor dem Ort des Benutzers entlang der Route, basierend auf der Fahrtgeschwindigkeit des Benutzers (z. B. längere Distanzen, wenn der Benutzer bei schnelleren Geschwindigkeiten fährt, und kürzere Distanzen, wenn der Benutzer bei langsameren Geschwindigkeiten fährt).
In der ersten Stufe 7405 ist der Fokuspunkt der virtuellen Kamera 7400 ein Punkt entlang der Rampe der Brücke, welche eine definierte Distanz vor dem Ort des Benutzers ist. Ein beispielhaftes gerendertes Bild der 3D-Karte 7435 aus dem Blickwinkel der virtuellen Kamera 7400 bei dieser Stufe 7405 ist gezeigt in der 3D-Kartenansicht 7420. Die 3D-Kartenansichten 7420, 7425 und 7430, welche in dieser Figur gezeigt sind, sowie diese, welche in anderen Figuren innerhalb dieses Abschnitts gezeigt sind, umfassen nicht verschiedene UI-Steuerungen und Merkmale (z. B. Straßenschilder, Navigationszeichen, schwebende Steuerungen, usw.), um die gerenderten Kartenbilder hervorzuheben.
Die zweite Stufe 7410 zeigt die virtuelle Kamera 7400 an einem anderem Ort und Position in der 3D-Karte 7435. In diesem Beispiel hat sich die virtuelle Kamera 7400 nach oben bewegt, weil der Fokuspunkt der virtuellen Kamera 7400 erhöht ist aufgrund der Höhe der Brücke. Zusätzlich hat sich die virtuelle Kamera 7400 hin zu der rechten Seite bewegt, um entlang der Routennavigation zu folgen. Von der ersten Stufe 7405 zu der zweiten Stufe 7410 hat die Kartenanwendung automatisch die virtuelle Kamera 7400 bewegt, Bilder der 3D-Karte aus dem Blickwinkel der virtuellen Kartenanwendung 7400 entlang des Pfades gerendert, und die Bilder auf der Vorrichtung angezeigt. Ein beispielhaftes gerendertes Bild der 3D-Karte 7435 aus dem Blickpunkt der virtuellen Kamera 7400 bei dieser Stufe 7410 ist in der 3D-Kartenansicht 7425 gezeigt.
Die dritte Stufe 7415 zeigt die virtuelle Kamera 7400 bei einem anderen unterschiedlichen Ort und Position der 3D-Karte 7435. Für dieses Beispiel hat sich die virtuelle Kamera 7400 nach unten bewegt, weil der Fokuspunkt der virtuellen Kamera 7400 auf der Straße ist und nicht länger auf der Brücke. Zusätzlich hat sich die virtuelle Kamera 7400 hin zu der rechten Seite bewegt, um entlang der Routennavigation zu folgen. Von der zweiten Stufe 7410 zu der dritten Stufe 7415 hat die Kartenanwendung automatisch die virtuelle Kamera 7400 bewegt, Bilder der 3D-Karte aus dem Blickpunkt der virtuellen Kamera 7400 entlang des Pfades gerendert, und die Bilder auf der Vorrichtung angezeigt. Ein beispielhaftes gerendertes Bild der 3D-Karte 7435 aus dem Blickpunkt der virtuellen Kamera 7400 bei dieser Stufe 7415 ist in der 3D-Kartenansicht 7430 gezeigt.
In einigen Ausführungsformen detektiert die Kartenanwendung einen Schwellenbetrag von Änderung in der Höhe, oder eine Schwellenrate von Änderungen in der Höhe des Brennpunktes entlang der Route. Die Kartenanwendung einiger solcher Ausführungsformen fügt eine Verzögerung zu der Positionierung der Anpassung der virtuellen Kamera des Nachverfolgens hinzu, in Antwort auf die Position des Fokuspunkts entlang der Route, wenn die Kartenanwendung detektiert, dass der Ort des Benutzers entlang der Route in der Höhe abgenommen hat und eine oder beide Schwellen überschritten worden sind. In einigen Ausführungsformen behält die Kartenanwendung die Höhe der virtuellen Kamera bei (z. B. die Position der virtuellen Kamera entlang einer z-Achse) für eine definierte Zeitdauer, wenn die Kartenanwendung das Abnehmen in der Höhe des Orts des Benutzers entlang der Route detektiert. Hinzufügen einer Verzögerung und Beibehalten der Höhe für eine definierte Zeitdauer sind Techniken, welche jeweils die virtuelle Kamera daran hindern, sich der Straße zu nahe zu nähern, oder in einigen Fällen in die Straße zu kollidieren. Auf diese Weise stellt die Kartenanwendung dem Benutzer eine bessere Ansicht der Karte bereit, während hügelige Straßen überquert werden.
75 zeigt konzeptionell einen Prozess einiger Ausführungsformen zum Animieren von Kartenansichten während einer Routennavigation. Die Kartenanwendung einiger Ausführungsformen führt den Prozess 7500 bei definierten Intervallen aus (z. B. 0,5 Sekunden, 1 Sekunde, 3 Sekunden, 5 Sekunden, usw.). In einigen Ausführungsformen führt die Kartenanwendung wiederholt den Prozess 7500 aus, während die Kartenanwendung in dem Routennavigationsmodus betrieben wird.
Der Prozess 7500 beginnt durch Identifizieren (bei 7510) eines Satzes von Attributen zum Bestimmen der Position der virtuellen Kamera an dem Ende einer Zeitperiode. In einigen Ausführungsformen ist das Ende der Zeitperiode die Zeit, zu welcher die Kartenanwendung den derzeitigen Ort des Benutzers empfängt, und der Beginn der Zeitperiode ist die Zeit, zu welcher die Kartenanwendung den vorherigen Ort des Benutzers empfängt. In einigen Ausführungsformen umfasst der Satz von Attributen Daten, welche verwendet werden zum Herleiten der Position und Orientierung der virtuellen Kamera.
In unterschiedlichen Ausführungsformen verwendet der Prozess 7500 unterschiedliche Sätze von Attributen. Das Folgende beschreibt einige oder alle Attribute, welche durch den Prozess 7500 einiger Ausführungsformen verwendet werden. Zum Beispiel verwendet der Prozess 7500 einiger Ausführungsformen den Ort eines Referenzpunkts (d. h. den Ort des Benutzers). Der Prozess 7500 einiger Ausführungsformen verwendet den Ort des Fokuspunkt der virtuellen Kamera, welcher verwendet wird zum Bestimmen, in welche Richtung die virtuelle Kamera in einigen Ausführungsformen sich wenden sollte.
In Fällen, wo der Benutzer außerhalb der Route ist, ist der Fokuspunkt eine feste Distanz vor dem Benutzer entlang der Fahrtrichtung des Benutzers (wenn diese bestimmt werden kann) oder eine feste Distanz nördlich des Benutzers, wenn die Fahrtrichtung des Benutzers nicht bestimmt werden kann. In Fällen, in denen der Benutzer auf der Route ist in Bezug auf die Routennavigation, ist der Fokuspunkt in einer festen Distanz vor dem Benutzer entlang der Route, um der virtuellen Kamera zu erlauben, subtil um Abbiegungen zu spähen, bevor der Benutzer tatsächlich abbiegt.
Einige Ausführungsformen beschränken den Winkel zwischen (1) einem Vektor, welcher von dem Referenzpunkt und dem Brennpunkt definiert ist, und (2) einem Vektor, welcher zu der Fahrtrichtung des Benutzers zeigt, auf einen definierten Maximalwinkelbetrag. Zum Beispiel, wenn die Route in kurzem Abstand voraus um eine Ecke biegt, wird der Fokuspunkt ein Punkt sein, der von der derzeitigen Position der Vorrichtung aus um die Ecke liegt. Während das Abbiegen der virtuellen Kamera, um sich diesem tatsächlichen Punkt zuzuwenden, die virtuelle Kamera veranlassen könnte, sich direkt einem Gebäude zuzuwenden, ist der Betrag, um welchen die virtuelle Kamera abbiegt, um um die Ecke zu spähen, beschränkt, so dass die Ansicht der Fahrtrichtung teilweise zu allen Zeiten gezeigt wird.
Ein weiterer virtueller Kamerapositionsindikator, welchen der Prozess 7500 einiger Ausführungsformen verwendet, ist ein Ort eines Punkts von Interesse (z. B. der Ort einer bevorstehenden Verkehrskreuzung). In einigen Ausführungsformen bestimmt der Prozess 7300 den virtuellen Kameraansichtsstil und verwendet diesen Indikator zum Herleiten der Position und der Orientierung der virtuellen Kamera. Beispiele der virtuellen Kameraansichtsstile umfassen top-down-zentriert, top-down-vorwärts und Dach (rooftop). Ein top-down-zentrierter Ansichtsstil in einigen Ausführungsformen ist, wo die virtuelle Kamera gerade nach unten auf den Ort des Benutzers schaut, so dass der Ort des Benutzers an dem Mittelpunkt des Bildschirms positioniert ist. In einigen Ausführungsformen ist der top-down-vorwärts Ansichtsstil, wo die virtuelle Kamera gerade nach unten auf den Ort des Benutzers schaut, so dass der Ort des Benutzers hin zu der unteren Seite der Anzeige positioniert ist. Ein „Dach”-Ansichtsstil in einigen Ausführungsformen ist, wo die virtuelle Kamera hinter dem Ort des Benutzers positioniert ist und so geneigt ist, dass sie nach vorne entlang des Vektors von dem Benutzerort zu dem Fokuspunkt schaut. Wenn der Benutzer außerhalb der Route der Routennavigation ist, oder die Fahrtrichtung des Benutzers nicht bestimmt werden kann (z. B. wenn der Benutzer parkt), wird die virtuelle Kamera zu einem top-down-zentrierten Ansichtsstil eingestellt. Ansonsten wird der Ansichtsstil bestimmt dadurch, ob der Benutzer einen 2D- oder 3D-Navigationsmodus angefragt hat. Wenn der Benutzer einen 2D-Navigationsmodus angefragt hat, wird der Ansichtsstil auf einen top-down-vorwärts Ansichtsstil eingestellt. Wenn der Benutzer einen 3D-Navigationsmodus angefragt hat, wird der Ansichtsstil auf einen Dach-Ansichtsstil eingestellt.
In einigen Ausführungsformen bestimmt der Prozess 7500 den Fokusstil der virtuellen Kamera und verwendet diesen, um die Position und Orientierung der virtuellen Kamera zu bestimmen. Beispiele der virtuellen Kamerafokusstile umfassen einen Fahrt(cruise)-Fokusstil und einen Hartfokusstil. In einigen Ausführungsformen ist der Fahrtfokusstil, wo die virtuelle Kamera auf eine voreingestellte Höhe und einen Neigungswinkel eingestellt ist. Ein Hartfokusstil in einigen Ausführungsformen ist, wo die virtuelle Kamera eingestellt ist auf eine Höhe (z. B. in den top-down-zentrierten oder top-down-vorwärts Ansichtsstilen) und/oder Neigung (z. B. in dem Dach-Ansichtsstil), so dass ein gegebener Punkt von Interesse auf dem Bildschirm angezeigt wird (z. B. die virtuelle Kamera fokussiert auf den Punkt von Interesse, während der Benutzer sich diesem nähert).
Als Nächstes bestimmt (bei 7520) der Prozess 7500 die Position und Orientierung der virtuellen Kamera basierend auf den identifizierten Attributen. Nach Bestimmen der Position und Orientierung der virtuellen Kamera, identifiziert (bei 7530) der Prozess 7500 die Orte eines Satzes von Referenzpunkten an dem Ende der Zeitperiode, basierend auf der Position und Orientierung der virtuellen Kamera. Beispiele von Referenzpunkten umfassen die Position der Kamera, die Kreuzung zwischen dem Vorwärtsvektor der virtuellen Kamera und dem Boden, einem definierten Punkt entlang des rechten Vektors der virtuellen Kamera, usw.
Der Prozess 7500 identifiziert (bei 7540) dann die Orte eines entsprechenden Satzes von vorherigen Referenzpunkten. In einigen Ausführungsformen behält die Kartenanwendung einen Verlauf der Orte der Sätze von Referenzpunkten, welche auf die gleiche Weise wie jene, welche durch den Prozess 7500 bei 7520 identifiziert werden, bestimmt werden, auf welche der Prozess 7500 zugreift.
Schließlich rendert (bei 7550) der Prozess 7500 eine animierte Kartenansicht für die Zeitperiode basierend auf den Sätzen von Referenzpunkten, welche bei 7530 und 7540 identifiziert werden. Um die animierte Kartenansicht zu rendern, verwendet der Prozess 7500 einiger Ausführungsformen kubische Polynome, welche mit jedem Referenzpunkt assoziiert sind. Der Prozess 7500 animiert die Kartenansicht durch (1) Durchlaufen jedes der Referenzpunkte der virtuellen Kamera entlang ihrer assoziierten kubischen Polynome während der Animation, während (2) des Renderns der Ansicht der Karte der virtuellen Kamera.
Vor dem Rendern der animierten Kartenansicht aktualisiert der Prozess 7500 einiger Ausführungsformen das kubische Polynom, welches mit einem speziellen Referenzpunkt assoziiert ist, wenn sich der Referenzpunkt in Bezug auf seinen entsprechenden vorherigen Referenzpunkt geändert hat. In einigen Ausführungsformen aktualisiert der Prozess 7500 das kubische Polynom mit einem kubischen Polynom, welches basierend auf dem Ort eines Referenzpunkts bestimmt wurde, dem Ort des entsprechenden vorherigen Referenzpunkts und zwei Tangenten, basierend auf dem Referenzpunkt und seinem entsprechenden vorherigen Referenzpunkt. In einigen Ausführungsformen verwendet der Prozess 7500 eine skalierte Version eines Vektors, welcher an dem Ort des Referenzpunkts endet und von dem Ort des entsprechenden vorherigen Referenzpunkts startet, als eine der Tangenten. Für die andere Tangente verwendet der Prozess 7500 einiger Ausführungsformen einen weiteren skalierten Vektor, welcher auf eine ähnliche Weise bestimmt wird wie der erste skalierte Vektor, außer dass der Vektor an dem Ort des vorherigen Referenzpunkts und dem Ort seines entsprechenden vorherigen Referenzpunkts endet. Der Prozess 7500 passt ein kubisches Polynom unter Verwendung dieser zwei Tangenten, des Orts des Referenzpunkts und des Orts des entsprechenden vorherigen Referenzpunkts an, und verwendet das angepasste kubische Polynom als das derzeitige kubische Polynom des Referenzpunkts.
2. Virtuelle Kamerabewegung um Verkehrskreuzungen herum
76 zeigt konzeptionell ein Beispiel einer virtuellen Kamera 7600, welche automatisch eine Abbiegung in einer 3D-Karte 7650, während sie auf einer Routennavigation ist, manövriert. 76 zeigt die Bewegung der virtuellen Kamera 7600 in der 3D-Karte 7650 bei drei unterschiedlichen Stufen 7605–7615. In einigen Ausführungsformen führt die Kartenanwendung den Prozess 7700 aus, welcher unten beschrieben ist durch Verweis auf 77, um eine Abbiegung zu manövrieren. Wie gezeigt, umfasst die Region der 3D-Karte 7650 eine Straße, welche an einer anderen Straße und einem Gebäude auf der rechten Seite der T-Kreuzung angrenzt.
Die erste Stufe 7605 zeigt die virtuelle Kamera 7600 an einem speziellen Ort und Position in der 3D-Karte 7650. In einigen Ausführungsformen wird der Punkt, auf welchen die virtuelle Kamera 7600 fokussiert (d. h. der Punkt, an welchem eine Linie, die herausragt aus der Vorderseite der virtuellen Kamera, die Straße kreuzt) in der 3D-Karte 7650 bezeichnet als ein Fokuspunkt. In einigen Ausführungsformen verwendet die Kartenanwendung einen Punkt entlang der Route, welcher eine definierte Distanz (z. B. 5 Fuß, 10 Fuß, 25 Fuß, 50 Fuß, usw.) vor dem Ort des Benutzers ist (dargestellt durch einen Kreis mit einem Dreieck darauf, in diesem Beispiel) als den Fokuspunkt der virtuellen Kamera 7600. Die Kartenanwendung einiger Ausführungsformen verwendet unterschiedliche Abstände vor dem Ort des Benutzers entlang der Route basierend auf der Fahrtgeschwindigkeit des Benutzers (z. B. längere Distanzen, wenn der Benutzer bei höheren Geschwindigkeiten reist, und kürzere Distanzen, wenn der Benutzer bei geringeren Geschwindigkeiten reist). Für dieses Beispiel ist der Fokuspunkt der virtuellen Kamera 7600 ein Punkt entlang der Route vor dem Ort des Benutzers.
In der ersten Stufe 7605 ist der Brennpunkt der virtuellen Kamera 7600 ein Punkt vor dem Ort des Benutzers auf der Straße, auf welcher der Benutzer fährt. Die erste Stufe 7605 zeigt auch eine entsprechende Top-Down-Ansicht 7620 der virtuellen Kamera 7600 und der 3D-Karte 7650. Wie gezeigt, ist der Fokuspunkt in diesem Beispiel angezeigt durch einen schwarzen Kreis, welcher vor dem Benutzer auf der Straße angeordnet ist, auf welcher der Benutzer fährt. Ein beispielhaftes gerendertes Bild der 3D-Karte 7650 aus dem Blickpunkt der virtuellen Kamera 7600 bei dieser Stufe 7605 wird in der 3D-Kartenansicht 7635 gezeigt. Die 3D-Kartenansicht 7635 zeigt auch den Fokuspunkt der virtuellen Kamera.
Die zweite Stufe 7610 zeigt die virtuelle Kamera 7600 an einem unterschiedlichen Ort und Position in der 3D-Karte 7650. Wie in der zweiten Stufe 7610 gezeigt, hat sich die virtuelle Kamera 7600 nach rechts hin zu der Verkehrskreuzung entlang der Routennavigation bewegt. Um den Fokus auf dem Fokuspunkt zu halten, hat sich auch die virtuelle Kamera 7600 nach oben bewegt (z. B. nach oben entlang der z-Achse), um eine bessere Sicht des Fokuspunkt während der Rechtsabbiegung bereitzustellen, für den Fall, dass diese behindert werden könnte. Zum Beispiel, wenn es Gebäude in der Nähe oder an der Verkehrskreuzung gibt, könnte der Fokuspunkt durch die Gebäude verdeckt werden, wodurch eine Sicht über die Ecke der Abbiegung hinaus verhindert werden würde.
Zusätzlich hat sich die virtuelle Kamera 7600 bei dieser Stufe, nach unten geneigt (z. B. verringerte Neigung), um das Ziel auf dem Fokuspunkt zu behalten. Die Top-down-Ansicht 7625 bei der zweiten Stufe 7610 zeigt, dass die virtuelle Kamera 7600 leicht zu der rechten Seite der Verkehrskreuzung gedreht hat (z. B. um die z-Achse), weil der Fokuspunkt genau rechts der Verkehrskreuzung befindet. Somit von der ersten Stufe 7605 zu der zweiten Stufe 7610, hat die Kartenanwendung automatisch die virtuelle Kamera 7600 vorwärts entlang der Routennavigation bewegt (zum Beispiel entlang der x-Achse, y-Achse oder einer Kombination von sowohl x- als auch y-Achsen, usw.) hin zu der Verkehrskreuzung, die virtuelle Kamera 7600 höher bewegt (z. B. hoch entlang der z-Achse) und die virtuelle Kamera 7600 rotiert (z. B. um die z-Achse) hin zu der rechten Seite der Verkehrskreuzung, während der Fokus auf dem Fokuspunkt vor dem Ort des Benutzers gehalten wird. Ein beispielhaftes gerendertes Bild der 3D-Karte 7650 aus dem Blickpunkt der virtuellen Kamera 7600 bei der zweiten Stufe 7610 wird in der 3D-Kartenansicht 7640 gezeigt.
Die dritte Stufe 7615 zeigt die virtuelle Kamera 7600 bei einem anderen unterschiedlichen Ort und Position in der 3D-Karte 7650. Hier hat sich die virtuelle Kamera 7600 zu der rechten Seite bewegt und ist an der Verkehrskreuzung entlang der Routennavigation. Um den Fokus auf den Fokuspunkt zu halten, hat sich die virtuelle Kamera 7600 auch nach oben bewegt (z. B. nach oben entlang der z-Achse) und über die Verkehrskreuzung, um eine bessere Sicht des Fokuspunkts bereitzustellen, während der Benutzer die Rechtsabbiegung macht aus den gleichen oder ähnlichen Gründen, wie oben erwähnt (z. B. Behinderung oder Verdeckung der Sicht der virtuellen Kamera 7600 des Fokuspunkt).
In der dritten Stufe 7615 hat sich die virtuelle Kamera 7600 ebenfalls weiter nach unten geneigt (z. B. verringerte Neigung), um den Fokus auf dem Brennpunkt zu halten. Die Top-down-Ansicht 7630 in der dritten Stufe 7615 zeigt, dass die virtuelle Kamera 7600 zu der rechten Seite gedreht hat (z. B. um die z-Achse), während der Brennpunkt nun an der Rechtsabbiegung der Verkehrskreuzung vorbei ist. Als solches, von der zweiten Stufe 7610 zu der dritten Stufe 7615 hat die Kartenanwendung die virtuelle Kamera 7600 automatisch nach vorne entlang der Routennavigation (z. B. entlang der x-Achse, y, Achse-, oder einer Kombination von sowohl x- als auch y-Achsen, usw.) zu der Verkehrskreuzung bewegt, die virtuelle Kamera 7600 höher bewegt (z. B. nach oben entlang der z-Achse) und die virtuelle Kamera 7600 rotiert (z. B. um die z-Achse) hin zu der rechten Seite der Verkehrskreuzung, während der Fokus auf dem Fokuspunkt vor dem Ort des Benutzers gehalten wird. Ein beispielhaftes gerendertes Bild der 3D-Karte 7650 aus dem Blickpunkt der virtuellen Kamera 7600 bei der dritten Stufe 7615 ist in der 3D-Kartenansicht 7645 gezeigt.
76 zeigt einen Fokuspunkt in den Top-down-Ansichten einer 3D-Karte und der gerenderten 3D-Kartenansichten der 3D-Karte zum Zwecke der Erklärung und Klarheit. In einigen Ausführungsformen rendert die Kartenanwendung tatsächlich nicht den Fokuspunkt in den 3D-Ansichten, und die 3D-Karte enthält keinen tatsächlichen Punkt, welcher den Fokuspunkt darstellt.
77 zeigt konzeptionell einen Prozess 7700 einiger Ausführungsformen zum Animieren einer Kartenansicht während einer Abbiegung einer Routennavigation. In einigen Ausführungsformen führt die Kartenanwendung iterativ den Prozess 7700 aus, wenn die Kartenanwendung eine Routennavigation durchläuft. Die Kartenanwendung einiger Ausführungsformen führt den Prozess 7700 bei definierten Intervallen aus (z. B. 0,5 Sekunden, 1 Sekunde, 3 Sekunden, usw.), während die Kartenanwendung eine Routennavigation durchläuft.
Der Prozess 7700 beginnt durch Identifizieren (bei 7710) einer bevorstehenden Verkehrskreuzung. In einigen Ausführungsformen verwendet der Prozess 7700 Kartendaten zum Identifizieren der bevorstehenden Verkehrskreuzung entlang der Routennavigation.
Als Nächstes bestimmt (bei 7720) der Prozess 7700, ob die Navigationsroute eine Abbiegung bei der bevorstehenden Verkehrskreuzung hat. Der Prozess 7700 einiger Ausführungsformen bestimmt, dass eine Navigationsroute eine Abbiegung bei der bevorstehenden Verkehrskreuzung hat, wenn der Prozess 7700 eine Schwellenwertänderung in der Richtung nahe oder bei der Verkehrskreuzung identifiziert, oder eine Änderung des Straßennamens entlang der Routennavigation bei der Verkehrskreuzung bestimmt. Zusätzliche und/oder andere Techniken sind möglich.
Wenn der Prozess 7700 bestimmt, dass es keine Abbiegung bei der nächsten Verkehrskreuzung gibt, endet der Prozess 7700. Ansonsten bestimmt (bei 7730) der Prozess 7700, ob der Abbiegungswinkel innerhalb eines Schwellenwertwinkels ist (ob die Kurve davon abweicht, gerade zu sein um mehr als einige Grad). Der Schwellenwertwinkel wird für verschiedene Ausführungsformen unterschiedlich definiert. In einigen Ausführungsformen wird der Schwellenwertwinkel als ein Wert unter 45 Grad, ein Wert zwischen 45 und 90 Grad, größer als 90 Grad usw. definiert.
Wenn der Prozess 7700 bestimmt, dass der Abbiegewinkel innerhalb des Schwellenwertwinkels ist, dann endet der Prozess 7700. Ansonsten zeigt (bei 7740) der Prozess 7700 die Kartenansicht in einem Top-down-Ansichtsmodus an. In einigen Ausführungsformen ist ein Top-down-Modus ein Ansichtsmodus, in welchem die virtuelle Kamera oberhalb oder „auf” der Szene ist und entweder größtenteils oder ganz nach unten zeigt. In einigen Ausführungsformen wird der Top-down-Ansichtsmodus bezeichnet als ein Hartfokusmodus. Der Top-down-Ansichtsmodus in einigen Ausführungsformen ist ein 2D-Modus. In einigen Fällen zeigte die Kartenanwendung bereits die Kartenansicht in dem Top-down-Modus an. In solchen Fällen fährt der Prozess 7700 in dem Ansichtsmodus durch die Abbiegung entlang der Routennavigation fort.
Als Nächstes bestimmt (bei 7750) der Prozess 7700, ob die Abbiegung fertiggestellt wurde. Der Prozess 7700 bestimmt, dass die Abbiegung fertiggestellt worden ist, wenn der Ort des Benutzers eine definierte Distanz hinter der Verkehrskreuzung liegt. In einigen Ausführungsformen bestimmt der Prozess 7700, dass die Abbiegung fertiggestellt worden ist, wenn die Position der virtuellen Kamera sich um einen Winkelbetrag des Abbiegungswinkels oder einen Schwellenwertwinkelbereich innerhalb des Winkels der Abbiegung gedreht hat. Wenn der Prozess 7700 bestimmt, dass diese Abbiegung nicht fertiggestellt worden ist, kehrt der Prozess 7700 zu 7750 zurück, um fortzufahren zu überprüfen, ob die Abbiegung fertiggestellt worden ist.
Wenn der Prozess 7700 bestimmt, dass diese Abbiegung fertiggestellt worden ist, zeigt (bei 7760) der Prozess 7700 die Kartenansicht in dem ursprünglichen Ansichtsmodus an. Das heißt, der Prozess 7700 zeigt die Kartenansicht in dem Ansichtsmodus an, welchen die Kartenanwendung anzeigte, bevor sich der Abbiegung genähert wurde. Der Prozess 7700 endet dann.
Obwohl der Prozess 7700 beschrieben worden ist als einen Top-down-Modus verwendend, verwenden einigen Ausführungsformen ansonsten ähnliche oder identische Prozesse eines Nicht-top-down-Modus, welcher die Abbiegung an der Ecke leichter zu sehen ermöglicht, als jedweden Modus, in welchem die Karte vor der Annäherung an die Ecke angezeigt worden ist.
3. Virtuelle Kamerabewegung beim Schwenken
78 zeigt konzeptionell ein Beispiel einer virtuellen Kamera 7800, welche um eine 3D-Karte 7835 während einer Routennavigation schwenkt. 78 zeigt die Bewegung der virtuellen Kamera 7800 um die Region der 3D-Karte 7835 bei drei unterschiedlichen Stufen 7805–7815. Die Kartenanwendung einiger Ausführungsformen führt den Prozess 7900, welcher unten mit Verweis auf 79 beschrieben ist, aus zum Schwenken der virtuellen Kamera 7800. Wie in dieser Figur gezeigt, umfasst die Region der 3D-Karte 7835 eine Straße und mehrere Gebäude entlang der Seite der Straße.
Die erste Stufe 7805 zeigt eine Top-down-Ansicht der virtuellen Kamera 7800 bei einem speziellen Ort und Position in der 3D-Karte 7835. In einigen Ausführungsformen wird der Punkt, auf welchen die virtuelle Kamera 7800 fokussiert (d. h. der Punkt, an welchem eine Linie, die herausragt aus der Vorderseite der virtuellen Kamera, die Straße kreuzt) in der 3D-Karte 7835 bezeichnet als ein Fokuspunkt. In einigen Ausführungsformen verwendet die Kartenanwendung einen Punkt entlang der Route, welcher eine definierte Distanz (z. B. 5 Fuß, 10 Fuß, 25 Fuß, 50 Fuß, usw.) vor dem Ort des Benutzers ist (dargestellt durch einen Kreis mit einem Dreieck darauf, in diesem Beispiel) als den Fokuspunkt der virtuellen Kamera 7800. Die Kartenanwendung einiger Ausführungsformen verwendet unterschiedliche Abstände vor dem Ort des Benutzers entlang der Route basierend auf der Fahrtgeschwindigkeit des Benutzers (z. B. längere Distanzen, wenn der Benutzer bei höheren Geschwindigkeiten reist, und kürzere Distanzen, wenn der Benutzer bei geringeren Geschwindigkeiten reist).
In der ersten Stufe 7805 ist der Fokuspunkt der virtuellen Kamera 7800 ein Punkt entlang der Straße eine definierte Distanz vor dem Ort des Benutzers, wie angezeigt durch einen Kreis in der 3D-Karte 7835. Ein beispielhaftes gerendertes Bild der 3D-Karte 7835 von dem Blickpunkt der virtuellen Kamera 7800 bei der ersten Stufe 7805 ist in der 3D-Kartenansicht 7820 gezeigt.
Die zweite Stufe 7810 zeigt eine Top-down-Ansicht der virtuellen Kamera 7800 bei einem anderen Ort und Position in der 3D-Karte 7835. Wie gezeigt, hat die virtuelle Kamera 7800 hin zu der rechten Seite rotiert (zum Beispiel um die z-Achse). In diesem Beispiel rotierte die Kartenanwendung einiger Ausführungsformen automatisch die virtuelle Kamera 7800 hin zu der rechten Seite in Antwort auf eine Gesteneingabe (z. B. eine Wisch-nach-links-Geste), welche durch einen Berührungsbildschirm empfangen wurde. Ein beispielhaftes gerendertes Bild der 3D-Karte 7835 aus dem Blickpunkt der virtuellen Kamera 7800 bei dieser Stufe 7810 wird in der 3D-Kartenansicht 7825 gezeigt.
Die dritte Stufe 7815 zeigt eine Top-down-Ansicht der virtuellen Kamera 7800 bei einem anderen unterschiedlichen Ort und Position der 3D-Karte 7835. Für dieses Beispiel hat die Kartenanwendung automatisch die virtuelle Kamera zurück hin zu der linken Seite rotiert, nach einer definierten Zeitdauer (z. B. 0,5 Sekunden, 1 Sekunde, 2 Sekunden, 3 Sekunden usw.). In einigen Ausführungsformen rotiert die Kartenanwendung die virtuelle Kamera 7800 zurück nach einem definierten zurückgelegten Distanzbetrag (z. B. 10 Yards, 25 Yards, eine halbe Meile usw.). Ein beispielhaftes gerendertes Bild der 3D-Karte 7835 von dem Blickpunkt der virtuellen Kamera 7800 bei der dritten Stufe 7815 ist in der 3D-Kartenansicht 7830 gezeigt.
79 zeigt konzeptionell einen Prozess 7900 einiger Ausführungsformen zum Schwenken zu der Seite einer Kartenansicht basierend auf Gesteneingabe. In einigen Ausführungsformen führt die Kartenanwendung den Prozess 7900 aus, wenn die Kartenanwendung in einem Routennavigationsmodus ist und die Kartenanwendung eine Geste über einen Berührungsbildschirm einer Vorrichtung empfängt, auf welcher die Kartenanwendung ausgeführt wird.
Der Prozess 7900 beginnt durch Empfangen (bei 7910) einer Geste zum Schwenken zur Seite. In einigen Ausführungsformen umfasst eine Geste zum Schwenken zur Seite eine Berührungsgeste, welche durch einen Berührungsbildschirm empfangen wird (z. B. Wischen des Berührungsbildschirms zu einer Seite mit einem Finger). Alternativ oder verbindend, umfasst die Geste zum Schwenken zur Seite in einigen Ausführungsformen eine Mehrfach-Berührungsgeste (z. B. Wischen des Berührungsbildschirms zu einer Seite mit mehreren Fingern).
Als Nächstes identifiziert (bei 7920) der Prozess 7900 eine Schwenkkomponente der Schwenkgeste. Der Prozess 7900 einiger Ausführungsformen identifiziert die horizontale Komponente der Schwenkgeste als die Schwenkkomponente. In anderen Ausführungsformen identifiziert der Prozess 7900 einen Vektor, welcher von einem Ort an der ursprünglichen Berührung der Geste definiert wird (z. B. dem Ort, an welchem ein Finger den Bildschirm berührt) zu dem Ort an dem Ende der Geste (z. B. den Ort, an welchem der Finger nicht länger den Berührungsbildschirm berührt).
In einigen Ausführungsformen beschränkt der Prozess 7900 die Schwenkkomponente der Schwenkgeste. Zum Beispiel, wenn der Prozess 7900 bestimmt (bei 7930), dass die Schwenkkomponente einen Schwellenbetrag überschreitet (z. B. der Größenbetrag der Schwenkkomponente überschreitet einen Schwellenbetrag), beschränkt (bei 7940) der Prozess 7900 die Schwenkkomponente (z. B. Reduzieren der Größe der Schwenkkomponente) auf eine definierte Grenze.
Basierend auf der Schwenkkomponente, schwenkt (bei 7950) dann der Prozess 7900 eine virtuelle Kamera, welche verwendet wird zum Rendern der 3D-Kartenansichten der Route entlang der Routennavigation. Der Prozess 7900 einiger Ausführungsformen schwenkt die virtuelle Kamera in einer ähnlichen Weise wie das Schwenken der virtuellen Kamera, welches oben mit Verweis auf 78 beschrieben wird. Das heißt, der Prozess 7900 rotiert die virtuelle Kamera um die z-Achse zum Schwenken der virtuellen Kamera.
Als Nächstes bestimmt (bei 7960) der Prozess 7900, ob eine definierte Zeitdauer (z. B. 0,5 Sekunden, 1 Sekunde, 2 Sekunden, 5 Sekunden, usw.) abgelaufen ist. Wenn der Prozess 7900 bestimmt, dass die definierte Zeitmenge nicht abgelaufen ist, kehrt der Prozess 7900 zu 7960 zurück, um fortzufahren mit dem Überprüfen danach, ob die Zeitdauer abgelaufen ist. Wenn der Prozess 7900 bestimmt, dass die definierte Zeitdauer abgelaufen ist, fährt der Prozess 7900 zu 7970 fort.
Schließlich schwenkt (in 7970) der Prozess 7900 die virtuelle Kamera zurück zu ihrer ursprünglichen Position. In einigen Ausführungsformen schwenkt der Prozess 7900 die virtuelle Kamera in einer ähnlichen Weise wie das Schwenken der virtuellen Kamera, welches oben mit Verweis auf 78 beschrieben ist. In anderen Worten, rotiert der Prozess 7900 die virtuelle Kamera um die z-Achse zum Schwenken der virtuellen Kamera.
4. Virtuelle Kamerabewegung während Perspektivenanpassungen
Neben (oder anstelle von) der Steuerung der Kamera durch die Navigationsanwendung (z. B. Wechseln von 3D auf 2D beim Fahren um Ecken) erlauben einige Ausführungsformen auch dem Benutzer den Level der Kamera anzupassen. Einige Ausführungsformen erlauben dem Benutzer eine Befehlsgeste mit zwei Fingern zu machen zum Anpassen der Distanz (Höhe) und des Winkels der Kamera. Einige Ausführungsformen erlauben sogar mehrere Typen von Gesten zum Steuern der Kamera.
80 zeigt konzeptionell ein Perspektivenanpassungsmerkmal, welches durch die Kartenanwendung einiger Ausführungsformen bereitgestellt wird. Insbesondere zeigt 80 eine virtuelle Kamera 8000 bei drei unterschiedlichen Stufen 8005–8015, welche die Anpassung der Position der virtuellen Kamera 8000 zeigen, in Antwort auf eine Perspektivenanpassung. Wie gezeigt, zeigt 80 einen Ort in einer 3D-Karte 8035, welche vier Objekte umfasst, welche zwei Gebäude und zwei sich kreuzende Straßen sind.
Die erste Stufe 8005 zeigt die virtuelle Kamera 8000 bei einer ersten Perspektivenposition, welche nach unten hin zu der 3D-Karte 8035 bei einem ersten Winkel (z. B. 45 Grad) in Bezug auf den Horizont zeigt. In dieser Position zeigt die Kamera 8000 auf einen Ort, welcher eine stationäre Position der Vorrichtung oder einen Ort, welcher erkundet wird, oder eine sich bewegende Position vor einem sich bewegenden Ort der Vorrichtung sein kann, in einem Fall, wo die Karte zur Navigation verwendet wird. In einigen Ausführungsformen soll die Default-Position der Kamera 8000 bei einer speziellen Orientierung in Bezug auf den derzeitigen Ort sein, aber diese Orientierung kann modifiziert werden, wenn der Benutzer die Karte rotiert. Das Rendern einer 3D-Kartenansicht basierend auf der Position der virtuellen Kamera 8000 resultiert in der 3D-Kartenansicht 8025.
Die zweite Stufe 8010 zeigt die virtuelle Kamera 8000 bei einer unterschiedlichen zweiten Perspektivenposition, welche auf eine niedrigere Perspektive hin zu der 3D-Karte 8035 bei einem kleineren zweiten Winkel (z. B. 30 Grad) in Bezug auf den Horizont zeigt. Die Stufe 8010 zeigt auch, dass ein Benutzer Eingabe bereitgestellt hat zum Anpassen der Perspektive der Ansicht der 3D-Karte 8035 durch Berühren von zwei Fingern auf dem Bildschirm, und Ziehen der zwei Finger in einer Nach-oben-Richtung (z. B. eine Wischgeste). Das Abflachen der Szene wird erreicht dadurch, dass die virtuelle Kamera 8000 den Betrachtungswinkel in Bezug auf den Horizont absenkt und verringert. Das Rendern einer 3D-Kartenansicht unter Verwendung der virtuellen Kamera 8000, welche bei diesem Winkel positioniert ist, resultiert in einer 3D-Kartenansicht 8030, in welcher Gebäude und die Straßen größer sind als ihre Darstellung in der ersten Kartenansicht 8025. Wie durch die gestrichelte Linienversion der virtuellen Kamera 8000 angezeigt, bewegte sich die virtuelle Kamera 8000 weiter nach unten entlang des Bogens 8050, während sie sich weiter nach oben neigt (z. B. Kippen).
Die dritte Stufe 8015 zeigt die virtuelle Kamera 8000 bei einer unterschiedlichen dritten Perspektivenposition, welche bei einer höheren Perspektive hin zu einem Ort (z. B. dem Fokuspunkt der virtuellen Kamera 8000) auf der 3D-Karte 8035 bei einem größeren dritten Winkel (z. B. 80°) in Bezug auf den Horizont zeigt. Die Stufe 8015 zeigt auch, dass der Benutzer Eingabe zum Anpassen der Perspektive der Ansicht der 3D-Karte 8035 bereitgestellt hat durch Berühren von zwei Fingern auf dem Bildschirm und ziehen der zwei Finger in einer Nach-unten-Richtung (z. B. eine Wischgeste). Das Absenken der Szene wird erreicht dadurch, dass die virtuelle Kamera 8000 aufsteigt und ihren Winkel in Bezug auf den Horizont erhöht. Wie gezeigt bei dieser Stufe 8015 in einigen Ausführungsformen flacht die Kartenanwendung die Gebäude (z. B. reduziert die z-Achsenkomponente der Polygone zu der Bodenebene) in der 3D-Karte 8035 ab, wenn die virtuelle Kamera 8000 in einer Top-down- oder nahezu Top-down-Position positioniert ist, so dass die 3D-Kartenansichten, welche unter Verwendung der virtuellen Kamera 8000 gerendert werden, 2D erscheinen. Das Rendern einer 3D-Kartenansicht unter Verwendung der virtuellen Kamera 8000, welche bei dem Winkel in der dritten Stufe 8015 positioniert ist, resultiert in einer 3D-Kartenansicht 8040, in welcher die Gebäude kleiner, flacher erscheinen und die Straßen kleiner als ihre Darstellung in der zweiten Kartenansicht 8030 erscheinen. Wie durch die Gestrichelte-Linien-Version der virtuellen Kamera 8000 gezeigt, hat sich die virtuelle Kamera 8000 weiter nach oben entlang des Bogens 8050 bewegt, während sie weiter nach unten geneigt wurde (z. B. Kippen).
In einigen Ausführungsformen kann die virtuelle Kamera 8000 dazu gebracht werden, sich auf diese Weise zu bewegen, wenn die Kartenanwendung Eingabe empfängt zum Anpassen der Perspektive der Betrachtung der 3D-Karte 8035. In einigen dieser Ausführungsformen wechselt die Kartenanwendung zu einem Top-down-Modus (wo die Rendering-Position nach gerade unten blickt), was 2D-Kartenansichten erzeugt, wenn der Zoom-Level einen speziellen Herauszoom-Level erreicht.
80 zeigt eine virtuelle Kamera, welche sich entlang eines speziellen Pfads entlang eines Bogens bewegt. Die Kartenanwendung unterschiedlicher Ausführungsformen bewegt die virtuelle Kamera entlang unterschiedlicher Pfade beim Anpassen der Perspektive der virtuellen Kamera. Zum Beispiel, in einigen Ausführungsformen verwendet die Kartenanwendung einen speziellen Bogen ähnlich zu dem Bogen, welcher in 80 gezeigt ist, außer dass der spezielle Bogen weiter weg und oben ist (z. B. zoomt heraus), während die virtuelle Kamera sich nach oben entlang des Bogens bewegt, und näher (z. B. zoomt herein) und unten ist, während die virtuelle Kamera sich nach unten entlang des Bogens bewegt. In einigen Ausführungsformen verwendet die Kartenanwendung einen Pfad für die virtuelle Kamera, welcher sich horizontal abflacht, während die virtuelle Kamera sich nach oben entlang des Bogens bewegt. Andere Pfade, auf welchen die virtuelle Kamera sich bewegt, sind in anderen Ausführungsformen möglich.
Während des Bewegens entlang einer dieser Bögen, rotiert die virtuelle Kamera zum Beibehalten eines gewünschten Orts auf der Karte bei dem Fokuspunkt der Kamera. Der gewünschte Ort ist in einigen Fällen ein stationärer Ort der Vorrichtung oder ein stationärer Ort, welchen der Benutzer auf der Karte sucht. In anderen Fällen ist der gewünschte Ort ein sich bewegender Ort, vor dem sich bewegenden Ort der Vorrichtung, während der Benutzer sich mit der Vorrichtung bewegt.
81 zeigt konzeptionell einen Prozess 8100 einiger Ausführungsformen zum Anpassen der Position einer virtuellen Kamera, welche verwendet wird zum Rendern einer Kartenansicht in Antwort auf eine Perspektivenanpassung. In einigen Ausführungsformen führt die Kartenanwendung, welche oben und unten mit Verweis auf 1 bis 108 beschrieben wird, den Prozess 8100 aus, wenn die Kartenanwendung in einem Kartenbetrachtungsmodus ist (z. B. ein Orts-Browsing-Modus, ein Navigationsmodus, usw.) und die Kartenanwendung eine Geste über einen Berührungsbildschirm einer Vorrichtung empfängt, auf welcher die Kartenanwendung ausgeführt wird.
Der Prozess 8100 beginnt durch Empfangen (bei 8110) einer Geste zum Anpassen der Perspektive einer Kartenansicht. In einigen Ausführungsformen umfasst eine Geste zum Anpassen der Perspektive der Kartenansicht eine Mehrfach-Berührungsgeste, welche über einen Berührungsbildschirm empfangen wird (z. B. simultanes Berühren des Berührungsbildschirms mit mehreren Fingern), wie diejenigen, welche oben mit Verweis auf 80 beschrieben sind. In diesem Beispiel empfängt der Prozess 8100 eine Zwei-Berührungs-Wischgeste.
Als Nächstes bestimmt (bei 8120) der Prozess 8100, ob ein Winkel basierend auf Berührungspunkten innerhalb eines Schwellenwinkels ist. In einigen Ausführungsformen wird der Winkel durch (1) einen ersten Vektor von dem Ort eines der Berührungspunkte hin zu dem Ort des anderen Berührungspunkts, und durch (2) einen zweiten Vektor von dem Ort des einen Berührungspunkts hin zu einer horizontalen Richtung definiert. Die horizontale Richtung einiger Ausführungsformen basiert auf der Orientierung der Vorrichtung, während die horizontale Richtung anderer Ausführungsformen auf der Orientierung der Anzeige der Vorrichtung basiert.
Wenn der Prozess 8100 bestimmt, dass der Winkel innerhalb des Schwellenwinkels ist, endet der Prozess 8100. Ansonsten identifiziert (bei 8130) der Prozess 8100 eine Translationskomponente der empfangenen Geste. In einigen Ausführungsformen identifiziert der Prozess 8100 die Translationskomponente der Geste durch Identifizieren einer Menge von vertikaler Translation der Berührungspunkte der Geste.
Der Prozess 8100 passt (bei 8140) dann die Perspektive der Kartenansicht basierend auf der identifizierten Translation an. Wie oben erklärt mit Verweis auf 3–5 und 74–80, wird eine virtuelle Kamera in einigen Ausführungsformen verwendet zum Rendern einer Kartenansicht. Der Prozess 8100 einiger Ausführungsformen passt die Perspektive der Kartenansicht an durch Anpassen der Position und Orientierung der virtuellen Kamera. In einigen Ausführungsformen verursacht eine nach-unten vertikale Translation, dass die Position der virtuellen Kamera in der Höhe erhöht wird und in der Neigung verringert wird (z. B. zeigt weiter nach unten), während der Fokuspunkt der virtuellen Kamera beibehalten wird (z. B. der Punkt, an welchem der Vorwärtsvektor der virtuellen Kamera sich mit dem Boden schneidet). Anders ausgedrückt, bewegt sich die Kamera entlang eines Bogens und rotiert mehr nach unten, während die Kamera sich nach oben entlang auf dem Bogen bewegt.
Unterschiedliche Ausführungsformen verwenden unterschiedliche Koordinatenräume für eine Karte. Zum Beispiel verwendet die Karte einiger Ausführungsformen einen Mercator-Einheitskoordinatenraum. In solchen Ausführungsformen passt der Prozess 8100 die Position der virtuellen Kamera in Bezug auf die Karte an, um die Perspektive der Kartenansicht anzupassen. Als ein anderes Beispiel in einigen Ausführungsformen verwendet die Karte ein World Geodetic System (z. B. WGS 84) als den Koordinatenraum der Karte. Der Prozess 8100 passt in solchen Ausführungsformen die Karte in Bezug auf die Position der virtuellen Kamera an, um die Perspektive der Kartenansicht anzupassen.
In einigen Ausführungsformen verursacht eine nach oben vertikale Translation, dass die Position der virtuellen Kamera in der Höhe abnimmt und in der Neigung zunimmt (z. B. zeigt weiter nach oben), während der Fokuspunkt der virtuellen Kamera beibehalten wird (z. B. der Punkt, an welchem der Vorwärtsvektor der virtuellen Kamera den Boden schneidet). Das heißt, die Kamera bewegt sich entlang eines Bogens und rotiert mehr nach oben, während die Kamera sich nach unten entlang des Bogens bewegt. In unterschiedlichen Ausführungsformen verursacht die vertikale Translation unterschiedliche Anpassungen der Position der virtuellen Kamera. Zum Beispiel kann eine nach unten vertikale Translation verursachen, dass die Position der virtuellen Kamera in der Höhe abnimmt und in der Neigung zunimmt, während der Fokuspunkt der virtuellen Kamera beibehalten wird, und eine nach oben vertikale Translation kann verursachen, dass die Position der virtuellen Kamera in der Höhe zunimmt und in der Neigung abnimmt, während der Fokuspunkt der virtuellen Kamera beibehalten wird.
Schließlich rendert (bei 8150) der Prozess 8100 eine Kartenansicht zur Anzeige basierend auf der angepassten Perspektive der Kartenansicht. Der Prozess 8100 endet dann.
Wie oben beschrieben, zeigt der Prozess, welcher in 81 gezeigt ist, eine Anpassung einer Perspektive einer Kartenansicht basierend auf Gesteneingabe. Der Prozess einiger Ausführungsformen beschränkt die Bewegungsreichweite der virtuellen Kamera. Wenn die Gesteneingabe verursacht, dass die Position der virtuellen Kamera einen definierten Bereich überschreitet, modifiziert der Prozess einiger Ausführungsformen die Position der virtuellen Kamera, innerhalb des definierten Bereichs zu sein. In einigen solchen Ausführungsformen rendert der Prozess die Kartenansicht der Position der virtuellen Kamera, selbst wenn die Position der virtuellen Kamera den definierten Bereich während der Gesteneingabe überschreitet (z. B. Finger, welche für Berührungspunkte verwendet werden, berühren immer noch den Berührungsbildschirm). Der Prozess rendert die Kartenansicht der Position der virtuellen Kamera, welche innerhalb des definierten Bereich modifiziert wird, wenn die Gesteneingabe fertiggestellt ist (z. B. Finger, welche verwendet werden für Berührungspunkte, berühren nicht länger den Berührungsbildschirm). In einigen Ausführungsformen, wenn die Gesteneingabe fertiggestellt ist, zeigt der Prozess eine Animation an, welche von der Kartenansicht der Position der virtuellen Kamera, welche den definierten Bereich überschreitet, zu der Kartenansicht der Position der virtuellen Kamera, welche innerhalb der definierten Reichweite modifiziert wird, „schnappt” (snap). In einigen Ausführungsformen können solch eine Animation und das Beschränkungsmerkmal bezeichnet werden als ein Offset-Gummibandmerkmal oder -effekt.
Wie in 80 gezeigt, rendern unterschiedliche virtuelle Kamerapositionen unterschiedliche Perspektiven einer Kartenansicht. Insbesondere zeigt die 80, dass die Kartenansicht von einer 3D-Kartenansicht zu einer 2D-Kartenansicht übergeht. Bei den unterschiedlichen Stufen des Übergangs scheinen die Gebäude in den Boden zu fallen. In ähnlicher Weise, während eines Übergangs der Kartenansicht von der 2D-Ansicht in der dritten Stufe 8015 zu der 3D-Kartenansicht in der ersten Stufe 8005, würden die Gebäude scheinen, als ob sie aus dem Boden aufsteigen. In einigen Ausführungsformen skaliert die Kartenanwendung die Knoten der Gebäude entlang der z-Achse, um zu veranlassen, dass das Gebäude aufzusteigen und zu fallen scheint, wenn die Kartenansicht zwischen 2D-ähnlichen Kartenansichten und unterschiedlichen Perspektiven von 3D-Kartenansichten übergeht. Das Folgende ist ein Beispiel einer Gleichung, welche verwendet wird durch die Kartenanwendung einiger Ausführungsformen, um einen Knoten entlang der z-Achse zu skalieren: new_scaled_vertex.z = scaled_vertex.z·u_scale wobei scaled_vertex.z die z-Komponente eines Knotens ist, u_scale ist ein Skalierungsfaktor, welcher einen Betrag zur Skalierung bestimmt, und new_scaled_vertex.z der neu skalierte Wert der z-Komponente des Knotens ist. Zusätzlich beim Hereinzoomen/Herauszoomen der 3D-Karte oder sich um die 3D-Karte bewegen, interpolieren einige Ausführungsformen die Alpha-Werte, welche verwendet werden zum Ein- und Ausblenden von Gebäuden, und interpolieren die Skalierungswerte, welche verwendet werden zum Anpassen der Höhe der Gebäude.
Wie oben erklärt, zeigt 80 einige Beispiel-Perspektivenanpassungsoperationen und die entsprechende Bewegung einer virtuellen Kamera in einer 3D-Karte, welche verwendet wird zum Rendern der 3D-Kartenansichten der 3D-Karte. Der Fachmann wird verstehen, dass jede Anzahl von unterschiedlichen perspektivischen Anpassungen möglich ist. Zusätzlich führt die Kartenanwendung einiger Ausführungsformen perspektivische Anpassungsoperationen aus in Antwort auf zusätzliche und/oder unterschiedliche Typen von Eingabe. Zum Beispiel in einigen Ausführungsformen, kann das Ziehen der zwei Finger nach unten die Perspektivenposition der virtuellen Kamera verringern, und Ziehen der zwei Finger nach oben kann die Perspektivenposition der virtuellen Kamera erhöhen.
Während 80 eine virtuelle Kamera zeigt, welche sich entlang eines Bogens bewegt, um die Perspektivenposition der virtuellen Kamera zu ändern, bewegt die Kartenanwendung einiger Ausführungsformen die virtuelle Kamera entlang unterschiedlicher Bögen bei unterschiedlichen Zoom-Leveln (z. B. Distanzen von einer 3D-Karte). 82 zeigt konzeptionell eine virtuelle Kamera 8210, welche entlang dreier verschiedener Bögen 8215–8225 bei drei unterschiedlichen Zoom-Leveln bewegbar ist. Wie gezeigt, zeigt die 82 einen Ort in einer 3D-Karte 8205, welcher zwei Gebäude und zwei Straßen umfasst, welche eine T-Verkehrskreuzung bilden.
Bei Zoom-Level 18, dem niedrigsten Zoom-Level in diesem Beispiel, ist die virtuelle Kamera 8210 entlang des Bogens 8215 für unterschiedliche Perspektivenpositionen der virtuellen Kamera 8210, welche zu der 3D-Karte 8205 zeigt, bewegbar. In anderen Worten, erlaubt die Kartenanwendung einiger Ausführungsformen bei diesem Zoom-Level einem Benutzer, die Perspektive für die Betrachtung der 3D-Karte 8205 innerhalb des Bereichs (z. B. einem Winkelbereich von 20 Grad) anzupassen, den die virtuelle Kamera 8210 entlang des Bogens 8215 bewegbar ist.
Wenn die virtuelle Kamera 8210 von dem Zoom-Level 19 (z. B. herauszoomen) übergeht, beschränkt die Kartenanwendung den Bereich der Perspektivenpositionen der virtuellen Kamera 8200 auf den Bereich entlang des Bogens 8215. In einigen Ausführungsformen positioniert die Kartenanwendung die virtuelle Kamera 8210 entlang der Position entlang des Bogens 8215, welche der Position entspricht, in welcher die virtuelle Kamera 8210 entlang des Bogens 8220 bei dem Zoom-Level 19 war vor dem Übergehen zu Zoom-Level 18. Wenn die Position der virtuellen Kamera 8210 bei dem Zoom-Level 19 den Bereich des Bogens 8215 überschreitet (z. B. eine Position entlang des unteren Perspektivenendes des Bogens 8220) beim Übergehen von Zoom-Level 19 zu Zoom-Level 18, positioniert die Kartenanwendung in einigen Ausführungsformen die virtuelle Kamera an der nächstmöglichen Position. In anderen Ausführungsformen bewegt die Kartenanwendung graduell die virtuelle Kamera 8210 hin zu der nächsten entsprechenden Position auf dem Bogen 8215 während in einer Übergangsregion zwischen Zoom-Leveln 18 und 19, beim Übergehen von dem Zoom-Level 19 zu dem Zoom-Level 18, um einen weichen Übergang der Bewegung der virtuellen Kamera 8210 von dem Zoom-Level 19 zu dem Zoom-Level 18 bereitzustellen.
Bei dem nächsten Zoom-Level 19 ist die virtuelle Kamera 8210 bewegbar entlang des Bogens 8220 für unterschiedliche Perspektivenpositionen der virtuellen Kamera 8210, welche hin zu der 3D-Karte 8205 zeigt. Wie gezeigt in einigen Ausführungsformen, erlaubt die Kartenanwendung bei diesem Zoom-Level dem Benutzer, die Perspektive zum Betrachten der 3D-Karte 8205 innerhalb des Bereichs (z. B. einem Winkelbereich von 45 Grad) anzupassen, den die virtuelle Kamera 8210 entlang des Bogens 8220 bewegbar ist. Somit erlaubt die Kartenanwendung der virtuellen Kamera 8210, entlang eines größeren Bereichs bei dem Zoom-Level 19 im Vergleich zum Zoom-Level 18 zu bewegen.
Wenn die virtuelle Kamera 8210 von dem Zoom-Level 18 oder dem Zoom-Level 20 (z. B. zoomt herein oder heraus) übergeht, begrenzt die Kartenanwendung den Bereich der Perspektivenpositionen der virtuellen Kamera 8200 auf den Bereich entlang des Bogens 8220. Die Kartenanwendung einiger Ausführungsformen positioniert die virtuelle Kamera 8210 entlang einer Position entlang des Bogens 8220, der der Position entspricht, bei der die virtuelle Kamera 8210 war, entlang des Bogens 8215 oder 8225 bei dem Zoom-Level 18 bzw. 20, vor dem Übergehen zu Zoom-Level 19. Wenn die Position der virtuellen Kamera 8210 bei dem Zoom-Level 20 den Bereich des Bogens 8220 überschreitet (z. B. eine Position entlang des unteren Perspektivenendes des Bogens 8225) beim Übergehen von dem Zoom-Level 20 zu dem Zoom-Level 19, positioniert in einigen Ausführungsformen die Kartenanwendung die virtuelle Kamera an der nächstmöglichen Position. Die Kartenanwendung anderer Ausführungsformen bewegt graduell die virtuelle Kamera 8210 hin zu der nächsten entsprechenden Position auf dem Bogen 8220, während in einer Übergangsregion zwischen Zoom-Level 19 und 20 befindlich, beim Übergehen von Zoom-Level 20 zu Zoom-Level 19, um einen weichen Übergang der Bewegung der virtuellen Kamera 8210 von dem Zoom-Level 20 zu dem Zoom-Level 19 bereitzustellen.
Bei dem Zoom-Level 20, dem höchsten Zoom-Level für dieses Beispiel, ist die virtuelle Kamera 8210 bewegbar entlang des Bogens 8225 für unterschiedliche Perspektivenpositionen der virtuellen Kamera 8210, welche hin zu der 3D-Karte 8205 zeigt. Das heißt, die Kartenanwendung in einigen Ausführungsformen bei diesem Zoom-Level erlaubt dem Benutzer, die Perspektive für die Betrachtung der 3D-Karte 8205 innerhalb des Bereichs (z. B. einem Winkelbereich von 85 Grad) anzupassen, den die virtuelle Kamera 8210 entlang des Bogens 8225 bewegbar ist. Somit erlaubt die Kartenanwendung der virtuellen Kamera 8210, entlang eines größeren Bereichs bei dem Zoom-Level 20 als bei den Zoom-Leveln 18 und 19 zu bewegen. Wenn die virtuelle Kamera 8210 von dem Zoom-Level 19 (z. B. zoomt herein) übergeht, beschränkt die Kartenanwendung den Bereich der Perspektivenpositionen der virtuellen Kamera 8200 auf den Bereich entlang des Bogens 8225.
Die oben beschriebene 82 zeigt ein Beispiel einer virtuellen Kamera, welche bewegbar entlang unterschiedlicher Bögen bei unterschiedlichen Zoom-Leveln ist, welche unterschiedliche Bereiche von Perspektivenpositionen für die virtuelle Kamera erlauben. Der Fachmann wird erkennen, dass die Kartenanwendung unterschiedlicher Ausführungsformen irgendeine Anzahl von unterschiedlichen Bögen mit Zahlenbereichen von Perspektivenpositionen für die virtuelle Kamera bei unterschiedlichen Zoom-Leveln verwendet.
83 zeigt konzeptionell einen Prozess 8300 einiger Ausführungsformen zum Bestimmen eines Bogens, entlang welchem eine virtuelle Kamera bewegbar ist. In einigen Ausführungsformen führt die Kartenanwendung, welche oben und unten mit Verweis auf 1 bis 108 in dieser Anmeldung beschrieben ist, den Prozess 8300 aus, wenn ein Zoom-Level angepasst wird (z. B. hereinzoomen oder herauszoomen) in einem 3D-Ansichtsmodus (z. B. einem 3D Navigationsmodus, einem 3D-Karten-Browsing-Modus, usw.).
Der Prozess 8300 startet durch Bestimmen (bei 8310), ob der derzeitige Zoom-Level auf einen neuen Zoom-Level angepasst ist. In einigen Ausführungsformen bestimmt der Prozess 8300, dass der derzeitige Zoom-Level auf einen neuen Zoom-Level angepasst wird, wenn der Prozess 8300 Eingabe empfängt zum Anpassen des Zoom-Levels einer Ansicht einer 3D-Karte (z. B. die Typen von Eingabe, welche unten mit Verweis auf 85 beschrieben sind). Wenn der Prozess 8300 bestimmt, dass der derzeitige Zoom-Level nicht angepasst ist, kehrt der Prozess 8300 zu 8310 zurück zum Fortfahren, nach einer Anpassung auf einen neuen Zoomlevel zu prüfen.
Wenn der Prozess 8300 bestimmt, dass eine Anpassung auf einen neuen Zoom-Level empfangen wird, identifiziert (bei 8320) der Prozess 8300 einen Bogen für den neuen Zoom-Level. Wie oben beschrieben, verwendet die Kartenanwendung einiger Ausführungsformen unterschiedliche Bögen bei unterschiedlichen Zoom-Leveln. Als solchen identifiziert der Prozess 8300 den Bogen, welcher für den neuen Zoom-Level definiert ist.
Als Nächstes bestimmt (bei 8330) der Prozess 8300, ob der Bogen für den neuen Zoom-Level eine Position hat, welche der Position der virtuellen Kamera entlang des vorherigen Bogens des vorherigen Zoom-Levels entspricht. Der Prozess 8300 einiger Ausführungsformen bestimmt, dass der Bogen für den neuen Zoom-Level eine entsprechende Position hat, wenn die Position der virtuellen Kamera entlang des vorherigen Bogens innerhalb des Winkelbereichs des Bogens für den neuen Zoom-Level ist. Bezug nehmend auf 82 als ein Beispiel, wenn der Zoom-Level von dem Zoom-Level 19 zu dem Zoom-Level 18 übergeht, bestimmt der Prozess 8300, dass der Bogen 8215 für den Zoom-Level 18 eine entsprechende Position hat, wenn die Position der virtuellen Kamera entlang des Bogens 8220 für den Zoom-Level 19 innerhalb ungefähr des oberen Drittels des Bogens 8220 ist.
Nach Bestimmen, dass der Bogen für den neuen Zoom-Level eine entsprechende Position hat, identifiziert (bei 8340) der Prozess 8300 die entsprechende Position entlang des Bogens für den neuen Zoom-Level als neue Position für die virtuelle Kamera. Ansonsten identifiziert (bei 8350) der Prozess 8300 die Position entlang des Bogens für den neuen Zoom-Level, welche die nächste zu der Position der virtuellen Kamera entlang des vorherigen Bogens des vorherigen Zoom-Levels ist, als die neue Position für die virtuelle Kamera. Bezug nehmend auf 82 als ein Beispiel, wenn die Position der virtuellen Kamera an dem unteren Perspektivenende des Bogens 8220 ist, wie gezeigt in 82, beim Übergehen von dem Zoom-Level 19 zu dem Zoom-Level 18, identifiziert der Prozess 8300 die Position der virtuellen Kamera, welche in 82 gezeigt ist, entlang des Bogens 8215 für den Zoom-Level 18 als die neue Position für die virtuelle Kamera.
Schließlich positioniert (bei 8360) der Prozess 8300 die virtuelle Kamera an der identifizierten neuen Position entlang des Bogens für den neuen Zoom-Level. Der Prozess 8300 endet dann.
Während 82 und 83 eine virtuelle Kamera beschreiben, welche bewegbar entlang unterschiedlicher Bögen unterschiedlicher Zoom-Level ist, verwenden einige Ausführungsformen einen speziellen Bogen für einen Bereich von unterschiedlichen Zoom-Leveln (z. B. einen Bogen für Zoom-Level 10–13, einen Bogen für Zoom-Level 14–16, usw.). In einigen Ausführungsformen werden unterschiedliche Bereiche von Zoom-Leveln definiert, die gleiche oder eine unterschiedliche Anzahl von Zoom-Leveln zu umfassen.
Wie oben diskutiert in einigen Ausführungsformen, verwendet die Kartenanwendung einen speziellen Bogen, entlang welchem eine virtuelle Kamera innerhalb eines speziellen definierten Winkelbereichs entlang des Bogens bewegbar ist, wenn die virtuelle Kamera bei einem speziellen Zoom-Level positioniert ist. Die Kartenanwendungen einiger Ausführungsformen verwenden die folgende Technik zum Bewegen der virtuellen Kamera entlang eines Bogens.
84 zeigt konzeptionell ein Merkmal, welches durch die Kartenanwendung einiger Ausführungsformen bereitgestellt wird, zum Beibehalten der Position einer virtuellen Kamera innerhalb eines definierten Bereichs entlang eines Bogens. Insbesondere zeigt 84 die virtuelle Kamera 8400 bei drei unterschiedlichen Stufen 8405–8415, welche die Position der virtuellen Kamera 8400 zeigen, welche innerhalb eines definierten Bereichs des Bogens 8450 behalten wird. Wie in 84 gezeigt, umfasst ein Ort in einer 3D-Karte 8435 zwei Gebäude und zwei Straßen, welche eine T-Kreuzung bilden.
Die erste Stufe 8405 zeigt die virtuelle Kamera 8400 bei einer speziellen Position entlang des Bogens 8450. Wie gezeigt, stellt der Bogen 8450 einen definierten Bereich (z. B. Winkelbereich) dar, innerhalb welchem die virtuelle Kamera 8400 bewegbar ist. Die erste Stufe 8405 zeigt auch drei Positionen 8455–8465 entlang des Bogens 8450 (z. B. perspektivische Ansichtswinkel). In diesem Beispiel bewegt die Kartenanwendung die virtuelle Kamera 8400 entlang des Bogens 8450 zwischen dem Hochperspektivenende des Bogens 8450 (z. B. die Position entlang des Bogens 8450, wenn die virtuelle Kamera 8400 am meisten nach unten geneigt ist) und der Position 8455 in einer Weise ähnlich zu der, welche mit Verweis auf 80 oben beschrieben ist. Das Rendern einer 3D-Kartenansicht, basierend auf der Position der virtuellen Kamera 8400 in der ersten Stufe 8405 resultiert in der 3D-Kartenansicht 8425.
Wenn die virtuelle Kamera 8400 die Position 8455 passiert während sie sich zu dem unteren perspektivischen Ende des Bogens 8450 bewegt, verringert die Kartenanwendung die Geschwindigkeit (z. B. verlangsamen), so dass die virtuelle Kamera 8400 sich zu dem niedrigen perspektivischen Ende des Bogens 8450 ungeachtet der durch den Benutzer bereitgestellten Eingabe, bewegt. In einigen Ausführungsformen reduziert die Kartenanwendung die Geschwindigkeit der virtuellen Kamera 8400 in einer konstanten Rate, während in einigen Ausführungsformen die Kartenanwendung die Geschwindigkeit der virtuellen Kamera 8400 in einer exponentiellen Rate reduziert. Zusätzliche und/oder unterschiedliche Verfahren zum Verringern der Geschwindigkeit der virtuellen Kamera 8400 werden in einigen Ausführungsformen verwendet.
Die zweite Stufe 8410 zeigt, dass sich die virtuelle Kamera 8400 zu einer Position entlang des Bogens 8450 zu oder nahe des niedrigen perspektivischen Endes des Bogens 8450 bewegt hat. Wie gezeigt stellt ein Benutzer eine Eingabe bereit, um die Perspektive der Ansicht der 3D-Karte 8435 einzustellen durch Berührung des Bildschirms mit zwei Fingern und Ziehen der zwei Finger in eine Aufwärtsrichtung (z. B. eine Wischgeste). Als Antwort auf die Eingabe bewegt die Kartenanwendung die virtuelle Kamera 8400 zu dem niedrigen perspektivischen Ende des Bogens 8450, während die virtuelle Kamera 8450 aufwärts geneigt wird. Wenn die virtuelle Kamera die Position 8465 entlang des Bogens 8450 erreicht, hindert die Kartenanwendung die virtuelle Kamera 8400 daran, sich niedriger und jenseits der Position 8465 zu bewegen, während der Benutzer weiterhin die Eingabe zur Verringerung der Perspektive der Ansicht der 3D-Karte 8435 bereitstellt (z. B. zieht der Benutzer weiterhin mit zwei Fingern aufwärts auf dem Berührungsbildschirm).
In einigen Ausführungsformen, wenn der Benutzer aufhört, Eingaben zum Verringern der Perspektive der Ansicht der 3D-Karte 8435 bereitzustellen (z. B. der Benutzer hebt die beiden Finger von dem Berührungsbildschirm), ”federt” oder ”schnappen” (snap) die Kartenanwendung die Position der virtuellen Kamera 8400 von der Position 8465 auf zu der Position 8460 entlang des Bogens 8450. Da die Kartenanwendung 3D-Kartenansichten der 3D-Karte 8435 basierend auf der Ansicht der virtuellen Kamera 8400 während der Feder- oder Schnappbewegung generiert oder rendert, stellt die generierte 3D-Kartenansicht eine Federanimation bereit, die die 3D-Kartenansicht kurz hinunterfedernd oder -schnappend anzeigt, um dem Benutzer anzugeben, dass die Perspektive der Kartenansicht nicht weiter verringert werden kann. Rendern einer 3D-Kartenansicht unter Verwendung der in diesem Winkel positionierten virtuellen Kamera 8400 resultiert in einer 3D-Kartenansicht 8430, in welcher die Gebäude und die Straßen verglichen mit der Kartenansicht 8425 größer sind.
Die dritte Stufe 8415 zeigt die virtuelle Kamera 8400 nachdem die Kartenanwendung die Position der virtuellen Kamera 8400 zu der Position 8460 in Antwort auf das Beenden der Bereitstellung von Eingaben durch den Benutzer, federte oder schnappte. Unterschiedliche Ausführungsformen verwenden unterschiedliche Techniken zur Implementierung des Federns oder Schnappens der virtuellen Kamera 8400. Zum Beispiel startet die Kartenanwendung einiger Ausführungsformen schnell die virtuelle Kamera 8400 entlang des Bogens 8450 für eine definierte Distanz oder bis die virtuelle Kamera 8400 eine definierte Geschwindigkeit erreicht hat, zu beschleunigen. Dann verlangsamt die Kartenanwendung die virtuelle Kamera 8400 für die verbleibende Distanz zu der Position 8460 entlang des Bogens 8450. Andere Möglichkeiten, um den Feder- oder Schnappeffekt zu implementieren, werden in einigen Ausführungsformen verwendet. Rendern einer 3D-Kartenansicht unter Benutzung der virtuellen Kamera 8400, welche an der Position 8460 entlang des Bogens 8450 in der dritten Stufe 8415 positioniert ist, resultiert in einer 3D-Kartenansicht 8440, in welcher die Gebäude etwas kleiner und flacher und die Straßen etwas kleiner verglichen mit der Kartenansicht 8430 erscheinen.
Wie oben beschrieben veranschaulicht 84 eine Technik zum Verhindern, dass sich eine virtuelle Kamera jenseits des niedrigen perspektivischen Endes eines Bogens bewegt. Alternativ oder in Verbindung mit der Verhinderung, dass sich die virtuelle Kamera jenseits des niedrigen perspektivischen Endes des Bogens bewegt, verwendet die Kartenanwendung einiger Ausführungsformen eine ähnliche Technik zum Verhindern, dass sich die virtuelle Kamera jenseits des hohen perspektivischen Endes des Bogens bewegt. Zusätzlich zeigt 84 ein Beispiel einer Position entlang eines Bogens, an welcher eine virtuelle Kamera abzubremsen ist, eine Position entlang des Bogens, um eine virtuelle Kamera am Vorbeigehen zu hindern und eine Position entlang des Bogens, zu welcher die virtuelle Kamera zurückschnappt oder -federt. Unterschiedliche Ausführungsformen definieren die Positionen in beliebig vielen unterschiedlichen Arten. Zum Beispiel ist in einigen Ausführungsformen die Position entlang des Bogens, an welcher die virtuelle Kamera abgebremst wird, die gleiche oder nahe der Position entlang des Bogens, an welcher die virtuelle Kamera zurückschnappt oder -federt.
5. Virtuelle Kamerabewegung während des Zoomens
Alternativ oder in Verbindung mit dem Perspektivenanpassungsmerkmal erlaubt die Kartenanwendung einiger Ausführungsformen dem Benutzer, in die Ansicht der 3D-Karte hereinzuzoomen und aus dieser herauszuzoomen (z. B. durch Bereitstellen von Gesteneingabe mit zwei Fingern). 85 zeigt ein Zoom-Anpassungsmerkmal, welches durch die Kartenanwendung einiger Ausführungsformen bereitgestellt wird. Insbesondere zeigt 85 eine virtuelle Kamera 8512 bei drei unterschiedlichen Stufen 8501–8503, welche die Bewegung der virtuellen Kamera 8512 in Antwort auf Zoom-Anpassungen zeigen. Wie gezeigt, zeigt 85 einen Ort in einer 3D-Karte 8510, welcher zwei Gebäude und zwei Straßen enthält, welche eine T-Kreuzung bilden.
In der ersten Stufe 8501 zeigt die eine 3D-Karte 8510 mit einer virtuellen Kamera 8512 bei einer speziellen Position, welche hin zu der 3D-Karte 8510 zeigt. In dieser Position zeigt die Kamera 8512 auf einen Ort, welcher eine stationäre Position der Vorrichtung oder ein Ort, welcher erkundet wird, sein kann, oder eine sich bewegende Position vor einem sich bewegenden Ort der Vorrichtung in einem Fall, wo die Karte zur Navigation verwendet wird. Das Rendern einer 3D-Kartenansicht, basierend auf den Positionsergebnissen der virtuellen Kamera 8512, resultiert in der 3D-Kartenansicht 8514. Die zweite Stufe 8502 zeigt die virtuelle Kamera 8512 bei einer unterschiedlichen Zoom-Level-Position, welche hin zu der 3D-Karte 8510 zeigt. Die Stufe 8502 zeigt, dass ein Benutzer Eingabe bereitgestellt hat, um den Zoom-Level der Ansicht der 3D-Karte 8510 zu erhöhen, durch Berühren von zwei Fingern nahe zueinander auf dem Bildschirm der Vorrichtung und Bewegen der Fingerspitzen weg voneinander, während die Finger den Bildschirm berühren (z. B. eine Spreiz-Geste).
Die Hereinzoomen-Anpassung wird dadurch erreicht, dass die virtuelle Kamera 8512 sich näher zu der 3D-Karte 8510 entlang einer Linie 8550 bewegt. In einigen Ausführungsformen ist die Linie 8550, welche die Kartenanwendung verwendet, um die virtuelle Kamera 8512 entlang dieser zu bewegen, eine Linie, welche durch die Vorderseite der virtuellen Kamera 8512 und den Fokuspunkt der virtuellen Kamera 8512 gebildet wird. Die Kartenanwendung einiger Ausführungsformen bewegt die virtuelle Kamera 8512 entlang einer Linie, welche durch die Vorderseite der virtuellen Kamera 8512 und einen Ort in der 3D-Karte 8510, basierend auf der Eingabe des Benutzers zum Hereinzoomen in die Ansicht der 3D-Karte 8510 gebildet wird.
Das Rendern einer 3D-Kartenansicht unter Verwendung der virtuellen Kamera 8512 bei dieser Position resultiert in einer 3D-Kartenansicht 8524, in welcher die Gebäude und die Straßen näher als die Position, welche in der 3D-Kartenansicht 8514 gezeigt ist, erscheinen. Wie durch die Gestrichelte-Linien-Version der virtuellen Kamera 8512 angedeutet, bewegt die virtuelle Kamera 8512 sich näher hin zu der 3D-Karte 8510 entlang der Linie 8550.
Die dritte Stufe 8503 zeigt die virtuelle Kamera 8512 bei einer unterschiedlichen Zoom-Level-Position, welche hin zu der 3D-Karte 8510 zeigt. In dieser Stufe 8503 hat der Benutzer Eingabe bereitgestellt zum Verringern des Zoom-Levels der 3D-Karte 8510 durch Berühren von zwei Fingern weit weg voneinander auf dem Bildschirm der Vorrichtung und näher zueinander Bewegen der Fingerspitzen, während die Finger den Bildschirm berühren (z. B. eine Kneif(pinch)-Geste).
Die Herauszoomen-Anpassung wird dadurch erreicht, dass sich die virtuelle Kamera 8512 weiter weg von der 3D-Karte 8510 entlang einer Linie 8555 bewegt. In einigen Ausführungsformen ist die Linie 8555, welche die Kartenanwendung verwendet, um die virtuelle Kamera 8512 entlang dieser zu bewegen, eine Linie, welche durch die Vorderseite der virtuellen Kamera 8512 und den Fokuspunkt der virtuellen Kamera 8512 gebildet wird. Die Kartenanwendung einiger Ausführungsformen bewegt die virtuelle Kamera 8512 entlang einer Linie, welche durch die Vorderseite der virtuellen Kamera 8512 und einen Ort in der 3D-Karte 8510 basierend auf der Eingabe des Benutzers zum Hereinzoomen in die Ansicht der 3D-Karte 8510 gebildet wird.
Das Rendern einer 3D-Kartenansicht unter Verwendung der virtuellen Kamera 8512 bei dieser Position resultiert in einer 3D-Kartenansicht 8534, in welcher die Gebäude und die Straßen weiter erscheinen als die Position, welche in der 3D-Kartenansicht 8524 gezeigt ist. Wie durch die Gestrichelte-Linien-Version der virtuellen Kamera 8512 gezeigt, bewegte die virtuelle Kamera 8512 sich weiter weg von der 3D-Karte 8510 entlang der Linie 8555.
Wie oben beschrieben, zeigt 85 einige Beispiel-Zoom-Anpassungsoperationen und die entsprechende Bewegung einer virtuellen Kamera in einer 3D-Karte, welche verwendet wird zum Rendern der 3D-Kartenansichten der 3D-Karte. Der Fachmann wird erkennen, dass jede Anzahl von unterschiedlichen Zoom-Anpassungen möglich ist. Zusätzlich führt die Kartenanwendung einiger Ausführungsformen Zoom-Anpassungsoperationen in Antwort auf zusätzliche und/oder unterschiedliche Typen von Eingaben aus (z. B. Antippen des Bildschirms, Doppel-Tippen des Bildschirms, usw.).
86 zeigt konzeptionell einen Prozess 8600 einiger Ausführungsformen, welcher die Position einer virtuellen Kamera anpasst, welche verwendet wird zum Rendern einer Kartenansicht in Antwort auf eine Zoom-Level-Anpassung. In einigen Ausführungsformen führt die Kartenanwendung, welche oben und unten durch Verweis auf 1–108 beschrieben wird, den Prozess 8600 aus, wenn die Kartenanwendung in einem Kartenansichtsmodus ist (z. B. einem Orts-Browsing-Modus, einem Navigationsmodus, usw.) und die Kartenanwendung eine Geste über einen Berührungsbildschirm einer Vorrichtung empfängt, auf welcher die Kartenanwendung ausgeführt wird.
Der Prozess 8600 startet durch Empfangen (bei 8610) einer Geste zum Anpassen des Zoom-Levels einer Kartenansicht. In einigen Ausführungsformen umfasst eine Geste zum Anpassen des Zoom-Levels der Kartenansicht eine Mehrfach-Berührungsgeste, welche über einen Berührungsbildschirm empfangen wird (z. B. simultanes Berühren des Berührungsbildschirms mit mehreren Fingern), wie beispielsweise diejenigen, welche oben mit Verweis auf 85 beschrieben sind. In diesem Beispiel empfängt der Prozess 8600 eine Zwei-Berührungs-Kneif- oder Spreiz-Geste.
Als Nächstes bestimmt (bei 8620) der Prozess 8600 einen Zoom-Ort basierend auf der empfangenen Geste. Der Zoom-Ort in einigen Ausführungsformen ist ein Ort in der Karte, zu welchem der Zoom-Level hin angepasst wird (z. B. für Hereinzoom-Anpassungen) oder von welchem der Zoom-Level weg angepasst wird (z. B. für Herauszoom-Anpassungen). In einigen Ausführungsformen bestimmt der Prozess 8600 den Zoom-Ort durch (1) Identifizieren der Orte der ursprünglichen zwei Berührungspunkte der Geste und (2) Identifizieren des Mittelpunkts entlang einer Linie, welche durch die Orte der zwei Berührungspunkte gebildet wird, als den Zoom-Ort. Der Prozess 8600 einiger Ausführungsformen verwendet zusätzliche und/oder unterschiedliche Techniken zum Bestimmen des Zoom-Orts. Zum Beispiel verwendet der Prozess 8600 den Mittelpunkt der Kartenansicht als den Zoom-Ort, in einigen Ausführungsformen.
Der Prozess 8600 bestimmt (bei 8630) dann einen Zoom-Betrag, basierend auf der empfangenen Geste. Der Prozess 8600 einiger Ausführungsformen bestimmt den Zoom-Betrag basierend auf einer Längendifferenz zwischen (1) einer ersten Linie, welche durch die Orte der ursprünglichen zwei Berührungspunkte der Geste gebildet wird (z. B. die Orte, an welchen der Benutzer einen Berührungsbildschirm mit zwei Fingern berührt), und (2) eine zweite Linie, welche durch die Orte der endenden zwei Berührungspunkte der Geste gebildet wird (z. B. die Orte, an welchen der Benutzer die zwei Finger von dem Berührungsbildschirm abhebt). In einigen Ausführungsformen bestimmt der Prozess 8600 einen positiven Zoom-Betrag (z. B. eine Hereinzoom-Anpassung), wenn die Länge der zweiten Linie größer als die Länge der ersten Linie ist, wohingegen der Prozess 8600 einen negativen Zoom-Betrag bestimmt (z. B. eine Herauszoom-Anpassung), wenn die Länge der zweiten Linie kleiner als die Länge der ersten Linie ist. Der Prozess 8600 einiger Ausführungsformen bestimmt, dass der Zoom-Betrag Null ist (z. B. keine Zoom-Anpassung), wenn die Differenz zwischen der Länge der zweiten Linie und der Länge der ersten Linie gleich oder innerhalb eines Schwellenlängenbetrags ist. In einigen Ausführungsformen verwendet der Prozess 8600 zusätzliche und/oder unterschiedliche Techniken zum Bestimmen des Zoombetrags.
Als Nächstes passt (bei 8640) der Prozess 8600 den Zoom-Level der Kartenansicht basierend auf dem identifizierten Zoom-Ort und Zoom-Betrag an. Wie oben durch Verweis auf 3–5 und 74–80 erklärt, wird die virtuelle Kamera in einigen Ausführungsformen verwendet zum Rendern einer Kartenansicht. Der Prozess 8600 einiger Ausführungsformen passt den Zoom-Level der Kartenansicht an durch Bewegen der Position der virtuellen Kamera (1) entlang einer Linie, welche durch die Vorderseite der virtuellen Kamera und den Zoom-Ort gebildet wird, und (2) durch einen Betrag basierend auf dem Zoom-Betrag.
Schließlich rendert (bei 6850) der Prozess (6800) eine Kartenansicht zur Anzeige basierend auf dem angepassten Zoom-Level der Kartenansicht. Der Prozess (6800) endet dann.
6. Virtuelle Kamerabewegung während der Rotation
87 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht gemäß einigen Ausführungsformen der Erfindung. Insbesondere zeigt 87 die Rotationsoperation bei zwei unterschiedlichen Stufen 8705 und 8710. In einigen Ausführungsformen führt die Kartenanwendung den Prozess 9000, welcher unten mit Verweis auf 90 beschrieben ist, aus, um die Rotationsoperation auszuführen.
Die erste Stufe 8705 zeigt eine 3D-Kartenansicht 8715 einer diagonalen Verkehrskreuzung von zwei Straßen und drei Gebäuden nahe der Verkehrskreuzung. Wie gezeigt, sind die drei Gebäude an der Oberseite und den Seiten der diagonalen Verkehrskreuzung in der 3D-Kartenansicht 8715 angeordnet. Die erste Stufe 8705 zeigt auch, dass ein Benutzer eine Geste ausführt, zum Rotieren der 3D-Kartenansicht 8715.
Wie gezeigt, hat der Benutzer zwei Orte nahe des Mittelpunkts der 3D-Kartenansicht 8715 auf dem Berührungsbildschirm berührt unter Verwendung von zwei Fingern und hat die zwei Orte im Uhrzeigersinn gedreht.
Die zweite Stufe 8710 zeigt die entsprechende Bewegung einer virtuellen Kamera 8700 um eine 3D-Karte 8725, welche verwendet wird zum Rendern der 3D-Kartenansicht 8715 in Antwort auf die Rotationsgeste, welche in der ersten Stufe 8705 gezeigt ist. In diesem Beispiel wurde die Rotationsgeste nahe oder an der Verkehrskreuzung der zwei Straßen empfangen. Wie gezeigt, hat die Kartenanwendung die virtuelle Kamera 8700 von der linken Seite der 3D-Karte 8725 hin zu der unteren Seite der 3D-Karte 8725 bewegt durch Rotieren der virtuellen Kamera 8700 um eine z-Achse, welche am oder nahe dem Mittelpunkt der Rotationsgeste angeordnet ist. Eine 3D-Kartenansicht 8720 zeigt ein beispielhaftes Rendern der 3D-Karte 8725 nach der Rotation der virtuellen Kamera 8700. Wie gezeigt ist die 3D-Kartenansicht nun rotiert, so dass die drei Gebäude und die Straßen im Uhrzeigersinn rotiert sind in Antwort auf die Rotationsgeste im Uhrzeigersinn, gezeigt in der ersten Stufe 8705.
Während die 87 eine Rotationsgeste zeigt, welche nahe oder an dem Mittelpunkt der 3D-Kartenansicht ausgeführt wird, können Rotationsgetsen an jedem Ort in der angezeigten 3D-Kartenansicht ausgeführt werden. In einigen Ausführungsformen rotiert die Kartenanwendung die 3D-Karte basierend vollständig oder teilweise auf dem Ort der Rotationsgeste. Zum Beispiel wenn eine Rotationsgeste in der oberen rechten Ecke der 3D-Kartenansicht ausgeführt wird, rotiert die Kartenanwendung einiger Ausführungsformen die virtuelle Kamera um eine z-Achse, welche an oder nahe dem Ort in der 3D-Karte angeordnet ist, welcher dem Ort der Rotationsgeste entspricht.
In einigen Ausführungsformen stellt die Kartenanwendung ein Positionsindikatormerkmal bereit, welches, wenn es aktiviert ist, die 3D-Kartenansicht an den Ort des Benutzers zurückpositioniert (z. B. den Ort der Vorrichtung in der 3D-Karte). Die Kartenanwendung einiger solcher Ausführungsformen führt eine Rotation der 3D-Kartenansicht unterschiedlich aus, wenn sie nach einer Aktivierung des Positionsindikatormerkmals ausgeführt wird.
88 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht nach einer Aktivierung solch eines Positionsindikatormerkmals gemäß einigen Ausführungsformen der Erfindung. Insbesondere zeigt 88 die Rotationsoperation bei zwei unterschiedlichen Stufen 8805 und 8810.
Die erste Stufe 8805 zeigt eine 3D-Kartenansicht 8815 einer diagonalen Verkehrskreuzung von zwei Straßen und drei Gebäuden nahe der Verkehrskreuzung. Wie gezeigt, sind die drei Gebäude an der oberen Seite und den Seiten der diagonalen Verkehrskreuzung in der 3D-Kartenansicht 8815 angeordnet. Die erste Stufe 8805 zeigt die 3D-Kartenansicht, nachdem ein Benutzer das Positionsindikatormerkmal aktiviert hat, welches die Kartenanwendung veranlasst hat, die 3D-Kartenansicht an den Ort des Benutzers zurück zu positionieren, welcher durch einen Kreis in diesem Beispiel dargestellt ist. Zusätzlich zeigt die erste Stufe 8805, dass der Benutzer eine Geste ausführt zum Rotieren der 3D-Kartenansicht 8815 in dem oberen Teil der 3D-Kartenansicht 8815. Wie gezeigt, hat der Benutzer zwei Orte in den oberen Teil der 3D-Kartenansicht 8815 auf dem Berührungsbildschirm unter Verwendung von zwei Fingern berührt und hat die zwei Orte im Uhrzeigersinn rotiert.
Die zweite Stufe 8810 zeigt die entsprechende Bewegung einer virtuellen Kamera 8800 um eine 3D-Karte 8825, welche verwendet wird zum Rendern der 3D-Kartenansicht 8815, in Antwort auf die Rotationsgeste, welche in der ersten Stufe 8805 gezeigt ist. In diesem Beispiel wurde die Rotationsgeste in dem oberen Teil der 3D-Kartenansicht 8815 hinter dem mittleren Gebäude empfangen, nachdem das Positionsindikatormerkmal aktiviert wurde.
In einigen Ausführungsformen rotiert die Kartenanwendung die 3D-Karte um den Ort des Benutzers, wenn die Kartenanwendung eine Rotationsgeste empfängt, nachdem das Positionsindikatormerkmal aktiviert ist. Die Kartenanwendung einiger Ausführungsformen führt die Rotationsoperation, welche in 88 gezeigt ist, nur aus, wenn die Kartenanwendung eine Rotationsgeste empfängt, nachdem das Positionsindikatormerkmal aktiviert worden ist und die Kartenanwendung nicht irgendwelche, dazwischenkommenden, Nicht-Rotationsgesten empfangen hat. In einigen Ausführungsformen führt die Kartenanwendung die Rotationsoperation, welche in 88 gezeigt ist, für eine definierte Dauer aus, nachdem das Positionsindikatormerkmal aktiviert ist, und kehrt dann zurück zu der Rotationsoperation, welche in 87 gezeigt ist.
Wie in der zweiten Stufe 8810 gezeigt, hat die Kartenanwendung die virtuelle Kamera 8800 von der linken Seite der 3D-Karte 8825 hin zu der unteren Seite der 3D-Karte 8825 bewegt durch Rotieren der virtuellen Kamera 8800 um eine z-Achse, welche an oder nahe dem Ort des Benutzers angeordnet ist, welcher durch einen schwarzen Punkt angedeutet ist, an der Verkehrskreuzung der zwei Straßen. Eine 3D-Kartenansicht 8820 zeigt ein beispielhaftes Rendern der 3D-Karte 8825, nach der Rotation der virtuellen Kamera 8800. Wie gezeigt, ist die 3D-Kartenansicht nun rotiert, so dass die drei Gebäude und die Straßen im Uhrzeigersinn um den Ort des Benutzers rotiert sind in Antwort auf die Rotationsgeste im Uhrzeigersinn, welche in der ersten Stufe 8805 gezeigt ist.
Die oben beschriebenen 87 und 88 zeigen Rotieren einer 3D-Karte während des Betrachtens einer 3D-Karte in einer 3D-Perspektivenansicht. In einigen Ausführungsformen erlaubt die Kartenanwendung auch einem Benutzer die 3D-Karte zu rotieren während des Betrachtens der 3D-Karte in einer 2D-Perspektivenansicht.
89 zeigt konzeptionell eine Rotationsoperation einer 3D-Kartenansicht von einer 2D-Perspektivenansicht der 3D-Karte gemäß einigen Ausführungsformen der Erfindung. Insbesondere zeigt 89 bei drei unterschiedlichen Stufen 8905 bis 8915 die Rotationsoperation zusammen mit einem Trägheitseffekt für die Rotationsoperation. In einigen Ausführungsformen führt die Kartenanwendung in dem Prozess 9000, welcher unten mit Verweis auf 90 beschrieben ist, aus, um die Rotationsoperation auszuführen.
Die erste Stufe 8905 zeigt eine 3D-Kartenansicht 8920 einer 3D-Karte. Wie gezeigt, umfasst die 3D-Kartenansicht 8920 mehrere Straßen, welche parallel oder in senkrechter Richtung laufen. Die erste Stufe 8905 zeigt auch, dass ein Benutzer Eingabe bereitstellt zum Rotieren der 3D-Kartenansicht 8920. Insbesondere führt der Benutzer eine Geste aus zum Rotieren der 3D-Kartenansicht 8920 durch Berühren zweier Finger an zwei Orten auf dem Berührungsbildschirm und Rotieren der zwei Finger im Uhrzeigersinn, wie durch zwei Pfeile angedeutet.
Die zweite Stufe 8910 zeigt die 3D-Karte, unmittelbar nachdem der Benutzer die Eingabe zum Rotieren der 3D-Karte fertiggestellt hat. Zum Beispiel hat der Benutzer die Eingabe fertiggestellt durch Abheben der zwei Finger von dem Berührungsbildschirm der Vorrichtung. Zusätzlich zeigt die zweite Stufe 8910 eine 3D-Kartenansicht 8925 der 3D-Karte, welche durch die Kartenanwendung gerendert wird. Wie gezeigt, hat die Kartenanwendung die 3D-Karte im Uhrzeigersinn von der 3D-Kartenansicht 8920 zu der 3D-Kartenansicht 8925 rotiert. Die Straßen, welche in der ersten Stufe 8905 gezeigt sind, wurden ungefähr 45 Grad im Uhrzeigersinn gedreht.
Die Kartenanwendung unterschiedlicher Ausführungsformen verwendet unterschiedliche Verfahren zum Implementieren eines Trägheitseffekts für eine Rotationsoperation. Zum Beispiel in einigen Ausführungsformen bestimmt die Kartenanwendung eine Winkelgeschwindigkeit der Eingabe des Benutzers an oder nahe der Instanz, an welcher der Benutzer den Finger von dem Berührungsbildschirm abhebt, basierend auf einem der Finger oder dem Durchschnitt von beiden der Finger. Die Kartenanwendung verwendet die Winkelgeschwindigkeit zum Bestimmen eines Winkelbetrags für den Trägheitseffekt und bestimmt die Art, auf welche die virtuelle Kamera, welche zur Betrachtung der 3D-Karte verwendet wird, die Winkelgeschwindigkeit verlangsamt (konstant, exponentiell, logarithmisch, usw.) zum Rotieren um den bestimmten Winkelbetrags. In einigen Ausführungsformen rendert die Kartenanwendung eine Animation des Trägheitseffekts und zeigt diese an (z. B. eine Verlangsamungsrotation der 3D-Karte von der 3D-Kartenansicht 8925, welche die 3D-Karte um den bestimmten Winkelbetrag rotiert). Die Kartenanwendung einiger Ausführungsformen implementiert den Trägheitseffekt nicht. Vielmehr wird der Trägheitseffekt durch ein Framework eines Betriebssystems implementiert, auf welchem die Kartenanwendung betrieben wird.
Die dritte Stufe 8915 zeigt die 3D-Karte, nachdem die Kartenanwendung die Animation des Trägheitseffekts gerendert und angezeigt hat. Wie gezeigt, wird eine 3D-Kartenansicht 8930 der 3D-Karte, welche durch die Kartenanwendung gerendert wurde, angezeigt. In der dritten Stufe 8915 hat die Kartenanwendung die 3D-Karte weiter im Uhrzeigersinn rotiert, nachdem der Benutzer die Eingabe in der zweiten Stufe 8910 fertiggestellt hat. Wie gezeigt, zeigt eine 3D-Kartenansicht 8930 in der dritten Stufe 8915 die Straßen weiter im Uhrzeigersinn rotiert von den Straßen, welche in der 3D-Kartenansicht 8925 gezeigt sind.
90 zeigt konzeptionell einen Prozess 9000 einiger Ausführungsformen zum Rotieren einer Kartenansicht basierend auf Gesteneingabe. In einigen Ausführungsformen führt die Kartenanwendung den Prozess 9000 aus, wenn die Kartenanwendung in einem Kartenansichtsmodus ist (z. B. Ortsbrowsing-Modus, Navigationsmodus, 2D-Ansichtsmodus, 3D-Ansichtsmodus usw.) und die Kartenanwendung einer Geste über einen Berührungsbildschirm einer Vorrichtung empfängt, auf welcher die Kartenanwendung ausgeführt wird.
Der Prozess 9000 startet durch Empfangen (bei 9010) einer Geste zum Rotieren der Kartenansicht. In einigen Ausführungsformen umfasst eine Geste zum Rotieren der Kartenansicht eine Mehrfachberührungsgeste, welche über einen Berührungsbildschirm empfangen wird (z. B. simultanes Berühren des Berührungsbildschirms mit mehreren Fingern). In diesem Beispiel empfängt der Prozess 9000 eine Zwei-Berührungsrotationsgeste.
Als nächstes identifiziert (bei 9020) der Prozess 9000 eine Rotationskomponente der empfangenen Geste. Der Prozess 9000 einiger Ausführungsformen identifiziert die Rotationskomponente der Geste durch Identifizieren eines Betrags von Rotation der Berührungspunkte der Geste. Zum Bespiel in einigen solcher Ausführungsformen identifiziert der Prozess 9000 den Betrag von Rotation der Berührungspunkte der Geste durch (1) Bestimmen eines ersten Vektors von dem ursprünglichen Ort eines Berührungspunkts zu dem ursprünglichen Ort des anderen Berührungspunkts (2) Bestimmen eines zweiten Vektors von einem zweiten Ort des einen Berührungspunkts zu einem zweiten Ort des anderen Berührungspunkts und (3) Bestimmen einer Rotationsrichtung basierend auf den ursprünglichen Orten der Berührungspunkte und der zweiten Orte der Berührungspunkte.
Der Prozess 9000 bestimmt (bei 9030) dann, ob der Betrag von Rotation innerhalb eines Schwellenbetrags ist. Wenn der Prozess 9000 bestimmt, dass der Betrag von Rotation nicht innerhalb des Schwellenbetrags ist, endet der Prozess 9000. Ansonsten bestimmt (bei 9040) der Prozess 9000 eine Rotationsachse basierend auf der Geste. In einigen Ausführungsformen bestimmt der Prozess 9000 die Rotationsachse durch (1) Identifizieren eines Punkts entlang eines Vektors von dem ursprünglichen Ort eines Berührungspunkts zu dem ursprünglichen Ort des anderen Berührungspunkts und (2) Bestimmen eines Punkts auf der Kartenansicht, welcher dem Punkt entlang des Vektors entspricht (z. B. den Punkt auf der Karte, welcher mit dem Punkt entlang des Vektors zusammenfällt). Der Prozess 9000 verwendet den bestimmten Punkt auf der Kartenansicht als den Ort einer Achse (z. B. einer z-Achse), um welche die Karte rotiert wird.
Als nächstes passt (bei 9050) der Prozess 9000 dann die Kartenansicht basierend auf der Rotationsachse und dem Betrag von Rotation an. In einigen Ausführungsformen passt der Prozess 9000 die Kartenansicht an durch Rotieren der Kartenansicht um die bestimmte Rotationsachse um den bestimmten Betrag von Rotation in der bestimmten Rotationsrichtung. Unterschiedliche Ausführungsformen verwenden unterschiedliche Koordinatenräume für eine Karte. Zum Beispiel verwendet die Karte einiger Ausführungsformen einen Mercator-Einheitskoordinatenraum. In solchen Ausführungsform passt der Prozess 9000 die Position der virtuellen Kamera in Bezug auf die Karte an, um die Kartenansicht anzupassen. Als ein anderes Beispiel in einigen Ausführungsformen verwendet die Karte World Geodetic System (z. B. WGS 84) als den Koordinatenraum der Karte. Der Prozess 9000 passt in solchen Ausführungsformen die Karte in Bezug auf die Position der virtuellen Kamera an, um die Kartenansicht anzupassen.
Schließlich rendert (bei 9060) der Prozess 9000 die angepasste Kartenansicht zur Anzeige auf der Vorrichtung. In einigen Ausführungsformen ist die gerenderte Kartenansicht ein Bild, welches die angepasste Kartenansicht darstellt. Dann endet der Prozess 9000.
Die 87 bis 90, welche oben beschrieben sind, zeigen verschiedene Beispiele von Rotationsoperationen, welche auf einer 3D-Karte ausgeführt werden. In einigen Ausführungsformen ist die 3D-Karte rotierbar um einen definierten Bereich und/oder Satz von Zoom-Leveln. Zum Beispiel in einigen Ausführungsformen erlaubt die Kartenanwendung der 3D-Karte um eine definierte Anzahl der höchsten Zoom-Level rotiert zu werden (z. B. Zoom-Level 10 bis 20) und hindert die 3D-Karte daran bei den verbleibenden geringeren Zoom-Leveln (z. B. 1 bis 10) rotiert zu werden. In einigen solcher Ausführungsformen erzeugt die Kartenanwendung keine Instruktionen zum Rotieren der 3D-Karte, wenn die Kartenanwendung Eingabe empfängt zum Rotieren der 3D-Karte bei einem Zoom-Level, welcher definiert ist, Rotationsoperationen nicht zu erlauben. In anderen solcher Ausführungsformen erzeugt die Kartenanwendung Instruktionen zum Rotieren der 3D-Karte, wenn die Kartenanwendung Eingabe empfängt zum Rotieren der 3D-Karte bei einem Zoom-Level, welcher definiert ist, Rotationsoperationen nicht zu erlauben, aber die Kartenanwendung ignoriert einfach die Instruktionen. Der Fachmann wird erkennen, dass die Zoom-Level, bei welchen Rotationsoperationen auf einer 3D-Karte erlaubt sind ausgeführt zu werden, auf jede Anzahl von unterschiedlichen Wegen in unterschiedlichen Ausführungsformen definiert sein können.
B. Immersive und nicht-immersive Ansichtsmodi
Viele der Figuren, welche unten und oben beschrieben sind, zeigen eine Kartenanwendung, welche ein Punkt-zu-Punkt-Navigationsmerkmal bereitstellen. In einigen Ausführungsformen stellt die Kartenanwendung mehrere Ansichtsmodi für solch ein Navigationsmerkmal bereit. Zum Beispiel stellt die Kartenanwendung einiger Ausführungsformen einen immersiven Ansichtsmodus und einen nicht-immersiven Ansichtsmodus bereit. In einigen Ausführungsformen dienen diese zwei Ansichtsmodi dem Betrachten unterschiedlicher 3D-Karten der gleichen geographischen Region. Das heißt eine 3D-Karte, welche unter Verwendung des immersiven Ansichtsmodus betrachtbar ist, und eine andere 3D-Karte, welche unter Verwendung des nicht-immersiven Ansichtsmodus betrachtbar ist, sind 3D-Karten der gleichen geographischen Region. Jedoch sind die immersiven und nicht-immersiven Ansichtsmodi einiger Ausführungsformen nicht beschränkt auf das Punkt-zu-Punkt-Navigationsmerkmal. Zum Beispiel können sowohl der immersive als auch der nicht-immersive Ansichtsmodus in einem Kartenbrowsingmodus verfügbar sein (d. h. wenn Navigation nicht verwendet wird). Des Weiteren verwenden einige Ausführungsformen den immersiven Ansichtsmodus für den Punkt-zu-Punkt-Navigationsmodus und den nicht-immersiven Ansichtsmodus für den Kartenbrowsingmodus.
In einigen Ausführungsformen sind die nicht-immersiven und immersiven Ansichtsmodi Ansichtsmodi zum Betrachten unterschiedlicher 3D-Karten, welche unterschiedlichen Aufbau und/oder Geometrien aufweisen. Zum Beispiel dient der nicht-immersive Ansichtsmodus einiger Ausführungsformen dem Betrachten einer 3D-Karte, welche durch Gebäudekacheln und Straßenkacheln beschrieben wird. In einigen Ausführungsformen enthält eine Gebäudekachel Polygondaten (z. B. ein Polygon der Grundfläche des Gebäudes und einen Höhenwert des Gebäudes) für jedes der Gebäude, welche in der Region der 3D-Karte angeordnet sind, welche die Gebäudekachel darstellt. Eine Straßenkachel speichert in einigen Ausführungsformen Informationen über die verschiedenen Straßen und Gelände, welche in der Region der 3D-Karte angeordnet sind, welche die Kartenkachel darstellt. In einigen Ausführungsformen sind die Straßen durch Straßenvektoren definiert, welche den Mittelpunkt der Straßen darstellen (z. B. Mittellinien) und das Gelände ist definiert durch Polygondaten.
Der immersive Ansichtsmodus einiger Ausführungsformen dient dem Betrachten einer 3D-Karte, welche durch Gebäudekacheln und Navigationskacheln beschrieben wird. In einigen Ausführungsformen werden die gleichen Gebäudekacheln, welche für den nicht-immersiven Ansichtsmodus verwendet werden, für den immersiven Ansichtsmodus verwendet, während in einigen Ausführungsformen Gebäudekacheln, welche für den immersiven Ansichtsmodus verwendet werden unterschiedlich sind (z. B. die immersiven Gebäudekacheln umfassend Polygondaten mit höherer Auflösung für die Gebäude).
In einigen Ausführungsformen umfasst eine Navigationskachel Polygondaten für Straßen und Polygondaten für Gelände. Durch Verwenden von Polygondaten zum Definieren von Straßen, können die Navigationskacheln reicher definiert werden. Zum Beispiel erscheinen die Straßen in 3D oder erscheinen als Asphalt, Bordsteine können entlang der Seiten der Straßen definiert werden, Schatten können für Überführungen und Brücken spezifiziert werden, usw. Jedoch erfordern die Navigationskacheln mehr Informationen, um die Straßen zu beschreiben im Vergleich zu Straßenkacheln in einigen Ausführungsformen.
In einigen Ausführungsformen werden Stylesheet-Daten, welche detaillierter unten beschrieben werden, verwendet zum Spezifizieren der Erscheinungen von Konstrukten in der 3D-Karte (z. B. Gebäude, Straßen, Autobahnen, Geländeoberflächen, Laub, Bezeichnungen, Schatten, Straßenbordsteine usw.). Zum Beispiel können Stylesheet-Daten die Texturen, welche auf die unterschiedlichen Konstrukte anzuwenden sind, die Farben der Texturen spezifizieren, welche auf die Konstrukte angewendet werden, usw. In einigen Ausführungsformen werden die Stylesheet-Daten verwendet zum Spezifizieren der Texturen für die Straßen, damit die Straßen wie Asphalt erscheinen.
Wie oben erwähnt, verwenden beide Ansichtsmodi die gleichen Gebäudekacheln zum Rendern der Gebäude für den Ansichtsmodus in einigen Ausführungsformen. Die Stylesheet-Daten in einigen Ausführungsformen definieren unterschiedliche Stile (z. B. unterschiedliche Texturen, Farben, Detaillevel usw.) für die Gebäude in den unterschiedlichen Ansichtsmodi. Zum Beispiel in einigen Ausführungsformen sind Gebäude in dem nicht-immersiven Ansichtsmodus als grau gestylt und die Umrisse der Straßenblöcke haben scharfe Ecken. Die gleichen Gebäude in dem immersiven Ansichtsmodus einiger Ausführungsformen sind gestylt als hellgrau oder weiß und die Umrisse der Straßenblöcke haben gerundete Ecken. Zusätzliche und/oder unterschiedliche Konstrukte können unterschiedlich für die unterschiedlichen Ansichtsmodi in einigen Ausführungsformen gestylt werden. Zum Beispiel spezifizieren einige Ausführungsformen unterschiedliche Texturen für die gleichen Gebäude in unterschiedlichen Ansichtsmodi.
Zusätzlich können Stylesheet-Daten unterschiedliche Stile für die gleichen oder ähnlichen Elemente in der 3D-Karte bei unterschiedlichen Zoom-Leveln spezifizieren. Zum Beispiel spezifizieren einige Ausführungsformen einfache Texturen für Gebäude bei niedrigen Zoom-Leveln, weil die Gebäude weiter weg sind und Details schwierig zu erkennen oder überhaupt nicht zu erkennen sind. Für höhere Zoom-Level spezifizieren einige Ausführungsformen detaillierte Gestaltungen für die Gebäude, wie beispielsweise definierte Formen von Gebäudedächern (im Gegensatz zu flachen Dächern für alle Gebäude).
Zusätzlich können die nicht-immersiven und immersiven Ansichtsmodi definiert werden zum Betrachten von 3D-Karten bei unterschiedlichen Bereichen von Zoom-Leveln. Zum Beispiel ist der nicht-immersive Ansichtsmodus einiger Ausführungsformen definiert zum Betrachten einer 3D-Karte bei Zoom-Leveln von 0 bis 14, während der immersive Ansichtsmodus einiger Ausführungsformen definiert ist zum Betrachten der 3D-Karte bei Zoom-Leveln 15 bis 21. Die Ansichtsmodi können definiert sein zum Betrachten irgendeiner Anzahl von unterschiedlichen Zoom-Leveln in unterschiedlichen Ausführungsformen. In einigen Fällen ist der Bereich von Zoom-Leveln des immersiven Ansichtsmodus definiert als höhere Zoom-Level als, geringere Zoom-Level als, die gleichen Zoom-Level wie, oder Zoom-Level, welche mit dem Zoom-Level überlappen, welcher für den nicht-immersiven Ansichtsmodus definiert ist. Zum Beispiel in einigen Ausführungsformen ist der nicht-immersive Ansichtsmodus definiert zum Betrachten bei allen Zoom-Leveln (z. B. Zoom-Level 0 bis 21), während der immersive Ansichtsmodus definiert ist für eine Untermenge von hohen Zoom-Leveln (z. B. Zoom-Leveln 15 bis 21).
Ein Zoom-Level in einigen Ausführungsformen ist ein definierter Bereich von Distanzen von der 3D-Karte. Zum Beispiel kann ein erster Zoom-Level definiert sein als 6 bis 10 Distanzeinheiten (z. B. Fuß, Yards und Meter usw.) von der 3D-Karte entlang der z-Achse, ein zweiter Zoom-Level kann definiert sein als 11 bis 15 Distanzeinheiten von der 3D-Karte entlang der z-Achse, ein dritter Zoom-Level kann definiert sein als 16 bis 20 Distanzeinheiten von der 3D-Karte entlang der z-Achse. Der Fachmann wird erkennen, dass die Zoom-Level definiert sein können, jede Anzahl von unterschiedlichen Bereichen von Distanzen unter Verwendung irgendeiner Anzahl von unterschiedlichen Distanzeinheiten zu umfassen. In einigen Ausführungsformen ist ein Zoom-Level ein definierter Bereich von Distanzen von einer 2D-Karte (z. B. einer 2D-Version der 3D-Karte).
In einigen Ausführungsformen erzeugt ein Kartendienstprovider (z. B. ein Kartenserver) unterschiedliche Sätze von 3D-Kartenkacheln der 3D-Karte für unterschiedliche Zoom-Level und stellt diese bereit. Zum Beispiel erzeugt der Kartendienstprovider einen Satz von 3D-Kartenkacheln für einen Zoom-Level 0, einen Satz von 3D-Kartenkacheln für einen Zoom-Level 1, einen Satz von 3D-Kartenkacheln für einen Zoom-Level 2 usw. (z. B. für den nicht-immersiven Ansichtsmodus). In einigen Ausführungsformen erzeugt der Kartendienstprovider nur einen Satz von 3D-Kartenkacheln der 3D-Karte (z. B. für den immersiven Ansichtsmodus). Die Kartenanwendung einiger solcher Ausführungsformen rendert die 3D-Kartenansichten der 3D-Karte bei unterschiedlichen Zoom-Leveln durch Modifizieren (z. B. Hoch- und/oder Herunterskalieren) der Daten in den 3D-Kartenkacheln (z. B. Knoten, Polygone usw.).
In einigen Ausführungsformen haben die unterschiedlichen Sätze von 3D-Kartenkacheln, welche der Kartendienstprovider für die unterschiedlichen Zoom-Level erzeugt, unterschiedliche Detaillevel. Zum Beispiel umfasst der Satz von 3D-Kartenkacheln, welche für den höchsten Zoom-Level erzeugt wurden, Hochauflösungs-3D-Konstrukte (z. B. die 3D-Konstrukte umfassen mehr Knoten), um die Konstrukte genauer darzustellen. Der Satz von 3D-Karten, welche für die niedrigsten Zoom-Level erzeugt wurden, umfassen niedrige Auflösungs-3D-Konstrukte (z. B. die 3D-Konstruktkacheln umfassen weniger Knoten), weil die 3D von einer weiten Distanz gerendert werden wird. Jedes zusätzliche Detail, welches in Höherauflösungs-3D-Kartenkacheln umfasst ist, ist bei solch weiten Distanzen nicht erkennbar.
Konstrukte und/oder Geometrien von nicht-immersiven und immersiven Ansichtsmodi einiger Ausführungsformen sind separat in unterschiedlichen Sätzen von 3D-Kartenkacheln definiert. Die unterschiedlichen Sätze von 3D-Kartenkacheln werden durch einen Kartendienstprovider basierend auf 3D-Karten erzeugt, welche der Kartendienstprovider erzeugt oder von einem (oder mehreren) 3D-Kartendatenprovider(n) importiert. Die unterschiedlichen 3D-Kartenkacheln werden verwendet durch die Kartenanwendung einiger Ausführungsformen zum Rendern von 3D-Kartenansichten für die unterschiedlichen Ansichtsmodi der 3D-Karte. In einigen Fällen erzeugt der Kartendienstprovider mehrere Sätze von 3D-Kartenkacheln für den gleichen Ansichtsmodus. Zum Beispiel in einigen Ausführungsformen erzeugt der Kartendienstprovider einen Satz von 3D-Gebäudekacheln und einen Satz von 3D-Staßenkacheln für einen nicht-immersiven Ansichtsmodus. Für einen immersiven Ansichtsmodus erzeugt der Kartendienstprovider einiger Ausführungsformen einen Satz von 3D-Gebäudekacheln und/oder den gleichen Satz von 3D-Gebäudekacheln für den nicht-immersiven Ansichtsmodus und einen Satz von 3D-Navigationskacheln.
91 zeigt konzeptionell ein Beispiel einer Kartenanwendung 9100, welche 3D-Kartenansichten für unterschiedliche Zoom-Level unterschiedlicher Ansichtsmodi rendert. Wie in diesem Beispiel gezeigt, ist der nicht-immersive Ansichtsmodus definiert zum Betrachten einer 3D-Karte bei Zoom-Leveln 1 bis N – 1, während der immersive Ansichtsmodus definiert ist, zum Betrachten der 3D-Karte bei Zoom-Leveln N bis N + M. In einigen Ausführungsformen implementiert die Anwendung 9100 einen Teil oder alle der Kartenanwendungen, welche oben und unten mit Verweis auf 1 bis 108 beschrieben sind. Wie gezeigt, umfasst 91 die Kartenanwendung 9100, einen Kartendienstprovider 9110, Sätze von 3D-Kartenkacheln 9120 und Sätze von 3D-Kartenansichten 9130.
Wie oben erwähnt, erzeugt ein Kartendienstprovider (z. B. ein Kartenserver) in einigen Ausführungsformen unterschiedliche Sätze von 3D-Kartenkacheln einer 3D-Karte für unterschiedliche Zoom-Level und stellt diese bereit. Wie gezeigt, erzeugt der Kartendienstprovider 9110 einen Satz von 3D-Kartenkacheln 9120 für jeden der Zoom-Level 1 bis N und stellt diese bereit. In einigen Ausführungsformen ist der Kartendienstprovider 9110 durch den Kartendienst implementiert, welcher unten detaillierter durch Verweis auf 108 beschrieben ist. Die Kartenanwendung 9100 erzeugt 3D-Kartenansichten 9130 basierend auf 3D-Kartenkacheln, welche von den Kartendienstprovidern 9110 empfangen werden.
Die Kartenanwendung 9100 einiger Ausführungsformen erzeugt 3D-Kartenansichten bei einem speziellen Zoom-Level basierend auf 3D-Kartenkacheln, welche für den speziellen Zoom-Level definiert sind. Zum Beispiel wie gezeigt in 91, verwendet die Kartenanwendung 9100 den Satz von 3D-Kartenkacheln 9120, welche für den Zoom-Level 1 definiert sind, um für den nicht-immersiven Ansichtsmodus den Satz von 3D-Kartenansichten 9130 bei dem Zoom-Level 1 zu erzeugen. In ähnlicher Weise erzeugt die Kartenanwendung 9100 für die nicht-immersiven und immersiven Ansichtsmodi einen Satz von 3D-Kartenansichten 9130 bei anderen Zoom-Leveln aus dem Satz von 3D-Kartenkacheln 9130, welche für den entsprechenden Zoom-Level definiert sind.
In einigen Ausführungsformen erzeugt die Kartenanwendung 9100 3D-Kartenansichten für mehrere Zoom-Level basierend auf 3D-Kartenkacheln, welche für einen einzelnen Zoom-Level definiert sind. Wie in diesem Beispiel gezeigt, verwendet die Kartenanwendung 9100 den Satz von 3D-Kartenkacheln 9120, welche für Zoom-Level N definiert sind, um für den immersiven Ansichtsmodus Sätze von 3D-Kartenkacheln 9120 bei Zoom-Leveln N bis N + M zu erzeugen. Die Kartenanwendung 9100 einiger Ausführungsformen erzeugt 3D-Kartenansichten bei N + 1 bis N + M Zoom-Leveln durch Modifizieren (Hoch- und/oder Herunterskalieren) der Daten der 3D-Kartenkacheln (z. B. 3D-Konstrukte), welche für den Zoom-Level N definiert sind.
Wie in 91 gezeigt, erzeugt die Kartenanwendung 9100 3D-Kartenansichten für einen nicht-immersiven Ansichtsmodus bei einem speziellen Zoom-Level basierend auf 3D-Kartenkacheln, welche für den speziellen Zoom-Level definiert sind, wohingegen die Kartenanwendung 9100 3D-Kartenansichten für einen immersiven Ansichtsmodus bei einem speziellen Zoom-Level basierend auf 3D-Kartenkacheln erzeugt, welche für den speziellen Zoom-Level definiert sind. Während 91 eine Kartenanwendung zeigt, welche für einen immersiven Ansichtsmodus 3D-Kartenansichten bei mehreren unterschiedlichen Zoom-Leveln erzeugt basierend auf einem Satz von 3D-Kartenkacheln für einen speziellen Zoom-Level, erzeugt in einigen Ausführungsformen die Kartenanwendung zusätzliche Zoom-Level für einen nicht-immersiven Ansichtsmodus.
Zusätzlich zeigt 91 Sätze von 3D-Kartenkacheln 9120, welche auf einem einzelnen Speicher des Kartendienstproviders 9110 gespeichert sind. In einigen Ausführungsformen werden unterschiedliche Sätze von 3D-Kartenkacheln 9120 in unterschiedlichen Speichern gespeichert. Zum Beispiel können einige 3D-Kartenkacheln 9120 für den nicht-immersiven Ansichtsmodus (einige 3D-Kartenkacheln 9120 von jedem der Zoom-Level 1 bis N – 1 in diesem Beispiel) in einem ersten Speicher gespeichert werden (z. B. einem 3D-Straßenkachelspeicher) und einige 3D-Kacheln 9120 für den immersiven Ansichtsmodus (z. B. einige 3D-Kartenkacheln 9120 von Zoom-Level N) werden in einem zweiten Speicher gespeichert (z. B. einem 3D-Navigationskachelspeicher). In einigen Ausführungsformen werden einige 3D-Kartenkacheln (z. B. einige 3D-Kartenkacheln von jedem der Zoom-Level 1 bis N) in noch einem anderen Speicher gespeichert (z. B. einem 3D-Gebäudekachelspeicher).
92 zeigt die Bewegung der virtuellen Kamera 9200 um die Region einer 3D-Karte 9235 bei drei unterschiedlichen Stufen 9205 bis 9215. Insbesondere ist die 3D-Karte 9235 eine beispielhafte 3D-Karte, welche definiert ist zum betrachtet werden durch einen immersiven Ansichtsmodus einiger Ausführungsformen. Wie oben stellt in einigen Ausführungsformen der Kartendienstprovider, von welchem die Kartenanwendung Kacheln abruft, nur einen Satz von 3D-Kartenkacheln der 3D-Karte 9235 bei einem speziellen Zoom-Level bereit (z. B. Zoom-Level 15). Um höhere Zoom-Level (z. B. Level 16 bis 21) basierend auf diesen 3D-Kartenkacheln zu rendern, rendert die Kartenanwendung einiger solcher Ausführungsformen 3D-Kartenansichten bei unterschiedlichen Zoom-Leveln durch Modifizieren (z. B. Hoch- und/oder Herunterskalieren) der Daten in den 3D-Kartenkacheln (z. B. Knoten, Polygone usw.). Wie gezeigt, umfasst die Region der 3D-Karte 9235 zwei Gebäude und eine Straße, welche an eine andere Straße angrenzt.
Die erste Stufe 9205 zeigt die virtuelle Kamera 9200 bei einem speziellen Ort und Positionen der 3D-Karte 9235. In einigen Ausführungsformen wird der Punkt, auf welchen die virtuelle Kamera 9200 fokussiert (d. h. der Punkt, an welchem eine Linie aus der Vorderseite der virtuellen Kamera herausragend die Straße kreuzt) in der 3D-Karte 9235 bezeichnet als ein Fokuspunkt. In der ersten Stufe 9205 ist der Fokuspunkt der virtuellen Kamera 9200 nahe der Verkehrskreuzung, welche durch die zwei Straßen gebildet wird. Ein beispielhaftes gerendertes Bild der 3D-Karte 9235 aus dem Blickpunkt der virtuellen Kamera 9200 bei dieser Stufe 9205 wird in der 3D-Kartenansicht 9220 gezeigt. Wie gezeigt, umfasst die 3D-Kartenansicht 9220 der 3D-Karte 9235 detaillierte Konstrukte wie Bäume, Spurmarkierungen, Asphalt (dargestellt durch ein Grauwerden der Straßen in diesem Beispiel).
Die zweite Stufe 9210 zeigt die virtuelle Kamera 9200 bei einem unterschiedlichen Ort und Position der 3D-Karte 9235. Wie in der zweiten Stufe 9210 gezeigt, hat die Kartenanwendung die virtuelle Kamera 9200 nach unten und hin zu der linken Seite der 3D-Karte 9235 bewegt. Für dieses Beispiel hat die Kartenanwendung die virtuelle Kamera 9200 in Antwort auf Eingabe (z. B. eine Gesteneingabe, wie beispielsweise eine Kneifgeste oder eine Doppeltippgeste) zum Hereinzoomen auf die 3D-Karte 9235 bewegt. Von der ersten Stufe 9205 zu der zweiten Stufe 9210, hat die Kartenanwendung automatisch die virtuelle Kamera 9200 auf die beschriebene Weise bewegt, um auf die 3D-Karte 9235 hinein zu zoomen. Ein beispielhaftes gerendertes Bild der 3D-Karte 9235 aus dem Blickpunkt der virtuellen Kamera 9200 bei der zweiten Stufe 9210 wird in der 3D-Kartenansicht 9225 gezeigt. Die 3D-Kartenansicht 9225 zeigt die Gebäude und Bäume größer und höher und die Straßen und Spurmarkierungen sind breiter als jene, welche in der ersten Stufe 9205 gezeigt sind.
Die dritte Stufe 9215 zeigt die virtuelle Kamera 9200 bei einem unterschiedlichen Ort und Position der 3D-Karte 9235. Bei dieser Stufe 9215 hat die Kartenanwendung die virtuelle Kamera 9200 weiter nach unten und hin zu der linken Seite der 3D-Karte 9235 von der Position der virtuellen Kamera 9200 bewegt, welche in der zweiten Stufe 9210 gezeigt ist. Fortfahrend mit dem obigen Beispiel, hat die Kartenanwendung die virtuelle Kamera 9200 in Antwort auf Eingabe (z. B. eine Gesteneingabe, wie beispielsweise eine Kneifgeste oder eine Doppeltippgeste) zum Hineinzoomen in die 3D-Karte 9235 bewegt. Zwischen der zweiten Stufe 9210 zu der dritten Stufe 9215 hat die Kartenanwendung automatisch die virtuelle Kamera 9200 auf die beschriebene Weise bewegt, um auf die 3D-Karte 9235 hinein zu zoomen. Ein beispielhaftes gerendertes Bild der 3D-Karte 9235 aus dem Blickpunkt der virtuellen Kamera 9200 bei dieser Stufe 9215 ist in der 3D-Kartenansicht 9230 gezeigt. Wie in der 3D-Kartenansicht 9230 gezeigt, sind die Gebäude und Bäume größer und höher und die Straßen und Spurmarkierungen sind breiter als jene, welche in der zweiten Stufe 9210 gezeigt sind.
93 zeigt die Bewegung der virtuellen Kamera 9300 um die Region einer 3D-Karte 9335 und einer 3D-Karte 9340 bei drei unterschiedlichen Stufen 9305 bis 9315. Insbesondere ist die 3D-Karte 9335 ähnlich zu der 3D-Karte 9235, welche oben mit Verweis auf 92 beschrieben wurde. Die 3D-Karte 9340 in diesem Beispiel ist eine 3D-Karte der gleichen geographischen Region, wie die 3D-Karte 9335, aber ist definiert, durch einen nicht-immersiven Ansichtsmodus einiger Ausführungsformen betrachtet zu werden. Als solches umfasst die Region der 3D-Karte 9340 in ähnlicher Weise zwei Gebäude oder eine Straße, welche an eine andere Straße angrenzt. Die erste Stufe 9305 zeigt die virtuelle Kamera 9300 bei einem speziellen Ort und Positionen der 3D-Karte 9335. In einigen Ausführungsformen wird der Punkt, auf welchen die virtuelle Kamera 9300 fokussiert (d. h. der Punkt, an welchem eine Linie aus der Vorderseite der virtuellen Kamera herausragend die Straße kreuzt) in der 3D-Karte 9335 bezeichnet als ein Fokuspunkt. In der ersten Stufe 9305 ist der Fokuspunkt der virtuellen Kamera 9300 nahe der Verkehrskreuzung, welche durch die zwei Straßen gebildet wird. Ein beispielhaftes gerendertes Bild der 3D-Karte 9335 aus dem Blickpunkt der virtuellen Kamera 9300 bei dieser Stufe 9305 wird in der 3D-Kartenansicht 9320 gezeigt. Wie gezeigt, umfasst die 3D-Kartenansicht 9320 der 3D-Karte 9335 detaillierte Konstrukte wie Bäume, Spurmarkierungen, Asphalt (dargestellt durch ein Grauwerden der Straßen in diesem Beispiel).
Die zweite Stufe 9310 zeigt die virtuelle Kamera 9300 bei einem unterschiedlichen Ort und Position der 3D-Karte 9335. Wie in der zweiten Stufe 9310 gezeigt, hat die Kartenanwendung die virtuelle Kamera 9300 nach oben und hin zu der rechten Seite der 3D-Karte 9335 bewegt. Für dieses Beispiel hat die Kartenanwendung die virtuelle Kamera 9300 in Antwort auf Eingabe (z. B. eine Gesteneingabe, wie beispielsweise eine Spreizgeste oder eine Zweifachberührungsgeste) zum Herauszoomen von der 3D-Karte 9335 bewegt. Von der ersten Stufe 9305 zu der zweiten Stufe 9310, hat die Kartenanwendung automatisch die virtuelle Kamera 9300 auf die beschriebene Weise bewegt, um aus der 3D-Karte 9335 heraus zu zoomen. Ein beispielhaftes gerendertes Bild der 3D-Karte 9335 aus dem Blickpunkt der virtuellen Kamera 9300 bei der zweiten Stufe 9310 wird in der 3D-Kartenansicht 9325 gezeigt. Die 3D-Kartenansicht 9325 zeigt die Gebäude und Bäume kleiner und kürzer und die Straßen und Spurmarkierungen sind enger als jene, welche in der ersten Stufe 9305 gezeigt sind.
Die dritte Stufe 9315 zeigt die virtuelle Kamera 9300 an einem anderen unterschiedlichen Ort und Position der 3D-Karte 9235. Bei dieser Stufe 9215 hat die Kartenanwendung von dem immersiven Ansichtsmodus zu dem nicht-immersiven Ansichtsmodus gewechselt. In einigen Ausführungsformen ist der spezielle Zoom-Level als der Übergangpunkt zwischen dem immersiven Ansichtsmodus und dem nicht-immersiven Ansichtsmodus definiert. Zum Beispiel verwendet die Kartenanwendung einiger Ausführungsformen den immersiven Ansichtsmodus zum Betrachten der Region der 3D-Karte bei Zoom-Leveln 15 bis 21 und verwendet den nicht-immersiven Ansichtsmodus zum Betrachten der Region der 3D-Karte bei Zoom-Leveln 0 bis 14. Somit, wenn die Kartenanwendung Eingabe empfängt zum Zoomen von dem Zoom-Level 15 zu dem Zoom-Level 14 wechselt die Anwendung automatisch vom dem immersiven Ansichtsmodus zu dem nicht-immersiven Ansichtsmodus. In ähnlicher Weise, wenn die Kartenanwendung Eingabe empfängt zum Zoomen von dem Zoom-Level 14 zu dem Zoom-Level 15, wechselt die Kartenanwendung automatisch von dem nicht-immersiven Ansichtsmodus zu dem immersiven Ansichtsmodus. Unterschiedliche Ausführungsformen können den Zoom-Level unterschiedlich definieren, bei welchem zwischen den zwei Zoom-Leveln zu wechseln ist. Zusätzlich wechseln einige Ausführungsformen nicht zwischen immersiven und nicht-immersiven Ansichtsmodi basierend auf dem Zoom-Level. Zum Beispiel verwenden unterschiedliche Ausführungsformen den immersiven Ansichtsmodus für Punkt-zu-Punkt-Navigation und den nicht-immersiven Ansichtsmodus für Kartenbrowsen oder umfassen eine UI-Steuerung, welche dem Benutzer erlaubt, zwischen einem nicht-immersiven Ansichtsmodus und einem immersiven Ansichtsmodus zu wechseln.
94 zeigt konzeptionell ein Beispiel einer Kartenanwendung 9400, welche 3D-Kartenansichten für unterschiedliche Zoom-Level unterschiedlicher Ansichtsmodi rendert. Wie in diesem Beispiel gezeigt, ist der nicht-immersive Ansichtsmodus definiert zum Betrachten einer 3D-Karte bei Zoom-Level 1 bis X, während der immersive Ansichtsmodus definiert ist zum Betrachten der 3D-Karte bei Zoom-Level X – K bis X. Somit kann die Anwendung eine Karte bei Zoom-Level X – K bis X entweder im immersiven oder nicht-immersiven Modus anzeigen. Wie gezeigt, umfasst 94 die Kartenanwendung 9400 und den Kartendienstprovider 9410, dessen Funktionalität ähnlich zu jener ist, welche oben mit Verweis auf 91 beschrieben ist (d. h. der Kartendienstprovider 9410 erzeugt Kartenkacheln 9420 und stellt diese bereit, und die Kartenanwendung rendert die Kartenansichten 9430 durch Verwendung dieser Kacheln).
In diesem Fall, wie in 91, erzeugt der Kartendienstprovider 9410 einen unterschiedlichen Satz von 3D-Kartenkacheln 9420 für jeden nicht-immersiven Zoom-Level und stellt diesen bereit, während er nur einen einzelnen Satz von 3D-Kartenkacheln 9420 für den immersiven Ansichtsmodus erzeugt und bereitstellt. Die Kartenanwendung 9400 erzeugt die Kartenansichten für Zoom-Level X – K bis X unter Verwendung der Kartenkacheln des Zoom-Level X – K. In einigen Ausführungsformen erzeugt die Kartenanwendung Kartenansichten unter Verwendung der nicht-immersiven 3D-Kartenkacheln, wenn in Kartenbrowsing-, Routenanzeige-, Routeninspektions- und Autostepping-Modi und erzeugt Kartenansichten unter Verwendung der immersiven 3D-Kartenkacheln, wenn im Punkt-zu-Punkt-Navigationsmodus. Diese Modi werden detaillierter mit Verweis auf 105 unten beschrieben.
In dem obigen Beispiel von 93 empfängt die Kartenanwendung Eingabe zum Herauszoomen aus einem Zoom-Level, welcher für den immersiven Ansichtsmodus definiert ist, zu einem anderen Zoom-Level, welcher für den nicht-immersiven Ansichtsmodus definiert ist. Als solche hat die Kartenanwendung eine Vorladeoperation ausgeführt zum Vorbereiten des Renderns der 3D-Kartenansichten der 3D-Karte 9340, welche für den nicht-immersiven Ansichtsmodus definiert ist. Beispiele von Vorladeoperationen sind unten mit Verweis auf 97, 95 und 102 beschrieben.
Nach der Vorladeoperation hat die Kartenanwendung die virtuelle Kamera 9300 von der Position, welche in der zweiten Stufe 9310 gezeigt ist, zu einer relativen Position weiter oben und hin zu der rechten Seite der 3D-Karte 9335 bewegt. Fortfahrend mit dem obigen Beispiel, hat die Kartenanwendung die virtuelle Kamera 9300 in Antwort auf Eingabe (z. B. eine Gesteneingabe, wie beispielsweise eine Kneifgeste oder eine Doppeltippgeste) zum Hereinzoomen auf die 3D-Karte 9335 bewegt. Zwischen der zweiten Stufe 9310 zu der dritten Stufe 9315 hat die Kartenanwendung automatisch die 3D-Karte 9340 vorgeladen und die virtuelle Kamera 9300 auf die beschriebene Weise bewegt, um aus der 3D-Karte 9335 heraus zu zoomen. Ein beispielhaftes gerendertes Bild der 3D-Karte 9335 von dem Blickpunkt der virtuellen Kamera 9300 bei dieser Stufe 9315 ist in der 3D-Kartenansicht 9330 gezeigt. Wie gezeigt, enthält die 3D-Kartenansicht 9330 die gleichen Gebäude und Straßen, aber enthält nicht irgendwelche der Konstrukte und/oder Details, welche in den 3D-Kartenansichten 9320 und 9325 gezeigt sind, da die Kartenanwendung nun 3D-Kartenansichten von der 3D-Karte 9340 rendert, welche dem weniger detaillierten, nicht-immersiven Ansichtsmodus dient.
Wie in 92 und 93 gezeigt, stellen der immersive Ansichtsmodus und der nicht-immersive Ansichtsmodus unterschiedliche Detaillevel einer Region einer 3D-Karte basierend auf dem Zoom-Level bereit, bei welchem die Region betrachtet wird. In einigen Ausführungsformen rendert die Kartenanwendung unterschiedliche Texturen für Gebäude bei unterschiedlichen Zoom-Leveln. Zum Beispiel rendert die Kartenanwendung einiger Ausführungsformen detaillierte Texturen (z. B. Farben, Muster usw.) für Gebäude in dem immersiven Ansichtsmodus und rendert einfachere Texturen (z. B. Vollfarben (solid colours) usw.) für die gleichen Gebäude in dem nicht-immersiven Ansichtsmodus. In einigen Ausführungsformen rendert die Kartenanwendung unterschiedliche Texturen für die gleichen Gebäude bei unterschiedlichen Zoom-Leveln in dem immersiven Ansichtsmodus. Zusätzlich oder in Verbindung mit dem Rendern von unterschiedlichen Texturen für Gebäude basierend auf unterschiedlichen Zoom-Leveln, rendert die Kartenanwendung einiger Ausführungsformen unterschiedliche Texturen für Gebäude, auch basierend auf anderen Faktoren (z. B. Tageszeit, geographische Region, Jahreszeit, Ferien usw.).
95 zeigt konzeptionell eine Verarbeitungspipeline 9500 der Kartenanwendung einiger Ausführungsformen zum Rendern von 3D-Kartenansichten 9560 basierend auf unterschiedlichen 3D-Kartenkacheln 9540 bis 9550. Wie gezeigt, umfasst die Verarbeitungspipeline 9500 eine Kartenrendering-Engine 9510, ein virtuelles Kameramodul 9520, einen Netzerzeuger 9530, einen Kachelprozessor 9570, drei unterschiedliche Speicher 9540 bis 9550 der 3D-Kartenkacheln und einen Stylesheet-Speicher 9555. In einigen Ausführungsformen speichert der Navigationskachelspeicher 9540 3D-Kartenkacheln (auch bezeichnet als Navigationskacheln) für den immersiven Ansichtsmodus und der Straßenkachelspeicher 9545 (auch bezeichnet als Straßenkacheln) speichert 3D-Kartenkacheln für den nicht-immersiven Ansichtsmodus. Der Gebäudekachelspeicher 9595 einiger Ausführungsformen speichert 3D-Kartenkacheln (auch bezeichnet als Gebäudekacheln) zur Verwendung sowohl im immersiven als auch im nicht-immersiven Ansichtsmodus. Der Stylesheet-Speicher 9555 speichert Definitionen zum Rendern von Texturen für 3D-Kartenansichten 9560 und andere Gestaltungsinformationen zum Rendern der 3D-Kartenansichten 9560.
Die virtuelle Kamera 9520 identifiziert einen Ort und Orientierung (z. B. Perspektivenposition, Zoom-Level usw.), aus welcher eine 3D-Karte zu betrachten ist. Die virtuelle Kamera 9520 sendet das Blickfeld der 3D-Karte (auch bezeichnet als Ansichtsstumpf (viewing frustum)) an den Kachelprozessor 9570 zur Verarbeitung.
Der Kachelprozessor 9570 empfängt Blickfelder der 3D-Karten von der virtuellen Kamera 9520. In einigen Ausführungsformen führt der Kachelprozessor 9570 jedes notwendige Aussortieren (z. B. Entfernen von Oberflächenbereich, der zu weit weg ist, Entfernen von Objekten, welche ganz hinter anderen Objekten sein werden usw.) auf die 3D-Kartenansicht, bevor er dem Netzerzeuger 9530 „leere” virtuelle 3D-Kartenkacheln in einigen Ausführungsformen sendet. Der Kachelprozessor 9570 einiger Ausführungsformen empfängt die „erzeugten” virtuellen 3D-Kartenkacheln von dem Netzerzeuger 9530 und sendet diese an die Kartenrendering-Engine 9510 zum Rendern. In einigen Ausführungsformen ist der Kachelprozessor 9570 implementiert durch die Steuereinheit und den Kachelprovider(n), welche unten mit Verweis auf 98 und 102 beschrieben sind.
In einigen Ausführungsformen bereitet der Netzerzeuger 9530 virtuelle 3D-Kartenkacheln für den Kachelprozessor 9570 vor. Der Netzerzeuger 9530 fragt 3D-Kartenkacheln (z. B. dekomprimierte 3D-Kartenkacheln) von den 3D-Kartenkachelspeichern 9540 bis 9550 basierend auf dem Ansichtsmodus an, welcher für das Blickfeld der 3D-Karte zu rendern ist. Zum Beispiel, wenn der Ansichtsmodus ein immersiver Ansichtsmodus ist, fragt der Netzerzeuger einiger Ausführungsformen Navigationskartenkacheln von dem Speicher 9540 und Gebäudekacheln vom dem Speicher 9550 an. In einigen Ausführungsformen fragt der Netzerzeuger 9530 Kartenkacheln von dem Speicher 9545 und Gebäudekacheln von dem Speicher 9550 an.
Sobald der Netzerzeuger 9530 die Kartenkacheln empfängt, erzeugt der Netzerzeuger 9530 ein Polygonnetz unter Verwendung von Vektordaten, welche in den Kacheln gespeichert sind. Der Netzerzeuger 9530 stellt auch Texturinformation basierend auf den Gestaltunginformationen bereit, welche von dem Stylesheetspeicher 9555 abgerufen wurden. In einigen Ausführungsformen erzeugt der Netzerzeuger 9530 das Polygonnetz auf einer Kachel-für-Kachel-Basis und sendet die virtuellen 3D-Kartenkacheln, welche in einigen Ausführungsformen eine Polygonnetzversion der virtuellen 3D-Kartenkacheln sind, welche der Netzerzeuger 9530 empfangen hat, welche von dem Kachelprozessor 9570 empfangen wurden.
Die Kartenrendering-Engine 9510 ist verantwortlich für das Erzeugen einer Zeichnung (z. B. einer 3D-Kartenansicht einer 3D-Karte) zur Ausgabe an eine Anzeigevorrichtung basierend auf dem Blickfeld, welches von der virtuellen Kamera 9520 empfangen wurde. Zusätzliche Details des Netzerzeugers 9530, der virtuellen Kamera 9520, dem Kachelprozessor 9570 und der Kartenrendering-Engine 9510 werden unten detaillierter mit Verweis auf 98 und 102 beschrieben.
Eine beispielhafte Operation der Verarbeitungspipeline 9500 wird nun beschrieben werden. Die virtuelle Kamera 9520 identifiziert einen Ort und eine Orientierung, von welchen die virtuelle Kamera 9520 eine 3D-Karte betrachtet. Die virtuelle Kamera 9520 sendet an den Kachelprozessor 9570 ein Blickfeld der 3D-Karte basierend auf dem identifizierten Ort und der Orientierung.
Wenn der Kachelprozessor 9570 das Blickfeld empfängt, sortiert der Kachelprozessor 9570 einiger Ausführungsformen das Blickfeld aus. Der Kachelprozessor 9570 sendet dann die virtuellen Kartenkacheln an den Netzerzeuger 9530 zur Verarbeitung.
Wenn die Kartenanwendung 3D-Kartenansichten in einem immersiven Ansichtsmodus erzeugt, ruft der Netzerzeuger 9530 Navigationskacheln vom dem Navigationskachelspeicher 9540 und Gebäudekacheln vom dem Gebäudekachelspeicher 9550 ab. Jedoch, wenn die Kartenanwendung 3D-Kartensichten in einem nicht-immersiven Ansichtsmodus erzeugt, ruft der Netzerzeuger 9530 stattdessen Straßenkacheln von dem Straßenkachelspeicher 9545 und Gebäudekacheln von dem Gebäudekachelspeicher 9550 ab. Das heißt, unterschiedliche Sätze von 3D-Kartenkacheln werden durch die Verarbeitungspipeline 9500 verwendet zum Rendern der 3D-Kartenansichten in diesen unterschiedlichen Ansichtsmodi.
In einigen Ausführungsformen werden die 3D-Kartenkacheln für eine Zeitperiode in dem Speicher 9540 zwischengespeichert (cached). Somit, in einigen solcher Ausführungsformen, wenn die 3D-Kartenkacheln nicht in dem Speicher 9540 verfügbar sind, werden die gewünschten 3D-Kartenkacheln von einem Kartendienst abgerufen.
Sobald der Netzerzeuger 9530 all die geeigneten 3D-Kartenkacheln hat, erzeugt der Netzerzeuger 9530 ein Polygonnetz basierend auf Vektordaten in den 3D-Kartenkacheln. Der Netzerzeuger 9530 sendet dann virtuelle Kartenkachelversionen der 3D-Kartenkacheln an den Kachelprozessor 9570.
Wenn der Kachelprozessor 9570 die virtuellen Kartenkacheln von dem Netzerzeuger 9530 empfängt, sendet der Kachelprozessor 9570 diese an die Kartenrendering-Engine 9510 zum Rendern. Die Kartenrendering-Engine 9510 empfängt die virtuellen Kartenkacheln von dem Kachelprozessor 9570 und rendert eine 3D-Kartenansicht 9560 basierend auf den virtuellen Kartenkacheln.
Die Beschreibung mehrerer Figuren oben und unten (z. B. 95, 98 und 102) diskutiert Verarbeitungspipelines zum Rendern von 3D-Kartenansichten einer 3D-Karte. In einigen Ausführungsformen erzeugt die Verarbeitungspipeline eine Datenstruktur zum Rendern einer Kartenansicht und speichert diese. 96 zeigt konzeptionell eine Datenstruktur 9600, welche durch die Verarbeitungspipeline einiger Ausführungsformen verwendet wird.
Wie gezeigt, umfasst die Datenstruktur 9600 eine virtuelle Kamera-ID 9605, virtuelle Kameraortsdaten 9610, Ansichtsmodus 9615, 3D-Kartenkacheln 9620, Stylesheet-Daten 9625, 3D-Kartenkachelcache 9630, virtuelle Kartenkacheln 9635, eine 3D-Kartenansicht 9640 und andere Daten 9645.
Die virtuelle Kamera-ID 9605 ist ein eindeutiger Bezeichner zum Identifizieren einer virtuellen Kamera, welche verwendet wird zum Rendern einer 3D-Kartenansicht. Wie oben und unten erwähnt, instanziiert die Verarbeitungspipeline einiger Ausführungsformen mehrere virtuelle Kameras zum Identifizieren von Ansichten der 3D-Karte. Wie in 96 gezeigt, ist ein Satz von virtuellen Kameras 9650 zur Verwendung für die Verarbeitungspipeline verfügbar. In diesem Beispiel identifiziert die virtuelle Kamera-ID 9605 die virtuelle Kamera 2 zur Verwendung für die Verarbeitungspipeline, um die 3D-Kartenansicht zu rendern.
Die virtuellen Kameraortsdaten 9610 speichern Informationen über den Ort der virtuellen Kamera, welche durch die virtuelle Kamera-ID 9605 identifiziert wurde. Beispiele solcher Informationen umfassen Koordinatenlevel der virtuellen Kamera (z. B. x-, y- und z-Koordinaten), einen Schwenkwinkel der virtuellen Kamera, einen Neigungswinkel der virtuellen Kamera, einen Rollwinkel der virtuellen Kamera, einen Zoom-Level der virtuellen Kamera usw.
Der Ansichtsmodus 9615 sind Daten, welche den Ansichtsmodus anzeigen, in welchem die 3D-Kartenansicht zu rendern ist. Zum Beispiel könnte der Ansichtsmodus 9615 Daten speichern, welche einen nicht-immersiven Ansichtsmodus, einen immersiven Ansichtsmodus, einen Satellitenansichtsmodus, einen Hybridansichtsmodus usw. anzeigen.
Die 3D-Kartenkacheln 9620 sind der Satz von 3D-Kartenkacheln, welcher den Teil der 3D-Karte darstellt, aus welchem die 3D-Karte zu rendern ist. Die Verarbeitungspipeline einiger Ausführungsformen verwendet die virtuellen Kameraortsdaten 9610 und den Ansichtsmodus 9615 zum Identifizieren des Teils und Abrufen der entsprechenden 3D-Kartenkacheln.
Die Stylesheet-Daten 9625 enthalten Gestaltungsinformationen, welche die Verarbeitungspipeline verwendet zum Erzeugen von Netzen. In einigen Ausführungsformen verwendet die Verarbeitungspipeline die Stylesheet-Daten 9625 zum Bestimmen von Texturdaten, Schattendaten, Triangulationsdaten usw.
Der 3D-Kartenkachelcache 9630 wird verwendet zum Zwischenspeichern von 3D-Kartenkacheln. In einigen Ausführungsformen speichert die Verarbeitungspipeline vorher genutzte 3D-Kartenkacheln, oft benutzte 3D-Kartenkacheln, 3D-Kartenkacheln, welche die Verarbeitungspipeline als wahrscheinlich bestimmt, dass sie in der nahen Zukunft wieder verwendet werden usw, zwischen.
Die virtuellen Kartenkacheln 9635 speichern Kartenkacheln, welche erzeugte Kartenkonstrukte umfassen. Wie gezeigt, umfasst eine virtuelle Kartenkachel Gebäudekonstrukte, Straßen-/Navigationskonstrukte, Bezeichnungskonstrukte, Geländeoberflächenkonstrukte, zusammen mit anderen Konstrukten. Insbesondere speichern die virtuellen Kartenkacheln 9635 einiger Ausführungsformen Kartenkacheln, welche Straßenkonstrukte umfassen, wenn die 3D-Kartenansicht in dem nicht-immersiven Ansichtsmodus zu rendern ist, und speichern Kartenkacheln, welche Navigationskonstrukte umfassen, wenn die 3D-Kartenansicht in dem immersiven Ansichtsmodus zu rendern ist.
Die 3D-Kartenansicht 9640 enthält die 3D-Kartenansicht, welche die Verarbeitungspipeline basierend auf den verschiedenen Informationen in der Datenstruktur 9600 rendert, welche die Kartenanwendung einiger Ausführungsformen anzeigt. Andere Daten 9645 speichern Informationen, welche die Verarbeitungspipeline in einigen Ausführungsformen brauchen könnte zum Rendern der 3D-Kartenansicht (z. B. die Anzahl von zu verwendenden Netzerzeugern, die Anzahl von Kachelprovidern zur Verwendung usw.).
Der Fachmann wird erkennen, dass die Datenstruktur 9600 nur eine mögliche Datenstruktur ist, welche die Verarbeitungspipeline einiger Ausführungsformen verwendet zum Speichern der benötigten Information um eine 3D-Kartenansicht zu rendern. Zum Beispiel könnten unterschiedliche Ausführungsformen zusätzliche oder weniger Informationen speichern, die Information in einer unterschiedlichen Reihenfolge speichern, eine unterschiedliche Struktur zum Speichern der Daten verwenden, usw.
97 zeigt konzeptionell ein Zustandsdiagramm 9700 einer Kartenanwendung einiger Ausführungsformen. Wie gezeigt, umfasst das Zustandsdiagramm 9700 Zustände 9710 bis 9770 der Kartenanwendung, während die Kartenanwendung zwischen einem ersten Ansichtsmodus und einem zweiten Ansichtsmodus während einer Routennavigation wechselt. In einigen Ausführungsformen sind die ersten und zweiten Ansichtsmodi ein nicht-immersiver Ansichtsmodus und ein immersiver Ansichtsmodus.
Die ersten und zweiten Ansichtsmodi einiger Ausführungsformen dienen dem Betrachten unterschiedlicher 3D-Karten der gleichen geographischen Region. Das heißt, eine erste 3D-Karte, welche betrachtet wird, unter Verwendung des ersten Ansichtsmodus und eine zweite 3D-Karte, welche betrachtet wird unter Verwendung des zweiten Ansichtsmodus, dienen beide dem Betrachten der gleichen geographischen Region.
Bei dem Zustand 9710 rendert die Kartenanwendung 3D-Karten in einem ersten Kartenansichtsmodus. In einigen Ausführungsformen betritt die Kartenanwendung den Zustand 9710, wenn die Kartenanwendung einen Navigationsmodus betritt (z. B. durch Auswählen eines UI-Elements zum Initiieren einer Routennavigation). Für dieses Beispiel, wenn die Kartenanwendung den Zustand 9710 betritt, verwendet die Kartenanwendung eine erste virtuelle Kamera zum Betrachten einer ersten 3D-Karte und rendert die 3D-Kartenansichten für den Kartenansichtsmodus in einem nicht-immersiven Ansichtsmodus.
In Zustand 9710 empfängt die Kartenanwendung einiger Ausführungsformen verschiedene Befehle (z. B. Zoombefehle, Schwenkbefehle, Rotierbefehle, Neigungsbefehle usw.) zum Bewegen der virtuellen Kamera um die erste 3D-Karte und Rendern der 3D-Kartenansichten basierend auf der Position der virtuellen Kamera in der ersten 3D-Karte. Während die virtuelle Kamera sich um die erste 3D-Karte bewegt, ruft die Kartenanwendung Kacheln von einem Kartendienst ab, wenn die virtuelle Kamera zu einer Region der ersten 3D-Karte, über welche die Kartenanwendung keine Daten hat.
Bei Zustand 9710, wenn die Kartenanwendung bestimmt, dass ein Übergang zu einem zweiten Ansichtsmodus wahrscheinlich ist, geht die Kartenanwendung zu dem Zustand 9720 über, um eine Vorladeoperation für den zweiten Ansichtsmodus auszuführen, um einen weichen Übergang von dem ersten Ansichtsmodus zu dem zweiten Ansichtsmodus bereitzustellen (z. B. um irgendwelches Ruckeln oder Verzögerungen beim Übergang zwischen den Modi zu verhindern). In diesem Beispiel ist der zweite Ansichtsmodus der immersive Ansichtsmodus. Das Bestimmen der Kartenanwendung einiger Ausführungsformen zu dem zweiten Ansichtsmodus überzugehen, basiert wahrscheinlich auf jeder Anzahl von unterschiedlichen Faktoren. Ein Beispiel solch eines Faktors umfasst einen Zoom-Level, bei welchem die virtuelle Kamera die erste 3D-Karte betrachtet. Zum Beispiel, wenn der identifizierte Zoom-Level der Kartenansicht ein Zoom-Level ist, in welchem Straßen als gelbe Linien angezeigt sind (z. B. ein nicht-immersiver oder Standardansichts-Modus), und der Zoom-Level innerhalb eines Schwellenbetrags von Zoom-Leveln von einem Zoom-Level, welcher definiert ist zum Übergehen zwischen dem nicht-immersiven Modus und immersiven Modus, ist, bestimmt die Kartenanwendung, dass ein Übergang zu dem zweiten Ansichtsmodus wahrscheinlich ist. Zusätzliche und/oder andere Faktoren, welche die Kartenanwendung berücksichtigt, umfassen einen Satz von Heuristiken, welche anzeigen, dass ein Übergang zu dem zweiten Ansichtsmodus wahrscheinlich ist.
Bei dem Zustand 9720 lädt die Kartenanwendung Daten für einen zweiten Lader (loader) herunter, welchen die Kartenanwendung für den zweiten Ansichtsmodus erzeugt. In einigen Ausführungsformen umfassen die Daten 3D-Kartenkacheln und Gestaltungsinformationen (z. B. Stylesheets), welche für den zweiten Ansichtsmodus notwendig sind (z. B. 3D-Kartenkacheln, welche Bereiche um den Ort des Benutzers und entlang der Routennavigation umfassen). Der Lader lädt Daten, welche sich auf die zweite 3D-Karte beziehen. Zusätzlich erzeugt die Kartenanwendung eine zweite virtuelle Kamera zum Betrachten der zweiten 3D-Karte und erzeugt 3D-Kartenansichten der zweiten 3D-Karte. Nach Erzeugen der zweiten virtuellen Kamera und des Laders und Herunterladen der Daten geht die Kartenanwendung zu dem Zustand 9730 über.
Wenn die Kartenanwendung zu dem Zustand 9730 übergeht, dekodiert die Kartenanwendung die 3D-Kartenkacheln für die zweite 3D-Karte. In einigen Ausführungsformen umfasst das Dekodieren der Daten auch Erzeugen von Netzen für Geometrien in der zweiten 3D-Karte, Abrufen der Gestaltungsinformationen, Assoziieren der Gestaltungsinformationen mit den erzeugten Netzen und Bestimmen der Zeichenreihenfolge der Netze. Die Kartenanwendung führt zusätzliche und/oder andere Operationen in einigen Ausführungsformen beim Dekodieren der heruntergeladenen Daten aus. Sobald die Kartenanwendung die Daten dekodiert hat, geht die Kartenanwendung zu dem Zustand 9740 über.
Bei dem Zustand 9740 bereitet die Kartenanwendung die Rendering-Engine vor, um 3D-Kartenansichten der zweiten 3D-Karte unter Verwendung der zweiten virtuellen Kamera zu rendern. Um die Rendering-Engine vorzubereiten, erzeugt die Kartenanwendung einiger Ausführungsformen Texturvorprozessoren, kompiliert die Rendering-Shader vor, erzeugt Gestaltungsinformationen für nahegelegene Geometrie, erzeugt Style-Ressourcen, erzeugt Texturen basierend auf den Gestaltungsinformationen und erzeugt alle Ressourcen, welche für die Geometrie benötigt werden. Zum Beispiel, wenn es einen Park nahe dem Ort des Benutzers gibt, bestimmt der Prozess 9700 Gestaltungsinformationen bezogen auf den Park und erzeugt dann irgendwelche und alle Ressourcen, welche notwendig sind zum Gestalten des Parks. Nach Vorbereiten der Rendering-Engine, geht die Kartenanwendung zu dem Zustand 9750 über.
Im Zustand 9750 fährt die Kartenanwendung damit fort, die 3D-Kartenansichten der ersten 3D-Karte unter Verwendung der ersten virtuellen Kamera zu rendern. Hier bestimmt die Kartenanwendung auch, ob sie von dem ersten Ansichtsmodus zu dem zweiten Ansichtsmodus beginnen soll, überzugehen. Wenn die Kartenanwendung bestimmt, dass ein Übergang von dem ersten Ansichtsmodus zu dem zweiten Ansichtsmodus kaum notwendig sein wird (z. B., nachdem eine definierte Dauer abgelaufen ist, der Zoomlevel des ersten Ansichtsmodus sich um einen Schwellenbetrag geändert hat, um anzuzeigen, dass ein Übergang nicht wahrscheinlich ist oder nicht auftreten wird, usw.), geht die Kartenanwendung über zu dem Zustand 9710. Wenn die Kartenanwendung bestimmt, von dem ersten Ansichtsmodus zu dem zweiten Ansichtsmodus überzugehen (z. B. die Kartenanwendung tritt in einen Zoomlevel ein, welcher den zweiten Ansichtsmodus erfordert, die Anwendung tritt in den Navigationsmodus ein usw.) geht die Kartenanwendung zu dem Zustand 9760 über.
Wenn die Kartenanwendung zu dem Zustand 9760 übergeht, führt die Kartenanwendung die Mischungsoperation aus durch Ausführen einer Quermischung (cross blend) der 3D-Kartenansichten der ersten 3D-Karte, welche unter Verwendung der ersten virtuellen Kamera gerendert wurden, mit den 3D-Kartenansichten der zweiten 3D-Karte, welche unter Verwendung der zweiten virtuellen Kamera gerendert wurden. In einigen Ausführungsformen rendert die Kartenanwendung die 3D-Kartenansichten der ersten 3D-Karte zuerst und rendert dann die 3D-Kartenansichten der zweiten 3D-Karte. Die Kartenanwendung einiger Ausführungsformen wechselt wiederholt zwischen dem Rendern einer 3D-Kartenansicht der ersten 3D-Karte und dem Rendern einer 3D-Kartenansicht der zweiten 3D-Karte für die Mischungsoperation. Sobald die Mischungsoperation fertig gestellt ist, geht die Kartenanwendung über zu dem Zustand 9770.
Bei dem Zustand 9770 stellt die Kartenanwendung den zweiten Ansichtsmodus als den ersten Ansichtsmodus ein und geht zurück über zu dem Zustand 9710. Weil die Kartenanwendung zwischen dem ersten und dem zweiten Ansichtsmodus beliebig oft wechseln kann, kehrt die Kartenanwendung zu dem Zustand 9710 zurück, um den zweiten Ansichtsmodus vorzuladen, um fortzufahren, die nahtlosen Übergänge zwischen den zwei Ansichtsmodi bereitzustellen.
C. Bildverarbeitungspipeline
98 zeigt konzeptionell eine Verarbeitungspipeline 9800, welche durch die Kartenanwendung einiger Ausführungsformen ausgeführt wird, um eine Karte zur Anzeige an der Clientvorrichtung zu rendern (z. B. auf der Anzeige der Clientvorrichtung). Wie gezeigt umfasst die Verarbeitungspipeline 9800 einen Anfrager 9805, einen Lader/Dekomprimierer 9810, einen Kachelprozessor 9850, einen Satz von Netzerzeugern 9815, einen Kachelprovider 9820, eine virtuelle Kamera 9880 und eine Kartenrendering-Engine 9825.
Der Kachelprozessor 9850 einiger Ausführungsformen empfängt Anfragen nach Kartenkacheln von den Netzerzeugern 9815 und führt eine Multiplexing-Operation vor Weiterleiten der Anfragen aus. Die Netzerzeuger 9815, wie unten beschrieben werden wird, identifizieren existierende Kartenkacheln (welche auf einem Kartendienstserver oder in einem Cache auf der Vorrichtung gespeichert sind, welche die Verarbeitungspipeline 9800 ausführt), welche notwendig sind zum Erzeugen ihrer jeweiligen Netze. In einigen Ausführungsformen werden die Kartenkacheln als Knoten eines Quadtrees referenziert. Der Kachelprozessor agiert als ein Multiplexer, wenn mehrere Netzerzeuger die gleiche Kachel anfragen. Während die Netzerzeuger Kacheln anfragen, in einigen Ausführungsformen, speichert der Kachelprozessor 9850 diese Kacheln in seiner Queue. Nach entweder einer speziellen Zeitperiode oder nachdem eine spezielle Anzahl von Kacheln angefragt worden ist, leert der Kachelprozessor 9850 die Queue und sendet die Kachelliste an den Lader/Dekomprimierer 9810.
Der Lader/Dekomprimierer 9810 empfängt die gemultiplexte Kachelliste 9835 von dem Kachelprozessor 9850 und handhabt die Rückgabe der dekomprimierten Kacheln 9845 an den Kachelprozessor 9850. In einigen Ausführungsformen überprüft der Lader/Dekomprimierer 9810 zuerst einen oder mehrere Caches, um zu bestimmen, ob sie die angefragten Kacheln auf der Vorrichtung gespeichert haben, auf welcher die Kartenanwendung betrieben wird. Wie gezeigt, umfassen einige Ausführungsformen sowohl einen ersten Kachelcache 9853, welcher auf nichtflüchtigem Speicher gespeichert ist (z. B. Disk, Flashspeicher usw.) sowie einen zweiten Kachelcache 9854, welcher in flüchtigem Speicher gespeichert ist (z. B. Speicher mit wahlfreiem Zugriff). Wenn der Lader/Dekomprimierer 9810 die Kacheln in einem der Caches 9853 und 9854 findet, sendet er diese Kacheln zurück zu dem Kachelprozessor 9850 (zurück an den (die) anfragenden Netzerzeuger 9815).
Wenn der Lader/Dekomprimierer 9810 nicht die Kacheln in seinem Cache hat, sendet er eine Anfrage an den Anfrager 9805 für die verbleibenden Kacheln. Nach Empfangen dieser Kartenkacheln 9840 in einem komprimierten Format, dekomprimiert der Lader/Dekomprimierer die empfangenen Kacheln, um dekomprimierte Kacheln 9845 zu erzeugen. In einigen Ausführungsformen, nach Erzeugen der Kartenkacheln wie oben beschrieben, komprimiert der Kartendienst auch die Kacheln unter Verwendung einer Codiertechnik. Unterschiedliche Ausführungsformen verwenden unterschiedliche Codiertechniken. Der Lader/Dekomprimierer 9810 gibt diese dekomprimierten Kacheln 9845 an den Kachelprozessor 9850 zurück, und in einigen Fällen speichert er diese auch in einem oder beiden der Kachelcaches 9853 und 9854.
Der Anfrager 9805 in einigen Ausführungsformen empfängt Anfragen für Kartenkacheln von dem Lader/Dekomprimierer 9810 (welcher wiederum die Anfragen von dem Kachelprozessor 9850 empfängt). Diese Kartenkacheln werden in einigen Ausführungsformen auf einem Server gespeichert (z. B. einem Server des Kartendienstes, mit welchem die Benutzervorrichtung verbindet). Der Anfrager sendet eine Kachelliste 9836 (empfangen von dem Lader/Dekomprimierer 9810), welche die Kacheln, welche von dem Kartendienst benötigt werden) identifiziert (und nicht in den Kachelcaches 9853 und 9854 verfügbar sind). In einigen Ausführungsformen zieht der Anfrager Vorteil aus den Netzwerkverbindungen der operierenden Vorrichtung (z. B. einer WiFi-Verbindung, einer GSM-Verbindung usw.), um den Kartendienst über das Internet zu kontaktieren zum Abrufen der benötigten Kartenkacheln. Nach Empfangen der Kacheln (in einer komprimierten Form) von dem Kartendienst, gibt der Anfrager 9805 die komprimierten Kacheln 9840 an den Lader/Dekomprimierer zurück.
In einigen Ausführungsformen identifiziert der Anfrager 9805 (oder der Kachelprozessor 9850 oder ein unterschiedlicher Teil der Pipeline) die Kacheln bei zusätzlichen Zoomleveln, welche den gesamten geografischen Bereich abdeckt, als die ursprünglich angefragten Kacheln und fügt diese Kacheln zu der Anfrageliste 9836 hinzu, sodass die Kacheln verfügbar sein werden, wenn sie in der nahen Zukunft benötigt werden. Zusätzlich fragen einige Ausführungsformen automatisch Kacheln an der gleichen (oder unterschiedlichen Zoomleveln) für nahe geografische Regionen an, um die Kacheln verfügbar zu haben im Fall, dass der Benutzer die Karte schwenkt. In einigen Ausführungsformen wirken der Anfrager 9805, der Lader/Dekomprimierer 9810 und der Kachelprozessor 9850 als ein unabhängiger Teil der Verarbeitungspipeline, mit den Netzerzeugern 9815 als die ”Clients” dieses Abschnitts.
Die Netzerzeuger 9815 (auch als Kachelquellen bezeichnet) von einigen Ausführungsformen sind durch den Kachelanbieter 9820 instanziiert, um unterschiedliche Schichten der virtuellen Kartenkacheln zu erzeugen. Abhängig von der durch die Kartenanwendung dargestellten Art der Karte kann der Kachelanbieter 9820 unterschiedliche Anzahlen und Typen von Netzerzeugern 9815 instanziieren. Zum Beispiel für eine Überflug-(oder Satelliten)-Ansichtskarte könnte der Kachelanbieter 9820 nur einen Netzerzeuger 9815 instanziieren, da die Überflug-Kartenkacheln einiger Ausführungsformen keine mehrfache Datenschichten enthalten. Genau genommen enthalten in einigen Ausführungsformen die Überflug-Kartenkacheln ein bereits erstelltes Netz, generiert in dem Kartendienst, für welchen die Überflugbilder (aufgenommen durch einen Satelliten, ein Flugzeug, einen Helikopter usw.) als Texturen verwendet werden. Allerdings können in einigen Ausführungsformen zusätzliche Netzerzeuger instanziiert werden, um die Bezeichnungen zu erzeugen, die über die Überflugbilder zu legen sind, wenn die Anwendung in einem Hybridmodus ist. Die Erzeugung von Überflugkarten einiger Ausführungsformen ist beschrieben in der PCT-Anmeldung PCT/EP2011/054155 mit dem Titel „3D Streets”. Die PCT-Anmeldung PCT/EP2011/054155 wird hierin durch Verweis aufgenommen. Für eine 2D- oder 3D-gerenderte Vektorkarte (z. B. eine Nicht-Satelliten-Bildkarte) instanziieren einige Ausführungsformen separate Netzerzeuger 9815, um die Netze für die Polygondaten der Landbedeckung (z. B. Parks, Gewässer, usw.), Straßen, Markierungen von Plätzen von Interesse, Punktbezeichnungen (z. B. Bezeichnungen für Parks, usw.), Straßenbezeichnungen (z. B. Straßenbezeichnungen im Karten-Durchsuchen-Modus (map browsing modus) und Straßenzeichen im Navigationsmodus), Verkehr (wenn Verkehr angezeigt wird), Gebäude, Rasterdaten (für bestimmte Objekte bei bestimmten Zoomstufen) sowie andere Datenschichten, die in die Karte einzugliedern sind, zu erzeugen.
Die Netzerzeuger 9815 empfangen in einigen Ausführungsformen ”leere” virtuelle Kartenkacheln 9860 von dem Kachelanbieter 9820 und geben ”erzeugte” virtuelle Kartenkacheln 9865 an den Kachelanbieter 9820 zurück. Das heißt, der Kachelanbieter 9820 sendet zu jedem Netzerzeuger 9815 eine oder mehrere virtuelle Kartenkacheln 9860. Jede der virtuelle Kartenkacheln 9860 gibt einen Bereich der Welt an, für welchen ein Netz gezeichnet werden soll. Beim Empfangen solch einer virtuelle Kartenkachel 9860, identifiziert ein Netzerzeuger 9815 die vom Kartendienst benötigten Kartenkacheln und sendet seine Liste zum Prozessor 9850.
Beim Zurückempfangen der Kacheln von den Prozessor 9850 verwendet der Netzerzeuger in den Kacheln gespeicherte Vektordaten, um ein Polygonnetz für den von der virtuellen Kartenkachel beschriebenen Bereich zu erzeugen. In einigen Ausführungsformen verwendet der Netzerzeuger 9815 mehrere unterschiedliche Funktionen, um das Netz zu erzeugen. Diese Funktionen umfassen den Netzgenerator 9816, den Triangulator 9817, den Schattengenerator 9818 und den Texturdecodierer 9819. In einigen Ausführungsformen sind diese Funktionen (und zusätzliche Netzerzeugungsfunktionen) jedem Netzerzeuger verfügbar, wobei unterschiedliche Netzerzeuger 9815 unterschiedliche Funktionen verwenden.
Zum Beispiel können die Netzerzeuger, welche für die Gebäudeschichten verantwortlich sind, einen Netzgenerator 9816 und einen Triangulator 9817 verwenden. Zusätzlich können einige unterschiedliche Typen von Schattengeneratoren für den Netzerzeuger 9815 verfügbar sein einschließlich einem ersten Schattengenerator zum Erzeugen von dynamischen Schatten (welche sich ändern, während die Karte rotiert) und einen zweiten Schattengenerator zum Erzeugen eines Rasterbildschlagschattens (raster image drop shadow).
Der Netzgenerator 9816 erzeugt ein Netz von Knoten unter Verwendung der Kachelvektordaten in einigen Ausführungsformen. Der Triangulator 9817 erzeugt Dreiecke aus dem Netz, um das eventuelle Rendern zu vereinfachen. Der Schattengenerator 9818 fügt Schatten zu dem Netz hinzu (z. B. durch Bezeichnen von Knoten und/oder Polygonen mit Werten, welche dem Renderer anzeigen einen Schatten zu zeichnen, oder wie dunkel ein Schatten zu zeichnen ist. Der Texturdecodierer 9819 decodiert Texturinformation (z. B. von einem Stylesheet) und wendet die Texturinformation auf das Netz an. In unterschiedlichen Ausführungsformen kann die Texturinformation Farben, Muster usw. anzeigen zum Hinzufügen zu den Polygonen, wenn gerendert, welches in das Netz codiert wird. Nach Erzeugen seines Netzes, gibt jeder Netzerzeuger 9815 seine virtuellen Kartenkacheln 9865 an den Kachelprovider 9820 mit seiner aufgefüllten Schicht des Netzes zurück.
In einigen Ausführungsformen kann die Texturinformation bestimmt werden basierend auf Stylesheetdaten 9855. Des Weiteren verwenden einige Ausführungsformen auch diese Stylesheetdaten 9855 zum Bestimmen des Schattens, Triangulation und/oder Netzkonstruktionsdaten. Verwenden von stylesheetgetriebenem Rendering ermöglicht einfache Modifikation vieler Aspekte der Kartenausgabe, weil Änderungen einer Textur, Farbe usw. über eine kleinere Modifikation eines Stylesheets gemacht werden können. Als ein Ergebnis können Texturen dynamisch on the fly erzeugt werden. Ein beispielhafter Vorteil des stylesheetgetriebenen Renderings ist die Ermöglichung der Verwendung unterschiedlicher Texturen für bestimmte Typen von Objekten bei unterschiedlichen Zoomleveln oder geografischen Regionen. Zum Beispiel, wenn betrachtet bei einem niedrigen Zoomlevel (weniger Detail), könnten einige Ausführungsformen einen Park mit einem einfachen hellen Grün einfärben. Auf der anderen Seite, während der Benutzer hin zu einem höheren Zoomlevel zoomt (mehr Details), zeigen die Stylesheets an ein Muster (z. B. ein Laubmuster) auf die Parkregion anzuwenden. In ähnlicher Weise könnten Muster bei höheren Zoomleveln zu Gebäuden, Gewässern, Asphalt, urbanen Geländeoberflächen usw. hinzugefügt werden. Diese Information kann in ein Stylesheet codiert werden und dann fügt der Netzerzeuger einfach die geeignete Texturinformation einem Kachelnetz basierend auf dem Zoomlevel der Kachel hinzu.
Durch Kennzeichnen von Straßen (z. B. als urban, suburban oder ländlich), kann der Kartendienst die Clientanwendung veranlassen, unterschiedliche Texturen für die Geländeoberflächenregionen um diese Straßen zu verwenden. Zusätzlich können die Geländeoberflächenregion Kennzeichnungen durch den Server basierend auf Metriken aktualisiert werden, welche indikativ für die Sorte von Bereich sind, welcher durch die Geländeoberflächenregion abgedeckt wird. Zum Beispiel bestimmen einige Ausführungsformen (auf der Kartendienstseite) die Dichte von mobilen Vorrichtungen innerhalb der Region (z. B. basierend auf der Anzahl von Vorrichtungen, welche auf den Kartendienst zugreifen) und erzeugen Kennzeichnungen für die Geländeoberfläche. Die Stylesheets, welche durch die Clientvorrichtung gespeichert werden (welche von dem Kartendienst in einigen Ausführungsformen aktualisiert werden können) zeigen dann an, wie diese Geländeoberflächenregionen zu zeichnen sind. In ähnlicher Weise können unterschiedliche Stile verwendet werden zum Rendern von Aspekten von unterschiedlichen Regionen (z. B. Wüste, Wald, steinig, usw. für Geländeoberflächen; unterschiedliche Farben für Bezeichnungen in unterschiedlichen Staaten; unterschiedliche Farben, Texturen und/oder Umhüllungen für unterschiedliche Straßen oder andere solche Unterscheidungen).
99 zeigt die Anwendung unterschiedlicher Texturen auf unterschiedliche Typen von Straßen für einige Ausführungsformen. Insbesondere zeigt diese Figur eine Kartendarstellung 9900 in der Kartenanwendung einiger Ausführungsformen, welche eine Autobahnauffahrt zeigt. In diesem Fall identifiziert die Anwendung die Straße, welche als eine Autobahn markiert ist, und die Straße, welche als eine Auffahrt markiert ist, und verwendet das Stylesheet zum Bereitstellen von unterschiedlichen Texturen (in diesem Fall, Asphaltschatten) für unterschiedliche Typen von Straßen.
Einige Ausführungsformen bezeichnen Straßen als dominant oder nicht dominant und rendern die Straßen entsprechend unterschiedlich. Zum Beispiel könnten Hauptstraßen als dominant im Vergleich zu Verbindungs-(z. B. Wohn-)straßen betrachtet werden. 100 zeigt eine Kartendarstellung 10000, welche eine Hauptstraße und zwei Verbindungsstraßen umfasst. In diesem Fall wird die Hauptstraße als die dominante Straße betrachtet und daher zeichnet die Anwendung die Hauptstraße größer und mit einer unterschiedlichen, prominenteren Umhüllung. Zusätzlich färbt in einigen Ausführungsformen die Anwendung die Hauptstraße dunkler, sodass sie prominenter heraussticht. In einigen Ausführungsformen zeigen 99 und 100 das Rendern von Straßen unter Verwendung von immersiven Navigationskacheln, in welchen die Straßen als 3D-Polygone definiert sind. In einigen solchen Ausführungsformen zeigen die Navigationskacheln an, welche Straßenumhüllung angezeigt werden sollte, über Zeichnung der Straßenpolygoneckpunkte.
Die Kartenkacheln einiger Ausführungsformen (für nicht-immersive Kartenbrowsingansicht, statt immersiver Navigationsansicht), auf der anderen Seite speichern die Straßendaten als Vektoren (d. h. eindimensionale Konstrukte). Die Kartenanwendung rendert nichtsdestotrotz einige der Straßen unterschiedlich einschließlich des Renderns von dominanten Straßen (z. B. Hauptstraßen) unterschiedlich von nicht dominanten Straßen. 101 zeigt eine nicht-immersive Kartendarstellung 10100, welche das Rendern von Straßen in einer Kartenkachel zeigt, in Kartenbrowsingansicht. In diesem Fall ist eine der Straßen als dominant klassifiziert und daher ist das Netz, welches für die Straße gebildet wird, unterschiedlich von den anderen umgebenden Straßen. Die dominante Straße wird als dunkler und dicker als die anderen umgebenden Straßen in einigen Ausführungsformen angezeigt.
Einige Ausführungsformen bestimmen dynamisch, welche Straßen innerhalb der Karte dominant sind und zeigen die dominanten Straßen unterschiedlich von den nicht dominanten Straßen innerhalb der Karte an (z. B. durch unterschiedliches Einfärben der Straßen, Zeichnen der dominanten Straßen dicker als die nicht dominanten Straßen, unter Verwendung von unterschiedlichen Umhüllungen für die dominanten Straßen usw.). Um zu bestimmen, welche Straßen innerhalb einer Karte dominant sind, verwenden einige Ausführungsformen Daten, welche über den Typ von Straßen, die für die Karte zu zeichnen sind, bereitstellen. Zum Beispiel können Straßen als Autobahnen, Hauptstraßen und Nichthauptstraßen klassifiziert werden, mit Subklassifikationen in einigen Ausführungsformen. Im Allgemeinen sind Hauptstraßen größere Straßen und führen mehr Verkehr als Nichthauptstraßen, und tendieren dazu, die Vorfahrt bei Verkehrskreuzungen mit Nichthauptstraßen zu haben. Somit, wenn eine Kartenanzeige sowohl Hauptstraßen als auch Nichthauptstraßen hat, zeichnen einige Ausführungsformen die Hauptstraßen als dominant. Andererseits, wenn eine Kartenanzeige keine Hauptstraßen hat, wählt die Kartenanwendung einiger Ausführungsformen einige der Nichthauptstraßen, welche zu zeichnen sind, als dominante Straßen aus. Jedoch, statt nur den tatsächlichen Teil der Karte zum Anzeigen für Hauptstraßen zu untersuchen, identifizieren einige Ausführungsformen auch Straßen, welche innerhalb einer Region eine spezielle Distanz um die Karte angeordnet sind. Wenn die Hauptstraßen innerhalb dieser Region präsent sind, dann zeichnet die Anwendung keine der Nichthauptstraßen als dominant, um zu vermeiden die Erscheinung der Straße plötzlich ändern zu müssen, wenn die Hauptstraße in die Kartenanzeige eintritt.
Der Kachelanbieter 9820 empfängt vom Steuergerät 9875 eine bestimmte Ansicht (d. h. einen Raum oder eine Pyramidenstumpfansicht (viewing frustum), die die anzuzeigende Kartenansicht darstellt (d. h. der von der virtuellen Kamera 9880 aus sichtbare Raum). Der Kachelanbieter führt jegliches Auswählen durch (z. B. den in einer virtuellen Kartenkachel anzuzeigenden Oberflächenbereich zu identifizieren), und sendet dann diese virtuellen Kartenkacheln 9860 zu den Netzerzeugern 9815.
Der Kachelanbieter 9820 empfängt anschließend die erstellten virtuellen Kartenkacheln 9865 von den Netzerzeugern und führt in einigen Ausführungsformen das Auswählen auf dem erstellten Netz unter Verwendung einer bestimmten Ansicht von der virtuellen Kamera 9880 durch (z. B. Entfernen eines zu weit entfernten Oberflächenbereichs, Entfernen von Objekten, die komplett hinter anderen Objekten sein werden usw.). In einigen Ausführungsformen empfängt der Kachelanbieter 9820 die erstellten virtuellen Kartenkacheln 9865 von unterschiedlichen Netzerzeugern zu unterschiedlichen Zeiten (z. B. aufgrund von unterschiedlichen Verarbeitungszeiten, um die mehr oder weniger komplizierten Netze zu vervollständigen, aufgrund von unterschiedlich verstrichener Zeit bevor die notwendigen Kartenkacheln von dem Kachelprozessor 9850 empfangen wurden usw.). Sobald alle der Schichten der virtuellen Kartenkacheln zurückgegeben sind, setzt der Kachelanbieter 9820 einiger Ausführungsformen die Schichten zusammen und gibt die Daten dem Steuergerät 9875 zum Rendern frei.
In einigen Ausführungsformen kann der Kachelprovider 9820 bereits ein neues virtuelles Kameravolume empfangen haben, für welches ein Netz zu bilden ist, bevor die Netzerzeuger ihre Daten zurückgegeben haben.
Zum Beispiel, wenn der Benutzer schnell eine Karte schwenkt oder zoomt, können die Daten, welche durch die Netzerzeuger zurückgegeben werden, veraltet sein. In einigen Ausführungsformen lässt der Kachelprovider entweder die gebildeten virtuellen Kartenkachelschichten fallen oder speichert diese im Speicher. Ob die gebildeten virtuellen Kartenkacheln fallen gelassen werden, ist in unterschiedlichen Ausführungsformen abhängig davon, ob es wahrscheinlich ist, dass die gebildeten Kacheln bald benötigt werden (z. B. wie viel der Benutzer die Kamera bewegt hat, ob eine Navigation läuft, welche es unwahrscheinlich macht, dass die Anwendung die älteren Daten anzeigen wird) und die Menge von Speicher, welcher derzeitig in Verwendung ist.
Die virtuelle Kamera 9880 generiert einen Raum oder eine Oberfläche, zum Rendern für die Pipeline 9800 und sendet diese Informationen zu dem Steuergerät 9875. Basierend auf einem/einer bestimmten Ort und Ausrichtung, von welcher die Karte gerendert werden wird (d. h. der Punkt im 3D-Raum, von welchem der Benutzer die Karte ”sieht”), identifiziert die virtuelle Kamera ein Sichtfeld zum tatsächlichen Senden zum Kachelanbieter 9820. In einigen Ausführungsformen, wenn die Kartenanwendung die 3D-perspektivische Ansicht für die Navigation rendert, wird das Sichtfeld der virtuellen Kamera entsprechend einem Algorithmus, der einen neuen Ort und eine neue Ausrichtung der virtuellen Kamera in regelmäßigen Intervallen basierend auf der Bewegung der Benutzervorrichtung generiert, bestimmt.
Das Steuereinheit 9875 ist in einigen Ausführungsformen verantwortlich für das Verwalten des Kachelabrufers 9820, der virtuellen Kamera 9830 und der Kartenrendering-Engine 9825. In einigen Ausführungsformen können in der Tat mehrere Kachelanbieter initiiert werden und das Steuergerät mehrere virtuellen Kartenkacheln zusammensetzen (z. B. Kartenkacheln und Gebäudekacheln), um eine Szene zu erschaffen, die der Kartenrendering-Engine 9825 übergeben wird.
Die Kartenrendering-Engine 9825 ist verantwortlich für die Erzeugung einer Zeichnung, um diese auf einer Bildschirmvorrichtung auszugeben, basierend auf den Netzkacheln 9865, die von der virtuellen Kamera gesendet werden. Wie gezeigt hat die Kartenrendering-Engine 9825 einiger Ausführungsformen mehrere Unterprozesse. In einigen Ausführungsformen wird jedes unterschiedliche Element von einem unterschiedlichen Unterprozess gerendert mit der Rendering-Engine 9825, die die Okklusion von unterschiedlichen Schichten von Objekten handhabt (z. B. Platzieren von Bezeichnungen über oder hinter unterschiedlichen Gebäuden, Erzeugen von Straßen auf Landbedeckungen usw. Diese Figur zeigt einen Straßenrenderingprozess 9826, einen Gebäuderenderingprozess 9827, und einen Bezeichnungsrenderingprozess 9828. Beispiele von zusätzlichen Prozessen umfassen einen Vegetationsrenderingprozess, einen Verkehrsrasterrenderingprozess, einen Straßenrasterrenderingprozess, einen Satellitenrenderingprozess, einen Polygonrenderingprozess, einen Hintergrundrasterrenderingprozess usw.
Jeder der Renderingprozesse umfasst einen Satz von Renderingparametern; gezeigt sind Straßenparameter 9836, Gebäudeparameter 9837 und Bezeichnungsparameter 9838. In einigen Ausführungsformen umfassen diese Daten Informationen darüber, wie die Straßen zu rendern sind (z. B. Shader-Information, Texturen, welche zu verwenden sind für unterschiedliche Typen von Straßen, usw.).
In einigen Ausführungsformen werden diese Sätze von Renderingparametern zumindest teilweise durch eine Rendering-Engine-Vorbereitungsoperation 9870 erzeugt. Die Rendering-Engine-Vorbereitungsoperation 9870 umfasst einen Shader-Compiler 9871 und einen Textur-Loader 9872 neben anderen Operationen. Der Shader-Compiler 9871 kompiliert die Shader, welche die Rendering-Engine verwenden wird, und der Textur-Loader 9872 lädt Texturinformation (z. B. in die Renderingparameter). Diese Texturinformation kann von den Stylesheetdaten 9855 in einigen Ausführungsformen kommen.
Die Funktionsweise der Rendering-Pipeline 9800 in einigen Ausführungsformen wird nun beschrieben werden. Basierend auf Benutzereingaben, um eine bestimmte Kartenregion in einer bestimmten Zoomstufe anzusehen, spezifiziert die virtuelle Kamera 9880 einen Ort und eine Ausrichtung, von welcher aus die Kartenregion anzusehen ist, und sendet diese Pyramidenstumpfansicht oder diesen Raum zum Steuergerät 9875. Das Steuergerät 9875 instanziiert einen oder mehrere Kachelanbieter. Während ein Kachelanbieter 9820 in dieser Figur gezeigt wird, erlauben andere Ausführungsformen die Instanziierung von mehreren Kachelanbietern auf einmal (z. B. wie unten gezeigt in 102). Zum Beispiel instanziieren einige Ausführungsformen separate Kachelanbieter für Gebäudekacheln und für Kartenkacheln.
Der Kachelanbieter 9820 führt jegliche notwendige Auswahl durch, um eine leere virtuelle Kartenkachel zu erzeugen, die die Regionen der Karteregion, für welche ein Netz erstellt werden muss, identifiziert, und sendet die leeren virtuellen Kartenkacheln 9860 an die Netzerzeugern 9815, welche für die unterschiedlichen Schichten der gezeichneten Karte instanziiert werden (z. B. Straßen, Landbedeckung, Punkt-von-Interesse-Bezeichnungen, usw.). Die Netzerzeuger 9815 verwenden ein vom Kartendienst empfangenes Manifest, das die unterschiedlichen verfügbaren Kacheln auf dem Kartendienstserver identifiziert (d. h. als Knoten eines ”Quadtrees”). Die Netzerzeuger 9815 fragen spezifische Kartenkacheln von den Kachelprozessor 9850 an, welcher alle doppelten Anfragen entfernt und die Kachelliste 9835 an den Lader/Dekomprimierer 9810 sendet.
Der Lader/Dekomprimierer 9810 bestimmt, ob die angefragten Kacheln in den Kachelcaches gespeichert sind (entweder der nichtflüchtige Speichercache 9853 oder der flüchtige Speichercache 9854), und gibt irgendwelche solcher Kacheln an den Kachelprozessor 9850 zur Verteilung an die anfragenden Netzerzeuger 9815 zurück. Für alle Kacheln, welche nicht bereits lokal gespeichert sind, sendet der Lader/Dekomprimierer 9810 eine Anfrage an den Anfrager 9805, welcher die Kachelliste 9836 (eine abgespeckte Version der Kachelliste 9835) an einen entfernten Kartendienstserver sendet. Der Anfrager 9805 empfängt die angefragten Kartenkacheln in komprimierter Form 9840 von dem Kartendienst und leitet sie an den Lader/Dekomprimierer 9810 weiter. Der Lader/Dekomprimierer 9810 dekomprimiert (z. B. decodiert) diese Kacheln, speichert sie in seinem/seinen Cache(s), und sendet die dekomprimierten Kacheln 9845 an den Kachelprozessor 9850 zur Rückgabe an den Netzerzeuger 9815.
Sobald ein bestimmter Kartenerzeuger 9815 seine Kartenkacheln empfangen hat, beginnt er unter Verwendung der Vektordaten, die in den Kartenkacheln gespeichert sind, das Netz für die von dem Kachelanbieter 9820 gesendeten virtuellen Kartenkacheln zu erzeugen. Nach dem Erzeugen des Netzes seiner Kartenschicht sendet der Netzerzeuger 9815 die erstellte virtuelle Kartenkachel 9865 zurück zu dem Kachelanbieter 9820. Der Kachelanbieter 9820 wartet bis er alle virtuellen Kartenkacheln der verschiedenen Netzerzeuger 9815 empfangen hat, dann schichtet er diese zusammen und sendet die vollständige virtuelle Kartenkachel an das Steuergerät 9875. Das Steuergerät fügt die zurückgegebenen Kacheln von allen Kachelanbietern zusammen (z. B. eine virtuelle Kartenkachel und eine virtuelle Gebäudekachel) und sendet diese Szene zu der Rendering-Engine 9825. Die Kartenrendering-Engine 9825 verwendet die Information in den Kartenkacheln, um die Szene zum Anzeigen zu zeichnen.
Die obige Pipeline ist für eine einzelne Szene von einer einzelnen virtuellen Kamera gezeigt. Einige Ausführungsformen instanziieren tatsächlich mehrere virtuelle Kameras und mehrere Kachelprovider gleichzeitig, um in der Lage zu sein, schnell von einer Szene zu der anderen zu wechseln, oder von einer Ansicht einer Szene zu einer anderen (z. B. Wechseln zwischen unterschiedlichen Zoomleveln oder von einer nicht-immersiven 3D-Kartenansicht in eine immersive 3D-Kartenansicht, um in die Navigation einzutreten). 102 zeigt konzeptionell eine Steuereinheit 10200, welche zwei virtuelle Kameras 10205 und 10210 für zwei unterschiedliche Ansichten von Kartenregionen instanziiert. Wie gezeigt stellt die erste virtuelle Kamera eine nicht-immersive 3D-Ansicht einer ersten Kartenregion bereit, während die zweite virtuelle Kamera eine immersive 3D-Ansicht einer zweiten Kartenregion bereitstellt. Die ersten und zweiten Kartenregionen könnten einfach unterschiedliche Ansichten der gleichen Kartenregion sein, oder Ansichten von unterschiedlichen Regionen einer Karte. In unterschiedlichen Ausführungsformen könnten die zwei virtuellen Kameras 10205 und 10210 Ansichten einer Kartenregion aus unterschiedlichen Zoomleveln bereitstellen, unterschiedliche Orte und Orientierungen spezifizieren, aus welchen die Kartenregion zu betrachten ist.
Anfangs empfängt die Steuereinheit 10200 die Szene von der ersten virtuellen Kamera 10205 und instantiiert den nicht-immersiven 3D-Kartenkachelprovider 10215 und den Gebäudekachelprovider 10220, um eine nicht-immersive 3D-Karte mit Gebäuden anzuzeigen. Jeder dieser Kachelprovider instantiiert seinen erforderlichen Satz von Netzerzeugern 10225 und 10230, um die virtuellen Kartenkacheln für die nicht-immersive 3D-Szene zu bilden. Sobald die Steuereinheit diese virtuellen Kacheln von den Kachelprovidern 10215 und 10220 empfangen hat, fügt die Steuereinheit 10200 diese zusammen, um eine Szene 10235 zu bilden. Sobald die Steuereinheit eine Anzeige empfängt, dass die Anwendung von dem nicht-immersiven Ansichtsmodus zu dem immersiven Ansichtsmodus wechseln könnte (z. B. wenn ein Benutzer eine Route eingibt mit der Option in die Navigation einzutreten), instantiiert die Steuereinheit 10200 die zweite virtuelle Kamera 10210, um eine Ansicht einer Kartenregion bereitzustellen. Basierend darauf, instantiiert die Steuereinheit den immersiven 3D-Kachelprovider 10240, welcher wiederum seinen Satz von Netzerzeugern 10245 instantiiert. Während des Instantiierens der immersiven 3D-Pipeline, fährt die Steuereinheit fort damit, die nicht-immersive 3D-Szene 10235 an die Rendering-Engine 10250 bereitzustellen. Sobald die Steuereinheit 10200 (i) die gebildeten virtuellen Kartenkacheln von dem immersiven 3D-Kachelprovider 10240 empfangen hat und (ii) einen Befehl empfangen hat zum Eintreten in den immersiven 3D-Modus (z. B. weil der Benutzer Navigation einer Route gestartet hat), beginnt die Steuereinheit die immersive 3D-Szene 10255 an die Rendering-Engine 10250 bereitzustellen. In einigen Ausführungsformen werden die virtuellen Gebäudekacheln, welche von dem Gebäudekachelprovider 10220 empfangen werden, für sowohl die immersiven als auch die nicht-immersiven 3D-Szenen verwendet.
103 zeigt konzeptionell einen Prozess 10300 einiger Ausführungsformen zum Vorladen von Navigationskacheln, um in Navigation einzutreten. Der Prozess 10300 wird mit Verweis auf 104 beschrieben werden, welche eine Vorrichtung 10400 zeigt, welche eine Kartenanwendung anzeigt, während die Anwendung von einer nicht-immersiven Kartenansicht zum Kartenbrowsen in eine immersive Kartenansicht zur Navigation übergeht, über sechs Stufen 10405 bis 10430.
Wie gezeigt beginnt der Prozess 10300 durch Anfragen (bei 10305) von Routeninstruktionen. In einigen Ausführungsformen kann dies auftreten, wenn ein Benutzer einen Ort auf einer Karte auswählt und dann eine ”Routen”-Taste auswählt (z. B. eine Taste in der Form eines Autos in der Beschriftung, welche für den Ort angezeigt wird) zum Anfragen einer Route von dem derzeitigen Ort des Benutzers zu dem ausgewählten Ort. Ein Benutzer könnte auch ein Suchfeld verwenden zum Suchen nach einer Route von dem derzeitigen Ort des Benutzers zu dem ausgewählten Ort. In Antwort auf die Benutzereingabe sendet die Kartenanwendung die Anfrage für nach den Routeninstruktionen an einen Kartendienst heraus. Die erste Stufe 10405 von 104 zeigt einen Benutzer, welche eine Schnell-Routen-Taste für einen Ort ”Pizza Place” auswählt, um eine Route von dem derzeitigen Ort des Benutzers (nahe dem Mittelpunkt des Bildschirms der Vorrichtung 10400) an den ausgewählten Ort zu erzeugen.
Nach Übertragen der Anfrage empfängt (bei 10310) der Prozess 10310 Routeninstruktionen und Navigationskacheln für zumindest einen Teil der Route. Der Kartenserver empfängt die Routenanfrage, erzeugt eine optimale Route von dem Startpunkt (z. B. dem Ort des Benutzers) zu dem Endpunkt und lädt die Routeninstruktionen an den Benutzer herunter. In einigen Ausführungsformen nimmt der Server an, dass der Benutzer wahrscheinlich den Navigationsmodus betreten wird, um entlang der Route zu reisen und lädt daher auch die Navigationskacheln herunter (d. h. die Kacheln zum Rendern der Bereiche entlang der Route von einem speziellen Hochdetaillevel-Zoomlevel).
Die Kartenanwendung einiger Ausführungsformen umfasst einen adaptiven Kachellademechanismus. In einigen Ausführungsformen lädt der adaptive Kachellademechanismus Kartenkacheln für eine definierte Distanz zu Beginn der Routennavigation herunter. Sobald der Benutzer startet entlang der Routennavigation zu reisen, erhöht die Kartenanwendung den Betrag von Kacheln, welche basierend auf Faktoren heruntergeladen werden, welche anzeigen, dass der Benutzer darauf festgelegt ist, die Route fertig zu stellen. Zum Beispiel erhöht die Kartenanwendung einiger Ausführungsformen den Betrag von Kacheln zum Herunterladen, wenn ein definiertes Distanzintervall überschritten wird. Zum Beispiel, nach jeder zehnten Meile, welche entlang der Routennavigation gereist wurde, lädt die Kartenanwendung einen erhöhten Betrag von Kartenkacheln für die kommende Route (zum Beispiel Kacheln für die nächsten 10 Meilen voraus, Kacheln für die nächsten 20 Meilen voraus usw.) herunter. Andere Techniken können verwendet werden zum adaptiven Herunterladen von Kacheln, um Leistungseinsparungen zu erhöhen (und, wenn der Benutzer nicht die Route fertig stellt, auch Herunterladezeit zu sparen).
Zurückkehrend zu 103 instanziiert (bei 10315) der Prozess 10300 als Nächstes eine Rendering-Pipeline für die Navigationskacheln, während des Anzeigens der Routeninformation. Wenn eine Route heruntergeladen wird, zeigt die Kartenanwendung eine statische Karte (in einigen Ausführungsformen entweder 2D oder 3D) an, mit der darübergelegten Route. Jedoch in dem Hintergrund bereitet die Anwendung vor Animieren zu beginnen unter Verwendung der Navigationskartenkacheln. Somit instanziiert der Prozess eine virtuelle Kamera, einen oder mehrere Kachelprovider und eine Serie von Netzerzeugern für das Navigationsrendering, und beginnt Erzeugen von virtuellen Kacheln basierend auf den heruntergeladenen Navigationskacheln.
Zusätzlich bereitet (bei 10320) der Prozess die Rendering-Engine für die Navigationskacheln vor. Wie oben beschrieben, kann diese Vorbereitung umfassen Kompilieren von Shadern zur Verwendung durch die Rendering-Engine und Laden von Texturen, auch zur Verwendung durch die Rendering-Engine. Die zweite Stufe 10410 von 104 zeigt die Kartenanwendung einer Route 10435 Anzeigen, um den Ort ”Pizza Place” zu erreichen. An diesem Punkt würde die Navigationsanwendung mit dem Herunterladen der immersiven 3D-Kacheln entlang der Route begonnen haben und mit dem Instantiieren einer Rendering-Pipeline für diese Kacheln begonnen haben, in dem Fall, dass der Benutzer sich für das Eintreten in die Navigation für diese Route entscheidet.
Der Prozess 10300 bestimmt (bei 10325) dann, ob in die Navigation einzutreten ist. Die Kartenanwendung einiger Ausführungsformen, beim Anzeigen einer Route, zeigt ein auswählbares Benutzerschnittstellenelement an, mit welchem ein Benutzer Navigation über die Route starten kann. Wenn ein Benutzer das Startelement auswählt, betritt die Anwendung dann Navigation (solange die Navigationskacheln heruntergeladen werden und das Rendern beginnen kann). Wenn der Benutzer noch nicht die Navigation betreten hat, bestimmt (bei 10330) der Prozess, ob die Route abgebrochen worden ist. Dies kann auftreten, wenn der Benutzer eine andere Suche macht (entweder nach einem unterschiedlichen Ort oder einer unterschiedlichen Route), die angezeigte Route ohne Eintreten in die Navigation schließt, die Kartenanwendung schließt, usw. Wenn der Benutzer nicht die Route abgebrochen hat, kehrt der Prozess zu 10325 zurück, um zu bestimmen, ob in die Navigation einzutreten ist. Diese zwei Operationen wirken effektiv als ein ”Warte”-Zustand, in welchem die Kartenanwendung die Route anzeigt und auf die Benutzereingabe wartet, um entweder die Route zu starten oder die Route abzubrechen (während sie auch möglicherweise auf Benutzereingabe antwortet, um Routeninstruktionen zu betrachten, die Karte entlang der Route zu bewegen, usw.
Wenn der Benutzer auswählt in die Navigation einzutreten, beginnt (bei 10335) der Prozess 10300 mit dem Rendern der Animation für die Navigationskacheln an dem Start der Route. Weil die Rendering-Pipeline bereits das Netz erzeugt hat und die Rendering-Engine vorbereitet hat, sollte die Verzögerungszeit zum Beginnen der Animation minimal sein. Ein Prozess zum Bestimmen des Pfades der virtuellen Kamera basierend auf dem Benutzerort, um die Animation zu bestimmen, wird im Detail oben beschrieben. Wenn auf der anderen Seite der Benutzer die Route abbricht, deinstanziiert (bei 10340) der Prozess die Rendering-Pipeline, auf der Annahme, dass der Benutzer nicht die Route navigieren werden wird. Einige Ausführungsformen entfernen auch die virtuellen Navigationskacheln aus dem Speicher, obwohl andere Ausführungsformen die virtuellen Navigationskacheln für eine Zeitdauer wenn möglich zwischenspeichern.
Bei der zweiten Stufe 10410 von 104 wählt der Benutzer die ”Start”-UI-Steuerung 10440 aus. Dementsprechend beginnt die Anwendung in die Navigation einzutreten, unter Verwendung der vorgeladenen immersiven 3D-Kacheln und der vorinstanziierten Rendering-Pipeline zum Beginnen des Renderns der Szene mit minimaler Verzögerung. Wie bei der dritten bis zu der sechsten Stufe 10415 bis 10430 gezeigt, verwenden einige Ausführungsformen cinematische Übergang von der 2D- (oder 3D) nicht-immersiven Kartenansicht in die 3D-immersive Kartenansicht. Die Anwendungsanzeige beginnt von ihrem derzeitigen Zustand (welcher bei 10410 gezeigt ist) und geht weich von der ersten virtuellen Kameraansicht zu der neuen virtuellen Kameraansicht über, welche mehr hereingezoomt ist und in die Richtung des Starts der Route zeigt. Auf diese Weise kann die virtuelle Kamera eine Kombination von Translation, Zoom und Rotationsoperationen ausführen, um den Start der Route für Navigation zu erreichen. Zusätzlich verwenden einige Ausführungsformen eine cross-fade-Operation zwischen der ersten virtuellen Kamera (Rendering der nicht-immersiven Kartenkacheln für Kartenbrowsen) und der zweiten virtuellen Kamera (Rendern der immersiveren Navigationskacheln zur Navigation). Wie gezeigt bei der dritten Stufe 10415 hat sich die erste virtuelle Kamera hin zum letztendlichen Ort der zweiten virtuellen Kamera bewegt, wobei die Karte nun rotiert und leicht gezoomt ist. Die nicht-immersiven Kartenkacheln sind noch gerendert zur Anzeige an diesem Punkt. In den vierten und fünften Zuständen 10420 und 10425 rendert die Kartenanwendung nun aus der Perspektive der zweiten virtuellen Kamera, wobei die immersiven Kacheln gerendert sind (wie gezeigt durch die Asphalt-Polygonstraßen). Über diese Stufen rotiert die zweite virtuelle Kamera in ihren letztendlichen Ort hinter dem Navigationsort in die Karte (d. h. dem Puck), wie in der sechsten Stufe 10430 gezeigt.
Die Karten- und Navigationsanwendung einiger Ausführungsformen führt diesen Übergang innerhalb der einzelnen integrierten Anwendung aus ohne die einzelne Anwendung zu verlassen. Das heißt, sowohl der Karten- und Routenbrowsingmodus (gezeigt in Stufen 10405 und 10410) als auch der Navigationsmodus (gezeigt in Stufen 10415 bis 10430) sind unterschiedliche Modi der gleichen integrierten Karten-, Such- und Navigationsanwendung. Würde der Benutzer die ”End”-Taste während des Navigationsmodus auswählen, würden einige Ausführungsformen zurück zu dem Kartenbrowsingmodus übergehen, entweder mit einem weichen cinematischen Übergang oder durch eine Bildschirmaktualisierung ohne Bewegung der virtuellen Kamera.
D. Integrierte Karten- und Navigationsanwendung
105 veranschaulicht konzeptionell ein Zustandsdiagramm 10500, das unterschiedliche Zustände und Übergänge zwischen diesen Zuständen der integrierten Karten-, Such- und Navigationsanwendung einiger Ausführungsformen beschreibt (z. B. die in den obigen Abschnitten beschriebene Client-seitige Anwendung). Der Fachmann wird erkennen, dass die Anwendung einiger Ausführungsformen viele unterschiedliche Zustände in Bezug auf alle unterschiedlichen Arten von Eingabeereignissen haben wird und dass das Zustandsdiagramm 10500 speziell auf eine Untermenge dieser Ereignisse fokussiert ist. Das Zustandsdiagramm 10500 beschreibt und bezieht sich auf verschiedene gestische Interaktionen (z. B. Mehrfachberührungsgesten) zum Ändern von Zuständen der Anwendung. Der Fachmann wird erkennen, dass verschiedene andere Interaktionen, so wie Gesten eines Zeigersteuergeräts und Knopfklicks, Tastatureingaben, Touchpad/Trackpad-Eingaben usw. auch für ähnliche Selektionsoperationen verwendet werden können.
Wenn ein Benutzer anfänglich die Kartenanwendung öffnet, ist die Anwendung in einem Zustand 10505, dem Kartendurchsuchungszustand. In diesem Zustand 10505 wird die Anwendung eine Kartenansicht generiert und angezeigt haben. Um diese Kartenansicht zu generieren und anzuzeigen, identifiziert die Anwendung in einigen Ausführungsformen eine notwendige Menge von Kartenkacheln für eine Region, fragt die Kartenkacheln an (z. B. von einem Kartendienstserver), generiert eine Ansicht der Kartenkacheln von einem bestimmten Ort, einer bestimmten Ausrichtung und einer bestimmten Perspektive der virtuellen Kamera und gibt die Kartenansicht auf einer Vorrichtungsanzeige wieder. Im Zustand 10505 ist die Kartenansicht statisch. Befindet sich die Anwendung im Zustand 10505, kann der Benutzer eine Vielzahl an Operationen zur Modifizierung der Kartenansicht, zum Suchen nach Einheiten (z. B. Plätze von Interesse, Adressen usw.), zum Abrufen einer Route für die Navigation, usw. durchführen.
In einigen Ausführungsformen wird die integrierte Anwendung auf einer Vorrichtung mit einer integrierten berührungsempfindlichen Anzeige angezeigt. Eine Vielzahl von gestischen Interaktionen über der Karte kann die Anwendung veranlassen, unterschiedliche Modifikationen der Kartenansicht durchzuführen (z. B. Verschieben, Rotieren, Zoomen, Ändern der Kartenperspektive usw.). Wenn die integrierte Anwendung gestische Interaktionen auf der Kartenanzeige empfängt (im Gegensatz zu Berührungseingaben auf den verschiedenen schwebenden oder nicht-schwebenden Steuerungen, die über der Kartenanzeige liegen), geht die Anwendung in den Zustand 10510 über, um eine Erkennung gestischer Eingaben durchzuführen.
Der Zustand der Erkennung gestischer Eingaben 10510 unterscheidet zwischen unterschiedlichen Arten von gestischen Eingaben und übersetzt diese Arten von Eingaben in unterschiedliche Änderungsoperationen der Kartenansicht. In einigen Ausführungsformen empfängt die Kartenanwendung die gestischen Eingaben als durch das Betriebssystem der Vorrichtung mit integrierter berührungsempfindlicher Anzeige übersetzte Eingabe. Das Betriebssystem übersetzt die Berührungseingaben in gestische Arten und Orte (z. B. ein ”Tippen” an den Koordinaten (x, y), eine ”Kneifen”-Operation mit unterschiedlichen Berührungseingaben an zwei unterschiedlichen Orten, usw.). In Zustand 10510 übersetzt die integrierte Kartenanwendung einiger Ausführungsformen diese in unterschiedliche Änderungsoperationen der Kartenansicht.
Wenn die Anwendung eine erste Art gestischer Eingaben empfängt (z. B. zwei separate Berührungseingaben, die sich zusammen in einer rotierenden Bewegung auf der Kartenansicht bewegen), geht die Anwendung in den Zustand 10515 über, um die Karte zu rotieren. Um die Kartenansicht zu rotieren, ändern einige Ausführungsformen den Ort und/oder die Ausrichtung der virtuellen Kamera, die bestimmt, welcher Anteil der Karte gerendert wird, um die Kartenansicht zu erzeugen. Zum Beispiel rotiert in einem 3D-Modus die Kartenanwendung die virtuelle Kamera um eine bestimmte Position (z. B. dem Zentrum der Berührungseingaben, dem Zentrum des Bildschirms, einem Ortsindikator, der den Ort des Benutzers identifiziert, usw.). Solange die erste Art der gestischen Eingabe weitergeht, verbleibt die Kartenanwendung im Zustand 10515, um die Karte weiter zu rotieren.
Wenn der Benutzer die erste gestische Eingabeart loslässt, geht die Anwendung von einigen Ausführungsformen in einen Zustand 10530, um eine Trägheitsberechnung durchzuführen. In einigen Ausführungsformen führt die Anwendung, nachdem der Benutzer bestimmte Arten von Berührungseingaben loslässt, weiterhin die verbundene Änderung der Kartenansicht für eine bestimmte Zeitdauer und/oder Distanz durch. In diesem Fall geht die Anwendung, nachdem der Benutzer die Rotationseingabe losgelassen hat, in den Zustand der Trägheitsberechnung 10530 über, um den zusätzlichen Rotationsanteil und die Zeit, in welcher die Rotation durchgeführt werden soll, zu berechnen. In einigen Ausführungsformen verlangsamt die Anwendung die Rotation der (Winkel)-Geschwindigkeit, in welcher die Karte rotiert wurde, als ob eine ”Reibungs”-Kraft auf die Karte angewendet wurde. Als solches basiert die Trägheitsberechnung einiger Ausführungsformen auf der Geschwindigkeit der ersten gestischen Eingabeart. Aus dem Zustand 10530 geht die Anwendung zurück zum Zustand der Kartenänderungen, in dem die Anwendung vorher war. Das heißt, wenn die Anwendung vom Zustand 10515 (dem Rotationszustand) zum Trägheitsberechnungszustand 10530 übergeht, geht sie zurück zum Zustand 10515, nachdem die Trägheitsberechnung durchgeführt wurde. Nachdem die Rotation der Karte abgeschlossen ist, geht die Anwendung zurück in den Zustand 10505.
Wenn die Anwendung eine zweite gestische Eingabeart empfängt (z. B. eine einzelne Berührungseingabe, die sich über die Karte bewegt), geht die Anwendung in einen Zustand 10520 über, um die Karte zu verschieben. Um die Kartenansicht zu verschieben, ändern einige Ausführungsformen den Ort der virtuellen Kamera, die bestimmt, welcher Anteil der Karte gerendert wird, um die Kartenansicht zu erzeugen. Dies veranlasst die Karte in eine Richtung, abgeleitet von der Richtung der zweiten gestischen Eingabeart, gleitend zu erscheinen. In einigen Ausführungsformen, wenn die Kartenansicht in einem 3D-Perspektivenmodus ist, involviert der Verschiebungsprozess die Durchführung einer Korrelation des Ortes der Berührungseingabe zu einem Ort auf der flachen Karte, um plötzliche ungewollte Sprünge in der Kartenansicht zu vermeiden. Solange die zweite gestische Eingabeart weiter anhält, verbleibt die Kartenanwendung in dem Zustand 10520, um die Karte weiter zu verschieben.
Wenn der Benutzer die zweite gestische Eingabeart loslässt, geht die Anwendung einiger Ausführungsformen in den Zustand 10530 über, um eine Trägheitsberechnung durchzuführen. In einigen Ausführungsformen führt die Anwendung, nachdem der Benutzer bestimmte Arten der Berührungseingaben losgelassen hat, weiterhin die Änderung der Kartenansicht für eine bestimmte Zeitdauer und/oder Distanz durch. In diesem Fall geht die Anwendung, nachdem der Benutzer die Verschiebungseingabe losgelassen hat, in den Trägheitsberechnungszustand 10530 über, um die zusätzliche Bewegungsmenge der Kartenansicht (d. h. Bewegung der virtuellen Kamera) und die Zeit, in welcher die Bewegung ausgeführt werden soll, zu berechnen. In einigen Ausführungsformen verlangsamt die Anwendung die Verschiebungsbewegung von der Geschwindigkeit, in welcher die Karte verschoben wurde, als ob eine ”Reibungs”-Kraft auf die Karte angewendet wurde. Als solches basiert die Trägheitsberechnung von einigen Ausführungsformen auf der Geschwindigkeit der zweiten gestischen Eingabeart. Aus dem Zustand 10530 geht die Anwendung zurück zum Kartenänderungszustand, in welchem die Anwendung vorher war. Das heißt, wenn die Anwendung vom Zustand 10520 (dem Verschiebungszustand) zu dem Trägheitsberechnungszustand 10530 übergeht, geht sie dann zurück zum Zustand 10520, nachdem die Trägheitsberechnung durchgeführt wurde. Nachdem die Verschiebung auf der Karte abgeschlossen ist, geht die Anwendung zurück in den Zustand 10505.
Wenn die Anwendung eine dritte gestische Eingabeart empfängt (z. B. zwei separate Berührungseingaben, die sich näher zusammen oder weiter auseinander bewegen), geht die Anwendung in einen Zustand 10525 über, um in die Karte hinein oder aus der Karte hinaus zu zoomen. Um die Zoomstufe der Kartenansicht zu ändern, ändern einige Ausführungsformen den Ort (d. h. Höhe) der virtuellen Kamera, die bestimmt, welcher Anteil der Karte gerendert wird, um die Kartenansicht zu erzeugen. Dies veranlasst die Kartenansicht mehr (beim Hinauszoomen) oder weniger (beim Hineinzoomen) der Karte zu beinhalten. In einigen Ausführungsformen ruft die Anwendung, indem der Benutzer hinein- oder hinauszoomt, unterschiedliche Kartenkacheln ab (für unterschiedliche Zoomstufen), um die neue Kartenansicht zu erzeugen und wiederzugeben. Während die gestische Eingabeart andauert, verbleibt die Kartenanwendung im Zustand 10525, um weiterhin die Karte zu verschieben.
Wenn der Benutzer die zweite gestische Eingabeart loslässt, geht die Anwendung einiger Ausführungsformen in den Zustand 10530 über, um eine Trägheitsberechnung durchzuführen. In einigen Ausführungsformen führt die Anwendung, nachdem der Benutzer bestimmte Arten von Berührungseingaben losgelassen hat, weiter die verbundene Kartenansichtsänderung für eine bestimmte Zeitdauer und/oder Distanz durch (d. h. die virtuelle Kamera höher oder niedriger bewegen). In diesem Fall geht die Anwendung, nachdem der Benutzer die Zoomeingabe losgelassen hat, in den Trägheitsberechnungszustand 10530 über, um die zusätzliche Zoommenge der Kartenansicht (d. h. Bewegen der virtuellen Kamera) und die Zeit, in welcher die Bewegung durchgeführt werden soll, zu berechnen. In einigen Ausführungsformen verlangsamt die Anwendung die Zoombewegung von der Geschwindigkeit, in welcher die Karte hinein- oder hinausgezoomt wurde (d. h. die Geschwindigkeit, in welcher die virtuelle Kamera die Höhe ändert), als ob eine ”Reibungs”-Kraft auf die Kamera angewendet wurde. Als solches basiert die Trägheitsberechnung einiger Ausführungsformen auf der Geschwindigkeit der dritten gestischen Eingabeart. Aus dem Zustand 10530 geht die Anwendung zurück zum Kartenänderungszustand, in welchem die Anwendung vorher war. Das heißt, wenn die Anwendung vom Zustand 10525 (dem Zoomzustand) zu dem Trägheitsberechnungszustand 10530 übergeht, geht sie dann zurück zum Zustand 10525, nachdem die Trägheitsberechnung durchgeführt wurde. Nachdem das Zoomen der Karte abgeschlossen ist, geht die Anwendung zurück in den Zustand 10505.
Der Einfachheit halber veranschaulicht das Zustandsdiagramm 10500 die Verschiebungs-, Zoom- und Rotationsprozesse der Karte, die den gleichen Trägheitsberechnungsprozess verwenden (Zustand 10530). Allerdings verwendet in einigen Ausführungsformen jeder dieser unterschiedlichen Kartenänderungsprozesse tatsächlich eine unterschiedliche Trägheitsberechnung, um die Verlangsamung und das Anhalten für die bestimmte Art der Bewegung zu identifizieren. Zusätzlich berechnen und ändern einige Ausführungsformen die Trägheitsvariablen bei Empfangen der Eingaben statt zu dem Zeitpunkt, an dem der Benutzer die gestische Eingabe loslässt.
Wenn die Anwendung eine vierte gestische Eingabeart empfängt (z. B. zwei separate Berührungseingaben, die sich auf der berührungsempfindlichen Anzeige gemeinsam hinauf und hinab bewegen), geht die Anwendung in einen Zustand 10535 über, um die perspektivische Ansicht der Karte zu ändern. Um die perspektivische Ansicht der Karte zu ändern, wird in einigen Ausführungsformen die virtuelle Kamera entlang eines Bogens über die Karte bewegt, wodurch sich sowohl der Ort als auch die Ausrichtung der virtuellen Kamera ändert (während die Kamera das Zentrum ihres Sichtfeldes an einem bestimmten Ort der Karte beibehält). In einigen Ausführungsformen verwenden unterschiedliche Zoomstufen unterschiedliche Bögen entlang welcher sich die virtuelle Kamera bewegt. Jeder dieser Bögen hat einen obersten Punkt, an welchem die virtuelle Kamera gerade hinunterzeigt, der eine 2D-Perspektivenansicht der Karte gibt. Zusätzlich hat jeder Bogen einen untersten Punkt, welcher der niedrigste Punkt des Bogens ist, zu welchem die virtuelle Kamera bewegt werden kann. Folglich kann die vierte gestische Eingabeart die Anwendung dazu veranlassen in einigen Ausführungsformen zwischen einer 2D-Kartenansicht und einer 3D-perspektivischen Kartenansicht zu wechseln. Während die vierte gestische Eingabeart weitergeht, verbleibt die Kartenanwendung in dem Zustand 10535, um die Änderung der perspektivischen Ansicht der Karte zu modifizieren.
Wenn der Benutzer die zweite gestische Eingabeart loslässt, geht die Anwendung einiger Ausführungsformen in einen Zustand 10540 über, um eine Trägheitsberechnung durchzuführen. In einigen Ausführungsformen führt die Anwendung, nachdem der Benutzer bestimmte Arten von Berührungseingaben losgelassen hat, weiter die verbundene Kartenansichtsänderung für eine bestimmte Zeitdauer und/oder Distanz durch (d. h. Bewegen der virtuellen Kamera höher oder niedriger). In diesem Fall geht die Anwendung, nachdem der Benutzer die Eingabe des perspektivischen Ansichtswechsels losgelassen hat, in den Trägheitsberechnungszustand 10540 über, um den zusätzlichen Anteil der perspektivischen Änderung der Kartenansicht (d. h. Bewegen der virtuellen Kamera entlang ihres Bogens) und die Zeit, in welcher die Bewegung durchgeführt werden soll, zu berechnen. In einigen Ausführungsformen verlangsamt die Anwendung die Bewegung der Geschwindigkeit, in welcher die Karte die Perspektive geändert hat (d. h. die Geschwindigkeit, in welcher die virtuelle Kamera sich entlang ihres Bogens bewegt), als ob eine ”Reibungs”-Kraft auf die Kamera angewendet wurde. Als solches basiert die Trägheitsberechnung einiger Ausführungsformen auf der Geschwindigkeit, mit welcher die vierte gestische Eingabeart durchgeführt wurde.
Zusätzlich gehen einige Ausführungsformen bei der perspektivischen Änderungsoperation zu einem Rückfederungsberechnungszustand 10545 über. Wie angegeben hat die perspektivische Änderungsoperation in einigen Ausführungsformen eine maximale und minimale erlaubte perspektivische Verschiebung, welche von der Zoomstufe der aktuellen Kartenansicht abhängen kann. Daher führt die Anwendung zusätzlich zu der Trägheitsberechnung eine Rückfederungsberechnung im Zustand 10545 durch. Die Rückfederungsberechnung verwendet die Trägheitsberechnung, um zu ermitteln, ob der maximale Punkt entlang des virtuellen Kamerabogens erreicht werden wird und wenn dem so ist, die Geschwindigkeit der virtuellen Kamera an diesem Punkt. Einige Ausführungsformen erlauben der virtuellen Kamera, sich leicht an dem maximalen Punkt vorbei zu bewegen, um einen ”Rückfederungs”-Punkt zu erreichen, an welchem Punkt die Anwendung die virtuelle Kamera auf ihrem Bogen wendet, wodurch sie zurück zum maximalen Punkt bewegt wird. Einige Ausführungsformen beinhalten solch eine Rückfederfunktionalität nur an einem Ende des virtuellen Kamerabogens (z. B. dem Unteren Ende des Bogens), während andere Ausführungsformen die Funktionalität an beiden Enden des Bogens beinhalten. Aus dem Rückfederungsberechnungszustand 10545 geht die Anwendung zurück in den Trägheitsberechnungszustand 10540, dann zurück zum perspektivischen Änderungszustand 10535, um die Kartenansichtsbewegung anzuzeigen. Außerdem, wenn der Benutzer die vierte Berührungseingabeart lange genug durchführt und die Perspektive ihren maximalen Punkt erreicht, geht die Anwendung direkt vom Zustand 10535 zum Zustand 10545 über, um die Rückfederungsinformation zu berechnen und dann zurück in den Zustand 10535 überzugehen. Nachdem die Änderung der perspektivischen Ansicht der Karte abgeschlossen ist, geht die Anwendung zurück in den Zustand 10505.
Die obigen Zustände betreffen eine Vielzahl von Mehrfachberührungsgesten über der Kartendarstellung, welche die integrierte Karten-, Such- und Navigationsanwendung in unterschiedliche Änderungen der Kartendarstellung übersetzt. Verschiedene andere Berührungseingaben können auch die Anwendung dazu veranlassen, Zustände zu ändern und verschiedene Funktion durchzuführen. Zum Beispiel legen einige Ausführungsformen einen 3D-selektierbaren Element über die Kartenansicht (z. B. als eine schwebende Steuerung), und selektieren (z. B. durch eine Tippeingabe) des 3D-Elements veranlasst die Anwendung in 10535 überzugehen, um die Perspektive der Kartenansicht zu modifizieren. Wenn die Kartenansicht in einer 3D-Perspektivenansicht startet, modifiziert die Anwendung die Perspektive in eine 2D-Ansicht, wenn die Kartenansicht in einer 2D-Ansicht startet, modifiziert die Anwendung die Perspektive in eine 3D-Ansicht. Nach der Modifikation kehrt die Anwendung zur Stufe 10505 zurück.
Da die Anwendung eine eng integrierte Karten-, Such-, Routen- und Navigationsanwendung ist, kann der Benutzer leicht auf die Routenfunktion aus dem Kartendurchsuchungszustand zugreifen. Wenn eine bestimmte Benutzerschnittstellensteuerung (z. B. ein Routeneintragsknopf) selektiert wird, geht die Anwendung zu dem Routeneintragszustand 10570 über. In dem Routeneintragszustand zeigen einige Ausführungsformen eine Berührungsbildschirmtastatur an, mit welcher der Benutzer Orte (z. B. Adressen, Plätzenamen, Plätzearten, usw.) sowohl in ein ”Zu”- als auch in ein ”Von”-Feld eingeben kann, um eine Route anzufragen. Während der Benutzer Zeichen eingibt, verbleibt die Anwendung im Zustand 10570 und stellt Vorschläge basierend auf letzten Routen, letzten Suchen, einer Autovervollständigung, die ähnlich zu der für den Sucheintrag beschriebenen ist, usw., bereit. Wenn der Benutzer die Benutzerschnittstellensteuerung zum Abbrechen in dieser Stufe selektiert, geht die Anwendung zurück über zum Zustand 10505 ohne eine Route abzurufen.
Wenn der Benutzer eine Route selektiert (z. B. durch Eingeben eines ”Zu”-Ortes und eines ”Von”-Ortes), geht die Anwendung in den Routenanzeigezustand 10575 über. In diesem Zustand zeigt die Anwendung eine oder mehrere Routen von einem ersten selektierten Ort zu einem zweiten selektierten Ort über die Kartenansicht an (z. B. durch Einblenden von Routenlinien auf der Kartenansicht). Einige Ausführungsformen selektieren automatisch eine erste Route aus den Routen. Der Benutzer kann jede der anderen Routen selektieren (z. B. durch Tippen auf die nicht selektierte Route), mit der Anwendung im Zustand 10575 verbleibend (jedoch durch Ändern der Anzeige der Routenlinien, um die Selektion einer anderen Route anzugeben). Außerdem zeigt die Anwendung im Zustand 10575 einiger Ausführungsformen unterschiedliche Benutzerschnittstellensteuerungen im Zusammenhang mit Routenplanung und Navigation an, einschließlich einer Steuerung für eine Anweisungsliste, eine Steuerung zum Starten der Navigation und andere. In einigen Ausführungsformen ist die Routenanzeige 10575 auch zugreifbar von anderen Stufen. Zum Beispiel, wenn ein Benutzer eine Schnellrouten-UI-Steuerung auf einem Ortsbanner auswählt, ruft die Anwendung eine oder mehrere Routen von dem aktuellen Ort der Vorrichtung zu dem Ort, mit welchem das Banner assoziiert ist, ab.
Auch können verschiedene gestische Interaktionen über der Karte, in welcher die Routen dargestellt werden, die Anwendung veranlassen, unterschiedliche Änderungen der Kartenansicht durchzuführen (z. B. Verschieben, Rotieren, Zoomen, Ändern der Kartenperspektive usw.). Wenn die integrierte Anwendung gestische Interaktionen über der Kartenanzeige empfängt während sie im Routenanzeigezustand 10575 ist, geht die Anwendung zum Zustand 10510 über, um eine Erkennung gestischer Eingaben durchzuführen, mit allen verfügbaren gestischen Kartenänderungsoperationen (z. B. Zustandsfolgen 10515–10545). Das heißt, die Anwendung übersetzt die gestische Eingabe in Verschiebe-, Rotier-, Zoom- und/oder perspektivische Änderungsoperationen ähnlich zu diesen für die Zustände 10515–10545 oben beschriebenen, mit ähnlichen Trägheits- und Rückfederungsmerkmalen für die Bewegung der virtuellen Kamera. Während die Operationen 10515–10545 zum Kartendurchsuchungszustand 10505 zurückkehren, kehren die Folgeoperationen, auf welche von dem Routenanzeigezustand 10575 zugegriffen werden, zu dem Routenanzeigezustand 10575 zurück.
Aus dem Routenanzeigezustand 10575 kann die Anwendung in verschiedene unterschiedliche Modi übergehen, abhängig von unterschiedlichen Steuerungen, die durch den Benutzer selektiert werden. Wenn der Benutzer eine Benutzerschnittstellensteuerung selektiert, um die Routen zu löschen, geht die Anwendung zurück in den Zustand 10505, um die Karte ohne Routen anzuzeigen. Außerdem kann die integrierte Anwendung eine oder mehrere Navigationsmodalitäten aus dem Routenanzeigezustand 10575 heraus betreten.
Wenn die im Zustand 10575 angezeigte selektierte Route an dem aktuellen Ort der Vorrichtung startet und der Benutzer eine Steuerung zum Starten der Navigation selektiert, geht die Anwendung in den Navigationszustand 10580 über. In einigen Ausführungsformen zeigt die Anwendung einen filmischen Übergang von der Kartenansicht in eine immersivere 3D-Ansicht für die Navigation an. Im Navigationszustand 10580 einiger Ausführungsformen folgt eine virtuelle Kamera dem Ort des Benutzers entlang der selektierten Route, um die bevorstehenden Teile der Route darzustellen. Wenn entweder die Route vollständig ist (die Vorrichtung hat ihren Zielort erreicht) oder der Benutzer selektiert eine Steuerung zum Beenden der Navigation, geht die Anwendung in den Zustand 10505 über, um die Kartendurchsuchungsansicht 10505 darzustellen.
In einigen Ausführungsformen können verschiedene gestische Interaktionen über der Karte, auf welcher die Routen angezeigt werden, die Anwendung dazu veranlassen, unterschiedliche Änderungen der Kartenansicht durchzuführen (z. B. Verschieben, Rotieren, Zoomen, Ändern der Kartenperspektive usw.) während sie im Navigationsmodus 10580 ist. In einigen Ausführungsformen sind nur einige der beschriebenen Kartenänderungsoperationen in dem Navigationsmodus verfügbar. Zum Beispiel erlauben einige Ausführungsformen dem Benutzer hinein oder hinaus zu zoomen, aber erlauben keine anderen Änderungen der Karte. Folglich, wenn der Benutzer gestische Eingaben bereitstellt, filtert der Zustand der Erkennung der gestischen Eingabe 10510 Arten der gestischen Eingabe heraus, die nicht mit der Zoomoperation verbunden sind (und die Anwendung geht danach zurück in den Zustand 10580). Wenn die gestische Eingabe, die mit der Zoomoperation verbunden ist, empfangen wird, erkennt der Zustand der Erkennung der gestischen Eingabe diese Eingabe und die Anwendung geht in einen Zustand ähnlich dem Zustand 10525 über, um die Zoomstufe der Karte zu ändern (mit der Trägheitsberechnung in einigen Ausführungsformen).
Andere Ausführungsformen können unterschiedliche Kartenänderungsoperationen ermöglichen. In einigen Ausführungsformen sind z. B. alle gestischen Kartenänderungsoperationen (z. B. Zustandsfolgen 10515–10545) während des Navigationsmodus verfügbar. Einige Ausführungsformen erlauben eine Untermenge der gestischen Kartenänderungsoperationen sowie Zoomen und eine limitierte Verschiebungsoperation. Die Verschiebungsoperation einiger Ausführungsformen bewegen, beim Empfangen der gestischen Eingabeart, die mit Verschiebung verbunden ist, die virtuelle Kamera (während im Navigationsmodus) auf die Seite und bringt anschließend die virtuelle Kamera zurück zum Zeigen entlang der Route. Während die Operationen 10515–10545 zum Kartendurchsuchungszustand 10505 zurückkehren, kehren die Folgeoperationen, auf die vom Navigationszustand 10580 zugegriffen wird, zum Navigationszustand 10580 zurück.
Wenn die im Zustand 10575 angezeigte selektierte Route an einem anderen Ort als dem aktuellen Ort der Vorrichtung startet (oder die Route ist eine Gehroute) und der Benutzer selektiert eine Steuerung zum Starten der Navigation, geht die Anwendung in den Schrittmodus oder in den Routenbesichtigungsmodus, Zustand 10585 über. In einigen Ausführungsformen zeigt die Anwendung die Manöver, die entlang der Route eines nach dem anderen durchgeführt werden (z. B. Navigationsschilder) an. Durch Bereitstellen von gestischen Eingaben (z. B. Wischgesten) auf den Manövern kann der Benutzer die unterschiedlichen Manöver ansehen während er im Routenbesichtigungsmodus ist. Die Manöver werden über die Karte gelegt und zumindest wird ein Teil der Route in der Karte angezeigt.
Wie im Routenanzeigemodus können verschiedene gestische Interaktionen über der Karte die Anwendung veranlassen, unterschiedliche Änderungen der Kartenansicht durchzuführen (z. B. Verschieben, Rotieren, Zoomen, Modifizieren der Kartenperspektive, usw.). Wenn die integrierte Anwendung gestische Interaktion über der Kartenanzeige empfängt während sie im Schrittmodus 10585 ist, geht die Anwendung in den Zustand 10510 über, um die Erkennung gestischer Eingaben durchzuführen, mit allen verfügbaren gestischen Kartenänderungsoperationen (z. B. Zustandsfolgen 10515–10545). Das heißt die Anwendung übersetzt die gestischen Eingaben in Verschiebe-, Rotier-, Zoom- und/oder perspektivische Änderungsoperationen ähnlich zu den in den Zuständen 10515–10545 oben beschriebenen, mit ähnlichen Trägheits- und Rückfederungsmerkmalen für die Bewegung der virtuellen Kamera. Während die Operationen 10515–10545 zum Kartendurchsuchungszustand 10505 zurückgehen, gehen die Operationsfolgen, auf die vom Schrittmodus 10585 zugegriffen wird, in den Schrittmodus 10585 zurück.
Weiterhin erkennt die Erkennung der gestischen Eingabe in einigen Ausführungsformen wenigstens eine Art gestischer Eingabe über den angezeigten Manövern, um zwischen den Manövern zu wechseln. Wenn eine bestimmte Art gestischer Eingabe (z. B. eine Wischgeste) über dem angezeigten Manöver empfangen wird (im Gegensatz zu über der Kartenansicht), geht die Anwendung in einen Zustand (nicht gezeigt) über, um das angezeigte Manöver zu wechseln, und geht dann in den Zustand 10585 zurück.
Wenn die integrierte Anwendung eine gestische Interaktion über der angezeigten Karte empfängt während sie im Schrittzustand 10575 ist, geht die Anwendung in den Zustand 10510 über, um eine Erkennung der gestischen Eingabe durchzuführen, mit allen verfügbaren gestischen Kartenänderungsoperationen (z. B. Zustandsfolgen 10515–10545). Wenn die Änderungsoperationen abgeschlossen sind, geht die Anwendung in den Zustand 10585 zurück. Wenn der Benutzer eine Steuerung zum Beenden des Durchschreitens der Manöver auswählt, geht die Anwendung in den Zustand 10505 über, um die Kartendurchsuchungsansicht darzustellen.
Zusätzlich kann in einigen Ausführungsformen die Anwendung vom Schrittmodus 10585 in einen automatischen Schrittzustand 10590 übergehen. Wenn der Benutzer eine Ortsverfolgungssteuerung selektiert während die Anwendung im Zustand 10585 ist, geht die Anwendung in den automatischen Schrittmodus 10590 über, welches eine unterschiedliche Navigationsmodalität ist. Im automatischen Schrittmodus einiger Ausführungsformen zeigt die integrierte Karten-, Such- und Navigationsanwendung das Manöver, zu welchem der Ort der Vorrichtung am nächsten ist, an (z. B. wie gemessen an einer Kreuzung, an welcher das Manöver durchgeführt wird). Wenn sich die Vorrichtung (z. B. entlang der Route) näher zu einem Ort eines unterschiedlichen Manövers bewegt, zeigt der automatische Schrittmodus automatisch das unterschiedliche Manöver an. Wenn der Benutzer die Ortsverfolgungssteuerung abwählt, geht die Anwendung zurück in den Schrittmodus 10585. Wenn der Benutzer eine Steuerung zum Beenden der Navigation während des automatischen Schrittzustands 10590 selektiert, geht die Anwendung in den Zustand 10505 über, um die Kartendurchsuchungsansicht darzustellen.
Wie im Schrittmodus 10585 können verschiedene gestische Interaktionen über der Karte veranlassen, dass die Anwendung unterschiedliche Änderungen der Kartenansicht durchführt (z. B. Verschieben, Rotieren, Zoomen, Ändern der Kartenperspektive usw.). Wenn die integrierte Anwendung eine gestische Interaktion über der Kartenanzeige empfängt während sie im automatischen Schrittmodus 10590 ist, geht die Anwendung in den Zustand 10510 über, um eine Erkennung der gestischen Eingabe durchzuführen, mit allen verfügbaren Kartenänderungsoperationen (z. B. Zustandsfolgen 10515–10545). Das heißt, die Anwendung übersetzt die gestischen Eingaben in Verschiebe-, Rotier-, Zoom- und/oder perspektivische Änderungsoperationen ähnlich zu den oben für die Zustände 10515–10545 beschriebenen, mit ähnlichen Trägheits- und Rückfederungsmerkmalen für die Bewegung der virtuellen Kamera. Während die Operationen 10515–10545 zu dem Kartendurchsuchungszustand 10505 zurückkehren, gehen die Operationsfolgen, auf die von dem automatischen Schrittmodus 10585 zugegriffen werden, zum automatischen Schrittmodus 10590 zurück. Zusätzlich schalten einige Ausführungsformen automatisch die Ortsverfolgungssteuerung aus, wenn der Benutzer die Karte eine bestimmte Distanz verschiebt, in diesem Fall geht die Anwendung zum Schrittmoduszustand 10585 statt zum automatischen Schrittzustand 10590 zurück.
IV. Elektronisches System
Viele der oben beschriebenen Merkmale und Anwendungen sind als Softwareprozesse implementiert, welche als eine Menge von Instruktionen, die auf einem computerlesbaren Speichermedium aufgenommen sind, spezifiziert sind (auch bezeichnet als computerlesbares Medium). Wenn diese Instruktionen durch eine oder mehrere rechnerische oder Verarbeitungseinheit(en) ausgeführt werden (z. B. einen oder mehrere Prozessoren, Prozessorkerne oder andere Verarbeitungseinheiten), veranlassen sie die Verarbeitungseinheit(en) die Aktionen, die in den Instruktionen angegeben sind, auszuführen. Beispiele von computerlesbaren Medien beinhalten, sind aber nicht limitiert auf, CD-ROMs, Flashlaufwerke, Speicher mit wahlfreiem Zugriff(RAM)-Chips, Festplatten, löschbare programmierbare Nur-Lesespeicher (EPROMs), elektrisch löschbare programmierbare Nur-Lesespeicher (EEPROMs), usw. Die computerlesbaren Medien beinhalten keine Trägerwellen und elektronische Signale, die kabellos oder über Kabelverbindungen passieren.
In dieser Spezifikation soll der Begriff ”Software” eine Firmware in einem Nur-Lesespeicher liegend oder Anwendungen in magnetischen Speichern gespeichert beinhalten, welche in den Speicher gelesen werden können, um von einem Prozessor verarbeitet zu werden. Auch können in einigen Ausführungsformen mehrere Softwareerfindungen als Unterteile eines größeren Programms implementiert werden, während sie getrennte Softwareerfindungen bleiben. In einigen Ausführungsformen können mehrere Softwareerfindungen auch als getrennte Programme implementiert werden. Schließlich ist jegliche Kombination von getrennten Programmen, die zusammen eine Softwareerfindung implementieren, die hier beschrieben wird, im Bereich dieser Erfindung. In einigen Ausführungsformen definieren die Softwareprogramme, wenn sie installiert sind, um auf einem oder mehreren elektronischen Systemen betrieben zu werden, eine oder mehrere spezifische Maschinenimplementierungen, die die Operationen der Softwareprogramme ausführen und durchführen.
A. Mobile Vorrichtung
Die Karten- und Navigationsanwendung einiger Ausführungsformen arbeiten auf mobilen Vorrichtungen, sowie Smartphones (z. B. iPhones^®) und Tablets (z. B. iPads^®). 106 ist ein Beispiel einer Architektur 10600 einer solchen mobilen Rechenvorrichtung. Beispiele von mobilen Rechenvorrichtungen beinhalten Smartphones, Tablets, Laptops, usw. Wie gezeigt beinhaltet die mobile Rechenvorrichtung 10600 ein oder mehrere Verarbeitungseinheiten 10605, eine Speicherschnittstelle 10610 und eine Peripherieschnittstelle 10615.
Die Peripherieschnittstelle 10615 ist mit verschiedenen Sensoren und Untersystemen gekoppelt, welche ein Kamerauntersystem 10620, ein drahtloses Kommunikationsuntersystem(e) 10620, ein Tonuntersystem 10630, ein Eingabe/Ausgabeuntersystem 10635 (E/A), usw., beinhalten. Die Peripherieschnittstelle 10615 erlaubt eine Kommunikation zwischen den Verarbeitungseinheiten 10605 und verschiedenen Peripheriegeräten. Zum Beispiel einen Ausrichtungssensor 10645 (z. B. ein Gyroskop) und einen Beschleunigungssensor 10650 (z. B. einen Beschleunigungsmesssensor) mit der Peripherieschnittstelle 10615 gekoppelt, um Ausrichtungs- und Beschleunigungsfunktionen zu ermöglichen.
Das Kamerauntersystem 10620 ist mit einem oder mehreren optischen Sensoren 10640 gekoppelt (z. B. ein optischer Sensor mit ladungsgekoppelten Bauteilen (CCD), ein optischer Sensor mit sich ergänzenden Metalloxid-Halbleitern (CMOS) usw.). Das Kamerauntersystem 10620, welches mit den optischen Sensoren 10640 gekoppelt ist, ermöglicht Kamerafunktionen, sowie Bild- und/oder Videodatenaufnahme. Das drahtlose Kommunikationsuntersystem 10625 dient dazu, Kommunikationsfunktionen zu ermöglichen. In einigen Ausführungsformen beinhaltet das drahtlose Kommunikationsuntersystem 10625 Funkfrequenzempfänger und -sender und optische Empfänger und Sender (nicht in 106 gezeigt). Diese Empfänger und Sender von einigen Ausführungsformen sind implementiert, um über ein oder mehrere Kommunikationsnetzwerke wie ein GSM-Netzwerk, ein Wi-Fi-Netzwerk, ein Bluetooth-Netzwerk, usw. zu arbeiten. Das Tonuntersystem 10630 ist mit einem Lautsprecher gekoppelt, um Ton auszugeben (z. B. um Sprachnavigationsinstruktionen auszugeben). Zusätzlich ist das Tonuntersystem 10630 mit einem Mikrofon gekoppelt, um sprachfähige Funktionen zu ermöglichen, wie eine Spracherkennung (z. B. zum Suchen), digitales Aufnehmen, usw.
Das E/A-Untersystem 10635 beinhaltet die Übertragung zwischen Eingabe/Ausgabe-Peripherievorrichtungen, wie einer Anzeige, einem Berührungsbildschirm, usw., und dem Datenbus der Verarbeitungseinheiten 10605 durch die Peripherieschnittstelle 10615. Das Eingabe/Ausgabe-Untersystem 10635 beinhaltet ein Berührungsbildschirmsteuergerät 10655 und andere Eingabesteuergeräte 10660, um die Übertragung zwischen Eingabe/Ausgabe-Peripherievorrichtungen und dem Datenbus der Verarbeitungseinheiten 10605 zu ermöglichen. Wie gezeigt, ist das Berührungsbildschirmsteuergerät 10655 mit einem Berührungsbildschirm 10665 gekoppelt. Das Berührungsbildschirmsteuergerät 10655 ermittelt einen Kontakt oder eine Bewegung auf dem Berührungsbildschirm 10665, indem es eine von mehreren berührungsempfindlichen Technologien verwendet. Die anderen Eingabesteuergeräte 10660 sind mit anderen Eingabe/Ausgabe-Vorrichtungen gekoppelt, sowie einem oder mehreren Knöpfen. Einige Ausführungsformen beinhalten einen fast-berührungsempfindlichen Bildschirm und ein entsprechendes Steuergerät, welches Fast-Berührungsinteraktionen anstelle von oder zusätzlich zu Berührungsinteraktionen feststellen kann.
Die Speicherschnittstelle 10610 ist mit dem Speicher 10670 gekoppelt. In einigen Ausführungsformen beinhaltet der Speicher 10670 volatilen Speicher (z. B. Hochgeschwindigkeitsspeicher mit wahlfreiem Zugriff), nichtvolatilen Speicher (z. B. Flash-Speicher), eine Kombination aus volatilem und nichtvolatilem Speicher und/oder irgendeine andere Art von Speicher. Wie in 44 veranschaulicht, speichert der Speicher 10670 ein Betriebssystem (operating system, OS) 10672. Das Betriebssystem 10672 beinhaltet Anweisungen, um Grundsystemdienste zu handhaben und um hardwareabhängige Aufgaben durchzuführen.
Der Speicher 10670 beinhaltet auch Kommunikationsinstruktionen 10674, um eine Kommunikation mit einer oder mehreren zusätzlichen Vorrichtungen zu ermöglichen; Instruktionen der grafische Benutzerschnittstelle 10676, um grafische Benutzerschnittstellenverarbeitungen zu ermöglichen; Bildverarbeitungsinstruktionen 10678, um bildbezogene Verarbeitung und Funktionen zu ermöglichen; Eingabeverarbeitungsinstruktionen 10680, um eingabebezogene (z. B. Berührungseingabe) Prozesse und Funktionen zu ermöglichen; Tonverarbeitungsinstruktionen 10682, um tonbezogene Prozesse und Funktionen zu ermöglichen; und Kamerainstruktionen 10684, um kamerabezogene Prozesse und Funktionen zu ermöglichen. Die oben beschriebenen Anweisungen sind nur beispielhaft und der Speicher 10670 beinhaltet zusätzliche und/oder andere Anweisungen in einigen Ausführungsformen. Beispielweise könnte der Speicher für ein Smartphone Telefoninstruktionen enthalten, um telefonbezogene Prozesse und Funktionen zu ermöglichen. Zusätzlich könnte der Speicher Instruktionen für eine Karten- und Navigationsanwendung wie auch für andere Anwendungen beinhalten. Die oben identifizierten Instruktionen müssen nicht als getrennte Softwareprogramme oder Module implementiert werden. Verschiedene Funktionen der mobilen Flächenvorrichtung können in Hardware und/oder Software implementiert werden, welche eine oder mehrere Signalverarbeitungs- und/oder anwendungsspezifische integrierte Schaltungen beinhalten.
Während die in 106 veranschaulichten Komponenten als getrennte Komponenten gezeigt werden, wird der Fachmann erkennen, dass zwei oder mehrere Komponenten in eine oder mehrere integrierte Schaltungen integriert werden können. Zusätzlich können zwei oder mehrere Komponenten über eine oder mehrere Kommunikationsbusse oder Signalleitungen verbunden werden. Obwohl viele der Funktionen beschrieben wurden, als ob sie durch eine Komponente durchgeführt werden würden, wird auch der Fachmann erkennen, dass die mit Bezug zu 106 beschriebenen Funktionen in zwei oder mehrere integrierte Schaltungen aufgeteilt werden können.
B. Computersystem
107 veranschaulicht konzeptionell ein anderes Beispiel eines elektronischen Systems 10700, mit welchem einige Ausführungsformen der Erfindung implementiert sind. Das elektronische System 10700 kann ein Computer (z. B. ein Desktop-Computer, persönlicher Computer, Tablet-Computer, usw.), ein Telefon, ein PDA oder jede andere Art von elektronischer Vorrichtung oder Rechenvorrichtung sein. Solch ein elektronisches System beinhaltet verschiedene Arten von computerlesbaren Medien und Schnittstellen für verschiedene andere Arten von computerlesbaren Medien. Das elektronische System 10700 beinhaltet einen Bus 10705, eine Verarbeitungseinheit(en) 10710, eine grafische Verarbeitungseinheit (GPU) 10715, einen Systemspeicher 10720, ein Netzwerke 10725, einen Festwertspeicher (ROM) 10730, eine permanente Speichervorrichtung 10735, Eingabevorrichtungen 10740 und Ausgabevorrichtungen 10745.
Der Bus 10705 stellt insgesamt alle System-, Peripherie- und Chipsatzbusse dar, die kommunikativ die zahlreichen internen Vorrichtungen des elektronischen Systems 10700 verbinden. Zum Beispiel verbindet der Bus 10705 kommunikativ die Verarbeitungseinheit(en) 10710 mit dem Festspeicher 10730, der GPU 10715, dem Systemspeicher 10720 und der permanenten Speichervorrichtung 10735.
Von diesen verschiedenen Speichereinheiten erhält die Verarbeitungseinheit(en) 10710 auszuführende Instruktionen und zu verarbeitende Daten, um die Prozesse der Erfindung auszuführen. Die Verarbeitungseinheit(en) kann ein einzelner Prozessor oder ein Mehrkernprozessor in unterschiedlichen Ausführungsformen sein. Einige Anweisungen werden an die GPU 10715 gegeben und durch sie ausgeführt. Die GPU 10715 kann verschiedene Berechnungen abstoßen oder die Bildverarbeitung, welche durch die Verarbeitungseinheit(en) 10710 bereitgestellt wird, ergänzen. In einigen Ausführungsformen kann eine solche Funktionalität durch die Benutzung die Kernel Shading Language der CoreImage bereitgestellt werden.
Der Nur-Lese-Speicher (ROM) 10730 speichert statische Daten und Anweisungen, die von der Verarbeitungseinheit(en) 10710 und anderen Modulen des elektronischen Systems benötigt werden. Die permanente Speichervorrichtung 10735 ist andererseits eine Lese- und Schreibspeichervorrichtung. Diese Vorrichtung ist eine nichtvolatile Speichereinheit, die Instruktionen und Daten speichert, sogar wenn das elektronische System 10700 aus ist. Einige Ausführungsformen der Erfindung verwenden eine Massenspeichervorrichtung (so wie eine magnetische oder optische Platte und ihre entsprechende Festplatte, integrierter Flashspeicher) als permanente Speichervorrichtung 10735.
Andere Ausführungsformen verwenden eine entnehmbare Speichervorrichtung (wie eine Diskette, eine Flashspeichervorrichtung, usw. und ihre entsprechenden Laufwerke) als permanente Speichervorrichtung. Wie die permanente Speichervorrichtung 10735, ist der Systemspeicher 10720 eine Lese- und Schreibspeichervorrichtung. Allerdings anders als die Speichervorrichtung 10735 ist der Systemspeicher 10720 ein volatiler Lese- und Schreibspeicher sowie ein Speicher mit wahlfreiem Zugriff. Der Systemspeicher 10720 speichert einige der Anweisungen und Daten, die der Prozessor zur Laufzeit benötigt. In einigen Ausführungsformen sind die Prozesse der Erfindung in dem Systemspeicher 10720, der permanenten Speichervorrichtung 10735 und/oder dem ROM-Speicher 10730 abgelegt. Von diesen verschiedenen Speichereinheiten ruft die Verarbeitungseinheit(en) 10710 auszuführende Instruktionen und zu verarbeitende Daten ab, um die Prozesse einiger Ausführungsformen auszuführen.
Der Bus 10705 schließt auch die Eingabe- und Ausgabevorrichtungen 10740 und 10745 an. Die Eingabevorrichtungen 10740 erlauben dem Benutzer, zu dem elektronischen System Informationen zu kommunizieren und Befehle zu selektieren. Die Eingabevorrichtungen 10740 beinhalten alphanumerische Tastaturen und Zeigevorrichtungen (auch ”Zeigersteuerungsvorrichtungen” genannt), Kameras (z. B. Webkameras), Mikrofone oder ähnliche Vorrichtungen zum Empfangen von Sprachbefehlen, usw. Die Ausgabevorrichtungen 10745 zeigen Bilder an, die von dem elektronischen System generiert sind oder anderweitige Ausgabedaten. Die Ausgabevorrichtungen 10745 beinhalten Drucker und Anzeigevorrichtungen, sowie Kathodenstrahlröhren (CRT) oder Flüssigkristallanzeigen (LCD), sowie Lautsprecher oder ähnliche Tonausgangsvorrichtungen. Einige Ausführungsformen beinhalten Vorrichtungen sowie einen Berührungsbildschirm, der als beides, Eingabe- und Ausgabevorrichtungen funktioniert.
Schließlich, wie in 107 gezeigt, koppelt der Bus 10705 auch das elektronische System 10700 an ein Netzwerk 10745 durch einen Netzwerkadapter (nicht gezeigt). Auf diese Weise kann der Computer ein Teil eines Computernetzwerkes (sowie ein lokales Netzwerk (”LAN”), ein Großraumnetzwerk (wide area network, ”WAN”) oder ein Intranet) oder ein Netzwerk von Netzwerken sowie das Internet, sein. Einige oder alle Komponenten des elektronischen Systems 10700 können in Verbindung mit der Erfindung verwendet werden.
Einige Ausführungsformen beinhalten elektronische Komponenten, wie beispielweise Mikroprozessoren, Ablagen und Speicher, die Computerprogramminstruktionen in einem maschinenlesbaren oder computerlesbaren Medium (alternativ bezeichnet als computerlesbare Speichermedien, maschinenlesbare Medien oder maschinenlesbare Speichermedien) abgelegt sind. Einige Beispiele solcher computerlesbaren Medien beinhalten RAM, ROM, Nur-Lese-Kompaktdisk (CD-ROM), beschreibbare Kompaktdisks (CD-R), wiederbeschreibbare Kompaktdisks (CD-RW), nur-lese-digitale vielseitige Disk (digital versatile disks) (z. B. DVD-ROM, zweischichtige DVD-ROM), eine Vielzahl von beschreibbaren/wiederbeschreibbaren DVDs (DVD-RAM, DVD-RW, DVD+RW, usw.), Flash-Speicher (z. B. SD-Karten, Mini-SD-Karten, Mikro-SD-Karten, usw.), magnetische Festplatten und/oder Halbleiterlaufwerke (SSD), nur-lese- und beschreibbare BlueRay^®-Disks, ultradichte optische Disks, beliebige andere optische oder magnetische Medien und Disketten. Die computerlesbaren Medien können ein Computerprogramm abspeichern, welches von wenigstens einer Verarbeitungseinheit ausgeführt werden kann und eine Menge von Instruktionen zum Durchführen verschiedener Operationen enthält. Beispiele von Computerprogrammen oder Computercode beinhalten Maschinencode, wie solcher, der von einem Kompilierer produziert wird, und Dateien, die Code einer höheren Stufe beinhalten, die von einem Computer, einer elektronischen Komponente oder einem Mikroprozessor, unter Verwendung eines Interpreters, ausgeführt werden.
Während die obige Diskussion primär auf Mikroprozessoren oder Mehrkernprozessoren, die Software ausführen, bezogen ist, werden einige Ausführungsformen durch eine oder mehrere integrierte Schaltungen ausgeführt werden, wie beispielsweise anwendungsspezifische integrierte Schaltungen (ASICs) oder feldprogrammierbare Gatteranordnungen (FPGAs). In einigen Ausführungsformen führen solche integrierte Schaltungen Instruktionen aus, die auf der Schaltung selbst abgespeichert sind. Zusätzlich führen einige Ausführungsformen Software, die in programmierbaren logischen Vorrichtungen (PLDs), ROM- oder RAM-Vorrichtungen gespeichert sind, aus.
Wie in dieser Spezifikation und in jedem Anspruch dieser Anmeldung verwendet, beziehen sich die Begriffe ”Computer”, ”Server”, ”Prozessor” und ”Speicher” alle auf elektronische oder andere technologische Vorrichtungen. Diese Begriffe schließen Personen oder Gruppen von Personen aus. Im Sinne der Spezifikation bedeuten die Begriffe Anzeige oder Anzeigen das Anzeigen auf einer elektronischen Vorrichtung. Wie in dieser Spezifikation und jedem Anspruch der Anmeldung verwendet, sind die Begriffe ”computerlesbares Medium”, ”computerlesbare Medien” und ”maschinenlesbares Medium”” vollständig beschränkt auf greifbare physische Objekte, die Informationen in einer Form, die von einem Computer gelesen werden kann, speichern. Diese Begriffe schließen jegliche drahtlose Signale, drahtgebunde Downloadsignale und jegliche andere flüchtige Signale aus.
V. Kartendienstumgebung
Verschiedene Ausführungsformen können innerhalb einer Kartendienstbetriebsumgebung arbeiten. 108 veranschaulicht eine Kartendienstbetriebsumgebung entsprechend einigen Ausführungsformen. Ein Kartendienst 10830 (auch bezeichnet als Kartendienst) kann Kartendienste für eine oder mehrere Clientvorrichtungen 10802a–10802c in Kommunikation mit dem Kartendienst 10830 durch verschiedene Kommunikationsverfahren und Protokolle bereitstellen. Ein Kartendienst 10830 stellt in einigen Ausführungsformen Karteninformationen und andere kartenbezogene Daten, sowie zweidimensionale Kartenbilddaten (z. B. Luftansicht von Straßen durch Verwendung von Satellitenbildern), dreidimensionale Kartenbilddaten (z. B. durchquerbare Karten mit dreidimensionalen Merkmalen, sowie Gebäude), Straßen- und Richtungsberechnungen (z. B. Fährroutenberechnungen oder Richtungen zwischen zwei Punkten für einen Fußgänger), Echtzeitnavigationsdaten (z. B. Punkt-zu-Punkt visuelle Navigationsdaten in zwei oder drei Dimensionen), Ortsdaten (z. B. wo die Clientvorrichtung sich aktuell befindet) und andere geografische Daten (z. B. drahtlose Netzabdeckung, Wetter, Verkehrsinformationen oder naheliegende Punkte von Interesse) bereit. In verschiedenen Ausführungsformen können die Kartendienstdaten lokalisierte Bezeichnungen für unterschiedliche Länder oder Regionen beinhalten. Lokalisierte Bezeichnungen können verwendet werden, um Kartenbezeichnungen (z. B. Straßennamen, Städtenamen, Punkte von Interesse) in unterschiedlichen Sprachen auf der Clientvorrichtung darzustellen. Die Clientvorrichtungen 10802a–10802c können diese Kartendienste verwenden, um Kartendienstdaten zu erhalten. Die Clientvorrichtungen 10802a–10802c können verschiedene Techniken implementieren, um Kartendienstdaten zu verarbeiten. Die Clientvorrichtungen 10802a–10802c können dann verschiedenen Einheiten Kartendienste bereitstellen, die beinhalten, jedoch nicht limitiert sind auf, Benutzer, interne Software- oder Hardwaremodule und/oder andere Systeme oder Vorrichtungen, die extern zu den Clientvorrichtungen 10802a–10802c sind.
In einigen Ausführungsformen ist ein Kartendienst durch einen oder mehrere Knoten in einem verteilten Rechensystem implementiert. Jeder Knoten kann einem oder mehreren Diensten oder einer oder mehreren Komponenten eines Kartendienstes zugeteilt sein. Einige Knoten können dem gleichen Kartendienst oder der gleichen Komponente eines Kartendienstes zugeteilt sein. Ein Lastverteilungsknoten verteilt in einigen Ausführungsformen Zugriffe oder Anfragen zu anderen Knoten in einem Kartendienst. In einigen Ausführungsformen ist ein Kartendienst als einzelnes System, wie z. B. ein einzelner Server, implementiert. Unterschiedliche Module oder Hardwarevorrichtungen in einem Server können einen oder mehrere von den verschiedenen Diensten, die von einem Kartendienst bereitgestellt werden, implementieren.
Ein Kartendienst stellt in einigen Ausführungsformen Kartendienste durch Generierung von Kartendienstdaten in verschiedenen Formaten bereit. In einigen Ausführungsformen ist ein Format von Kartendienstdaten Kartenbilddaten. Kartenbilddaten stellen Bilddaten einer Clientvorrichtung bereit, so dass die Clientvorrichtung die Bilddaten verarbeiten kann (z. B. Rendern und/oder Anzeigen der Bilddaten als eine zweidimensionale oder dreidimensionale Karte). Kartenbilddaten, ob in zwei oder drei Dimensionen, können eine oder mehrere Kartenkacheln spezifizieren. Eine Kartenkachel kann ein Teil eines größeren Kartenbildes sein. Das Zusammenfügen der Kartenkacheln einer Karte produziert die originale Karte. Kacheln können aus Kartenbilddaten und/oder Navigationsdaten oder jeden anderen Kartendienstdaten generiert werden. In einigen Ausführungsformen sind Kartenkacheln rasterbasierte Kartenkacheln mit Kachelgrößen, die sich über alle Größen erstrecken, mit größeren und kleineren als üblicherweise benutzten 256 Pixel zu 256 Pixel Kacheln erstrecken. Rasterbasierte Kartenkacheln können in jeglicher Anzahl von standardisierten digitalen Bilddarstellungen codiert werden, die beinhalten, sind jedoch nicht limitiert auf, Bitmap (.bmp), Graphics Interchange Format (.gif), Joint Photographic Experts Group (.jpg, jpeg, usw.), Portable Networks Graphic (.png) oder Tagged Image File Format (.tiff). In einigen Ausführungsformen sind Kartenkacheln vektorbasierte Kartenkacheln, die Vektorgrafiken benutzend codiert sind, welche beinhalten, jedoch nicht limitiert sind auf, Scalable Vektor Graphics (.svg) oder ein Drawing File (.drw). Einige Ausführungsformen beinhalten auch Kacheln mit einer Kombination aus Vektor- und Rasterdaten. Metadaten oder andere Informationen, die die Kartenkacheln betreffen, können auch in oder bei einer Kartenkachel enthalten sein, die weitere Kartendienstdaten der Clientvorrichtung bereitstellt. In verschiedenen Ausführungsformen ist eine Kartenkachel für einen Transport codiert, der verschiedene Standards und/oder Protokolle verwendet.
In verschiedenen Ausführungsformen können Kartenkacheln aus Bilddaten unterschiedlicher Auflösung abhängig von der Zoomstufe hergestellt werden. Zum Beispiel, für eine niedrige Zoomstufe (z. B. Welt- oder Globusansicht), muss die Auflösung der Karte oder der Bilddaten nicht so hoch sein, relativ zu der Auflösung in einer hohen Zoomstufe (z. B. Stadt- oder Straßenstufe). Zum Beispiel, wenn in einer Globusansicht, gibt es keinen Bedarf, um Artefakte der Straßenstufe wiederzugeben, da solche Objekte so klein sein würden, dass sie in den meisten Fällen vernachlässigbar sind.
Ein Kartendienst führt in einigen Ausführungsformen verschiedene Techniken zur Analyse einer Kartenkachel aus, bevor die Kachel für den Transport codiert wird. Diese Analyse kann die Leistung des Kartendienstes für beide, Clientvorrichtung und einen Kartendienst optimieren. In einigen Ausführungsformen werden Kartenkacheln auf Komplexität gemäß vektorbasierten grafischen Techniken analysiert und unter Verwendung von komplexen und nichtkomplexen Schichten erstellt. Kartenkacheln können also auch auf gewöhnliche Bilddaten oder Muster, die als Bildtexturen gerendert und auch Bildmasken setzend erstellt werden. In einigen Ausführungsformen enthalten rasterbasierte Bilddaten in einer Kartenkachel bestimmte Maskenwerte, welche mit einer oder mehreren Texturen verbunden sind. Einige Ausführungsformen analysieren Kartenkacheln auch auf spezielle Merkmale, welche mit bestimmten Kartenarten, die bestimmte Artbezeichnungen enthalten, verbunden werden können.
Andere Kartendienste generieren Kartendienstarten, welche auf verschiedenen Datenformaten getrennt von einer Kartenkachel in einigen Ausführungsformen setzen. Zum Beispiel Kartendienste, die Ortsdaten bereitstellen, können Datenformate entsprechend den Protokollen von Ortsdiensten verwenden, sowie, aber nicht limitiert auf, Radio Resource Location Service Protocol (RRLP), TIA 801 für Code Division Multiple Access (CDMA), Radio Resource Control (RRC) Positions Protocol oder LTE Positioning Protocol (LPP). Ausführungsformen können auch Daten von Clientvorrichtungen erhalten oder anfragen, welche Möglichkeiten oder Attribute (z. B. Hardwarespezifikationen oder Betriebssystemversion) oder Kommunikationsmöglichkeiten (z. B. Kommunikationsbandbreite der Vorrichtung, die durch drahtlose Signalstärke oder Kabel oder drahtlose Netzwerkart bestimmt wird) der Vorrichtung identifizieren.
Ein Kartendienst kann Kartendienstdaten von einer internen oder externen Quelle erhalten. Zum Beispiel Satellitenbilder, die in Kartenbilddaten verwendet werden, können von externen Diensten oder internen Systemen, Speichervorrichtungen oder Knoten erhalten werden. Andere Beispiele können beinhalten, sind aber nicht limitiert auf, GPS-Unterstützungsserver, drahtlose Netzwerkabdeckung-Datenbanken, Geschäfts- oder persönliche Verzeichnisse, Wetterdaten, Regierungsinformationen (z. B. Aktualisierungen von Bauten oder Änderung von Straßennamen) oder Verkehrsberichte. Einige Ausführungsformen eines Kartendienstes können Kartendienstdaten (z. B. drahtlose Netzwerkabdeckung) für die Analyse von zukünftigen Anfragen der Clientvorrichtungen, aktualisieren.
Verschiedene Ausführungsformen eines Kartendienstes können auf die Anfrage von Clientvorrichtungen für Kartendienste antworten. Diese Anfragen können Anfragen für eine spezifische Karte oder Teile einer Karte sein. Einige Ausführungsformen formatieren Anfragen für eine Karte sowie Anfragen für bestimmte Kartenkacheln. In einigen Ausführungsformen beliefern die Anfragen den Kartendienst auch mit Fahrtorten (oder aktuellen Orten) und Zielorten für eine Routenberechnung. Eine Clientvorrichtung kann auch Renderinginformationen des Kartendienstes, sowie Kartentexturen oder Formatvorlagen, anfragen. In wenigstens einigen Ausführungsformen sind Anfragen auch eine einer Serie von Anfragen, die eine Punkt-zu-Punkt-Navigation implementieren. Anfragen für andere geografische Daten können beinhalten, sind jedoch nicht limitiert auf, einen aktuellen Ort, eine drahtlose Netzwerkabdeckung, Wetter, Verkehrsinformationen oder naheliegende Punkte von Interesse.
Ein Kartendienst analysiert in einigen Ausführungsformen Anfragen einer Clientvorrichtung, um eine Vorrichtungs- oder Kartendienstoperation zu optimieren. Zum Beispiel kann ein Kartendienst erkennen, dass der Ort einer Clientvorrichtung in einem Bereich mit schlechter Verbindung (z. B. schwaches drahtloses Signal) ist und mehr Kartendienstdaten sendet, um eine Clientvorrichtung im Falle von Verbindungsverlust zu beliefern oder sendet Instruktionen, um unterschiedliche Clienthardware (z. B. Ausrichtungssensoren) oder Software (z. B. drahtlose Ortsdienst oder Wi-Fi-Positionierung anstelle von GPS-basierten Diensten zu verwenden) zu verwenden. In einem anderen Beispiel kann ein Kartendienst eine Anfrage einer Clientvorrichtung auf vektorbasierte Kartenbilddaten analysieren und ermitteln, dass rasterbasierte Kartendaten die Kartenbilddaten entsprechend der Bildkomplexität besser optimieren. Ausführungsformen von anderen Kartendiensten können ähnliche Analysen der Anfragen von Clientvorrichtungen ausführen und als solche in die oberen Beispiele nicht als eingrenzend anzusehen.
Verschiedene Ausführungsformen von Clientvorrichtungen (z. B. Clientvorrichtungen 10802a–10802c) sind auf unterschiedlichen tragbaren multifunktionalen Vorrichtungsarten implementiert. Clientvorrichtungen 10802a–10802c verwenden einen Kartendienst 10830 durch verschiedene Kommunikationsverfahren und Protokolle. In einigen Ausführungsformen erhalten Clientvorrichtungen 10802a–10802c Kartendienstdaten von dem Kartendienst 10830. Clientvorrichtungen 10802a–10802c verlangen oder erhalten Kartendienstdaten. Clientvorrichtungen 10802a–10802c verarbeiten dann die Kartendienstdaten (z. B. Rendern und/oder Anzeigen der Daten) und können die Daten zu einem anderen Software- oder Hardwaremodul der Vorrichtung oder zu einer externen Vorrichtung oder einem externen System senden.
Eine Clientvorrichtung entsprechend einigen Ausführungsformen implementiert Techniken, um Karten wiederzugeben und/oder anzuzeigen. Diese Karten können in verschiedenen Formaten angefragt oder erhalten werden, so wie die oben beschriebenen Kartenkacheln. Eine Clientvorrichtung kann eine Karte in zweidimensionalen oder dreidimensionalen Ansichten rendern. Einige Ausführungsformen einer Clientvorrichtung zeigen eine gerenderte Karte und erlauben einem Benutzer, einem System oder eine Vorrichtung, Eingaben, um eine virtuelle Kamera in der Karte zu manipulieren, die Kartenansicht entsprechend der Position, der Ausrichtung und dem Sichtfeld der virtuellen Kamera ändernd, bereitzustellen. Verschiedene Formen und Eingabevorrichtungen sind implementiert, um eine virtuelle Kamera zu manipulieren. In einigen Ausführungsformen manipulieren Berührungseingaben, durch bestimmte einzelne oder Kombinationsgesten (z. B. Berühre und Halte oder ein Wischen) die virtuelle Kamera. Andere Ausführungsformen erlauben durch eine Manipulation des physischen Ortes der Vorrichtung, eine virtuelle Kamera zu manipulieren. Zum Beispiel kann eine Clientvorrichtung aus ihrer aktuellen Position aufwärts gekippt werden, um die virtuelle Kamera zum aufwärts Rotieren zu manipulieren. In einem anderen Beispiel kann eine Clientvorrichtung aus ihrer aktuellen Position vorwärts geneigt werden, um die virtuelle Kamera nach vorn zu bewegen. Andere Eingabevorrichtungen für die Clientvorrichtung können implementiert werden, beinhaltend aber nicht limitiert auf, Toneingabe (z. B. gesprochene Worte), eine physische Tastatur, eine Maus und/oder ein Joystick.
Einige Ausführungsformen stellen verschiedene visuelle Rückmeldungen zu virtuellen Kameramanipulationen bereit, so wie die Anzeige einer Animation von möglichen virtuellen Kameramanipulationen, beim Übergehen von zweidimensionalen Kartenansichten zu dreidimensionalen Kartenansichten. Einige Ausführungsformen erlauben auch Eingabe, um ein Kartenmerkmal oder ein Objekt (z. B. ein Gebäude) auszuwählen und heben das Objekt hervor, dies produziert einen Unschärfeeffekt, welcher die Sichtweise der virtuellen Kamera des dreidimensionalen Raums beibehält.
In einigen Ausführungsformen implementiert eine Clientvorrichtung ein Navigationssystem (z. B. Punkt-zu-Punkt-Navigation). Ein Navigationssystem stellt Anweisungen oder Routeninformationen bereit, welche einem Benutzer angezeigt werden können. Einige Ausführungsform einer Clientvorrichtung fragen Anweisungen oder eine Routenberechnungen von einem Kartendienst an. Eine Clientvorrichtung kann Kartenbilddaten und Routendaten eines Kartendienstes erhalten. In einigen Ausführungsformen implementiert eine Clientvorrichtung ein Punkt-zu-Punkt-Navigationssystem, welches Echtzeit-Routen- und Richtungsinformationen basierend auf Ortsinformationen und Routeninformationen, die von einem Kartendienst und/oder anderen Ortssystemen, sowie einem Global Positioning Satellite (GPS) erhalten werden, bereitgestellt werden. Eine Clientvorrichtung kann Kartenbilddaten anzeigen, die den aktuellen Ort der Clientvorrichtung wiederspiegeln und die Kartenbilddaten in Echtzeit aktualisieren. Ein Navigationssystem kann akustische oder visuelle Anweisungen, um einer bestimmten Route zu folgen, bereitstellen.
Eine virtuelle Kamera ist implementiert, um Navigationskartendaten entsprechend einiger Ausführungsformen zu manipulieren. In einigen Ausführungsformen erlauben die Clientvorrichtungen der Vorrichtung, die Ausrichtung der virtuellen Kameraanzeige anzupassen, um sie in Richtung des Routenziels auszurichten. Einige Ausführungsformen erlauben der virtuellen Kamera auch, Abbiegungen zu navigieren, indem sie die Trägheitsbewegung der virtuellen Kamera simuliert.
Clientvorrichtungen implementieren verschiedene Techniken, um Kartendienstdaten von einem Kartendienst zu verwenden. Einige Ausführungsformen implementieren einige Techniken, um das Rendern von zweidimensionalen und dreidimensionalen Kartenbilddaten zu optimieren. In einigen Ausführungsformen speichert eine Clientvorrichtung Renderinginformation lokal. Zum Beispiel speichert ein Client eine Formatvorlage, welche Renderinginstruktionen für Bilddaten, die Artbezeichnungen enthalten, bereitstellen. In einem anderen Beispiel können häufige Bildtexturen gespeichert werden, um die Anzahl an Kartenbilddaten, die vom Kartendienst übertragen werden, zu reduzieren. Clientvorrichtungen in unterschiedlichen Ausführungsformen implementieren verschiedene Modellierungstechniken, um zweidimensionale und dreidimensionale Kartenbilddaten wiederzugeben, Beispiele von diesen enthalten, sind aber nicht limitiert auf: Generierung von dreidimensionalen Gebäuden aus Profildaten von zweidimensionalen Gebäuden; Modellierung von zweidimensionalen und dreidimensionalen Kartenobjekten, um die Verbindungsumgebung der Clientvorrichtung zu ermitteln; Generierung von Modellen, um zu ermitteln, ob Kartenbezeichnungen aus einer bestimmten virtuellen Kameraposition gesehen werden; und Generierung von Modellen, um Übergänge zwischen Kartenbilddaten zu glätten. In einigen Ausführungsformen ordnen oder priorisieren die Clientvorrichtungen auch Kartendienstdaten nach bestimmten Techniken. Zum Beispiel stellt eine Clientvorrichtung die Bewegung oder Geschwindigkeit einer virtuellen Kamera fest, wenn diese bestimmte Schwellenwerte überschreitet, werden weniger detaillierte Bilddaten für bestimmte Bereiche geladen und gerendert. Andere Beispiele beinhalten: da Rendern vektorbasierter Kurven als eine Serie von Punkten, Vorladen von Kartenbilddaten für Bereiche mit schlechter Verbindung zu einem Kartendienst, Anpassen von Texturen basierend auf der angezeigten Zoomstufe oder Rendern von Kartenbilddaten entsprechend der Komplexität.
In einigen Ausführungsformen kommunizieren Clientvorrichtungen unter Verwendung verschiedener Datenformate getrennt von einer Kartenkachel. Zum Beispiel implementieren einige Clientvorrichtungen Assistant Global Positioning Satellites (A-GPS) und kommunizieren mit Ortsdiensten, die Datenformate verwenden, die den Protokollen der Ortsdienste entsprechen, so wie, aber nicht limitiert auf, Radio Resource Location services Protocol (RRLP), TIA 801 für Code Division Multiple Access (CDMA), Radio Resource Control(RRC)-Positionsprotoll oder LTE Positioning Protocol (LPP). Clientvorrichtungen können auch direkt GPS-Signale erhalten. Ausführungsformen können auch Daten senden, mit oder ohne Anforderungen von einem Kartendienst, die die Möglichkeiten oder Attribute (z. B. Hardwarespezifikation oder Betriebssystemversion) oder Kommunikationsmöglichkeiten (z. B. Kommunikationsbandbreite der Vorrichtung, wie sie von drahtloser Signalstärke oder Kabel oder vom drahtlosen Netzwerktyp bestimmt wurde) der Clientvorrichtungen identifizieren.
108 veranschaulicht eine mögliche Ausführungsform einer Betriebsumgebung 10800 für einen Kartendienst 10830 von Clientvorrichtungen 10802a–10802c. In einigen Ausführungsformen kommunizieren Vorrichtungen 10802a, 10802b und 10802c über ein oder mehrere Kabel oder kabellose Netzwerke 10810. Zum Beispiel ein drahtloses Netzwerk 10810, wie ein Mobilfunknetz, können mit einem Großraumnetzwerk (WAN) 10820, wie das Internet, durch die Verwendung eines Gateways 10814 kommunizieren. Ein Gateway 10814 stellt in einigen Ausführungsformen einen paketorientierten mobilen Datendienst, so wie General Package Radio Service (GPRS) oder einen anderen mobilen Datendienst bereit, der drahtlosen Netzwerken erlaubt, Daten zu anderen Netzwerken, wie Großraumnetzwerk 10820, zu übertragen. Ebenso stellt eine Zugriffsvorrichtung 10812 (z. B. IEEE 802.11g drahtlose Zugriffsvorrichtung) Kommunikationszugriff zu WAN 10820 bereit. Vorrichtungen 10802a und 10802b können jegliche tragbare elektronische oder Rechenvorrichtung sein, die fähig sind, mit einem Kartendienst zu kommunizieren. Die Vorrichtung 10802c kann jegliche nicht tragbare elektronische oder Rechenvorrichtung sein, die fähig ist, mit einem Kartendienst zu kommunizieren.
In einigen Ausführungsformen werden beide, Sprach- und Datenkommunikation über ein drahtloses Netzwerk 10810 und eine Zugriffsvorrichtung 10812 aufgebaut. Zum Beispiel kann die Vorrichtung 10802a einen Telefonanruf tätigen und empfangen (z. B. unter Verwendung von Voice-over-Internet-Protocol(VoIP)-Protokollen), Senden und Empfangen von Emailnachrichten (z. B. unter Verwendung von Simple Mail Transfer Protocol (SMTP) oder Post Office Protocol 3 (POP3)) und Abrufen von elektronischen Dokumenten und/oder Datenströme, wie Webseiten, Fotos und Videos, über das drahtlose Netzwerk 10810, den Gateway 10814 und das WAN 10820 (z. B. unter Verwendung von Transmission Control Protocol/Internet Protocol (TCP/IP) oder User Datagram Protocol (UDP)). Ebenso können in einigen Implementierungen die Vorrichtungen 10802b und 10802c Telefonanrufe tätigen oder empfangen, Emailnachrichten senden und empfangen und elektronische Dokumente über die Vorrichtung 10812 und WAN 10820 abrufen. In verschiedenen Ausführungsformen kann jede der veranschaulichten Clientvorrichtungen mit dem Kartendienst 10830 und/oder anderen Dienst(en) 10850 unter Verwendung einer permanent aufgebauten Verbindung entsprechend mit einem oder mehreren Sicherheitsprotokollen, sowie das Secure Sockets Layer(SSL)-Protocol oder das Transport Layer Security(TLS)-Protocol kommunizieren.
Die Vorrichtungen 10802a und 10802b können auch durch andere Mittel Verbindungen aufbauen. Zum Beispiel kann die drahtlose Vorrichtung 10802a mit anderen drahtlosen Vorrichtungen (z. B. anderen Vorrichtungen 10802b, Mobiltelefonen, usw.) über das drahtlose Netzwerk 10810 kommunizieren. Ebenso können Vorrichtungen 10802a und 10802b Peer-to-Peer-Kommunikationen 10840 (z. B. einen persönlichen Netzwerkbereich) aufbauen durch die Verwendung eines oder mehrerer Kommunikationsuntersysteme, sowie Bluetooth^®-Kommunikation von Bluetooth Special Interest Group, Inc. aus Kirkland, Washington. Die Vorrichtung 10802c kann auch Peer-to-Peer-Verbindungen mit den Vorrichtungen 10802a oder 10802b (nicht gezeigt) aufbauen. Andere Kommunikationsprotokolle und Topologien können auch implementiert werden. Die Vorrichtungen 10802a und 10802b können auch Global Positioning Satellite(GPS)-Signale von GPS-Satelliten 10860 empfangen.
Die Vorrichtungen 10802a, 10802b, und 10802c können mit dem Kartendienst 10830 über das eine oder die mehreren drahtgebundenen und/oder drahtlosen Netzwerke 10812 oder 10810 kommunizieren. Zum Beispiel kann der Kartendienst 10830 Kartendienstdaten für die Renderingvorrichtungen 10802a, 10802b und 10802c bereitstellen. Der Kartendienst 10830 kann auch mit anderen Diensten 10850 kommunizieren, um Daten für die Implementierung von Kartendiensten zu erhalten. Der Kartendienst 10830 und andere Dienste 10850 können auch GPS-Signale von GPS-Satelliten 10860 erhalten.
In verschiedenen Ausführungsformen wird der Kartendienst 10830 und/oder andere Dienst(e) 10850 konfiguriert, um Suchanfragen von jeder der Clientvorrichtungen zu verarbeiten. Suchanfragen können beinhalten, sind aber nicht limitiert auf, Anfragen für Geschäfte, Adressen, Wohnorte, Punkte von Interesse oder einigen Kombinationen davon. Der Kartendienst 10830 und/oder andere Dienst(e) 10850 können konfiguriert werden, um Ergebnisse zurückzuliefern, die mit einer Vielzahl von Parametern zusammenhängen, welche beinhalten, aber nicht limitiert sind auf, einen Ort, der in einen Adressbalken oder ein anderes Texteingabefeld eingegebenen wird (Abkürzungen und/oder andere Kurzschriftbezeichnungen beinhaltend), eine aktuelle Kartenansicht (z. B. kann ein Benutzer einen Ort auf einer Multifunktionsvorrichtung ansehen, während er sich an einem anderen Ort befindet), einen aktuellen Ort des Benutzers (z. B. in Fällen, wo die aktuelle Kartenansicht keine Suchergebnisse beinhaltet) und die aktuelle Route (wenn eine vorhanden ist). In verschiedenen Ausführungsformen können diese Parameter die Zusammensetzung der Suchergebnisse (und/oder der Ordnung der Suchergebnisse) basierend auf unterschiedlichen Prioritätsgewichtungen beeinflussen. In verschiedenen Ausführungsformen können die Suchergebnisse, die zurückgegeben werden, eine Untermenge von selektierten Ergebnissen basierend auf einem spezifischen Kriterium, welches beinhaltet, aber nicht limitiert ist auf eine Menge, wie oft das Suchergebnis angefragt wurde (z. B. ein bestimmter Punkt von Interesse), ein Maß an Qualität verbunden mit dem Suchergebnis (z. B. höchster Benutzer oder Editoren-Rezension-Bewertung) und/oder die Anzahl an Prüfungen für die Suchergebnisse (z. B. die Anzahl der Male, die das Suchergebnis geprüft oder bewertet wurde).
In verschiedenen Ausführungsformen sind der Kartendienst 10830 und/oder andere Dienst(e) 10850 konfiguriert, um automatisch vervollständigte Suchergebnisse bereitzustellen, die auf der Clientvorrichtung, sowie in der Kartenanwendung, angezeigt werden. Zum Beispiel können automatisch vervollständigte Suchergebnisse einen Teil des Bildschirms befüllen, während der Benutzer ein oder mehrere Suchstichworte in die Multifunktionsvorrichtung eingibt. In einigen Fällen kann dieses Merkmal dem Benutzer Zeit sparen, weil das gewünschte Suchergebnis angezeigt werden kann, bevor der Benutzer die gesamte Suchanfrage eingegeben hat. In verschiedenen Ausführungsformen können die automatisch vervollständigten Suchergebnisse Suchergebnisse, die der Client auf der Clientvorrichtungen gefunden hat (z. B. Lesezeichen oder Kontakte), Suchergebnisse, die woanders durch den Kartendienst 10830 und/oder andere Dienst(e) 10850 gefunden werden (z. B. aus dem Internet) und/oder einige Kombinationen davon sein. Wie in dem Fall der Befehle, können alle Suchanfragen durch den Benutzer über Sprache oder durch Tippen eingegeben werden. Die Multifunktionsvorrichtung kann konfiguriert werden, um Suchergebnisse grafisch innerhalb jeder hier beschriebenen Kartenansichten anzuzeigen. Zum Beispiel kann ein Pin oder ein anderer grafischer Indikator Orte der Suchergebnisse als Punkt von Interesse spezifizieren. In verschiedenen Ausführungsformen, antworten auf eine Benutzerauswahl, eines dieser Punkte von Interesse (z. B. eine Berührungsselektion, so wie ein Tippen), ist die Multifunktionsvorrichtung konfiguriert, um zusätzliche Informationen über den selektierten Punkt von Interesse anzuzeigen, beinhaltend aber nicht limitiert auf Bewertungen, Prüfungen oder Prüfungsausschnitte, Betriebsstunden, Geschäftsstatus (z. B. Offen für Verkauf, permanent geschlossen usw.) und/oder Bilder der Fassade des Punktes von Interesse. In verschiedenen Ausführungsformen können all diese Informationen in einer grafischen Informationskarte angezeigt werden, die als Antwort auf die Benutzerselektion des Punktes von Interesse angezeigt wird.
In verschiedenen Ausführungsformen stellen der Kartendienst 10830 und/oder andere Dienst(e) 10850 ein oder mehrere Rückmeldemechanismen bereit, um Rückmeldung von den Clientvorrichtungen 10802a–10802c zu erhalten. Zum Beispiel können Clientvorrichtungen Rückmeldung auf Suchresultate dem Kartendienst 10830 und/oder anderen Dienst(e) 10850 bereitstellen (z. B. Rückmeldung, welche Bewertungen, Rezensionen, temporäre oder permanente Schließungen von Geschäften, Fehler usw. spezifizieren); diese Rückmeldung kann verwendet werden, um Informationen über Punkte von Interesse zu aktualisieren, um genauere oder aktuellere Suchergebnisse in Zukunft bereitzustellen. In einigen Ausführungsformen kann der Kartendienst 10830 und/oder andere Dienst(e) 10850 Testinformationen der Clientvorrichtung bereitstellen (z. B. ein A/B-Test), um zu ermitteln, welche Suchergebnisse die Besten sind. Zum Beispiel kann die Clientvorrichtung in zufälligen Intervallen zwei Suchergebnisse erhalten und dem Benutzer darstellen und dem Benutzer erlauben, das beste Resultat anzugeben. Die Benutzervorrichtung kann die Testergebnisse dem Kartendienst 10830 und/oder anderen Dienst(en) 10850 mitteilen, um zukünftige Suchergebnisse basierend auf der gewählten Testtechnik, sowie eine A/B-Testtechnik, in welcher eine Basislinienstichprobe mit einer Vielzahl an Testproben mit einzelner Variable verglichen wird, um die Ergebnisse zu verbessern.
Während die Erfindung hinsichtlich zahlreicher spezifischer Details beschrieben wurde, wird der Fachmann erkennen, dass die Erfindung in anderen spezifischen Formen ausgeführt werden kann, ohne von der Idee der Erfindung abzuweichen. Zum Beispiel veranschaulichen viele der Figuren verschiedene Berührungsgesten (z. B. Tippen, Doppeltippen, Wischgesten, Drück- und Haltegesten usw.). Allerdings könnten viele der veranschaulichten Operationen durch unterschiedliche Berührungsgesten (z. B. ein Wischen anstelle eines Tippens usw.) oder durch Nichtberührungseingaben (z. B. Verwenden eines Zeigersteuergeräts, einer Tastatur, eines Touchpads/Trackpad, eines fast-berührungsempfindlichen Bildschirms usw.) durchgeführt werden. Zusätzlich veranschaulichen eine Anzahl von Figuren Prozesse konzeptionell. Die spezifische Operation dieser Prozesse muss nicht genau in der gezeigten und beschriebenen Reihenfolge durchgeführt werden. Die spezifischen Operationen müssen nicht in einer kontinuierlichen Serie von Operationen durchgeführt werden und unterschiedliche spezifische Operationen können in unterschiedlichen Ausführungsformen durchgeführt werden. Außerdem könnte der Prozess unter Verwendung mehrerer Unterprozesse oder als ein Teil eines größeren Makroprozesses implementiert werden. Daher würde der Fachmann verstehen, dass die Erfindung nicht durch die vorangehenden veranschaulichten Details limitiert wird, sondern durch die anhängenden Ansprüche definiert wird.

Claims

Nicht-flüchtiges maschinenlesbares Medium, welches eine Kartenanwendung speichert, welche, wenn sie auf einer Vorrichtung durch zumindest eine Verarbeitungseinheit ausgeführt wird, durch eine dreidimensionale (3D) Karte navigiert, während die Kartenanwendung in einem Routennavigationsmodus betrieben wird, wobei die Kartenanwendung Sätze von Instruktionen aufweist zum: zu einer ersten und zweiten Instanz in der Zeit, Bestimmen entsprechender erster und zweiter Positionen einer virtuellen Kamera in der 3D-Karte, wobei die virtuelle Kamera dem Identifizieren einer speziellen Position in der 3D dient, von welcher eine Ansicht der 3D-Karte zu rendern ist, wobei die virtuelle Kamera eine Pluralität von Referenzpunkten aufweist; Identifizieren erster und zweiter Pluralitäten von Orten der Referenzpunkte bei den ersten und zweiten Positionen der virtuellen Kamera; Bestimmen einer Pluralität von Pfaden in der 3D-Karte basierend auf den ersten und zweiten Pluralitäten der Orte der Referenzpunkte; und Bewegen der virtuellen Kamera entlang der Pluralität von Pfaden durch Beibehalten der Pluralität von Referenzpunkten der virtuellen Kamera auf der entsprechenden Pluralität von Pfaden in der 3D-Karte, während die Ansichten der 3D-Karte gerendert werden, um eine animierte Ansicht der 3D-Karte bereitzustellen.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 1, wobei der Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera aufweist einen Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera basierend auf einer geographischen Position der Vorrichtung zu der ersten Instanz in der Zeit.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 1, wobei der Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera aufweist einen Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera basierend auf einem Punkt, bei welchem eine Linie, welche aus der Vorderseite der virtuellen Kamera herausragt, den Boden in der 3D-Karte kreuzt.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 1, wobei der Satz von Instruktionen zum Bestimmen der Pluralitätvon Pfaden in der 3D-Karte aufweist einen Satz von Instruktionen zum Bestimmen der Pluralitätvon Pfaden in der 3D-Karte basierend auf einem Satz von Polynomfunktionen, welche gemäß den ersten und zweiten Pluralitäten von Orten der Referenzpunkte an den ersten und zweiten Positionen der virtuellen Kamera definiert werden.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 1, wobei der Satz von Instruktionen zum Rendern von Ansichten der 3D-Karte, um eine animierte Ansicht der 3D-Karte bereitzustellen, aufweist einen Satz von Instruktionen zum Rendern einer Pluralität von aufeinanderfolgenden Ansichten der 3D-Karte, welche startet durch Rendern einer Ansicht der 3D-Karte von der ersten Position der virtuellen Kamera in der 3D-Karte und endet durch Rendern einer Ansicht der 3D-Karte von der zweiten Position der virtuellen Kamera in der 3D-Karte.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 1, wobei die Kartenanwendung weiterhin aufweist einen Satz von Instruktionen zum Anzeigen der gerenderten Ansichten der 3D-Karte auf der Vorrichtung.
Nicht-flüchtiges maschinenlesbares Medium, welches ein Kartenprogramm zur Ausführung auf einer Vorrichtung durch zumindest eine Verarbeitungseinheit speichert, wobei das Kartenprogramm Sätze von Instruktionen aufweist zum: Definieren einer virtuellen Kamera zur Positionierung an unterschiedlichen Orten in einer dreidimensionalen (3D) Karte, von welcher unterschiedliche Perspektivenansichten der 3D-Karte zu identifizieren sind zum Rendern für die Anzeige auf der Vorrichtung; Definieren eines ersten Pfades in der 3D-Karte, entlang welchem die virtuelle Kamera bewegbar ist zum Anpassen der Perspektivenansicht der 3D-Karte der virtuellen Kamera, während die virtuelle Kamera innerhalb eines ersten Bereichs von Distanzen von der 3D-Karte ist; Definieren eines zweiten Pfades in der 3D-Karte, entlang welchem die virtuelle Kamera bewegbar ist zum Anpassen der perspektivischen Ansicht der 3D-Karte der virtuellen Kamera, während die virtuelle Kamera innerhalb eines zweiten Bereichs von Distanzen von der 3D-Karte ist; und wenn eine Kartenanpassungsoperation empfangen wird, welche die virtuelle Kamera an einer Schwellendistanz von der 3D-Karte zwischen den ersten und zweiten Bereichen von Distanzen vorbei anpasst, Bewegen der virtuellen Kamera von einem der ersten und zweiten Pfade zu dem anderen Pfad.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die ersten und zweiten Bereiche von Distanzen orthogonale Distanzen von der 3D-Karte sind.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei das Kartenprogramm weiterhin aufweist einen Satz von Instruktionen zum Definieren eines dritten Pfades in der 3D-Karte, entlang welchem die virtuelle Kamera bewegbar ist zur Anpassung der perspektivischen Ansicht der 3D-Karte der virtuellen Kamera, während an einem dritten Bereich von Distanzen von der 3D-Karte, welche zwischen den ersten und zweiten Bereichen von Distanzen liegt.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 9, wobei zumindest ein Teil des dritten Bereichs von Distanzen mit einem Teil von zumindest einem der ersten und zweiten Bereiche von Distanzen überlappt.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 9, wobei die ersten, zweiten und dritten Bereiche von Distanzen nicht miteinander überlappen.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die ersten und zweiten Pfade in der dritten Karte erste und zweite Bögen sind, welche mit Bezug auf einen Punkt in der 3D-Karte definiert sind.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die Kartenanpassungsoperation eine Hereinzoomen-Operation ist.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die Kartenanpassungsoperation eine Herauszoomen-Operation ist.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die Kartenanpassungsoperation eine 3D-Perspektiven-Anpassungsoperation ist.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei der Satz von Instruktionen zum Bewegen der virtuellen Kamera Sätze von Instruktionen aufweist zum: Identifizieren einer Position der virtuellen Kamera entlang des einen Pfades, wenn die virtuelle Kamera die Schwellendistanz überschreitet; Bestimmen, ob der andere Pfad eine Position hat, welche der Position der virtuellen Kamera entlang des einen Pfades entspricht; wenn der andere Pfad bestimmt wird, die Position zu haben, welche der Position der virtuellen Kamera entlang des einen Pfades entspricht, Bewegen der virtuellen Kamera zu der entsprechenden Position entlang des anderen Pfades.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 16, wobei der Satz von Instruktionen zum Bewegen der virtuellen Kamera weiterhin Sätze von Instruktionen aufweist zum: wenn der andere Pfad bestimmt wird, nicht die Position zu haben, welche der Position der virtuellen Kamera entlang des einen Pfades entspricht, Identifizieren einer Position entlang des anderen Pfades am nächsten an der Position der virtuellen Kamera entlang des einen Pfades; und Bewegen der virtuellen Kamera zu der Position entlang des anderen Pfades am nächsten zu der Position der virtuellen Kamera entlang des einen Pfades.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 7, wobei die Kartenanpassungsoperation eine erste Kartenanpassungsoperation ist, wobei das Kartenprogramm weiterhin einen Satz von Instruktionen aufweist zum: Bewegen der virtuellen Kamera von dem anderen Pfad zu dem einen Pfad in Antwort auf eine zweite Kartenanpassungsoperation, welche die virtuelle Kamera an der Schwellendistanz von der 3D-Karte zwischen den ersten und zweiten Bereichen von Distanzen vorbei anpasst.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 18, wobei der Satz von Instruktionen zum Bewegen der virtuellen Kamera von dem anderen Pfad zu dem einen Pfad Sätze von Instruktionen aufweist zum: Identifizieren einer Position der virtuellen Kamera entlang des anderen Pfades, wenn die virtuelle Kamera die Schwellendistanz überschreitet; Bestimmen, ob der eine Pfad eine Position hat, welche der Position der virtuellen Kamera entlang des anderen Pfades entspricht; wenn der eine Pfad bestimmt wird die Position zu haben, welche der Position der virtuellen Kamera entlang des anderen Pfades entspricht, Bewegen der virtuellen Kamera zu der entsprechenden Position entlang des einen Pfades.
Nicht-flüchtiges maschinenlesbares Medium nach Anspruch 19, wobei der Satz von Instruktionen zum Bewegen der virtuellen Kamera von dem anderen Pfad zu dem einen Pfad weiterhin Sätze von Instruktionen aufweist zum: wenn der eine Pfad bestimmt wird, nicht die Position zu haben, welche der Position der virtuellen Kamera entlang des anderen Pfades entspricht, Identifizieren einer Position entlang des einen Pfades am nächsten zu der Position der virtuellen Kamera entlang des anderen Pfades; und Bewegen der virtuellen Kamera zu der Position entlang des einen Pfades am nächsten zu der Position der virtuellen Kamera entlang des anderen Pfades.
Vorrichtung aufweisend: einen Anzeigebildschirm; mindestens eine Verarbeitungseinheit; und einen Speicher, welcher ein Kartenprogramm speichert, welches, wenn es durch die Verarbeitungseinheit ausgeführt wird, durch eine dreidimensionale (3D) Karte navigiert, während das Kartenprogramm in einem Routennavigationsmodus betrieben wird, wobei das Kartenprogramm Sätze von Instruktionen aufweist zum: zu einer ersten und zweiten Instanz in der Zeit, Bestimmen entsprechender erster und zweiter Positionen einer virtuellen Kamera in der 3D-Karte, wobei die virtuelle Kamera dem Identifizieren einer speziellen Position in der 3D dient, von welcher eine Ansicht der 3D-Karte zu rendern ist, wobei die virtuelle Kamera eine Pluralität von Referenzpunkten aufweist; Identifizieren erster und zweiter Pluralitäten von Orten der Referenzpunkte bei den ersten und zweiten Positionen der virtuellen Kamera; Bestimmen einer Pluralität von Pfaden in der 3D-Karte basierend auf den ersten und zweiten Pluralitäten der Orte der Referenzpunkte; und Bewegen der virtuellen Kamera entlang der Pluralität von Pfaden durch Beibehalten der Pluralität von Referenzpunkten der virtuellen Kamera auf der entsprechenden Pluralität von Pfaden in der 3D-Karte, während die Ansichten der 3D-Karte gerendert werden, um eine animierte Ansicht der 3D-Karte bereitzustellen.
Vorrichtung nach Anspruch 21, wobei der Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera aufweist einen Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera basierend auf einer geographischen Position der Vorrichtung zu der ersten Instanz in der Zeit.
Vorrichtung nach Anspruch 21, wobei der Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera aufweist einen Satz von Instruktionen zum Bestimmen der ersten Position der virtuellen Kamera basierend auf einem Punkt, bei welchem eine Linie, welche aus der Vorderseite der virtuellen Kamera herausragt, den Boden in der 3D-Karte kreuzt.
Vorrichtung nach Anspruch 21, wobei der Satz von Instruktionen zum Bestimmen der Pluralitätvon Pfaden in der 3D-Karte aufweist einen Satz von Instruktionen zum Bestimmen der Pluralitätvon Pfaden in der 3D-Karte basierend auf einem Satz von Polynomfunktionen, welche gemäß den ersten und zweiten Pluralitäten von Orten der Referenzpunkte an den ersten und zweiten Positionen der virtuellen Kamera definiert werden.
Vorrichtung nach Anspruch 21, wobei der Satz von Instruktionen zum Rendern von Ansichten der 3D-Karte, um eine animierte Ansicht der 3D-Karte bereitzustellen, aufweist einen Satz von Instruktionen zum Rendern einer Pluralität von aufeinanderfolgenden Ansichten der 3D-Karte, welche startet durch Rendern einer Ansicht der 3D-Karte von der ersten Position der virtuellen Kamera in der 3D-Karte und endet durch Rendern einer Ansicht der 3D-Karte von der zweiten Position der virtuellen Kamera in der 3D-Karte.
Vorrichtung nach Anspruch 21, wobei das Kartenprogramm weiterhin aufweist einen Satz von Instruktionen zum Anzeigen der gerenderten Ansichten der 3D-Karte auf dem Anzeigebildschirm der Vorrichtung.
Maschinenlesbares Medium, welches eine Kartenanwendung zur Ausführung durch zumindest einen Prozessor speichert, wobei die Kartenanwendung Sätze von Instruktionen aufweist zum: Rendern eines ersten Kartenansichtsmodus durch Verwenden eines ersten Satzes von Kartenkacheln; während des Renderns des ersten Kartenansichtsmodus, Bestimmen, dass ein Wechsel zu einem zweiten Kartenansichtsmodus wahrscheinlich ist aufzutreten; basierend auf der Bestimmung, Herunterladen eines zweiten Satzes von Kartenkacheln zur Verwendung beim Rendern des zweiten Kartenansichtsmodus; und vor Empfangen einer Anfrage zu dem zweiten Kartenansichtsmodus zu wechseln, Vorbereiten einer Pipeline zum Rendern des zweiten Kartenansichtsmodus durch Verwenden des zweiten Satzes von Kartenkacheln.
Maschinenlesbares Medium nach Anspruch 27, wobei der erste Kartenansichtsmodus eine nicht-immersive 3D-Kartenansicht ist und der zweite Kartenansichtsmodus eine immersive 3D-Kartenansicht ist.
Maschinenlesbares Medium nach Anspruch 27, wobei der erste Kartenansichtsmodus ein Kartenbrowsingmodus ist und der zweite Kartenansichtsmodus ein Navigationsmodus ist.
Maschinenlesbares Medium nach Anspruch 12, wobei ein Wechsel zu dem zweiten Kartenansichtsmodus wahrscheinlich auftreten wird, wenn die Kartenanwendung eine Anfrage für eine Route von einem derzeitigen Ort eines Benutzers zu einem Ziel empfängt.
Maschinenlesbares Medium nach Anspruch 27, wobei die Kartenanwendung weiterhin einen Satz von Instruktionen aufweist zum Rendern des zweiten Kartenansichtsmodus nach Empfang der Eingabe zum Wechseln zu dem zweiten Kartenansichtsmodus.
Maschinenlesbares Medium nach Anspruch 31, wobei die Kartenanwendung weiterhin einen Satz von Instruktionen aufweist zum Rendern eines Übergangs von dem ersten Kartenansichtsmodus zu dem zweiten Kartenansichtsmodus.
Für eine Kartenanwendung weist ein Verfahren auf: Rendern eines ersten Kartenansichtsmodus durch Verwenden eines ersten Satzes von Kartenkacheln; während des Renderns des ersten Kartenansichtsmodus, Bestimmen, dass ein Wechsel zu einem zweiten Kartenansichtsmodus wahrscheinlich auftreten wird; basierend auf der Bestimmung, Herunterladen eines zweiten Satzes von Kartenkacheln zur Verwendung beim Rendern des zweiten Kartenansichtsmodus; und vor Empfangen einer Anfrage zum Wechseln zu dem zweiten Kartenansichtsmodus, Vorbereiten einer Pipeline zum Rendern des zweiten Kartenansichtsmodus durch Verwenden des zweiten Satzes von Kartenkacheln.
Verfahren nach Anspruch 33, wobei der erste Kartenansichtsmodus eine nicht-immersive 3D-Kartenansicht ist und der zweite Kartenansichtsmodus eine immersive 3D-Kartenansicht ist.
Verfahren nach Anspruch 33, wobei der erste Kartenansichtsmodus ein Kartenbrowsingmodus ist und der zweite Kartenansichtsmodus ein Navigationsmodus ist.
Verfahren nach Anspruch 35, wobei ein Wechsel zu dem zweiten Kartenansichtsmodus wahrscheinlich auftreten wird, wenn die Kartenanwendung eine Anfrage für eine Route von einem derzeitigen Ort eines Benutzers zu einem Ziel empfängt.