DE102011082761A1

DE102011082761A1 - Lieferung, Verarbeitung und Aktualisierung von fortgeschrittenen Karteninformationen

Info

Publication number: DE102011082761A1
Application number: DE102011082761A
Authority: DE
Inventors: Mark Schunder; David M. DiMeo; Mark Scalf
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2010-09-29
Filing date: 2011-09-15
Publication date: 2012-03-29
Also published as: CN102540223B; US20120078493A1; RU2577548C2; US9568325B2; US20140025289A1; RU2011139473A; US8849552B2; CN102540223A

Abstract

Ein veranschaulichendes Verfahren zum Datensammeln beinhaltet das Bestimmen, dass eine Fahrzeugfahrcharakteristik sich über einen erwarteten Parameter hinaus geändert hat. Das Verfahren beinhaltet weiter das Aufzeichnen der GPS-Koordinaten des Fahrzeugs und Abbrechen der Aufzeichnung der GPS-Koordinaten des Fahrzeugs, wenn die Fahrzeugfahrcharakteristik den erwarteten Parameter wieder aufnimmt. Schließlich beinhaltet das Verfahren das Bestimmen und Speichern eines Verkehrssteuermerkmals, verbunden mit zumindest einem Satz der GPS-Koordinaten, wenn die aufgezeichneten GPS-Koordinaten des Fahrzeugs vormals aufgezeichneten GPS-Koordinaten entsprechen.

Description

