-
Die
Erfindung bezieht sich auf ein Verfahren zum Updaten von Kartendaten
mit den oberbegrifflichen Merkmalen des Patentanspruchs 1 bzw. auf
einen Server und einen Client zum Durchführen eines solchen Verfahrens.
-
Allgemein
bekannt ist ein Verfahren zum Updaten von Kartendaten, bei dem Kartendaten
einer bestimmten Aktualisierungs-Version
auf einem Server bereitgestellt werden. Durch einen Client, beispielsweise
einen Computer, können
von dem Server diese Kartendaten einer aktuellen Version abgerufen werden,
beispielsweise durch Herunterladen mittels einer entsprechenden
Software. Nach Installation der Kartendaten auf dem Client kann
dann der Benutzer des Client die entsprechenden Kartendaten zum
Anzeigen einer Karte oder eines gewünschten Kartenausschnitts auf
einer Anzeigeeinrichtung nutzen. Bekannt ist auch die Übertragung
von Kartendaten von einem Server mittels beispielsweise eines eigenständigen Datenträgers auf
eine Navigationseinrichtung zum Bestimmen von Fahrrouten eines Kraftfahrzeugs,
wobei die Navigationseinrichtung den Client ausbildet.
-
Nachteilhaft
an einem derartigen Verfahren zum Updaten von Kartendaten ist, dass
stets die gesamten Kartendaten durch den Client von dem Server abgerufen
und heruntergeladen werden müssen. Dies
ist zeitaufwändig
und im Falle einer großen
zu übertragenden
Datenmenge mit im Wesentlichen nur geringfügig geänderten Daten auch kostenintensiv, wenn
die Übertragungszeit
oder die Übertragungsmenge
an Daten Grundlage für
eine Vergebührung bildet.
-
Die
Aufgabe der Erfindung besteht darin, ein Verfahren zum Updaten von
Kartendaten bereitzustellen, welches einen geringeren Aufwand zur Übertragung
von Daten zwischen Client und Server ermöglicht.
-
Diese
Aufgabe wird durch ein Verfahren zum Updaten von Kartendaten mit
den Merkmalen von Patentanspruch 1 gelöst.
-
Vorteilhaft
ist ein Verfahren zum Updaten von Kartendaten, bei dem Kartendaten
einer aktuellen Version auf einem Server bereitgestellt werden und durch
einen Client von dem Server Kartendaten der aktuellen Version abgerufen
werden, wobei die Kartendaten aus einer Vielzahl von Kacheln mit
jeweils Ausschnitten eines Gesamtgebietes der Kartendaten zusammensetzbar
sind, jeder Kachel eine Versionsinformation bezüglich deren Aktualisierungsstand
zugeordnet ist und beim Abrufen durch den Client nur eine Kachel
zum Client übertragen
wird, deren Versionsinformation auf dem Client eine älteren Aktualisierung
als eine Versionsinformation dieser abgerufenen Kachel auf dem Server
beinhaltet.
-
In
Verbindung mit einem solchen Verfahren ist vorteilhaft ein Server
mit Kacheln aus Kartendaten und mit einer Verarbeitungseinrichtung
und einer Schnittstelle zum Aktualisieren der Kartendaten und zum Übertagen
ausgewählter
Kacheln nach einem derartigen Verfahren. Außerdem vorteilhaft ist entsprechend
ein Client, insbesondere Computer, PDA (Personal Digital Assistant/persönlicher
digitaler Assistent), Smartphone oder eine Navigationseinrichtung,
mit Kacheln aus Kartendaten und mit einer Verarbeitungseinrichtung
und einer Schnittstelle zum Abrufen von aktuellen bzw. aktualisierten
Kacheln von einem Server gemäß einem
solchen Verfahren.
-
Vorteilhafte
Ausgestaltungen sind Gegenstand abhängiger Ansprüche.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem eine Aktualisierung der
Kachel auf dem Server nur individuell für zu diesem Zeitpunkt zu aktualisierende
Kacheln durchgeführt
wird.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem eine Aktualisierung von
solchen Kacheln auf dem Server nur im Fall einer Mindestanzahl zu
aktualisierender Kacheln durchgeführt wird.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem auf dem Server die aktualisierteste
Kachel mit einer entsprechenden Versionsinformation und zusätzlich entsprechende
Kacheln gleichen Gebiets mit älteren
Versionsinformationen gespeichert sind. Die älteren Versionen werden verwendet,
wenn Delta-Information
zu älternen
Kacheln erzeugt und übertragen
werden soll.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem beim Abrufen vom Client
für gegebenenfalls zu übertragende
solcher Kacheln deren Versionsinformation auf dem Client an den
Server übertragen wird,
wobei der Server die vom Client empfangene Versionsinformation mit
der oder den Versionsinformationen gegebenenfalls zu übertragender
Kacheln vergleicht.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem vom Client einzelne solcher
Kacheln oder zusammenhängende,
insbesondere rechteckförmig zusammenhängende Blöcke aus
solchen Kacheln abgerufen und/oder vom Server einzeln bzw. als zusammenhängende Blöcke aus
Kacheln übertragen werden.
Bevorzugt wird insbesondere ein Verfahren, bei dem die zusammenhängenden
Blöcke
durch Angabe nur einer Kachelnummer jeweils einer ersten und einer
letzten Kachel des Blocks bezeichnet werden.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem nach dem Abrufen aktualisierter
Kacheln im Client allen abgerufenen Kacheln unabhängig von
einer tatsächlichen Übertragung
aktualisierter Kacheln die aktuellste Versionsinformation zugewiesen
wird.
-
Bevorzugt
wird insbesondere ein Verfahren, wobei die Versionsinformation einer
zu einem offenen Gebiet am Rand eines aktualisierten Bereichs gehörenden Kachel
nur bei tatsächlicher
Ak tualisierung der jeweiligen Kachel als aktuellste Versionsinformation
zugewiesen wird. Dies ist vorteilhaft, wenn diese Kacheln Teil eines
nicht aktualisierten Gebiets sind, das über den Updatebereich hinausragt.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem im Fall eines kachelübergreifenden
Objektes einer Kachel bezüglich
zumindest einer benachbarten Kachel eine Abhängigkeitsinformation unter
Angabe der für
beide Kacheln bezüglich
des Objektes relevanten Versionsinformation zugeordnet wird. Für den Fall
eines randübergreifenden
Updatengebiets werden ggfs. Sonderbehandlungen notwendig vorgenommen.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem aufgrund einer Auswahl
durch den Client nur Kacheln für
einen zusammenhängenden
geschlossenen Bereich aus Kacheln übertragen werden mit einer Übertragung
aller Kacheln, die auf dem Server aktueller sind als auf dem Client.
Bevorzugt wird insbesondere ein Verfahren, bei dem Kacheln eines nicht
geschlossenen aktualisierbaren Gebiets nicht auf die aktuelle Versionsnummer
aktualisiert werden.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem aufgrund einer Auswahl
durch den Client zumindest eine Kachel eines nicht geschlossenen
Bereichs aus Kacheln übertragen
wird, wobei die Kachel zu einer nicht zu übertragenden benachbarten Kachel
durch ein übergreifendes
Objekt abhängig
ist. Bevorzugt wird insbesondere ein Verfahren, bei dem die nicht übertragene
benachbarte Kachel als solche im Client gekennzeichnet wird.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem aufgrund einer Auswahl
durch den Client zumindest eine Kachel eines ergänzenden und/oder nicht geschlossenen
Bereiches aus Kacheln übertragen
wird, so dass ein geschlossener Bereich entsteht.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem der Client vom Server Kacheln
anfordert und die zu übertragenden
Daten und/oder Kacheln auf eine bestimmt maximale Menge beschränkt sind,
wobei der Server Kacheln entsprechend der maximalen Menge nach deren
Aktualisierungsrelevanz und/oder nach deren Übertragbarkeit als zusammenhängende Blöcke aus
Kacheln zusammenstellt und überträgt.
-
Bevorzugt
wird insbesondere ein Verfahren, bei dem der Server abhängig vom
geringeren Übertragungsaufwand,
insbesondere einer geringeren zu übertragenden Datenmenge, wahlweise
ganze Kacheln oder Differenzdaten zwischen einer Kachel auf dem
Client und einer aktuellern gleichen Kachel auf dem Server überträgt.
-
Ein
Ausführungsbeispiel
wird nachfolgend anhand der Zeichnung näher erläutert. Es zeigen:
-
1 einen
Server mit Kartendaten, welche in Form einer Vielzahl von Kacheln
aus Abschnitten der Kartendaten bereitgestellt werden, und einen
Client, welcher gezielt einzelne Kacheln zum Update abruft,
-
2 beispielhafte
Kacheldaten verschiedener Aktualisierungsversionen auf dem Server
sowie auf dem Client und eine Aktualisierungsprozedur und
-
3 zwei
zueinander benachbarte Kacheln mit kachelübergreifenden Objekten in verschiedenen Aktualisierungsversionen.
-
Wie
dies aus 1 ersichtlich ist, werden in einem
Speicher MS eines Servers S Kartendaten bereitgestellt. Die Kartendaten
sind dabei unterteilt in eine Vielzahl zueinander benachbarter Kacheln
Kij, aus welchen durch insbesondere Nebeneinandersetzen ein beliebiger
Kartenausschnitt oder die gesamte Karte zusammensetzbar ist. Neben
den aktuellsten Kartendaten bzw. Kacheln Kij einer aktuellsten Kartenversion
werden außerdem
Kartendaten bzw. Kacheln Kij älterer
Aktualisierungsversionen ge speichert. Entsprechend sind in dem Speicher
MS den jeweiligen Kacheln Kij der verschiedenen Versionen entsprechende
Versionsnummern bzw. Versionsinformationen Vx = V1, V2, V3 zugeordnet.
Je nach Ausgestaltung kann jeweils pro Aktualisierungsversion ein
vollständiger
Satz aus Kacheln Kij bereitgestellt werden oder es können jeweils
nur Kacheln Kij in einer aktuelleren Kachelversion bereitgestellt
werden, welche gegenüber
einer bezüglich
dieser Kacheln Kij aktualisiert wurden.
-
Zur
Aktualisierung und Verwaltung der Kacheln Kij im Speicher MS des
Servers S weist der Server eine zentrale Steuereinrichtung CS und
eine beispielsweise über
eine Schnittstelle TI angeschlossene Eingabeeinheit TS auf. Eine
Speicherung von Daten bzw. Kacheln Kij auf dem Server S erfolgt
vorzugsweise für
ein übergeordnetes
Servergebiet. Die Kacheln Kij werden mit einer zugeordneten Versionsinformation
Vx gespeichert, wobei durch die Versionsinformation Vx erkennbar
ist, zu welchem Zeitpunkt bzw. mit welchem Aktualisierungslauf die
Kacheln Kij erzeugt wurden. Auf dem Server S werden mehrere Kacheln
Kij an gleicher Stelle bzw. für
einen gleichen geographischen Bereich mit unterschiedlichen Versionsnummern
bzw. Versionsinformationen Vx bereitgestellt. Optional für eine Gebietsoptimierung
erfolgt zu jeder Kachel Kij, eine Angabe, zu welcher benachbarten
Kachel und zu welcher ältesten Version
der benachbarten Kachel in jeder der Kachelrichtungen, d. h. insbesondere
8 Richtungen, eine Abhängigkeit
besteht.
-
Der
Server S weist außerdem
eine Schnittstelle IS zum Aufbauen einer Aktualisierungsverbindung
zu externen Einrichtungen auf, welche allgemein als Client C bezeichnet
werden. Ein Client C ist beispielsweise ein über eine Internetverbindung
angeschlossener Computer oder eine PDA oder eine Navigationseinrichtung
in einem Fahrzeug, welche über
eine Funkverbindung beispielsweise eines Mobilfunknetzes mit dem
Server S kommunizieren.
-
Der
Client C umfasst ebenfalls einen Speicher MC zum Speichern von Kartendaten
in Form einzelner Kacheln Kbc, Kbd, Kcc, Kcd als Kacheln Kij mit
beispielsweise einer Aktualisierungsversion mit der zweiten Versionsinformation
V2. Zum Verwalten, Verarbeiten und Aktualisieren der Kartendaten
weist der Client C in üblicher
Art und Weise eine Steuereinrichtung CC, eine Benutzer-Ein-/Ausgabeeinrichtung TC
sowie eine Extern-Schnittstelle
IC auf, wobei die Extern-Schnittstelle IC zum Aufbau der Verbindung mit
der Schnittstelle IS des Servers S dient.
-
Auf
dem Client C werden Kacheln Kij für ein Gebiet als Clientgebiet
gespeichert, welches dem Gesamtumfang der Kacheln auf dem Server
S umfassen kann, zumeist aber nur einem Ausschnitt des Servergebiets
entsprechen wird. Im Rahmen eines Updates werden auf dem Client
C für das
gesamte Clientgebiet oder einen ausgewählten gewünschten Ausschnitt des Clientgebiets
die betroffenen Kacheln Kij auf den aktuellsten Stand der auf dem
Server S gespeicherten Kacheln Kij gebracht. Entsprechend wird den
aktualisierten Kacheln auf dem Client C im Rahmen eine Updates,
insbesondere in einem abschließenden
Schritt S4 die Versionsnummer der höchsten Versionsinformation
V3 zugewiesen. Die Zuweisung erfolgt dabei zweckmäßigerweise
auch für
einzelne Kacheln Kbc, Kcc, welche aufgrund eines noch aktuellen
Versionsstandes V1, V2 vom Server S zum Client C nicht zu übertragen
waren. D. h., nicht nur Kacheln Kbd, Kcd, welche auf dem Server 5
mit einer aktuelleren Versionsinformation V3 verfügbar sind
und entsprechend bei einem Übertragungsschritt
S3 vom Server S zum Client C übertragen
werden, erhalten im Client C die aktuellste Versionsinformation
V3 zugeordnet, sondern alle der Kacheln Kij in dem Gebiet, für welches
der Client C in einem einleitenden Schritt S1 beim Server S eine
Aktualisierung angefordert hat, erhalten die aktuellste Versionsinformation
V3 zugeordnet.
-
Verfahrensgemäß wird von
dem Client C nach einem Verbindungsaufbau in einem ersten Schritt
S1 das Gebiet aus Kacheln Kbc – Kcd
sowie deren aktuelle Versionsinformation V2 auf dem Client C an
den Server S übertragen.
Der Server S bzw. dessen zentrale Steuereinrichtung CS vergleicht
in einem nachfolgenden Schritt S2 die vom Client angegebene Vielzahl
angeforderter Kacheln Kij mit deren Versionsinformation V2 mit den
entsprechenden Aktualisierungsständen
der Kacheln Kij in dem Speicher MS des Servers S. Bei dem dargestellten
Ausführungsbeispiel
wurden in einem ersten serverseitigen Aktualisierungsschritt nur
einzelne Kacheln Kbb, Kbc, Kcb, Kcc aktualisiert, wobei diesen die
nächsthöhere Versionsinformation
V2 zugeordnet ist. Der Client C hat somit Kartendaten bzw. Kacheln,
welche dieser Aktualisierungsstufe des Servers entsprechen. Der
Server S weist außerdem
von einer noch aktuelleren Aktualisierung Kacheln Kbd, Kbe, Kcd, Kce
auf, welchen die nächste,
dritte Versionsinformation V3 zugeordnet ist. Entsprechend erkennt
der Server S aufgrund der Anforderung des Clients C, dass nur die
Daten der Kacheln Kbd, Kcd des Clients C nicht auf dem aktuellsten
Stand sind und stellt entsprechend zur Übertragung an den Client C
nur diese Kacheln Kbd, Kcd bereit. In dem nachfolgenden dritten
Schritt S3 werden dann diese zu aktualisierenden Kacheln Kbd, Kcd
sowie die aktuellste Versionsinformation V3 an den Client C übertragen,
welcher entsprechend nur diese Kachel in seinem Speicher MC auszutauschen
hat. Anstelle einer Übertragung
der Kacheln des gesamten zu aktualisierenden Datenbestandes werden
somit nur die tatsächlich
zu aktualisierenden Daten übertragen,
wodurch die Übertragungsdauer
und die zu übertragende
Datenmenge in solchen Fällen
reduzierbar ist.
-
Optional
kann in einem noch weiter vorgeschalteten Verfahrensschritt SO von
dem Client C nur dessen momentane Versionsinformation V2 an den Server
S übertragen
werden, woraufhin der Server S seinen aktuellsten Stand der Versionsinformation
V3 an den Client C überträgt. Dieser
könnte
für den
Fall identischer Versionsinformationen V2 dann erkennen, dass auf
dem Server S keine aktuelleren Kacheln bereitstehen können, so
dass ein Update noch nicht erforderlich ist. Dies ist ein optionaler
Schritt, der auch weggelassen werden kann.
-
Anstelle
der Übertragung
vollständiger
Kacheln Kij vom Server S an den Client C können von dem Server S an den
Client C auch nur ausgewählte Daten
oder Updateinformationen übertragen
werden, wenn beispielsweise nicht der gesamte Datenbestand einer
Kachel zu aktualisieren ist sondern nur eine geringe Datenmenge
aus der Kachel. In einem solchen Fall ist die Übertragung von nur Differenz- bzw.
Delta-Daten oder Delta-Operationen mit Austauschanweisungen anstelle
der Übertragung
von ganzen Kacheln Kij günstiger.
Beispielsweise kann als Delta-Operation die Anweisung übertragen
werden, Bit 17 in der angefragten Kij durch „0" zu ersetzen.
-
Bei
einer derartigen gekachelten Verwaltung von Kartendaten kann der
Mechanismus der Kartenaktualisierung somit hinsichtlich einer Minimierung des
Aufwand zur Übertragung
von Daten zwischen Client C und Server S bzw. zwischen Server und
Client C vorteilhaft ausgestaltet werden. Voraussetzung ist einerseits,
dass die Kartendaten auf dem Server S immer wieder aktualisiert
werden, sowie andererseits ein Client C, auf dem Kartendaten liegen,
welche nur von Zeit zu Zeit zu aktualisieren sind. Insbesondere muss
bei einem solchen Verfahren auf dem Server S nicht für jeden
denkbaren Client C dessen aktueller Stand mitverwaltet werden. Das
aufwändige
Speichern von Client-Kartenständen
auf dem Server S ist somit nicht erforderlich.
-
Ermöglicht wird
vorteilhafterweise ein selektives und räumlich begrenztes Update ohne
dabei Konsistenzbedingungen zu verletzen. Eine generelle Aktualisierung
aller Client-Kacheln auf die letzte aktuelle Serverversion ermöglicht eine
sehr effiziente Handhabung des Updates, ohne dass serverseitig Informationen über den
Client-Zustand zwischengespeichert werden müssen. Ergänzende Gebietsabgrenzungen
einerseits und eine rechteckbezogene Übertragung der aktuellen Client-Versionen
andererseits minimieren zusätzlich
den Übertragungsaufwand.
-
Die
Version bzw. Versionsinformation Vx der verschiedenen Aktualisierungen
kann beispielsweise als laufende Nummer geführt werden. Bei jedem Updatelauf
auf dem Server S wird einen neue Versionsnummer als Versionsinformation
Vx durch beispielsweise Hochzählen
der bisherigen Versionsinformation Vx erzeugt. Im Rahmen von Aktualisierungen
werden auf dem Server S für
zu aktualisierende Kacheln zusätzliche
neue entsprechende Kacheln Kij mit den aktuellen Daten und der entsprechend
neuesten Versionsinformation Vx gespeichert. Vorteilhafterweise werden
in dem Server S viele Kacheln Kij gleichzeitig aktualisiert, so
dass nicht für
jede einzelne zu ändernde
Kachel Kij eine neue Versionsinformation Vx erzeugt werden muss.
Als Kriterium kann z. B. eine Mindestanzahl zu aktualisierender
Kacheln Kij innerhalb eines bestimmtes Gebietes der serverseitigen Kacheldaten
angesetzt werden.
-
Im
Rahmen der Anforderung eines Updates wählt der Client C einen Updatebereich
aus, beispielsweise ein bestimmtes Gebiet aus Kacheln aus dem gesamten
Clientgebiet. Insbesondere im Fall einer Vergebührung von aktualisierten Kacheln
kann es für
den Benutzer des Clients von Interesse sein, nur Kacheln aus einem
tatsächlich
regelmäßig und aktuell
benötigten
Gebiet der Gesamtkartendaten aktualisieren zu lassen. Auch kann
der Benutzer beispielsweise nur Gebiete des Clientgebiets aktualisieren
lassen, bei denen bereits mehrere Aktualisierungen im Datenbestand
des Servers S durchgeführt wurden.
-
Der
Client C überträgt die Versionsinformation
Vx für
alle Kacheln Kbc, Kbd, Kcc, Kcd im gewünschten Updatebereicht bc,
bd, cc, cd an den Server S. Vorteilhafterweise werden diese Zustände möglichst
komprimiert übertragen.
Insbesondere wird versucht, eine minimale Anzahl von Rechtecken zu
finden, welche eine gleiche Versionsinformation V2 haben. Für solche
Rechtecke müssen
dann nur zwei diagonal gegenüberliegende
Eckkoordinaten bc, cd, sowie der Updatestand bzw. deren Versionsinformation
V2 an den Server S übertragen
werden. Vorzugsweise werden Kartendaten für einen ganzen Bereich gleichzeitig
aktu alisiert. Nach der Aktualisierung haben alle Kacheln Kbc – Kcd in
dem gewünschten
Bereich normalerweise die gleiche Version. Deshalb ist es sehr Platz
sparend bzw. Datenmengen sparend, wenn die Version für das ganze Rechteck übertragen
wird. Anstelle einer Vielzahl von Kacheldaten mit zugeordneten Versionsinformationen
werden somit nur zwei Eckpunkt-Kacheldaten sowie deren einheitliche
Versionsinformation Vx übertragen.
-
Im
Rahmen der Planung des Updates vergleicht der Servers S seine verschiedenen
Versionen in seinem Speicher MS anhand deren Versionsinformationen
V1 – V3
mit der mitgeteilten Versionsinformation V2 des Client C. Dabei
wird jede betroffene Kachel Kij verglichen. Unterschiede werden
identifiziert. Im Client C zu aktualisieren bzw. entsprechend durch
den Server S bereitzustellen und zu übertragen sind alle Kacheln
Kbd, Kcd, deren Serverversion höher
als die der Clientversion ist.
-
Vorteilhafterweise
identifiziert der Server Gebiete aus zusammenhängenden Kacheln Kij, die als Updategebiete
zu aktualisieren sind. Zusammenhängend
sind dabei Kachel Kij auf dem Server, wenn diese aneinander grenzen
und deren Versionsinformation Vx neuer als die Versionsinformation
V2 der entsprechenden Client-Kacheln ist. Es ist dabei vorteilhaft,
wenn es möglichst
viele solcher Gebiete gibt, da dann der Umfang der Übertragungs-
bzw. Updateschritte kleiner ist, wenn für jedes der Gebiete ein eigener
Updateschritt durchgeführt
wird.
-
Für eine Gebietsoptimierung
bei der Planung des Updates kann vorteilhafterweise zusätzlich abgefragt
werden, ob die Versionsinformation Vx einer abhängigen Kachel Kij auf dem Server
S neuer als die entsprechende Versionsinformation Vx der entsprechenden
Kachel Kij auf dem Client C ist, da nur dann die Nachbarkachel als
die zu der zu aktualisierenden Kachel Kij benachbarte Kachel im
gleichen Gebiet liegen muss bzw. sollte. Unter einer abhängigen Kachel
wird dabei eine zu einer Kachel Kij benachbarte Kachel verstanden,
wenn ein Objekt O sich von einer der beiden in die andere der beiden Kacheln
erstreckt.
-
Beispielsweise
zeigt 3 Abhängigkeiten A
von zwei zueinander benachbarten Kacheln Kaa, Kab. Im Rahmen eines
ersten Serverupdates SU1 werden auf dem Server S die Kacheln Kaa,
Kab mit der Version der ersten Versionsinformation V1 bereitgestellt.
Ein Objekt O1 erstreckt sich dabei über beide Kacheln Kaa, Kab,
so dass die erste der Kacheln Kaa hinsichtlich der Versionsinformation
V1 von der zweiten dieser Kacheln Kab bzw. auch umgekehrt abhängt. Im
Rahmen eines nachfolgenden Serverupdates SU2 wird nur die zweite
dieser Kacheln Kab durch Aufnahme eines weiteren Objektes O2 aktualisiert.
Ein Austausch der zweiten Kachel Kab auf einem Client C ist somit
möglich,
ohne die Integrität des
Objektübergangs
zwischen diesen beiden Kacheln Kab, Kaa, zu verletzen. In einem
nachfolgenden Serverupdate SU3 wird ein weiteres Objekt O3 in den
Daten der ersten Kachel Kaa hinzugefügt. Auch bei diesem Updateschritt
wird die Abhängigkeit
A nicht geändert
sondern verbleibt bei der ersten Versionsinformation V1. Bei einem
nachfolgenden Serverupdate SU4 wird ein weiteres Objekt O4 den Daten
der beiden Kacheln Kaa, Kab hinzugefügt, wobei sich das Objekt über die
Kachelgrenze zwischen diesen erstreckt. Entsprechend ist für zukünftige Aktualisierungen
auf einem Client C zweckmäßigerweise eine
neue Abhängigkeit
A zu beachten, so dass mit der Aktualisierung einer der beiden Kacheln
Kaa, Kab mit der vierten Versionsinformation V4 zweckmäßigerweise
auch die andere dieser beiden Kacheln Kab bzw. Kaa auf dem Client
C mitaktualisiert werden sollte.
-
Beispiele
für Abhängigkeiten,
welche im Rahmen eines Updates eines Client C berücksichtigt werden
können
und sollten, sind anhand 2 dargestellt. Auf dem Server
S ist beispielsweise ein Gebiet aa – ff mit Kacheln Kij verschiedener
Aktualisierungsstufen dargestellt. Beispielsweise umfasst ein rechteckiger
Block als geschlossenes Gebiet cb – ec bis auf eine Randkachel
Kcc eine Versionsstufe mit der Versionsinformation V3. Entsprechend
kann für ein
Update ein geschlossener Bereich für einen entsprechenden geschlossenen
Updatetyp UA bereitgestellt werden. Eine weitere Kachel fd mit einem
nicht auf diese Ka chel beschränkten
Gebiet und einer zweiten Versionsinformation V2 liegt beispielsweise aus
Sicht eines für
einen Client C zu aktualisierenden Gebiets G am Randbereich des
Gebiets G und bildet somit ein nicht geschlossenes Updategebiet
am Rand des Bereichs bzw. einen Updatetyp UB nicht geschlossener
Art. Ergänzende
Updategebiete für Geschlossenheit
außerhalb
des durch den Client C angeforderten Aktualisierungsgebietes G bilden
beispielsweise einen weiteren Updatetyp UC, wie beispielsweise die
Kachel fe mit der aktuellsten Versionsinformation V3. Gemäß einer
bevorzugten Version erhält
der Client C Informationen zum Updateaufwand für den Gesamtbereich G, für welchen
der Client C eine Aktualisierung anfordert. Dabei wird nach den
drei Updatetypen UA – UC
sowie vorzugsweise jeweils Anzahl auszutauschender Kacheln Kij und Summe
der Kachelinhalte unterschieden. Der Client C fordert dann das Update
an. Er kann unterscheiden, ob er ein Update gemäß einem der Updatetypen UA
UB oder UC anfordert. Er kann alternativ oder zusätzlich auch
Daten in einem bestimmten Maximalumfang anfordern, wobei er in diesem
Fall möglichst nur
geschlossene Updategebiete übertragen
bekommt.
-
Bei
dem in 2 dargestellten Ausführungsbeispiel fordert der
Client C zur Aktualisierung ein Gebiet G mit den Koordinaten ca – fd beim
Server S an. Da die Randkachel Kfd mit der Koordinate fd im Rahmen
der Aktualisierung aufgrund einer Abhängigkeit zur außerhalb
des Aktualisierungsgebietes G liegenden benachbarten Kachel Kfe
für weitere
nachfolgende Verfahren potenziell gefährlich ist, da ein nicht geschlossener
Zustand erzeugt werden würde, werden
dem Client von dem Server S nur aktualisierte Kacheln außer dieser
Randkachel Kfd übertragen. Im
Client C werden nach der Installierung der empfangenen Kacheln Kij
die Versionsinformationen V3 auf den aktuellsten Stand gesetzt,
wobei die Versionsinformation V1 der kritischen Randkachel Kfd nicht
aktualisiert wird. In einem nachfolgenden Update werden dann vom
Server S an den Client C vorzugsweise nicht nur die fehlende Randkachel
Kfd sondern auch die abhängige
Kachel Kfe übertragen, so
dass kein nicht geschlossener Zustand mit Inkonsistenz zwischen
diesen beiden Kacheln entsteht.
-
Die
Durchführung
des Updates erfolgt durch das Übertragen
der aktuellen Versionsinformation Vx vom Server S an den Client
C, für
welche das Update durchgeführt
wird. Zur Minimierung des Updateaufwands kann der Server S für jede Kachel
Kij entscheiden, ob diese gar nicht, gesamt oder mittels einer Differenz- bzw. Deltaoperation
zu der bestehenden Client-Kachel erfolgen soll. Optional werden
die Updatesätze
so sortiert, dass sie nacheinander als geschlossene Gebiete beim
Client C eingebaut werden können
d. h. jeder Teilschritt des Updates ist in sich geschlossen, wie
beispielsweise im Fall der beiden Updateschritte gemäß 2.
Der Client C empfängt
die Update-Datensätze und
speichert sie vorläufig.
Anschließend
führt der
Client C lokal das Update seiner Datenbestände durch und aktualisiert dann
seine entsprechenden Tabellen. Insbesondere werden alte Kacheln
Kij durch neue Kacheln ersetzt und Versionsnummern bzw. Versionsinformationen Vx
dieser Kacheln Kij auf die aktuelle Versionsinformation Vx gesetzt.
-
Besonders
vorteilhaft ist, den Updatestand aller Kacheln im aktualisierten
Bereich des Clients C auf den neuesten, aktuellen Stand zu bringen,
d. h. die Versionsinformation Vx auch von Kacheln, für die es
auf dem Server S keine neue Version gab, auf den neuesten Stand
zu bringen. Die Versionsinformationen Vx aller nicht neu geladenen
Kacheln Kij im Updatebereich können
vor oder nach dem Einspielen der Updates aktualisiert werden. Auch
sie erhalten entsprechend die aktuelle Versionsinformation Vx. Im einfachsten
Fall, dass kein Update erforderlich ist, werden keine neuen Kacheln
Kij übertragen,
sondern es wird nur die Versionsinformation Vx für den gesamten Updatebereich
auf die aktuelle Versionsnummer gesetzt. Ausgenommen werden dabei
zweckmäßigerweise
Kacheln am Rand eines Bereiches, welche per Definition aufgrund
Abhängigkeiten
zu benachbarten Kacheln nicht geschlossen sind.