HINTERGRUND
1. Technisches Gebiet
Die veranschaulichenden Ausführungsformen beziehen sich im Allgemeinen auf Systeme, Verfahren und Vorrichtung zur fortgeschrittenen Lieferung und Verarbeitung von Karteninformationen.
2. Stand der Technik
Navigationssysteme sind in vielen Fahrzeugen und auf vielen nomadischen Geräten weit verbreitet, einschließlich, aber nicht beschränkt auf, Mobiltelefone, Smartphones, PDAs (personal data assistants) usw. Diese Systeme verwenden im Allgemeinen GPS-(global positioning system)-Koordinaten, um den aktuellen Ort eines Benutzers zu bestimmen, und es kann ebenfalls ein Zielort darin eingegeben werden.
ZUSAMMENFASSUNG
Der Zielort wird typischerweise, wenn auch nicht notwendigerweise, in Form einer Adresse, eines Ortsnamen oder einer Querstraße eingegeben. Während ursprüngliche GPS-Systeme von Bergwanderern und Outdoor-Anhängern verwendet wurden, werden moderne GPS im Allgemeinen verwendet, um von einem Ort zu einer vorbestimmten Adresse oder Gegend zu navigieren, der normalerweise mit einem Kartenort übereinstimmt.
Dementsprechend integrieren die meisten modernen GPS-Systeme die Verwendung einer Form von Kartendaten bei der Planung von Richtungen. Das heißt, dass, anstatt des Aufstellens einer Luftlinienroute oder des bloßen Ausgebens eines Steuerkurses, dem der Benutzer folgen soll, die Systeme Kartendaten integrieren, sodass die Route, der gefolgt werden soll, im Allgemeinen entlang existierender Fahrbahnen gesetzt ist. Dies ist aufgrund der weitverbreiteten Verwendung in Fahrzeugen, deren Fahrstrecke normalerweise auf akzeptierte vorbestimmte Straßen beschränkt ist.
Selbstverständlich wird überall auf der Welt durchgängig gebaut, die Straßen werden verändert, es gibt neue Straßen, Straßen werden aufgebrochen usw. Daten, die Tage, Wochen, Monate oder sogar Jahre alt sind, können einfach nicht länger akkurat sein. Ein gutes Beispiel hierfür wird in Washington DC nach den Anschlägen vom 11. September 2001 gefunden.
Als Ergebnis erhöhter Sicherheitsbedenken wurden Fahrbahnen geschlossen, einspurig gemacht, durch Barrikaden versperrt und eine ganze Autobahn, die nahe dem Pentagon verlief, wurde weiter weg vom Pentagon verlegt. Alte Kartendaten, die vor dem Ereignis zurückdatierten, hätten jedoch die ganzen alten Straßen gezeigt, und der Benutzer würde leicht verwirrt werden, wenn er diese Daten verwenden würde, da das GPS angezeigt hätte, dass sie in einem Feld fahren, oder sie angewiesen hätte, eine Straße entlang zu fahren, die nicht länger existiert.
Im allgemeineren Sinne werden neue Unterteilungen konstant gebaut, und all die Straßen, die darin gebaut werden, sind in veralteten Karten nicht vorhanden. Daher kann ein Benutzer, der in ein neues Haus zieht, feststellen, dass deren gesamte Unterteilung nur ein leerer Fleck im GPS ist.
Viele Unternehmen, die Karteninformationen an Benutzer bereitstellen, stellen ebenfalls eine Option bereit, Karteninformationen zu aktualisieren. Diese Informationen können jedoch in ihrer Gesamtheit ziemlich umfangreich und nicht allzu nützlich sein. Beispielsweise kann ein Benutzer, der im Allgemeinen im südöstlichen Michigan unterwegs ist, wenig oder keine Verwendung einer Kartenaktualisierung der Straßen von Hawaii aufweisen.
Weitere erschwerende potenzielle Aktualisierungsprobleme sind Bedenken hinsichtlich der Bandbreite. Das gesamte Fahrbahnsystem der Vereinigten Staaten ist ein extrem komplexes Netzwerk von Autobahnen, Landstraßen, Straßen, Plätzen usw. Zu dieser Komplexität beitragend sind variierende Geschwindigkeitsbegrenzungen, Umleitungen, Stoppschilder, Straßenbeleuchtungen, Steigungen, Verkehrsmuster usw. Wenn alle diese Informationen auf dieser detaillierten Ebene aktualisiert werden würden, könnte die Bandbreitenanforderung für nützlichen Transfer immens sein.
Außerdem würde, wenn Benutzer im mehrstelligen Millionenbereich versuchen würden, die Daten gleichzeitig zu aktualisieren, dies eine weitere Belastung für die Server darstellen, die diese Daten bereitstellen.
Schließlich gibt es, wenn neue Straßen gebaut werden, keine allgemeine „Dokumentationsstelle”, der die Straßen vorgelegt werden, also könnte es den Fall geben, wo eine Straße gebaut wird, und die Straße für eine tatsächliche Person nur entdeckt werden kann, indem sie an diesen Ort fährt oder indem ein Satellitenbild den Bau der Straße wiedergibt.
Bei einer ersten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Bestimmen, dass eine Fahrzeugfahrcharakteristik einen erwarteten Parameter überschritten hat. Das Verfahren beinhaltet weiter das Aufzeichnen von Fahrzeug-GPS-Koordinaten und das Abbrechen der Aufzeichnung der Fahrzeug-GPS-Koordinaten, wenn die Fahrzeugfahrcharakteristik eine Abbruchtoleranz (wie z. B. Wiederaufnehmen des erwarteten Parameters) überschreitet.
Schließlich beinhaltet dieses veranschaulichende Verfahren das Bestimmen und Speichern eines Verkehrssteuermerkmals, verbunden mit zumindest einem Satz der GPS-Koordinaten, abhängig von einer vorbestimmten Anzahl an aufgezeichneten Fahrzeug-GPS-Koordinaten, die zumindest dem einen Satz an GPS-Koordinaten entsprechen.
Bei einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren zum Sammeln von Daten das Bestimmen, dass ein Fahrzeug an einem geländegängigen Ort lokalisiert ist, und das Aufzeichnen von Fahrzeug-GPS-Koordinaten.
Dieses veranschaulichende Verfahren beinhaltet weiter das Fortfahren mit dem Aufzeichnen der GPS-Koordinaten des Fahrzeugs in vorbestimmten Intervallen, bis das Fahrzeug an einem straßenseitigen Ort lokalisiert ist.
Das Verfahren beinhaltet ebenfalls das Speichern, zumindest bis das Fahrzeug an dem straßenseitigen Ort lokalisiert ist, aller GPS-Koordinaten, die von der Aufzeichnung aufgezeichnet wurden, um eine neue Straße zu erzeugen.
Bei noch einer dritten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Empfangen von, bei einem oder mehr Servern, GPS-Koordinaten von einer Vielzahl von Fahrzeugen, für die sich ein Fahrmerkmal über einen erwarteten Grenzwert hinaus verändert hat.
Das Verfahren beinhaltet ebenfalls das Vergleichen empfangener GPS-Koordinaten. Sodann wird, basierend zumindest teilweise auf einer Übereinstimmung zwischen einer vorbestimmten Anzahl an empfangenen GPS-Koordinaten, ein Verkehrssteuermerkmal registriert. Schließlich beinhaltet das Verfahren das Verbinden des Verkehrssteuermerkmals mit den GPS-Koordinaten und das Speichern des Verkehrssteuermerkmals.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes EDV-System.
2A zeigt ein veranschaulichendes Beispiel einer Darstellung einer Kartenkachel;
2B zeigt ein veranschaulichendes Beispiel von Daten, die hinsichtlich Straßenkacheln gespeichert werden können;
3, ein Modell des Staates Michigan, zeigt beispielhafte Kachelung;
4 zeigt einen beispielhaften Prozess zum Aktualisieren von Kachelinformationen;
5 zeigt einen beispielhaften veranschaulichenden Prozess zum Bestimmen, ob ein Benutzer für eine Aktualisierung einer bestimmten Kachel berechtigt ist;
6 zeigt zumindest ein Beispiel eines Prozesses zum Bestimmen von „Flottendienstleistungs”-Verfügbarkeit;
7 zeigt ein Beispiel für Privatdatensammlung;
8 zeigt ein veranschaulichendes Beispiel eines Datensammelprozesses;
9 zeigt zumindest einen Fall einer beispielhaften Straßenabweichungsdatensammlung;
10 zeigt ein Beispiel dieser Datensammlung; und
11 zeigt ein veranschaulichendes Beispiel für automatisches Erkennen eines Verkehrssignals.
AUSFÜHRLICHE BESCHREIBUNG
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes EDV-System 1 (vehicle based computing system, VCS) für ein Fahrzeug 31. Ein Beispiel für solch ein fahrzeugbasiertes EDV-System 1 ist das von THE FORD MOTOR COMPANY hergestellte System SYNC. Ein mit einem fahrzeugbasierten EDV-System ausgestattetes Fahrzeug kann eine im Fahrzeug angeordnete visuelle Frontschnittstelle 4 enthalten. Möglicherweise kann der Benutzer auch mit der Schnittstelle interagieren, wenn dies vorgesehen ist, zum Beispiel über einen berührungsempfindlichen Bildschirm. Bei einer weiteren veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastendruck, akustische Sprache und Sprachsynthese.
Bei der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten EDV-Systems. Der im Fahrzeug bereitgestellte Prozessor ermöglicht die Onboard-Verarbeitung von Befehlen und Routinen. Weiter ist der Prozessor sowohl mit dem nicht-dauerhaften 5 als auch mit dem dauerhaften Speicher 7 verbunden. Bei dieser veranschaulichenden Ausführungsform ist der nicht-dauerhafte Speicher ein Random Access Memory (RAM) und der dauerhafte Speicher eine Festplatte (HDD) oder ein Flash-Speicher.
Der Prozessor ist außerdem mit einer Reihe verschiedener Eingänge ausgestattet, die dem Benutzer die Verbindung mit dem Prozessor ermöglicht. Bei dieser veranschaulichenden Ausführungsform werden ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 bereitgestellt. Außerdem wird ein Eingangswahlschalter 51 bereitgestellt, der dem Benutzer das Umschalten zwischen den verschiedenen Eingängen ermöglicht. Der Eingang sowohl für das Mikrofon als auch für den Hilfsanschluss wird von einem Konverter 27 von analog zu digital umgewandelt, bevor er zum Prozessor geleitet wird.
Ausgänge am System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang umfassen, sind aber nicht darauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 über einen Digital-zu-Analog-Konverter 9. Es kann auch ein Ausgang für ein entferntes BLUETOOTH-Gerät, zum Beispiel ein PND 54, oder ein USB-Gerät, zum Beispiel ein Fahrzeugnavigationsgerät 60, entlang der bidirektionalen Datenströme genutzt werden, die unter 19 bzw. 21 dargestellt werden.
Bei einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/Empfänger 15 zur Kommunikation 17 mit dem mobilen Gerät 53 (z. B. Mobiltelefon, Smartphone, PDA oder ein anderes Gerät mit drahtloser Verbindung zu einem entfernten Netzwerk) eines Benutzers. Das mobile Gerät kann dann für die Kommunikation 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 über beispielsweise die Kommunikation 55 mit einem Sendemast 57 verwendet werden. Bei manchen Ausführungsformen kann es sich bei dem Turm 57 um einen WiFi-Zugangspunkt handeln.
Beispielhafte Kommunikation zwischen dem mobilen Gerät und dem BLUETOOTH-Sender/Empfänger wird durch das Signal 14 dargestellt.
Das Zusammenschalten eines mobilen Geräts 53 mit dem BLUETOOTH-Sender/Empfänger 15 kann über eine Taste 52 oder eine vergleichbare Eingabe angewiesen werden. Entsprechend wird der CPU mitgeteilt, dass der BLUETOOTH-Bordsender/Empfänger mit einem BLUETOOTH-Sender/Empfänger in einem mobilen Gerät zusammengeschaltet wird.
Daten können zwischen CPU 3 und Netzwerk 61 unter Verwendung zum Beispiel eines Datenplans, Data-over-Voice oder DTMF-Töne übertragen werden, die mit dem mobilen Gerät 53 verbunden sind. Als Alternative kann es wünschenswert sein, ein Bordmodem 63 mit einer Antenne 18 einzubeziehen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übertragen 16. Das mobile Gerät 53 kann dann zur Kommunikation 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31, zum Beispiel durch Kommunikation 55 mit einem Mobilfunkturm 57, verwendet werden. Bei manchen Ausführungsformen kann das Modem 63 eine Verbindung 20 mit dem Turm 57 zur Kommunikation mit dem Netzwerk 61 herstellen. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem und die Verbindung 20 eine Mobilfunkverbindung sein.
Bei einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem einschließlich API zur Kommunikation mit der Modemanwendungssoftware versehen. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Transceiver zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie er zum Beispiel in einem mobilen Gerät zu finden ist) durchzuführen.
Bei einer weiteren Ausführungsform umfasst das mobile Gerät 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexverfahren bekannte Technologie implementiert werden, bei der der Eigentümer des mobilen Geräts über das Gerät sprechen kann, während Daten übertragen werden. Wenn der Eigentümer das Gerät nicht verwendet, kann die Datenübertragung die ganze Bandbreite nutzen (300 Hz bis 3,4 kHz in einem Beispiel).
Wenn der Benutzer einen Datenplan hat, der mit dem mobilen Gerät verbunden ist, ist es möglich, dass der Datenplan eine Breitbandübertragung ermöglicht und das System eine viel größere Bandbreite nutzen kann (was die Datenübertragung beschleunigt). Bei einer weiteren Ausführungsform wird das mobile Gerät 53 durch ein am Fahrzeug 31 angebrachtes Mobilkommunikationsgerät (nicht gezeigt) ersetzt. Bei einer anderen weiteren Ausführungsform kann es sich beim NG 53 um ein drahtloses LAN-Netzwerkgerät handeln, das zur Kommunikation über beispielsweise (aber nicht ausschließlich) ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk in der Lage ist.
In einer Ausführungsform können eingehende Daten über das mobile Gerät per Data-over-Voice oder Datenplan über den Onboard-BLUETOOTH-Transceiver und zum internen Prozessor des Fahrzeugs 3 geleitet werden. Bei bestimmten temporären Daten können die Daten zum Beispiel auf der Festplatte oder einem anderen Speichermedium 7 gespeichert werden, bis sie nicht mehr benötigt werden.
Zusätzliche Quellen, für die eine Verbindung mit dem Fahrzeug möglich ist, sind zum Beispiel ein persönliches Navigationsgerät 54, das zum Beispiel eine USB-Verbindung 56 und/oder Antenne 58 hat, oder ein Fahrzeugnavigationsgerät 60, das eine USB- 62 oder andere Verbindung hat, ein Onboard-GPS-Gerät 24 oder ein entferntes Navigationssystem (nicht abgebildet), das eine Verbindung zu Netzwerk 61 hat.
Weiter könnte die CPU mit einer Vielzahl von Zusatzgeräten 65 kommunizieren. Diese Geräte können über eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden werden. Die CPU könnte alternativ auch mit einem fahrzeugbasierten drahtlosen Router 73 verbunden werden, zum Beispiel mithilfe eines WiFi-Transceivers 71. Dies könnte der CPU eine Verbindung zu entfernten Netzwerken im Bereich des lokalen Routers 73 ermöglichen. Zusatzgeräte 65 können unter anderem persönliche Medienabspielgeräte, drahtlose medizinische Geräte, tragbare Computer und dergleichen sein.
Selektive Lieferung
In einem verbesserten Kartendatenverarbeitungs-, -lieferungs- und -aktualisierungssystem kann es wünschenswert sein, selektiv nützliche Kartendaten an einen Benutzer zu liefern, um zu verhindern, dass der Benutzer warten muss, bis er sich einen ganzen Datensatz herunterladen kann. Dies kann ebenfalls eine kostengünstigere Option sein, da der Benutzer erforderlicherweise nur für Daten bezahlen muss, die er tatsächlich verwenden wird. Solch ein System kann insbesondere nützlich sein, wenn Bandbreiteneinschränkungen ein Bedenken darstellen.
Ein Beispiel eines solchen Systems ist das System SYNC von FORD. In diesem System werden einige (aber nicht alle) Datenverbindungen durch eine DOV-(data over voice)-Verbindung zu einem entfernten Server hergestellt. DOV stellt jedoch für den Transfer eine eingeschränkte Bandbreitenverfügbarkeit bereit. Dementsprechend könnte es buchstäblich Stunden dauern, eine große Kartenaktualisierung über diese Bandbreite zu übertragen, und ein Telefon eines Benutzers lahmlegen sowie Anrufzusatzgebühren anhäufen.
Kartendaten können jedoch in stärker eingeschränkter Form verfügbar sein, wie z. B. Kacheln, deren Gesamtsumme eine Karte umfasst. Daher wäre es möglich, „Brocken” einer Karte in kleinerem und nützlicherem Format herunterzuladen.
Kachelzusammensetzung
Bei zumindest einer veranschaulichenden Ausführungsform wird vorgesehen, dass Kartendaten in der Form von Kacheln verfügbar sind. Bei dieser Ausführungsform sind diese Kacheln eingeschränkte Teilsätze einer ganzen Karte und sind in Gebiete unterteilt, die durch logische (Straßenecke, Bezirk, Stadt usw.) Grenzen oder geografische Grenzen (Koordinaten usw.) begrenzt werden. Egal wie die Kacheln implementiert werden, es geht daraus hervor, dass eine gegebene Route, sogar eine Route über das gesamte Land, wahrscheinlich keine hundertprozentige Aktualisierung der Kacheln benötigt. Im Allgemeinen muss ein Aktualisieren oder Herunterladen von solchen Kacheln erhalten werden, die Teile der zu fahrenden Straße umfassen oder zumindest in der Nähe dazu liegen.
2A zeigt ein veranschaulichendes Beispiel einer Darstellung einer Kartenkachel. Bei diesem veranschaulichenden Beispiel wird die Kartenkachel von vier GPS-Koordinaten 201, 203, 205, 207 begrenzt, und bildet ein Quadrat. Jede Kartenkachel in einem System, einschließlich einer Vielzahl von Kartenkacheln, wie z. B. Kachel 200, beinhaltet eine Vielfalt von Daten, die sich auf die Straßen 209 beziehen, die innerhalb der GPS-Grenzen der Kachel existieren. Wie aus diesem Beispiel ersichtlich, verlaufen einige Straßen über die Grenzen der Kachel hinfort. Bei dieser Ausführungsform werden Daten, die sich auf die Teile der Straße innerhalb der Kachelgrenzen beziehen, hinsichtlich der bestimmten Kachel gespeichert. Straßensteigungen, Straßenschilder, Geschwindigkeitsänderungen usw. werden hinsichtlich der Straßen, die innerhalb der Kachel enthalten sind, behalten.
Kacheldaten
Eine fast unmessbare Menge an Daten kann über eine bestimmte Fahrbahn gesammelt und gespeichert werden, abhängig von der gewünschten Komplexität der Informationen. Ohne Einschränkung beinhalten diese Straßenkoordinaten, Straßenzusammensetzung, Straßentyp, Straßenklasse, Fahrbeschränkungen, Steigungen, Verkehrsschilder, Verkehrsmuster, Häufigkeit der Verwendung, Bauinformationen usw. 2B zeigt ein veranschaulichendes Beispiel von Daten, die hinsichtlich Straßenkacheln gespeichert werden können. In diesem Beispiel hat jede Straße 211 eine Reihe von Daten, die damit verbunden sind.
Geografische Daten
Einige der Daten, die am häufigsten gesammelt und bei der Abbildung von Straßen in einem GPS-System verwendet werden, sind die geografischen Koordinateninformationen über die Straße 213. Diese Daten sind zumindest nützlich, um es einem Benutzer zu ermöglichen, ein visuelles Bild einer Straßenanordnung zu sehen, und zu wissen, wohin die Straße führt und welche anderen Straßen durch diese bestimmte Straße gekreuzt werden. Abhängig davon, wie präzise die Straße hinsichtlich GPS-Koordinaten dargestellt ist, können diese Daten nicht besonders intensiv zu sammeln und darzustellen sein (d. h. ein Sechs-Meilen-Abschnitt einer geraden Straße kann durch zwei Punkte dargestellt werden). Für jede Kachel hat bei dieser Ausführungsform jede Straße eine Vielzahl von Koordinaten 221, die damit verbunden sind. Durch Vergleichen dieser Koordinaten mit einer Fahrzeugposition und/oder -fahrtrichtung kann ein Fahrzeug-EDV-System bestimmen, auf welcher Straße ein Fahrzeug fährt.
Funktions-/Klassendaten
Ein anderer herkömmlicher Informationssatz, der über Straßen gesammelt wird, ist als Klassifikation der Straße bekannt. Viele Datenprovider klassifizieren eine bestimmte Straße, sowohl hinsichtlich Funktion (Straße, Autobahn) als auch/oder hinsichtlich Geschwindigkeitsbegrenzungsbereich (z. B. 5–20 mph, 25–35 mph, 35–45 mph usw.) 215.
Anhand dieser Informationen, kombiniert mit den geografischen Informationen, können schnelle Bestimmungen über die Streckenführung gemacht werden. Es kann beispielsweise bestimmt werden, dass eine bestimmte Route X Meilen lang ist (basierend auf geografischen Daten), und die Durchschnittsgeschwindigkeit über die Routensegmente, multipliziert mit der Länge der Segmente, kann eine schnelle Abschätzung der Fahrzeit bereitstellen.
Diese Daten können ebenfalls verwendet werden, um „Nur Autobahn”- oder „Oberflächenstraße”-Routen einem Ort zuzuteilen, für den Fall, dass ein bestimmter Benutzer auf einem bestimmten Straßentyp nicht fahren möchte. Wenn beispielsweise ein Benutzer gefährliches oder ungewöhnlich sperriges Transportgut transportiert, kann der Benutzer wünschen, Autobahnen vollständig zu vermeiden. Unter Verwendung der Funktionsinformationen kann das GPS-System den Benutzer um Autobahnen herumleiten, um gefährliche Fahrbedingungen zu vermeiden.
Bei diesem veranschaulichenden Beispiel beziehen sich verschiedene Klassennummern 223 auf vordefinierte Geschwindigkeitsklassifizierungen. Beispielsweise kann sich eine 1 auf eine Straße beziehen, auf der 25 mph oder darunter gelten, kann sich eine 2 auf eine Straße beziehen, deren Geschwindigkeitsbegrenzung zwischen 25 und 35 mph liegt, und eine 3 kann sich auf eine Straße beziehen, deren Geschwindigkeitsbegrenzung zwischen 35 und 45 mph liegt.
Verkehrsregelungsdaten
Eine weitere mögliche Datenebene sind Verkehrsregelungsdaten 217. Diese können Informationen beinhalten, wie z. B. Stoppschilder, Ampeln, tatsächlich aufgestellte Geschwindigkeitsbegrenzungen (im Gegensatz zu Bereichen). Unter Verwendung dieser Informationen kann eine viel akkuratere Bestimmung hinsichtlich der Fahrzeit gemacht werden. Selbstverständlich liegt der Kompromiss hierin, dass diese Daten sowohl viel intensiver zu sammeln als auch herunterzuladen sind. Dies kann zu gestiegenen Kosten zur Verwendung und Aktualisierung sowie erhöhten Bandbreitenanforderungen zum Empfang beitragen.
Bei dem gezeigten veranschaulichenden Beispiel kann jede Verkehrsregelung (Stoppschild, Straßenbeleuchtung, Vorfahrtsschild usw.) mit einem oder mehr Koordinatenorten verbunden werden 225. Wenn daher eine Route diesen Ort kreuzt, kann das Fahrzeug-EDV-System in der Lage sein, einen Geschwindigkeitsunterschied bei einer Route, basierend auf diesen Informationen, zu berechnen. Wenn beispielsweise eine Route drei Meilen lang ist, sie aber keine Verkehrsregelungen (wie z. B. Stoppschilder) hat, kann es schneller sein, hier entlang zu fahren, im Vergleich zu einer Route, die zwar nur eine Meile lang ist, aber mehrere Stoppschilder hat.
Verkehrsmusterdaten
Verkehrsmusterdaten können ebenfalls nützliche Informationen sein, die hinsichtlich einer Kachel gespeichert werden sollen 219. Diese Daten können abermals steigend akkurate Fahrzeitabschätzungen bereitstellen. Es gibt jedoch auch die Anforderung zusätzlicher Ressourcen zum Sammeln und Aktualisieren dieser Informationen.
Verkehrsdaten können von historischer oder echtzeitiger Natur sein. Echtzeitdaten erfordern mehr Bandbreite, da sie potenziell strömend sind, und daher in konstantem Fluss sind. Dementsprechend können Echtzeitdaten für die gesamte Route untragbar in der Größe sein, wenn eine Route lang genug ist. Andererseits kann es wenig Grund dafür geben, derzeitige Verkehrsdaten für einen Punkt herunterzuladen, der zwei Stunden auf einer Route entfernt ist, da diese Daten sich wahrscheinlich ändern werden, sobald der Punkt erreicht worden ist.
Historische Verkehrsdaten können beim Identifizieren von Gegenden und Zeiten nützlich sein, wenn der Verkehr an einem gegebenen Ort besonders schlecht ist. Selbstverständlich kann dies für Hindernisse, wie z. B. Verkehrsunfälle, kurzfristige Bauarbeiten, Stromunterbrechungen zur Beleuchtung usw., nicht zutreffen. Im Allgemeinen können diese Daten jedoch Verkehrsmuster zeigen und eine erhöhte Ebene an Genauigkeit hinsichtlich Geschwindigkeitsvorhersagen bereitstellen.
Bei dieser veranschaulichenden Ausführungsform werden verschiedene Zeiten und verbundenen Verkehrsebenen für jede Straße hinsichtlich dieser Zeiten gespeichert. Die Verkehrsebenen können auf einer Abstufung (hoch, mittel, niedrig usw.) oder einer durchschnittlichen Geschwindigkeitsanpassung oder durchschnittlichen Verkehrsgeschwindigkeit auf der Straße zu diesem Zeitpunkt basieren. Diese Informationen können verwendet werden, um zu bestimmen, wie erwarteter Verkehr wahrscheinlich die Menge an Zeit beeinflussen wird, die benötigt wird, um auf einer bestimmten Route zu fahren.
Andere Daten
Zumindest ein Beispiel anderer Daten würde Straßensteigungsdaten beinhalten. Diese Daten können bei Fahrzeugen mit regenerativen Bremssystemen nützlich sein. Unter Verwendung dieser Daten könnte ein GPS-Routingsystem eine regenerative Route generieren, die Kraftstoff-(Benzin, Elektrizität usw.)-Verbrauch über den Verlauf der Route optimiert. Andererseits, wenn ein Benutzer ein Fahrzeug ohne regenerative Systeme hätte, wäre es für den Benutzer nicht sonderlich nützlich, diese Daten zu erhalten.
Zahlreiche andere Datentypen können ebenfalls mit Fahrrouten verbunden werden, und sie können normalerweise auf eine Art und Weise angewendet werden, um eine bestimmte Berechnung hinsichtlich einer bestimmten Route anzupassen oder zu verbessern.
Kachelversionen
Neben der Unzahl an Datentypen, die mit Kacheln verbunden sein können, kann es ebenfalls nützlich sein, Versionsnummern mit Kacheln zu verbinden. Da Nummern im Datensinn kompakt sind, kann dies einen leichten Weg bereitstellen, den Status einer bestimmten Kachel zu überprüfen, ohne jegliche komplexe Vergleiche ausführen zu müssen.
Kacheldatenversionen
In einem veranschaulichenden Beispiel sind die Vereinigten Staaten in Staaten, Bezirke, Städte, Lokalitäten usw. aufgeteilt, wobei jeder davon von einer Kachel oder Kachelgruppe dargestellt wird. Die einzelnen Kacheln, die die Lokalitäten ausmachen, werden durch logische oder geografische Koordinaten aufgeteilt, wenn es mehr als eine Kachel an einem Lokalität gibt. Selbstverständlich können die größeren Sätze und Teilsätze ebenfalls durch logische oder geografische Koordinaten beliebig definiert werden, anstatt diese durch regierungstechnisch erzeugte Abgrenzungen aufzuteilen.
Jede Kachel wird sodann weiter in eine Vielzahl von Datenteilsätzen aufgeteilt. Bei dieser Ausführungsform haben die unterschiedlichen Schichten der Kachel und die Kachel selbst eine Versionsnummer. Diese kann entweder eine einzelne Zahl, die die Versionen aller Schichten (durch Komplexität) darstellt, oder eine Reihe von Zahlen sein, die einzelne Versionen anzeigt.
Wenn beispielsweise eine Kachel fünf Schichten hätte, dann könnte jede Anzahl an komplexen Bitsätzen in einer Zeichenkette verwendet werden, um all die Schichten darzustellen (in einer grob vereinfachten Version wird eine Hexadezimalzahl mit 12 Elementen verwendet, wobei die ersten beiden Hexadezimalzahlen die Kachelversion darstellen, die nächsten beiden die geografische Version darstellen usw.). Jedes alternative Nummerierungssystem ist ebenfalls geeignet.
Unter Verwendung solcher Versionsnummerierung können Kacheln schnell überprüft werden, um zu sehen, welche Elemente davon mit den entsprechenden Versionen übereinstimmen, die auf einem entfernten Server gespeichert sind (die wahrscheinlich die aktuellste Version darstellen). Wenn nur ein Teil der Kacheldaten nicht „aktualisiert” wird, kann nur dieser Teil der Kacheldaten eine Aktualisierung benötigen.
Außerdem kann eine längere Route eine große Anzahl an Kacheln beinhalten, und es kann nicht machbar oder zumindest vernünftig sein, alle Informationen für alle Kacheln über eine Route herunterzuladen, wenn einige dieser Kacheln Hunderte von Meilen entlang der Straße liegen.
Dementsprechend können die Daten auf eine Art und Weise heruntergeladen werden, die die Komplexität von Informationen liefert, die für einen lokalisierten Satz der Kacheln entlang der Route benötigt werden, wobei mehr Grundinformationen für später auftretende Kacheln heruntergeladen werden. Sobald sich der Benutzer den Kacheln annähert, für die keine Aktualisierung oder eine begrenzte Aktualisierung heruntergeladen wurde, kann das System diejenigen Kacheln hinsichtlich Herunterladeinformationen überprüfen (oder hat bereits eine Überprüfung durchgeführt und eine Warteschlange gebildet).
Auf diese Art und Weise können gegebenenfalls Bandbreiteneinschränkungen beobachtet werden. Selbstverständlich ist es ebenfalls möglich, alle Informationen für eine Route bei Beginn der Route herunterzuladen.
Außerdem oder alternativ kann die Kachelversion selbst zuerst überprüft werden, und wenn sich diese nicht verändert hat, dann haben sich wahrscheinlich keine der Daten darin verändert, und Zeit kann bei dieser Art von System eingespart werden, vor den einzelnen Datenelementüberprüfungen.
Regionale Versionen
Neben der Nummerierung von einzelnen Kacheln kann es wünschenswert sein, Regionen, Bezirke, Städte, Staaten usw. zu nummerieren. Auf diese Art und Weise kann die entfernte Regionsversion mit lokal gespeicherten Daten verglichen werden, wenn ein Benutzer in einer Region fährt oder darin eintritt, um zu sehen, ob irgendwelche Kacheln innerhalb der Region aktualisiert worden sind. Dies kann erneut Zeit und Bandbreite in dem Vergleichsalgorithmus einsparen.
Eine umfassende Nummerierungslösung
Bei zumindest einer veranschaulichenden Ausführungsform wird eine umfassende Lösung für Kachelversionierung vorgesehen. Bei dieser Lösung wird eine große Region durch eine Versionsnummer dargestellt, die Darstellungsinformationen von Unterregionen darin umfasst.
Wenn beispielsweise ein Staat vierundsechzig Regionen enthielte, dann wäre eine Versionsnummer mit vierundsechzig separaten Elementen (möglicherweise in einer Zeichenkette oder anderer Form) die Versionsnummer für den Staat. Änderungen bei dieser Nummer würden sodann nicht nur eine Änderung bei einer Region des Staates anzeigen, sondern würden ebenfalls anzeigen (durch das veränderte Element), welche Regionen sich geändert haben. Dies würde die Notwendigkeit einer darauffolgenden rekursiven Suche verhindern, um zu sehen, ob gewünschte Regionen sich verändert haben.
Gleichermaßen würde eine Region eine Anzahl an separaten Elementen in Verbindung zu der Anzahl an Teilkacheln darin haben. Sobald eine Regionsänderung bestimmt worden ist, könnte die Regionsnummer schnell überprüft werden, um zu bestimmen, ob eine Lokalität sich verändert hat, basierend auf den verschobenen Elementen in der Regionsnummer.
Dieser Prozess könnte sich bis zur untersten Ebene, der einzelnen Kachel, fortsetzen. Die Kachel selbst könnte eine Nummer haben, basierend auf den separaten Datenelementen, die die Kachel umfassen.
Unter solch einem System, wenn ein Benutzer z. B. in einen Staat eintritt, könnte das GPS schnell die Staatsversionsnummer überprüfen. Unter Verwendung verschobener Elemente könnte das System bestimmen, welche Regionen sich in dem Staat verändert haben usw. bis zu den Daten in der Kachel.
Bei einer Version dieser Ausführungsform könnte jedes separate Element in der höheren Version vollständig aus dem ganzen Satz an Elementen der niedrigeren Version bestehen. Mit anderen Worten wäre ein Abruf einer Staatsversion eine Zusammensetzung der gesamten Regionsversionsnummern, die selbst eine Zusammensetzung der gesamten Lokalitätsversionsnummern sein würden, die eine Zusammensetzung aller Kachelversionsnummern darin sein würden, die eine Zusammensetzung der Datenversionen einer jeden Kachel sein würden.
Auf der hohen Ebene wäre dies eine ziemlich große Nummer oder Darstellung, aber dies würde sofort und akkurat Änderungen bis hin zu der einzelnen Kacheldatenebene wiedergeben. Eingeschränkte Variationen dieses Schemas könnten ebenfalls implementiert werden.
Ein Beispiel, das mehrere dieser Konzepte verkörpert, wird nachstehend für einen „Staat” gezeigt, der zwei „Regionen” und vier „Lokalitäten” enthält, wobei jede „Lokalität” zwei Kacheln darin hat.
STAAT –
Regionen: A, B
Lokalitäten: A, B, C, D
Kacheln: A, B, C, D, E, F, G, H, I
REGION A –
Lokalitäten: A, B
Kacheln: A, B, C, D
REGION B –
Lokalitäten: C, D
Kacheln: E, F, G, H
LOKALITÄT A –
Kacheln: A, B
LOKALITÄT B –
Kacheln: C, D
LOKALITÄT C –
Kacheln: E, F
LOKALITÄT D –
Kacheln: G, H
Jede Kachel hat ebenfalls drei Datenebenen, Ebene I, Ebene II und Ebene III.
Jedes Datenelement wird durch eine Hexadezimalzahl mit zwei Elementen dargestellt, wobei das folgende nummerierte Schema hergestellt wird:
Kachel A – 1A3D23 (Element I Version: 1A; Element II Version: 3D; Element 3 Version: 23)
Kachel B – FC2EFF
Kachel C – 334DE1
Kachel D – 122AA1
Kachel E – E1EF23
Kachel F – 111E3E
Kachel G – A11E23
Kachel H – 2D22ED
Jede Lokalität beinhaltet sodann die Daten, in der Reihenfolge der Kacheln darin:
Lokalität A – 1A3D23FC2EFF
Lokalität B – 334DE1122AA1
Lokalität C – E1EF23111E3E
Lokalität D – A11E232D22ED
Gleichermaßen beinhalten die Regionen die Lokalitätsdaten
Region A – 1A3D23FC2EFF334DE1122AA1
Region B – E1EF23111E3E A11E232D22ED
Und schließlich beinhaltet der Staat die Regionen:
Staat – 1A3D23FC2EFF334DE1122AA1E1EF23111E3E A11E232D22ED
In diesem System kann ein schneller Vergleich der Staatsversionen mit einer gespeicherten Version ein GPS-System darüber informieren, ob es überhaupt irgendwelche Änderungen gegeben hat. Da je zwei Hexadezimalelemente des Staates einem tatsächlichen Kacheldatenelement entsprechen, kann ebenfalls sofort erkannt werden, welche Elemente sich verändert haben. Selbstverständlich können die Werte in der Praxis viel größer werden, aber dies ist zumindest ein mögliches System. Es ist ebenfalls möglich dieses System in mehreren Schichten zu implementieren, sodass die Staatsebenendaten nicht die einzelnen Kachelelementversionsdaten benötigen, wenn z. B. diese Detailebene verursacht, dass die Staatsebenenversion zu groß wird.
Dieses Beispiel zeigt, dass eine systematische Unterteilung und Nummerierung für umfassenden Vergleich mit niedriger Bandbreite verwendet werden kann.
Kachelauswahl
Wenn das System ein Verfahren zum Auswählen bestimmter Teile von Daten zum Herunterladen hat, kann auf dieses Verfahren zugegriffen werden, um die Gesamtmenge an Bandbreitenverwendung zu senken, die erforderlich ist, um Daten für eine Route, die einem Benutzer dargestellt werden soll, herunterzuladen/zu aktualisieren.
Sobald der Benutzer einen Zielort eingegeben hat, und das System einen aktuellen Ort des Benutzers bestimmt hat, kann eine Berechnung durchgeführt werden, um zu bestimmen, welche Straßen für die Fahrt empfohlen werden. Selbstverständlich gibt es die Möglichkeit, dass ein Benutzer von der empfohlenen Route abweicht, deshalb kann eine Entfernungstoleranz von diesen Straßen ebenfalls wünschenswert sein (z. B. eine größere Region). Das Ausbalancieren der Toleranz und die resultierende Menge an benötigten Daten, mit den Bandbreiteneinschränkungen, kann erforderlich sein.
Nachdem (oder sowie) das System eine Route bestimmt hat, wird das System wahrscheinlich wissen, welche Straßendaten erforderlich sind. Diese Daten können Kacheln entsprechen, die bereits in einer lokalen Datenbank gespeichert sind, oder es kann das Herunterladen/Aktualisieren von Kacheln erforderlich sein. Kommunikation zwischen dem lokalen Navigationssystem und einem entfernten Speicher von aktualisierten Kacheln kann dabei helfen, zu bestimmen, ob Aktualisierung/Herunterladen notwendig ist.
Wenn die Kacheln unterteilt oder anderweitig markiert und/oder kategorisiert sind, wie z. B. in der hierin beschriebenen beispielhaften Lösung, oder auf eine andere Art und Weise, kann das System das entsprechende Markierungsschema verwenden, um zu bestimmen, ob lokal gespeicherte Kacheln aktualisiert werden müssen, welche Kacheln heruntergeladen werden müssen usw.
Wenn keine solche Lösung vorhanden ist, kann das System alternativ dynamisch eine Anfrage nach Daten aufbrechen, basierend auf logischen oder geografischen Grenzen. Bei einer weiteren veranschaulichenden Ausführungsform kann das System lokal eine Kachelungslösung implementieren und Anfragen basierend auf dieser Lösung anwenden. Oder ein intermediärer entfernter Server kann ein lokal verwendetes System implementieren, und der entfernte Server kann sodann die angemessenen Anfragen an einen Datenprovider zusammenstellen.
Befehle für Aktualisierungen können von beiden Enden der Verbindung kommen. Das heißt, ein Server kann bestimmen, dass eine Aktualisierung benötigt wird, und die Aktualisierung zu dem Fahrzeug-EDV-System schieben, oder das System kann bestimmen, dass Aktualisierungen benötigt werden, und die Aktualisierungen von einem entfernten Server heranziehen.
Dienstleistungsebene (Monetisierung von Kacheldaten)
Ein weiterer Faktor, den ein Navigationssystem (oder ein entfernter Server, der ein Navigationssystem bedient) bei der Bestimmung von Aktualisierungen in Betracht ziehen kann, ist eine bestimmte Dienstleistungsebene, zu der ein Benutzer berechtigt ist. Beispielsweise können Daten in separaten Mengen verkauft werden, in entweder Umlage- oder Vorausbezahlungsform.
Dementsprechend, wenn bestimmte Datenaktualisierung oder Datenherunterladen vorgesehen ist, kann das Navigationssystem (oder entfernte Server) ebenfalls die Dienstleistungsebene in Betracht ziehen, zu der ein Benutzer berechtigt ist. Dies kann dabei helfen, den Entscheidungsfindungsprozess zu rationalisieren, und ebenfalls Datenzugriff auf neue Monetisierungsebenen zu öffnen.
Das Kaufen von Aktualisierungen
Bei einem ersten veranschaulichenden Beispiel zur Monetisierung von Kacheldaten kauft ein Benutzer ein bestimmtes Aktualisierungspaket oder der Benutzer kann beispielsweise die Entscheidung treffen, Aktualisierungen bedarfsgerecht zu kaufen. Dazu kann eine weitere Charakterisierung zu den Kacheldaten hinzugefügt werden, die die Wichtigkeit von Aktualisierungen anzeigt. Beispielsweise können Änderungen bei der Steigung einer Straße keine wichtigen Daten sein, allerdings kann der Aufbruch einer Straße dies durchaus sein.
Wenn der Benutzer von unterwegs aus bezahlt, dann kann dem Benutzer die Option bereitgestellt werden, eine Aktualisierung, die Kosten einer Aktualisierung usw. zu erhalten. Oder der Benutzer kann beispielsweise immer (oder die Option auf immer) wichtige Aktualisierungen erhalten. Wichtigkeit von Aktualisierungen kann ebenfalls verwendet werden, um zu bestimmen, ob eine Aktualisierung dynamisch wünschenswert ist (im Gegensatz zum Off-Board-Aktualisieren der Daten oder zu einem Zeitpunkt, wenn sich das Fahrzeug im Stillstand befindet). Dies kann eine nützliche Bestimmung sein, wenn Bandbreite anderweitig verwendet wird.
Wenn der Benutzer innerhalb der Einschränkungen der gekauften Aktualisierungsoptionen ist, können Daten aktualisiert werden. Für einen Benutzer, der zwei Meilen zur Arbeit fährt und das Fahrzeug ansonsten fast nie benutzt, können keine Aktualisierungen benötigt werden. Für einen Benutzer, der jedoch ausgiebig fährt, kann ein uneingeschränktes Aktualisierungspaket wünschenswert sein.
Kaufen von regionalen/Lokalitäts-/Kacheldaten
Neben dem Kauf von Aktualisierungshäufigkeit/-ebene kann ein Benutzer Mengen an Daten für einen bestimmten Kachelsatz kaufen (Region, Lokalität, herkömmlich verwendete Kacheln usw.). Die Kosten können hierfür zum Beispiel dynamisch variiert sein, basierend auf der Fahrzeugverwendungshistorie. Wenn ein Benutzer historisch sechzig Kacheln für fünfundneunzig Prozent der Fahrt verwendet, kann ein Benutzer wünschen, konstante Aktualisierungen dieser Kacheln zu kaufen, aber kann nicht wollen, dafür zu bezahlen, dass eine Kachel aktualisiert wird, auf der der Benutzer nur zum zweiten Mal fährt.
Basierend auf sowohl dem Wissen eines Benutzers hinsichtlich der Gebiete, in denen der Benutzer herkömmlicherweise fahren wird, und Daten, die angesammelt sind, die herkömmliche Fahrtkacheln anzeigen, können Pakete auf die spezifische Benutzerebene zu geschnitten werden, wenn gewünscht. Optionen, so wie diese, können den Kauf neuer Daten ebenfalls fördern, da es der Fall sein kann, dass wenige Benutzer die Kosten einer Aktualisierung einer gesamten Reisekarte nicht anfallen lassen wollen, sondern nur für einen kleinen Teil dieser Karte.
Das Kaufen von Datenebenen
Gleichermaßen können Benutzer nur wünschen, bestimmte Datenebenen für Kacheln zu kaufen. Dynamische Verkehrsdaten können beispielsweise hinsichtlich Sammeln und Liefern sowohl im Sinne der Ressourcen als auch der Bandbreite kostspielig sein. Ein Benutzer könnte nur für diese Daten bezahlen wollen, wenn er in Eile ist oder während er pendelt usw. Dementsprechend könnte die Option an einen Benutzer bereitgestellt werden, diese Ebene (oder jede Ebene) der Daten zu aktivieren/deaktivieren.
Bei einer weiteren veranschaulichenden Ausführungsform kann der Benutzer immer Verkehrsdaten für Pendelfahrten, bei bestimmten hochdichten Verkehrszeiten, in bestimmten Gebieten usw. wünschen. Datenebenen und Zeiten und Regionen, in denen Daten gewünscht werden, können auf die Wünsche eines einzelnen Benutzers zugeschnitten werden. Pauschalpakete können selbstverständlich ebenfalls auf einer weniger zugeschnittenen Ebene verkauft werden.
Es kann der Fall sein, dass die Mehrheit der Benutzer Verkehrsdaten zwischen 8 Uhr und 10 Uhr morgens und 16 Uhr und 18 Uhr abends wünscht. Datenlieferbandbreite wird während dieser Stunden stark beansprucht, aus diesem Grund können somit höhere Kosten mit den Daten verbunden werden, die während dieser Zeiten geliefert werden, um die zusätzlichen Ressourcen auszugleichen, die benötigt werden, um die Informationen akkurat und schnell zu liefern.
Ähnliche Konzepte können bei allen Datenebenen innerhalb der Kacheln angewendet werden. Spezifische Verkehrsbeleuchtungs-/-schilderdaten können nur für bestimmte Regionen gewünscht werden. Benutzer können die Daten und Datenebenen für unterschiedliche beabsichtigte Verwendungszwecke kaufen. Da lokalisierte Systeme in der Lage sein können, Fahrtinformationen zu speichern, könnte ein Benutzer beispielsweise ein System anweisen, die Kosten für alle Datenebenen für „die derzeit befahrene Route” zu bestimmen. Dem Benutzer könnte sodann beispielsweise ein auf ihn zugeschnittenes Paket für eine herkömmliche Route gegeben werden, und er könnte bestimmten, ob der Paketpreis den Wert der Verwendung der Daten wert war. Der Benutzer könnte die Daten ebenfalls „sampeln”, wobei die gesampelten Daten beispielsweise entweder temporär oder auf einer Gesamtanzahl der Sampleverwendungen gespeichert werden können. Dies könnte bei einer Bestimmung helfen, ob die Daten nützlich genug waren, um die Kosten zu rechtfertigen.
Beinhaltete Daten
Bestimmte Ebenen von Fahrzeug oder Dienstleistung können ebenfalls automatisch bestimmte Datenpakete beinhalten. Beispielsweise können Luxusfahrzeuge umfassende Datenpläne beinhalten, zumindest auf einer temporären Basis, wobei Eintrittsebenenfahrzeuge nur Zugriff auf die am weitesten eingeschränkten Daten haben können, im regionalen oder Datenebenensinn beispielsweise. Diese Rasterung kann weiter eine „verbesserte” Erfahrung für den Käufer eines Luxusfahrzeugs erzeugen, während sie gleichzeitig die fundamentalen und notwendigen Daten an einen Benutzer der Eintrittsebene zum Erhalt von Richtungen bereitstellt, während die Kosten für diesen Benutzer niedrig gehalten werden.
Lokal gespeicherte Daten
Ein weiterer Faktor, den es bei der Entscheidung, ob eine Kachel heruntergeladen wird, zu berücksichtigen gilt, ist, ob die Kachel in einer lokalen Datenbank gespeichert ist. Basierend auf der Größe, Zugriffsrechten, Speicherrechten usw. einer lokalen Festplatte oder anderem Speichergerät kann ein Benutzer in der Lage sein, herkömmlich verwendete Daten zu speichern, sobald diese zum ersten Mal heruntergeladen worden sind. Ein Fahrzeug eines Benutzers kann sogar mit einem bestimmten Datensatz vorausgestückt werden, basierend auf der Region, in der das Fahrzeug verkauft worden ist, oder dem Zweck, für den das Fahrzeug beabsichtigt ist.
Es kann jedoch nicht möglich sein, alle Daten, die heruntergeladen worden sind, aufgrund von Platzbeschränkungen, Lizenzierungseinschränkungen usw. zu speichern. Dementsprechend existieren mehrere potenzielle Lösungen für das lokale Speichern von Daten.
Mappendaten können extrem detailliert sein, und daher potenziell eine große Menge an Speicher verbrauchen. Beispielsweise wird unter Bezugnahme auf 3 ein Modell des Staates Michigan 300 gesehen. Die GPS-Koordinaten in diesem Staat wurden in diesem Beispiel in eine Vielzahl von Teilregionen 301 aufgeteilt. Region 301 wird weiter in Regionen 303 unterteilt. Region 303 wird weiter in sogar noch kleinere Regionen 305 unterteilt (ein Beispiel hierfür kann die Kachel 200 sein, die in 2 gezeigt ist).
Wie aus diesem Beispiel ersichtlich können Hunderte oder sogar Tausende dieser Kacheln verwendet werden, um einen einzelnen Staat darzustellen. Die meisten, typischerweise fast alle, dieser Kacheln werden von einem durchschnittlichen Benutzer niemals verwendet. Sogar wenn der Benutzer von einer Seite des Staates zur anderen fahren würde, kann die Mehrheit dieser Route nur entlang einem kleinen Weg von Kacheln liegen. Da das Aktualisieren der Kacheln und/oder Speichern der Kacheln teuer sein kann, sowohl hinsichtlich der Bandbreite (und/oder Speicher) als auch monetär, kann es wünschenswert sein, ein System bereitzustellen, wobei der Benutzer typischerweise nur auf ein lokalisiertes System von Kacheln zugreift und mit diesen interagiert, oder nur mit Kacheln, die für eine gegebene Route benötigt werden.
Dynamische Speicherbestimmung
Ein veranschaulichendes Beispiel zum Bestimmen, welche Daten zu speichern sind, wäre eine dynamische Lösung. In diesem veranschaulichenden Beispiel werden alle legitimen (z. B. nicht lizenzunterbindende) Daten lokal gespeichert, bis ein Grenzwert erreicht ist. Der Grenzwert könnte eine vorbestimmte Menge an Daten sein, eine vorbestimmte Menge an Speicherverwendung als ein Prozentsatz, bis der Speicher voll ist, usw.
Sobald der Grenzwert erreicht ist, muss das System bestimmen, welche Daten „entsorgt” werden. Ein möglicher Weg zum Bestimmen ist es, eine Verwendungsmarke an bestimmten Datenkacheln anzubringen. Diese Markierung kann beinhalten, ohne darauf beschränkt zu sein, wie oft diese verwendet worden sind, wann diese zuletzt verwendet worden sind usw. Sodann kann ein Algorithmus implementiert werden, um zu bestimmen, ob eine bestimmte Kachel gespeichert werden soll oder nicht, oder ob diese zugunsten einer neuen Kachel entsorgt werden soll.
Beispielsweise kann eine Kachel ohne Einschränkung fünfzig Mal verwendet worden sein, kann aber ebenfalls mehrere Jahre lang nicht verwendet worden sein (was eine wahrscheinliche Übersiedlung des Fahrzeugs anzeigt). Basierend auf einer Bestimmung, dass die Kachel in einer bestimmten temporären Nähe nicht verwendet worden ist, kann die Kachel entsorgt werden.
In einem weiteren Beispiel könnte die Bestimmung einfach auf der Häufigkeit der Kachelverwendung basieren. In diesem Beispiel kann es wünschenswert sein, eine Speicherregion für „erstmalige” Kacheln zu reservieren, und diese Kacheln für eine minimale Zeitdauer zu behalten, um zu bestimmen, ob diese Kacheln tatsächlich häufig verwendet werden. Dies könnte dabei helfen, zu vermeiden, dass Kacheln, die auf einer neuen, aber in Zukunft häufig befahrenen Route liegen, voreilig entsorgt oder nicht gesichert werden.
Benutzerbestimmter Speicher
Bei noch einer weiteren veranschaulichenden Ausführungsform kann ein Benutzer bestimmen, welche Regionen oder Kacheln gespeichert werden sollen. Wenn er beispielsweise eine Route anfragt, könnte der Benutzer anzeigen, dass die Route eine herkömmliche ist, und somit das Speichern der Route auslösen. Oder der Benutzer könnte entfernt (z. B. auf einer Webseite) herkömmliche Fahrrouten oder -regionen anzeigen. Ein entfernter Server könnte sodann das lokale System anweisen, Kacheln in diesen Routen/Regionen zu speichern, oder diese Anweisung könnte physisch von dem Benutzer auf ein lokales Navigationssystem hochgeladen werden (über Drahtlosnetzwerk, Flash-Drive usw.).
Ein Ausgleich kann zwischen beiden Lösungen (oder jeder anderen vernünftigen Lösung) gefunden werden, sodass die Benutzererfahrung optimiert wird, das Herunterladen beschränkt wird usw. Wenn beispielsweise Speicher kostengünstig und Bandbreite „kostenintensiv” ist, kann es wünschenswert sein, eine große Anzahl an Kacheln zu speichern.
Andererseits, wenn Bandbreite relativ leicht verfügbar ist, dann kann es nur Sinn machen, Daten zu speichern, die sich für gewöhnlich nicht ändern, wie z. B. Straßengeografie und -steigung. Verkehrs- und andere Daten können einfach bedarfsgerecht erhalten werden.
Bei zumindest einer veranschaulichenden Ausführungsform „mietet” sich der Benutzer die Daten bedarfsgerecht. Das heißt, die Daten werden für eine beschränkte Zeitdauer zur Verfügung gestellt. Dies kann dazu beitragen, Datenkosten in einem Modell zu mildern, während ein kontinuierlicher Erlösstrom sichergestellt wird. Es kann der Fall sein, dass ein Benutzer bereit ist, für gemietete Daten X zu bezahlen, die nur einmal oder unregelmäßig benutzt werden, während der Benutzer Y (X < Y) für Daten bezahlt, die häufig verwendet werden und als Eigentum gewünscht werden. Jedes geeignete Kostenmodell kann verwendet werden, um den Speicher aufzustocken.
Außerdem können Daten, wie z. B. aus der Menschenmenge ermittelte Daten (wie z. B. ohne Einschränkung Verkehrsflussdaten oder alternative Routendaten), von einem Benutzer auf einer Fall-zu-Fall-Basis gekauft oder gemietet werden. Das heißt, dass für eine gegebene Route ein Benutzer in die Verwendung der Daten zu vorbestimmten Kosten „einwilligen” kann. Die Kosten können sogar dynamisch sein, wobei der Preis fällt (oder steigt), wenn mehr Benutzer sich für die Verwendung der Daten entscheiden.
Ein Beispielprozess zum Aktualisieren von Kacheln Bei dieser veranschaulichenden Ausführungsform, gezeigt in 4, empfängt ein Fahrzeug-EDV-System einen Eingabezielort von einem Benutzer 401. Basierend auf dieser Bestimmung wird eine Route (oder mehrere optionale Routen) unter Verwendung von z. B. herkömmlichen Verfahren zur Routenbestimmung bestimmt 403. Bei dieser Ausführungsform beinhaltet das Bestimmen der Route ebenfalls das Bestimmen einer Anzahl an Kacheln, durch die die Route verlaufen wird.
Sobald die Liste von Kacheln bestimmt worden ist, wird eine erste Kachel entlang der Route überprüft 405. Diese Überprüfung wird zumindest aus dem Grund der Bestimmung durchgeführt, ob eine Aktualisierung bei der Kachel notwendig ist (wobei angenommen wird, dass die Kachel lokal gespeichert ist). Wenn eine neue Version der Kachel benötigt wird 407, überprüft das System, um zu sehen, ob der Benutzer für die Aktualisierung berechtigt ist 409. Berechtigung wird unter Bezugnahme auf 5 beispielhaft erörtert. Im Allgemeinen ist die Berechtigung eine Bestimmung, die getroffen wird, basierend auf einer vordefinierten Dienstleistungsebene unter Bezugnahme auf ein gekauftes Paket, ein beinhaltetes Paket, eine geografische Region, in der die Kachel liegt, usw. Selbstverständlich könnte ein Benutzer ebenfalls, wenn gewünscht, einfach für alle Aktualisierungen berechtigt werden.
Wenn der Benutzer für eine Aktualisierung berechtigt ist und eine Aktualisierung benötigt wird 411, wird die Kachel z. B. von einem entfernten Kachelspeicher aktualisiert 415. Wenn die Kachel nicht aktualisiert werden muss, kann die Kachel markiert werden 413, z. B. als eine Kachel, die überprüft worden ist an diesem bestimmten Datum (dies kann z. B. verwendet werden, wenn die Aktualisierungsbestimmung auf einer Bestimmung hinsichtlich des Datums der letzten Aktualisierung basiert).
Wenn Kacheln zur Überprüfung übrig bleiben 417, kann der Prozess wiederholt werden, bis keine Kacheln mehr übrig sind. Sobald alle Kacheln aktualisiert worden sind und keine Kacheln zur Überprüfung übrig sind, wendet das System die Kacheldaten auf die bestimmte(n) Route(n) an, um die schnellste (oder anderweitig wünschenswerte) Route zu finden. Die Route, die diese gewünschten Kriterien erfüllt, wird sodann dem Benutzer vorgelegt 421.
Ein Beispielprozess zu Kachelberechtigung und -zugriff
5 zeigt einen beispielhaften veranschaulichenden Prozess zum Bestimmen, ob ein Benutzer für eine Aktualisierung an einer bestimmten Kachel berechtigt ist. Bei dieser Ausführungsform wurde einem Benutzer eine bestimmte Ebene an Aktualisierungsberechtigung bereitgestellt, basierend auf einem vorbestimmten Aktualisierungspaket. Dieses Paket könnte eine Dienstleistungsebene, eine vorbestimmte Anzahl an Aktualisierungen, ein regionales Paket usw. beinhalten, ist aber nicht darauf beschränkt.
Das Aktualisierungspaket des Benutzers wird zuerst von dem System überprüft 501. Wenn der Benutzer ein umfassendes (d. h. All-Inklusive-)Paket 503 hat, ist keine weitere Überprüfung notwendig, da alle Aktualisierungen beinhaltet sind, und ein „Ja” 519 wird an die Nachfrage der Berechtigung zurückgegeben.
Wenn der Benutzer kein umfassendes Paket hat, dann überprüft das System, um zu sehen, ob die bestimmte benötigte Aktualisierung abgedeckt ist 505. Beispielsweise kann die Aktualisierung zu einer neuen Straße gehören, und alle Benutzer können für Datenaktualisierungen einer neuen Straße berechtigt sein. Andererseits, wenn die Aktualisierung zu Echtzeit-Verkehrsdaten gehört, können nur bestimmte Benutzer, basierend auf der Paketebene, für eine Aktualisierung dieses Datentyps berechtigt sein.
Wenn der Benutzer nicht berechtigt ist, basierend auf einer Paketebene, kann das System weiter überprüfen, um zu sehen, ob eine Aktualisierung sicherheitsbezogen ist 507. Beispielsweise können Verkehrsdaten nicht für alle Benutzer verfügbar sein, aber wenn die Verkehrsdaten beispielsweise einen Gefahrenstoffunfall beinhalten, dann können alle Benutzer für diese Art Aktualisierung berechtigt sein, um alle Benutzer um dieses Gebiet herumzuleiten.
Wenn für die Aktualisierung kein Sicherheitsgrund besteht, kann der Benutzer bei dieser Ausführungsform die Option haben (freigeschaltet haben), die Aktualisierung zu kaufen 509. Wenn beispielsweise ein Fahrzeug erstmalig mit solch einem System aktiviert wird, dann kann das System dem Benutzer eine Kaufoption bereitstellen wollen. Wenn der Benutzer die Kaufoption nicht möchte, möchte der Benutzer jedoch wahrscheinlich nicht mit einer Frage zum Kaufen der Aktualisierungen belästigt werden, jedes Mal wenn eine benötigt wird. Also kann die Kaufoption unverkäuflich sein.
Oder die Option kann für bestimmte Arten von Informationen nicht verfügbar sein, wie z. B. Informationen, die von den Benutzern herkömmlicherweise nicht verwendet werden. Andererseits, wenn sich ein Benutzer typischerweise nicht um Verkehrsinformationen kümmert, allerdings in bestimmter Eile ist, kann es für den Benutzer angenehm sein, selektiv Verkehrsinformationen für diese Fahrt kaufen zu können.
Wenn die Kaufoption nicht verfügbar ist, überprüft das System schließlich, um zu sehen, ob die Aktualisierung wichtig ist 511. Dieser wichtige Status könnte beispielsweise von einem entfernten Provider bereitgestellt werden. Beispielsweise könnte eine Straße nicht mehr existieren, großflächige Bauarbeiten könnten eine Vielfalt von neuen Routen hinzugefügt haben, Verkehr könnte entlang der Route zu einem vollständigen Stillstand gekommen sein usw. Wenn die Aktualisierung wichtig ist und/oder wenn der Benutzer die Kaufoption hat, dann könnte der Benutzer über die Verfügbarkeit von Daten benachrichtigt werden.
Wenn der Benutzer wählt, die Daten zu kaufen, 515, dann wird eine positive Antwort auf die Berechtigungsfrage zurückgegeben, ansonsten wird eine negative Antwort zurückgegeben 517.
Eine zugeschnittene Benutzererfahrung
Neben dem Bereitstellen strategischer Datensammlung und Informationsspeicherung wird bei zumindest einer veranschaulichenden Ausführungsform das Herunterladen und Aktualisieren einer zugeschnittenen benutzerbasierten Datenbereitstellungserfahrung vorgesehen. Da Daten in einzelnen Fahrzeugen gesammelt und gespeichert werden können, und von einem Fahrzeug zu einem anderen geschoben werden können (zumindest in dem hierin beschriebenen Sinn), kann eine Benutzererfahrung auf die Bedürfnisse dieses bestimmten Benutzers verfeinert werden. Dies kann zum Beispiel beim Zusatzverkauf von Datenpaketen helfen, wenn der Benutzer einen wahren Sinn des Werts der Erfahrung erfährt, die durch den Kauf verfügbar ist.
Benutzer-„Flotten”-Erfahrung
Es ist für einen bestimmten Benutzer nicht ungewöhnlich, mehr als ein Fahrzeug zu besitzen. Entweder, weil der Benutzer ein „Sommer”- oder „Freizeit”-Fahrzeug hat, oder weil es innerhalb eines Haushalts mehrere Fahrer gibt, wobei eine Anzahl an Fahrzeugen in einer persönlichen „Flotte” eines Benutzers besessen werden können.
Abhängig von einer Dienstleistungsebene, oder möglich als eine automatische oder kaufbare Option, kann eine Kartenerfahrung von einem Benutzer von einem Fahrzeug zu anderen Fahrzeugen innerhalb der Flotte dieses Benutzers übertragen werden. Beispielsweise können bei einer Ausführungsform Daten hinsichtlich des aktuellen Kachelsatzes, der auf einem bestimmten Fahrzeug besteht, Off-Board, z. B. auf einem entfernten Server, gespeichert werden. Diese Daten können aktualisiert werden, basierend auf bekannten Herunterladungen und Aktualisierungen, und/oder basierend auf Änderungen (wie z. B. dem Entsorgen von Kacheln), die lokal stattfinden.
Wenn dieser Benutzer mit einem neuen Fahrzeug über eine Verbindung mit dem bekannten nomadischen Gerät dieses Benutzers geSYNCt wird, dann könnte eine von zumindest mehreren möglichen Optionen stattfinden. Wenn beispielsweise dieser Benutzer als Eigentümer oder regulärer Fahrer des neuen Fahrzeugs zugelassen ist, dann kann, entweder zu dem Zeitpunkt oder zu einem Zeitpunkt, wenn Bandbreite verfügbar ist, der entfernte Server die Bereitstellung aller Daten anweisen, die auf dem anderen Fahrzeug des Benutzers existieren, an das neue Fahrzeug bereitgestellt zu werden.
Bei einem anderen Beispiel kann zumindest ein beschränkter Teilsatz, wie z. B. die herkömmlichsten Routen, Routen, die am häufigsten befahren werden, zu dem Zeitpunkt, wenn der Benutzer in dem Fahrzeug präsent ist, bestimmte Datenebenen usw., an dieses Fahrzeug übertragen werden.
Bei noch einer weiteren Ausführungsform könnte die Datenebene, die für dieses bestimmte Fahrzeug verfügbar ist, dynamisch angepasst werden, basierend auf dem Benutzer. Wenn beispielsweise ein Elternteil Verkehrsdaten zu kaufen wünscht, aber nicht für die Daten für ein Kind bezahlen möchte, basierend auf dem vorhandenen nomadischen Gerät, würde der entfernte Server wissen, welcher Benutzer wahrscheinlich ein Fahrzeug fährt, und eine bestimmte Ebene von Dienstleistung/Daten an dieses Fahrzeug bereitstellen, basierend auf dem Preis, den dieser Benutzer für eine persönliche Anmeldung gezahlt hat. Alternativ könnten die Daten und Dienstleistungen selbstverständlich an ein Fahrzeug im Gegensatz zu einem Benutzer gebunden werden. Oder die Dienstleistungen könnten an einen Benutzer und eine Gruppe an Fahrzeugen gebunden werden, sodass die Dienstleistungen nur für den Benutzer verfügbar sind, wenn der Benutzer Fahrzeuge fährt, die diesem Benutzer gehören.
Zumindest ein Beispiel eines Prozesses zum Bestimmen von „Flottendienstleistungs”-Verfügbarkeit wird in 6 gezeigt. Bei diesem veranschaulichenden Beispiel fährt ein Benutzer in einem Fahrzeug, das dem Benutzer gehört (oder das auf diesen Benutzer zugelassen ist), das keine solch fortgeschrittene Ebene an Aktualisierungsdienstleistungen damit verbunden hat, als ein anderes Fahrzeug, das dem gleichen Benutzer gehört.
Bei diesem Beispielprozess schaltet sich das Fahrzeug-EDV-System mit dem Telefon oder anderem tragbaren Gerät des Benutzers 601 zusammen. Sobald auf die Benutzerinformationen durch dieses Zusammenschalten (in diesem beispielhaften Beispiel beinhalten die Benutzerinformationen zumindest eine Telefonnummer oder andere Zugriffsnummer, die mit dem tragbaren Gerät verbunden ist) zugegriffen werden kann, kontaktiert das Fahrzeug-EDV-System ein entferntes Netzwerk 603.
Die Benutzer-ID-Daten (Telefonnummer, Drahtlosgeräteadresse usw.) werden dem entfernten Netzwerk zusammen mit einer Fahrgestellnummer (vehicle identification number, VIN) oder anderer Fahrzeug-ID bereitgestellt 605. Basierend auf zumindest teilweise der Benutzerinformationen bestimmt das entfernte Netzwerk, ob ein Benutzerkonto existiert oder nicht 607. Wenn beispielsweise dem Benutzer ein primäres Fahrzeug mit einer fortgeschrittenen Dienstleistungsebene gehört, dann könnte das Netzwerk bestimmen, basierend auf bereitgestellten Informationen, dass solch ein Eigentumsrecht existiert. Wenn die fortgeschrittene Dienstleistungsebene zur Verwendung in allen Fahrzeugen, die dem Benutzer gehören (oder auf ihn zugelassen sind), verfügbar wäre, dann könnte das Netzwerk ebenfalls bestimmen, dass das derzeitige Fahrzeug für die Verwendung der Dienstleistung berechtigt ist 609.
Es kann der Fall sein, dass ein Benutzer die fortgeschrittenen Dienstleistungen nicht einfach in jedem Fahrzeug verwenden kann, in dem der Benutzer derzeit befindlich ist. Wenn aber das entfernte Netzwerk sich der Tatsache bewusst ist (basierend z. B. auf Benutzerkontoinformationen und/oder einem Zusammenschalten zwischen einem bestimmten Benutzer und einem bestimmten Fahrzeug), dass das Fahrzeug, mit dem das tragbare Gerät des Benutzers derzeit zusammengeschaltet ist, für die Dienstleistung berechtigt ist, dann kann der Benutzer diese Dienstleistung in diesem Fahrzeug verwenden. Dementsprechend wird, sobald solch eine Bestimmung getroffen wurde, dem Benutzer die fortgeschrittene Ebene von Dienstleistung bereitgestellt 611. Auf diese Art und Weise kann ein Dienstleistungskonto mit allen Fahrzeugen eines Benutzers zusammengeschaltet werden, anstatt auf ein bestimmtes Fahrzeug beschränkt zu sein, mit dem es ursprünglich verbunden war.
Ein veranschaulichendes Beispiel dieses Szenarios wäre das Folgende. Eine Familie besitzt drei Fahrzeuge, wobei jedes z. B. mit dem System SYNC von FORD ausgerüstet ist, und in der Lage ist, ein entferntes Netzwerk durch ein tragbares Gerät eines Benutzers (oder auf eine andere Art und Weise) zu kontaktieren. Es gibt drei Familienmitglieder, eine Mutter, einen Vater und ein Kind, wobei jedes ein tragbares Gerät besitzt. Alle drei tragbaren Geräte sind mit allen drei Fahrzeugen als „Eigentümer”- oder „zugelassene” Geräte verbunden. Das heißt, dass, obwohl das Kind nicht alle drei (oder möglicherweise keines) der Fahrzeuge besitzt, was das entfernte Netzwerk betrifft, weist das Gerät des Kindes es als einen ”Eigentümer” aus.
Wenn eines der drei verbundenen Geräte in einem der drei Fahrzeuge vorhanden ist, und mit SYNC zusammengeschaltet wird, dann hat das Fahrzeug in diesem Beispiel Zugriff auf die höchste Ebene von Kartendatendienstleistung, die für jedes der drei Fahrzeuge verfügbar ist. Dies ist erneut nur das Beispiel in diesem Szenario und soll als in keiner Weise einschränkend erachtet werden. Es könnte sein, dass nur ein Benutzer die Dienstleistung zwischen Fahrzeugen „tragen” kann, oder es könnte sein, dass nur zwei der drei Fahrzeuge Zugriff auf diese Ebene von Dienstleistung haben usw.
Bei einer veranschaulichenden Ausführungsform speichert ein tragbares drahtloses Gerät eines Benutzers eine Kopie von Aktualisierungen, die bei Kacheln gemacht worden sind, in einem Fahrzeug, in dem ein Benutzer fährt. Das tragbare Gerät „weiß” bei dieser Ausführungsform, dass es zumindest ein anderes Fahrzeug in der Flotte des Benutzers gibt, das diese Aktualisierungen empfangen hat oder nicht. Bei einem späteren Zusammenschalten mit einem Fahrzeug-EDV-System in dem/den anderen Fahrzeug(en) überträgt das System die aktualisierten Daten an das Fahrzeug-EDV-System, mit einem Bedarf (potenziell) für einen Abruf an ein entferntes Netzwerk. Sobald eine oder alle der „bekannten” Flottendatenbanken aktualisiert worden sind, kann das tragbare Gerät sodann die Aktualisierungsdaten von seinem residenten Speicher löschen.
Wenn während des Aktualisierungsprozesses das tragbare Gerät die gleiche oder eine neuere aktualisierte Version einer Kachel erkennt, kann die residente Version gelöscht werden oder sogar zu der neueren Version geändert werden (um sodann darauffolgend in dem ursprünglichen Fahrzeug aktualisiert zu werden). Auf diese Art und Weise kann das tragbare Gerät als ein drahtloser Aktualisierungsmechanismus zum Übertragen der neuesten verfügbaren Daten zwischen Flottenfahrzeugen dienen, ohne Bandbreite bei entfernten Netzwerkabrufen zu verwenden (es wird angenommen, dass der Plan des Benutzers keine solchen Abrufe benötigt, bevor Daten gemeinsam benutzt werden können).
Markenloyalitätserfahrung
Auf eine ähnliche wie vorstehend beschriebene Art und Weise können eine Dienstleistung und gesammelte Daten eines Benutzers an einen Kauf eines neuen Fahrzeugs übertragen und/oder beim Verkauf eines Fahrzeugs gelöscht werden. Wenn ein nomadisches Gerät bei einem neu gekauften Fahrzeug registriert wurde und Entfernung dieses Geräts von einem alten Fahrzeug gemacht wurde, können ähnliche Aktualisierungen/Löschungen hinsichtlich dieser Fahrzeuge stattfinden.
Diese Art Erfahrung kann einen Benutzer ermutigen, weiterhin Fahrzeuge von einem bestimmten Dienstleister zu kaufen, sodass der Benutzer in der Lage ist, klar und leicht eine Benutzererfahrung weiter zu erleben, wobei es nur geringe oder keine Unterbrechung oder Ausfallzeiten gibt, während neue Kartendaten gesammelt und angeordnet werden. Dies hilft dabei, dem neuen Fahrzeug ein zugeschnittenes und familiäres Gefühl zu verleihen.
Private Benutzerkarten
Da individuelle Fahrzeuge Zugriff auf ihre derzeitigen Orte zu jedem Zeitpunkt haben können, kann es ebenfalls möglich sein, zugeschnittene Karten für einen bestimmten Benutzer zu erzeugen. Existierende Kacheldaten können durch ein lokales System hinzugefügt werden, mit einem System oder einer Markierung, die sicherstellt, dass diese Daten nicht ohne Benutzererlaubnis überschrieben werden.
Beispielsweise fährt bei einer Ausführungsform der Benutzer geländegängig, wünscht aber eine Aufzeichnung der Fahrt, um den Weg leicht zurück zu einer Straße zu finden, von der aus losgefahren wurde. Der Benutzer kann eine „Zurückverfolgungsroute” oder ähnliches Merkmal auswählen, und der lokale Speicher kann eine Aufzeichnung der Fahrt des Benutzers „zusammenstellen”. Sodann kann, wenn der Benutzer zu der bekannten Straße zurückkehren will, das System entlang der gespeicherten Pseudo-Straße eine „Zurückverfolgung” durchführen. Diese Daten könnten sodann entsorgt werden, wenn sie nicht mehr gebraucht werden, möglicherweise auf Anfrage oder Option des Benutzers.
Bei einer weiteren veranschaulichenden Ausführungsform kann eine private oder öffentliche Straße bei aktualisierten Kartendaten nicht auftauchen, da der Kartendatenprovider diese bestimmten Informationen beispielsweise noch nicht erhalten hat. Daher kann, trotz der Fähigkeit des Systems, dynamisch aktualisierte Daten zu empfangen, das Nicht-Existieren der existierenden Straße in den Daten bestehen.
In diesem veranschaulichenden Beispiel kann der Benutzer das Zurückverfolgungsmerkmal oder andere Merkmal, wie z. B. „Straße speichern/erzeugen” auswählen. Das System kann sodann die Route des Benutzers auf der gespeicherten Kachel abbilden und diese Daten speichern. Da der Benutzer wiederholt über diese gleiche Route fährt, können zusätzliche Variationen bei GPS-Koordinaten gespeichert werden, um die Details der Route vollständig auszugeben (oder eine bestimmte Toleranz kann einfach nur angenommen werden).
Auf diese Art und Weise kann der Benutzer persönlich nützliche, zugeschnittene/zuschneidbare Karten zu seiner Verfügung stehend haben, sodass, in diesem und zukünftigen Fahrzeugen, existierende Straßen den Kartenkacheln hinzugefügt werden, die ansonsten diese Straßen nicht zeigen können. Diese Daten können in Regionen des Landes besonders nützlich sein, wo Aktualisierungen nicht häufig vorgenommen werden, oder wo der Benutzer ein großes Gelände mit selbstgebauten Straßen hat, die niemals auf irgendeiner Karte erscheinen werden.
In noch einem weiteren Beispiel von „privater Kartierung” können Daten für eine vorbestimmte Zeitdauer/Strecke/etc. gesammelt werden, wenn ein Benutzer eine bekannte Straße verlässt. Dies könnte nützlich sein, wenn ein Benutzer ein Fahrzeug hat, das in der Lage ist, „geländegängig” zu fahren und die Straße verlässt, wobei es weit genug fährt, sodass die Straße von dem Benutzer nicht länger gesehen werden kann. Unter Verwendung einer Brotkrumenspur gesammelter GPS-Punkte kann zumindest eine „künstliche Straße” zurück zu der Hauptstraße bekannt sein. Angenommen der Benutzer kann zumindest zu der Hauptstraße zurückkommen, indem er der Spur folgt, entlang derer der Benutzer die Straße verlassen hat, sodass zu jedem Punkt, wenn der Benutzer wendet oder die „künstliche Straße” durchtrennt, das GPS den Benutzer zurück zu der echten Straße leiten kann.
Ein Beispiel für Privatdatensammlung wird unter Bezugnahme auf 7 gezeigt. In diesem veranschaulichenden Beispiel erkennt das Fahrzeug-EDV-System (oder GPS-System), dass der Benutzer eine bekannte Straße verlässt 701. Grundsätzlich wurde das Fahrzeug des Benutzers als an einem Koordinatenpunkt seiend bestimmt, der keiner Straße entspricht, die dem System bekannt ist.
Wenn automatische Zurückverfolgung für diese Situation freigegeben wird 703, beginnt das System damit, Koordinatendaten aufzuzeichnen 707. Ein Algorithmus kann bereitgestellt werden, sodass die benötigte Menge an Daten zum „Abbilden” der Fahrtstrecke des Fahrzeugs gesammelt werden kann. Wenn automatische Zurückverfolgung nicht freigegeben ist, kann das Fahrzeug-EDV-System (oder GPS) den Benutzer fragen, ob Zurückverfolgung gewünscht wird 705. Wenn Zurückverfolgung gewünscht wird, dann werden die Daten zurückverfolgt und gespeichert, bis eine bekannte Straße erneut erreicht wird 709.
Es kann der Fall sein, dass die Daten über einen Punkt hinaus zur späteren Verwendung gespeichert werden, wenn z. B. eine bekannte Straße erneut erreicht wird. Bei dieser Ausführungsform ist jedoch zumindest die Zurückverfolgungsfunktion gesperrt, während der Benutzer auf einer bekannten Straße fährt.
Fortgeschrittenes Datensammeln und -aktualisieren
Bei noch einer weiteren veranschaulichenden Ausführungsform kann die Fähigkeit eines entfernten Servers/entfernter Server in Kommunikationen mit einem Netzwerk von Benutzerfahrzeugen, Daten zu sammeln, auf verbesserte einzelne Benutzererfahrungen angewendet werden. Ein enormer Zufluss von Daten kann verwendet werden, um neue Straßen zu entdecken, bevorzugte Routen zu entdecken, verkehrsbezogene Daten zu entdecken (wie z. B. Stoppschilder, Straßenbeleuchtungen usw.), und im Allgemeinen eine vorteilhaftere Erfahrung erzeugen.
Kollektive Datensammlung
Bei einer veranschaulichenden Ausführungsform kann ein bestimmtes Fahrzeug erkennen, dass ein Benutzer derzeit an einem GPS-Ort fährt, der außerhalb einer „bekannten” Straße ist (basierend auf den Kacheldaten, die in diesem Fahrzeug vorhanden sind). Neben den anderen Optionen für diese Entdeckung, die hierin bereitgestellt sind, kann das System dieses Ereignis markieren, und eine Koordinate oder eine Zeichenkette von Koordinaten zurück zu einem zentralen Ort berichten.
An dem zentralen Ort können diese Daten gegebenenfalls zur späteren Verarbeitung aufgezeichnet werden. Wenn entdeckt wird, dass eine sehr beschränkte Anzahl an oder nur ein bestimmtes Fahrzeug (basierend z. B. auf Berichterstattung) an einen Ort fährt, dann kann es sicher sein, anzunehmen, dass dies entweder eine private Straße, keine Straße, eine Auffahrt usw. ist.
Wenn jedoch eine Anzahl an unterschiedlichen Fahrzeugen ein Fahren entlang eines Koordinatenweges zeigt, dann kann das System dynamisch an diesem Ort eine Straße „erzeugen”. Alternativ oder zusätzlich kann das System einen Datenprovider über die wahrscheinliche Existenz einer neuen Straße benachrichtigen, und der Datenprovider kann sich bedarfsgerecht um eine Aktualisierung kümmern.
Verschiedene Grenzwertebenen können eingestellt werden, sowohl lokal auf der Fahrzeugebene als auch entfernt auf der Serverebene, um bei diesen Bestimmungen zu helfen. Beispielsweise kann das Fahrzeug den Fall nicht zu dem Server berichten, bis eine Anzahl an wiederholten Vorgängen stattgefunden hat. Gleichermaßen kann ein Server keine Handlungen anstrengen, bis ein erster Grenzwert erreicht ist. Sobald ein Grenzwert überschritten worden ist, kann der Server eine wahrscheinliche Straße erzeugen und/oder die Straße an einen Datenprovider berichten, entweder gleichzeitig oder bei einem anderen Grenzwert.
Durch Ausnutzen der Fähigkeit, die Orte von Fahrzeugen in Kommunikation mit einem Netzwerk zu „wissen”, kann sich das System daher dynamisch selbst verbessern, und allen Benutzern eine vorteilhaftere Erfahrung bereitstellen.
Ein veranschaulichendes Beispiel solch eines Sammelprozesses wird unter Bezugnahme auf 8 gezeigt. Bei dieser veranschaulichenden Ausführungsform erkennt ein Fahrzeug-EDV-System (oder GPS-freigegebenes System), dass eine „geländegängige” Situation stattgefunden hat 801. Diese Situation heißt beispielsweise, dass die Fahrzeugkoordinaten an einem Ort sind, der nicht mit einer bekannten Straße in Beziehung gesetzt werden kann.
Nachdem die geländegängige Situation entdeckt worden ist, überprüft das Fahrzeug-EDV-System, um zu sehen, ob Koordinaten existieren, die mit den entdeckten Koordinaten in Beziehung gesetzt werden können 803. Dies kann z. B. ein vormaliger Fall sein, wo dieses Fahrzeug bei diesen oder nahe dieser Koordinaten gefahren ist, und die vormals gespeichert worden sein könnten. Wenn beispielsweise ein Benutzer entlang einer unaufgezeichneten Straße fahren würde, sogar wenn das Fahrzeug nicht über genau die gleichen aufgezeichneten Koordinaten fährt, könnte das Fahrzeug über ähnliche Koordinaten innerhalb einer Toleranz der aufgezeichneten Koordinaten fahren, und daher könnten die vorhandenen Koordinaten mit den gespeicherten Koordinaten in Beziehung gesetzt werden.
Wenn die in Beziehung gesetzten Koordinaten vormals gespeichert worden sind, dann wird ein Zähler, der mit diesen Koordinaten verbunden ist, aktualisiert 807. Dieser Zähler kann aus mehreren unterschiedlichen Gründen verwendet werden. Die Gründe beinhalten, sind aber nicht beschränkt auf, das Bestimmen, ob die Koordinaten als eine „persönliche” Karte für den Benutzer gespeichert werden sollen, ob die Koordinaten an ein entferntes Netzwerk berichtet werden sollen usw.
Wenn beispielsweise der Benutzer wiederholt entlang der gleichen „unmarkierten” Route fährt, kann das Fahrzeug-EDV-System bestimmen, dass dies eine Straße ist, zumindest was diesen Benutzer betrifft. Wenn weiter ein Grenzwert (der einfach einmal sein kann) überschritten wurde, dann kann das Fahrzeug-EDV-System die Koordinaten an ein entferntes Netzwerk als eine Anzeige berichten, dass eine Straße existieren kann. Wenn ausreichend Daten von einer Vielzahl von Benutzern berichtet wurden, die anzeigen, dass die Straße existiert, dann kann das entfernte Netzwerk bestimmten, dass eine „Straße” vorhanden ist, um zweckdienlich die Straße an alle Benutzer zu berichten. Außerdem oder alternativ kann das entfernte Netzwerk die angenommene Existenz einer Straße an einen Kartendatenprovider berichten, sodass der Provider die Existenz/Nicht-Existenz einer Straße verifizieren kann.
Wenn derzeit keine in Beziehung zu setzende Koordinaten in dem Fahrzeug-EDV-System aufgezeichnet sind, kann das Fahrzeug-EDV-System die Koordinaten 805 speichern, und sodann einen Zähler hinsichtlich dieser Koordinaten aktualisieren.
Nachdem jegliche Zähler aktualisiert worden sind, überprüft das System, um zu sehen, ob zusätzliche „geländegängigen” Koordinaten vorhanden sind 809. Wenn keine neuen Koordinaten vorhanden sind, können jegliche Daten, die berichtet werden müssen, berichtet werden 811. Wenn weitere Koordinaten vorhanden sind, dann können diese Koordinaten gleichermaßen verarbeitet werden, bis keine weiteren Koordinaten mehr vorhanden sind.
Zusätzliche einschränkende und bestimmende Faktoren können verwendet werden. Wenn beispielsweise nur ein oder zwei Koordinatensätze, die eine sehr kurze Fahrstrecke darstellen, häufig für einen bestimmten Benutzer entdeckt werden, kann bestimmt werden, dass eine Auffahrt oder andere kurze, unbenötigte Straße das ist, was entdeckt wurde, und diese Daten können ignoriert werden oder nicht. Alternativ oder zusätzlich kann, wenn eine Vielfalt von Koordinaten über ein großes, aber beschränktes Gebiet entdeckt worden ist, bestimmt werden, dass ein Parkplatz oder ähnliches Merkmal an diesem Ort existiert, und das System kann ebenfalls diese Daten dementsprechend protokollieren oder ignorieren. Es kann nützlich sein, die Existenz und Dimensionen eines Parkplatzes aufzuzeichnen, da solche Daten oftmals herkömmlichen GPS-Systemen nicht zur Verfügung stehen. Einfahrten in und Ausfahrten aus dem Parkplatz können sogar auf diese Art und Weise entdeckt werden, da die Koordinaten, die variieren können, indem die Benutzer in den Parkplatz einfahren, alle ein paar gemeinsame Punkte gemeinsam benutzen können, wo der Benutzer einfährt und ausfährt.
Kollektive Routenbestimmung
Eine weitere Möglichkeit zum Verwenden der Überlegenheit von kollektivem Informationssammeln ist es, eine bevorzugte Route zu bestimmen. Dies kann auf einer Gruppen- oder Einzelpersonebene erfolgen. Es kann beispielsweise der Fall sein, dass eine Anzahl an unterschiedlichen Benutzern zwischen einem bestimmten Satz an Punkten entlang jeglichen Pfades fährt.
Obwohl die Richtungen zwischen diesen Punkten eine bestimmte Route vorschlagen können, kann es ein beobachtetes Phänomen sein, dass die Mehrheit, alle oder zumindest einige der Benutzer die angewiesene Route häufig vermeiden oder niemals verwenden. Dies kann eine Anomalie entlang dieser Route anzeigen, oder einfach, dass eine alternative Route eine zu bevorzugende ist.
Das Auftreten, wenn eine Route vermieden wird, kann gesammelt und in einem entfernten Server kategorisiert werden, auf eine Art und Weise, die ähnlich ist zu derjenigen, die hinsichtlich der Datensammlung aufgeführt ist. Unter Verwendung dieser Daten kann der Server in der Lage sein, eine „optimale” Route an einen Benutzer bereitzustellen, sogar wenn diese Route nicht die offensichtliche optimale Route ist, basierend auf den verfügbaren Kartendaten.
Zumindest ein Fall eines solchen System ist unter Bezugnahme auf 9 gezeigt. In diesem veranschaulichenden Beispiel bestimmt ein Fahrzeug-EDV-System (oder anderes System, das mit GPS- und/oder Routenbestimmungsleistungsfähigkeit ausgerüstet ist) eine zu fahrende Route 901.
Das Fahrzeug-EDV-System vergleicht sodann die geplante Route mit entweder entfernten oder gespeicherten Kartendaten 903. Wenn ein Teil der Route herkömmliche Abweichungen hat, die damit verbunden sind 905, wird der Benutzer benachrichtigt, dass Menschen dazu neigen, an einem bestimmten Gebiet vorbeizufahren (oder andere angemessene Benachrichtigung) 909.
Herkömmliche Abweichungen können auf einer Kartendatenkachelebene verbunden sein, oder im Allgemeinen mit einer Straße usw. verbunden sein. Wenn z. B. ein Teil einer Straße oder eine ganze Straße ein Feldweg ist, kann es sein, dass viele Menschen dort herumfahren. Konstante Vermeidung dieser Straße, trotz ihrer Erscheinung auf vielen Routenanweisungen, kann darin resultieren, dass diese Straße/Teil zur Vermeidung markiert wird. Andere Straßen oder Straßenteile können aus einer Vielfalt von Gründen vermieden werden (z. B. ohne Einschränkung schlechte Straßenbedingungen, Straßenbau, Straßenaufbruch usw.).
Wenn es keine herkömmlichen Abweichungen gibt, dann wird die Route dem Benutzer vorgelegt, wie vormals geplant 907. Wenn es Abweichungen gibt, die mit der Route verbunden sind, und der Benutzer wünscht, diesen Abweichungen zu folgen 911, dann wird eine alternative Route, einschließlich der Abweichungen 913, bestimmt. Es kann ebenfalls resultieren, dass das Folgen einer Abweichung andere Teile der Route ändert (z. B. setzt den Benutzer näher an eine andere Straße, die günstiger sein kann, unter Berücksichtigung der neuen Abweichung).
Außerdem oder alternativ können diese Daten gesammelt und auf einer lokalen Ebene gespeichert werden, wodurch ein „intelligentes” lokales Kartensystem erzeugt wird. Wenn das System beobachtet und aufzeichnet, dass ein Benutzer immer einen bestimmten Teil einer vorgeschlagenen Route vermeidet, könnte das System beginnen, die bevorzugte Version der Route zu der Vorgeschlagenen zu machen. Solch menschliche Abweichung könnte von fahrerbeobachteten Phänomenen resultieren, die nicht mit Kartendaten verfügbar sind. Oder der Benutzer kann beispielsweise nicht für Verkehrsdaten bezahlen, sondern kann stattdessen einfach wissen, wo Gebiete mit hohem Verkehrsaufkommen existieren, und diese vermeiden. In solch einem Fall würde das System „lernen”, den Benutzer einfach um diese Gebiete herumzuleiten, basierend auf vergangenem Verhalten, wodurch dem Benutzer die Kosten erspart bleiben, die möglicherweise teuren Echtzeitverkehrsdaten zu kaufen.
Ein Beispiel für dieses Datensammeln ist unter Bezugnahme auf 10 gezeigt. In diesem veranschaulichenden Beispiel erkennt das Fahrzeug-EDV-System, dass der Benutzer von der empfohlenen Route abgewichen ist 1001. Die Abweichung von dieser Route wird aufgezeichnet 1003. Solch eine Abweichung kann stattfinden, da ein Benutzer mit einer Route vertraut ist, die besser ist, aber für das GPS-Gerät nicht offensichtlich ist.
Das System überprüft ebenfalls, um zu sehen, ob es eine Beziehung mit einer vormals gespeicherten Abweichung gibt 1005. Beispielsweise kann diese Abweichung vormals aufgezeichnet worden sein, besonders, wenn die Route herkömmlicherweise von dem Benutzer genommen wird.
Wenn die Abweichung vormals aufgezeichnet worden ist, wird ein Zähler (der verwendbar ist, um zum Beispiel zu bestimmen, ob diese Route im Allgemeinen empfohlen werden soll) hinsichtlich der Abweichung aktualisiert. Bis die empfohlene Route wieder aufgenommen wird 1007, zeichnet das System die Abweichung auf. Der Punkt des Wiedereintritts wird ebenfalls aufgezeichnet 1011.
Wenn die Route erneut berechnet wird, dann kann es der Fall sein, dass nur ein paar Datenpunkte einen aufgezeichneten Status haben, der mit diesen verbunden ist, aber sogar dies reicht aus, wenn das System wünscht, die Abweichung als eine empfohlene zu erkennen.
Verkehrssteuermerkmalbestimmung
11 zeigt ein veranschaulichendes Beispiel zum automatischen Erkennen eines Verkehrssignals. Dieser Prozess kann verwendet werden, um eine Anzahl an unterschiedlichen Verkehrssignalen zu entdecken. Beispiele werden hinsichtlich Ampeln und Stoppschildern bereitgestellt, aber zahlreiche andere Verkehrssignale und dergleichen (wie Geschwindigkeitsbegrenzungen, aber nicht darauf beschränkt) können erkannt werden.
Bei dieser veranschaulichenden Ausführungsform erkennt das Fahrzeug-EDV-System eine unerwartete Fahrzeuggeschwindigkeitsänderung (andere Fahrzeugzustandsänderungen können ebenfalls erkannt werden) 1101. Wenn das Fahrzeug zum Beispiel auf einer Straße dritter Klasse unterwegs ist (bei welcher zu diesem Zweck angenommen wird, dass dort 35–45 mph herrschen), und das Fahrzeug plötzlich anhält oder wesentlich unter eine erwartete Geschwindigkeitsbegrenzung verlangsamt, wird die Änderung erkannt.
Das Fahrzeug-EDV-System beginnt damit, Koordinaten des Fahrzeugs während der Geschwindigkeitsänderung zu protokollieren 1103. Wenn das Fahrzeug anhält 1105, werden die Koordinaten des Fahrzeugs bei dem Stillstand aufgezeichnet 1105. Wenn erwartete Geschwindigkeiten wieder aufgenommen werden 1107, überprüft das System, um zu sehen, ob Berichtsbedingungen erfüllt sind 1111, ansonsten fährt es damit fort, die Fahrzeugkoordinaten aufzuzeichnen.
Wenn ordentliche Berichtsbedingungen erfüllt sind, kann das System die Koordinaten an ein entferntes Netzwerk berichten 1113. Auf diese Art und Weise können verschiedene Verkehrssignale erkannt werden.
Wenn beispielsweise alle oder ein sehr hoher Prozentsatz an Fahrzeugen innerhalb eines kleines Koordinatenbereichs aufhören, sich zu bewegen (oder so langsam werden, dass sie fast stehen), und sodann eine Geschwindigkeit wieder aufnehmen, kann angenommen werden, dass ein Stoppschild an diesem Ort vorhanden ist.
In einem weiteren veranschaulichenden Beispiel, wenn sich ein vernünftiger Prozentsatz an Fahrzeugen einem Koordinatengebietsstopp annähert, dann kann angenommen werden, dass eine Ampel vorhanden ist. Ampeln können ebenfalls durch Stillstand an einer Querstraße zu der Kreuzung erkannt werden.
Auf eine ähnliche Art und Weise können Straßengeschwindigkeitsänderungen aufgrund von z. B. Bauarbeiten, Stadtänderungen usw. durch Zurückverfolgen von Daten bestimmt werden. Unter Verwendung von Informationen von einer ausreichenden Anzahl an Fahrzeugen können viele Verkehrssignale und Straßenbedingungen auf effiziente und kostengünstige Art und Weise entdeckt werden. Diese Daten können verwendet werden, um weiter ein Fahrzeug intelligent umzuleiten.
Im Allgemeinen
Unter Verwendung aller Systeme und Verfahren, die hierin beschrieben sind, und der logischen Erweiterungen dieser Systeme und Verfahren kann eine effiziente, zuschneidbare, monetisierbare Strategie für Karten- und Kartendatenimplementierung in einem Navigationssystem erhalten werden. Benutzer können eine hoch zugeschnittene Ebene von Datenlieferung erfahren, und diese Daten können auf effiziente und selektive Art und Weise bereitgestellt werden. Selbstverständlich sind individuelle Aspekte dieser veranschaulichenden Ausführungsformen ebenfalls zur Implementierung als alleinstehende Ausführungsformen geeignet.

Claims

Computerimplementiertes Verfahren, umfassend: Bestimmen, dass eine Fahrzeugfahrcharakteristik einen erwarteten Parameter überschritten hat; Aufzeichnen von Fahrzeug-GPS-Koordinaten; Abbrechen der Aufzeichnung der Fahrzeug-GPS-Koordinaten, wenn die Fahrzeugfahrcharakteristik eine Abbruchtoleranz überschreitet; und Bestimmen und Speichern eines Verkehrssteuermerkmals, das zumindest mit einem Satz der GPS-Koordinaten verbunden ist, abhängig von einer vorbestimmten Anzahl an aufgezeichneten Fahrzeug-GPS-Koordinaten, die zumindest dem einen Satz an GPS-Koordinaten entsprechen.
Verfahren nach Anspruch 1, wobei die Fahrzeugfahrcharakteristik eine Fahrzeuggeschwindigkeit ist.
Verfahren nach Anspruch 2, wobei der erwartete Parameter eine erwartete Geschwindigkeitsbegrenzung oder -bereich ist.
Verfahren nach Anspruch 3, wobei, wenn die Fahrzeuggeschwindigkeit auf 0 mph verringert wird, der Punkt, wo die Fahrzeuggeschwindigkeit auf 0 mph verringert wird, aufgezeichnet wird.
Verfahren nach Anspruch 4, wobei, wenn eine Vielzahl von Punkten, wo die Fahrzeuggeschwindigkeit auf 0 mph verringert wird, aufgezeichnet wird, das Speichern des Verkehrssteuermerkmals mit dem Punkt verbunden wird, der am nächsten zu einem Punkt liegt, wo das Fahrzeug den erwarteten Parameter wieder aufnimmt.
Verfahren nach Anspruch 1, wobei der zumindest eine Satz der GPS-Koordinaten der Satz an GPS-Koordinaten ist, die am nächsten zu Koordinaten liegen, die eine Querstraße markieren, bevor die Querstraße in Fahrzeugfahrtrichtung gekreuzt wird.
Verfahren nach Anspruch 1, wobei die Abbruchtoleranz der erwartete Parameter ist.
Verfahren nach Anspruch 1, weiter umfassend: Bestimmen, dass ein Fahrzeug an einem GPS-Koordinatenpunkt, der ein Stoppschild damit verbunden hat, vorbeigefahren ist, ohne sich unter einen vorbestimmten Grenzwert zu verlangsamen; Aufzeichnen eines Falls, wo das Fahrzeug an der GPS-Koordinate vorbeifährt, die ein Stoppschild damit verbunden hat, ohne sich unter den vorbestimmten Grenzwert zu verlangsamen; Bestimmen, dass eine Anzahl an Fällen, wo ein oder mehr Fahrzeuge, die an der GPS-Koordinate vorbeifahren, die ein Stoppschild damit verbunden hat, eine vorbestimmte Zahl überschreitet; und Ändern des Verkehrsmerkmals, das mit dem GPS-Koordinatenpunkt verbunden ist, von einem Stoppschild zu einer Straßenbeleuchtung.