DE202011110873U1

DE202011110873U1 - Skalierbare Wiedergabe von großen räumlichen Datenbanken

Info

Publication number: DE202011110873U1
Application number: DE202011110873.6U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2010-06-08
Filing date: 2011-06-06
Publication date: 2017-01-18
Anticipated expiration: 2021-06-07
Also published as: EP2580691A2; EP2580691A4; EP2580691B1; WO2011156265A2; US8589425B2; US20120278313A1; US9098530B2; US20140074854A1; US20110302194A1; US8244743B2; WO2011156265A3

Abstract

System zur Behandlung von Benutzerabfragen und zur Durchführung von Datenverwaltung, umfassend: Mittel zum Speichern von mit Benutzerabfragen verbundenen Daten; und ein logisch mit dem Speichermittel gekoppeltes Prozessorgerät, das betrieben werden kann zum: Empfangen von Datensätzen von einer Vielzahl von Benutzergeräten; Speichern der einzelnen Datensätze als mit einem jeweiligen Benutzer verbundene Tabelle; Generieren einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile einer gegebenen einen aus der Gruppe von Tabellen darstellt; Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; Beantworten einer oder mehrerer aus der Vielzahl von Benutzerabfragen durch Erzeugen einer Visualisierung von ausgewählten Daten für die Anzeige auf einem oder mehreren der Benutzergeräte, wobei die Visualisierung anhand von in der zusammengesetzten Tabelle vorgefundenen Datentypen und den für die einzelnen Visualisierungen erforderlichen Datentypen bestimmt wird; und Einfügen von geographischen Merkmalen der einzelnen Datensätze in einen räumlichen Index.

Description

VERWEIS AUF VERWANDTE ANMELDUNG
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen. Die vorliegende Anwendung beansprucht die Priorität der US-Patentanwendung Nr. 12/796,142 , eingereicht am 8. Juni 2010 mit dem Titel „Scalable Rendering of Large Spatial Databases” (Skalierbare Wiedergabe von räumlichen Datenbanken), deren Offenbarung durch Verweis in Gänze hierin aufgenommen ist.
HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein kollaborative Anwendungen, darunter die Behandlung von räumlichen und strukturierten Abfragen in großen Datenbanken. Beschreibung des Stands der Technik
Kollaborative Tools gestatten den Benutzern die Zusammenarbeit an verschiedenen Anwendungen und die gemeinsame Nutzung von Daten. In vielen Fällen können Benutzer gleichzeitig zusammenarbeiten und Daten von entfernten Zugriffsorten aus gemeinsam nutzen. Dies verbessert die Produktivität und beschleunigt die Anwendungsentwicklung und den Einsatz von Diensten. Doch kann es eventuell nicht leicht sein, große Datenmengen unter mehreren Benutzern auszutauschen und zu verwalten. Dies kann das kollaborative Erlebnis verringern oder beschränken.
ZUSAMMENFASSUNG DER ERFINDUNG
Aspekte der Erfindung gestatten Benutzern das Hochladen oder Exportieren von Datentabellen in verschiedenen Formaten, darunter Tabellenkalkulationen, CSV-Dateien und KML-Dateien. Die Daten können mit geographischen Informationen verbunden sein und große Datenmengen umfassen. Wie hierin erläutert, gestattet das System und Verfahren gemäß Aspekten der Erfindung, große Datensätze von z. B. 100 MB, 250 MB oder mehr in eine Cloud-artige Architektur hochzuladen. Nach dem Hochladen können andere Mitarbeiter die Daten anzeigen, bearbeiten oder weitere Daten hinzufügen. Die Informationen können sofort auf einer Karte oder in einem Diagramm angezeigt werden, wodurch der Zusammenarbeitsprozess gefördert wird.
Nach einer Ausführungsform wird ein Verfahren zur Behandlung von Benutzerabfragen und zur Durchführung von Datenverwaltung bereitgestellt. Das Verfahren umfasst das Empfangen von Datensätzen von einer Vielzahl von Benutzergeräten; das Speichern der einzelnen Datensätze als eine mit einem bestimmten Benutzer verbundene Tabelle; das Erzeugen einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit den jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile aus einer gegebenen einen Tabelle der Gruppe von Tabellen darstellt; das Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; und das Antworten auf eine oder mehrere der Vielzahl von Benutzerabfragen durch Erzeugen einer Visualisierung der gewählten Daten in der zusammengesetzten Tabelle zur Anzeige auf einem oder mehreren der Benutzergeräte, wobei die Visualisierung anhand von in der zusammengesetzten Tabelle vorgefundenen Datentypen und den für die einzelne Visualisierung erforderlichen Datentypen bestimmt wird; worin einer der Datentypen der zusammengesetzten Tabelle Ortsinformationen umfasst und die Visualisierung eine Karte zur Anzeige mindestens eines Teils der Ortsinformationen umfasst.
In einem Beispiel wird die zusammengesetzte Tabelle durch Verschmelzen der Gruppe von Tabellen in einer Ansicht gebildet. In einem anderen Beispiel dürfen berechtigte Benutzer Kommentare zu Zeilen, Spalten oder Zellen aller Tabellen in der zusammengesetzten Tabelle anfügen. Hier können alle Kommentare zu Daten in der zusammengesetzten Tabelle in einer einzelnen Tabelle gespeichert sein, die über einen Schlüssel verfügt, der ein kommentiertes Element nach Tabelle, Zeile und Spalte kennzeichnet. In diesem Fall ist es bevorzugt, dass ein Wert der Zeile mindestens entweder den Text des Kommentars, den Autor oder das Eingabedatum des Kommentars darstellt.
In einem weiteren Beispiel umfasst das Antworten auf eine gegebene Benutzerabfrage das Mapping der gegebenen Abfrage in eine Schlüsselsuche, einen Präfix-Scan und einen Bereichs-Scan. In einem weiteren Beispiel umfasst das Verfahren weiterhin das Abbilden der zusammengesetzten Tabelle als eine oder mehrere Kartenschichten. Hier kann das Antworten auf eine oder mehrere Benutzerabfragen das Senden einer Sammlung von Kacheln mit Kartenschichten an bestimmte ausgewählte, mit den Benutzerabfragen verbundene Benutzergeräte umfassen.
Nach einer weiteren Ausführungsform der Erfindung wird ein Verfahren zur Behandlung von Benutzerabfragen und zur Durchführung von Datenverwaltung bereitgestellt. Das Verfahren umfasst das Empfangen von Datensätzen von einer Vielzahl von Benutzergeräten; das Speichern der einzelnen Datensätze als eine mit einem bestimmten Benutzer verbundene Tabelle; das Erzeugen einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit den jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile aus einer gegebenen einen Tabelle der Gruppe von Tabellen darstellt; das Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; und das Antworten auf eine oder mehrere der Vielzahl von Benutzerabfragen durch Erzeugen einer Visualisierung der gewählten Daten in der zusammengesetzten Tabelle zur Anzeige auf einem oder mehreren der Benutzergeräte, wobei die Visualisierung anhand von in der zusammengesetzten Tabelle vorgefundenen Datentypen und für die einzelne Visualisierung erforderlichen Datentypen bestimmt wird; und das Einfügen von geographischen Merkmalen der einzelnen Datensätze in einen räumlichen Index.
In einem Beispiel ist der räumliche Index für die dynamische Modifizierung durch kollaborative Benutzer konfiguriert, sodass Merkmale zu dem räumlichen Index hinzugefügt, darin gelöscht oder aktualisiert werden können. In einem alternativen Beispiel kann der räumliche Index eine raumfüllende Kurve verwenden, um Punkte auf der Erdoberfläche auf einer eindimensionalen Kurve abzubilden. In einem weiteren alternativen Beispiel umfasst das Verfahren weiterhin das Ausdünnen des räumlichen Index zur Reduzierung einer Anzahl der in einer gegebenen Kartenkachel sichtbaren Merkmale auf einen Satz von Merkmalen, der nicht größer als eine vorbestimmte Merkmalsmenge ist. Hier ist es bevorzugt, dass die Visualisierung den Merkmalssatz des ausgedünnten räumlichen Index umfasst wobei der Merkmalssatz unter den Antworten auf verschiedene Benutzerabfragen übereinstimmend ist.
In einer weiteren Ausführungsform umfasst ein Datenverarbeitungsverfahren das Generieren einer zusammengesetzten Tabelle aus einer mit bestimmten Benutzern verbundenen Gruppe von Tabellen, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile einer gegebenen einen der Gruppe von Tabellen darstellt; das Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren Benutzergeräten; und dass Antworten auf mindestens eine der Benutzerabfragen durch Ausführen einer räumlichen Abfrage zum Erhalt des Ergebnisses einer räumlichen Abfrage; Ausführen einer strukturierten Abfrage zum Erhalt des Ergebnisses einer strukturierten Abfrage; Bilden der Schnittmenge aus dem Ergebnis der räumlichen und dem der strukturierten Abfrage; und Senden der Schnittmengenergebnisse zur Anzeige an mindestens eines der Benutzergeräte.
Nach noch einer weiteren Ausführungsform wird ein System zur Behandlung von Benutzerabfragen und zur Durchführung von Datenverwaltung bereitgestellt. Das System umfasst Mittel zum Speichern von mit Benutzerabfragen verbundenen Daten und ein Prozessorgerät, das logisch mit dem Speichermittel gekoppelt ist. Das Prozessorgerät ist betriebsfähig zum Empfangen von Datensätzen von einer Vielzahl von Benutzergeräten; zum Speichern der einzelnen Datensätze als eine mit einem bestimmten Benutzer verbundene Tabelle; zum Erzeugen einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit den jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile aus einer gegebenen einen Tabelle der Gruppe von Tabellen darstellt; zum Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; und zum Antworten auf eine oder mehrere der Vielzahl von Benutzerabfragen durch Erzeugen einer Visualisierung der gewählten Daten in der zusammengesetzten Tabelle zur Anzeige auf einem oder mehreren der Benutzergeräte, wobei die Visualisierung anhand von in der zusammengesetzten Tabelle vorgefundenen Datentypen und für die einzelne Visualisierung erforderlichen Datentypen bestimmt wird; und Einfügen von geographischen Merkmalen der einzelnen Datensätze in einen räumlichen Index.
In einem Beispiel umfasst das Prozessorgerät ein Dispatcher-Modul zum Umwandeln der Benutzerabfragen in eine allgemeine Darstellung, ein Abfrageverarbeitungsmodul zum Erstellen eines Abfrageplans, und ein Backend-Modul zum Kommunizieren mit einem Satz von entfernten Computern für das Speichern und Verwalten der Datensätze und der zusammengesetzten Tabelle. In einem weiteren Beispiel ist der räumliche Index für die dynamische Modifizierung durch kollaborative Benutzer konfiguriert, sodass Merkmale zu dem räumlichen Index hinzugefügt, darin gelöscht oder aktualisiert werden können. In einem alternativen Beispiel kann der räumliche Index eine raumfüllende Kurve verwenden, um Punkte auf der Erdoberfläche auf einer eindimensionalen Kurve abzubilden. In einem weiteren alternativen Beispiel ist das Prozessorgerät weiterhin betriebsfähig zum Ausdünnen des räumlichen Index zur Reduzierung einer Anzahl der in einer gegebenen Kartenkachel sichtbaren Merkmale auf einen Satz von Merkmalen, der nicht größer als eine vorbestimmte Merkmalsmenge ist. In diesem Fall kann die Visualisierung einen Merkmalssatz des ausgedünnten räumlichen Index umfassen. Hier bleibt der Merkmalssatz unter den Antworten auf unterschiedliche Benutzerabfragen gleich.
In einer weiteren Ausführungsform umfasst das Datenverwaltungssystem Mittel zum Speichern von mit Benutzerabfragen verbundenen Daten und ein Prozessorgerät, das logisch mit dem Speichermittel gekoppelt ist. Das Prozessorsystem ist betriebsfähig zum Generieren einer zusammengesetzten Tabelle aus einer mit bestimmten Benutzern verbundenen Gruppe von Tabellen, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile einer gegebenen einen der Gruppe von Tabellen darstellt; zum Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren Benutzergeräten; und zum Antworten auf mindestens eine der Benutzerabfragen durch Ausführen einer räumlichen Abfrage zum Erhalt des Ergebnisses einer räumlichen Abfrage; Ausführen einer strukturierten Abfrage zum Erhalt des Ergebnisses einer strukturierten Abfrage; Bilden der Schnittmenge aus dem Ergebnis der räumlichen und dem der strukturierten Abfrage; und Senden der Schnittmengenergebnisse zur Anzeige an mindestens eines der Benutzergeräte.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1A–B zeigt ein System zur Verwendung gemäß Aspekten der Erfindung.
2 zeigt eine beispielhafte Architektur gemäß Aspekten der Erfindung.
3A–C zeigen Karten und Benutzerschnittstellenkonfigurationen gemäß Aspekten der Erfindung.
4 zeigt ein Beispiel einer Hilbert-Kurve gemäß Aspekten der Erfindung.
Aspekte, Merkmale und Vorteile der Erfindung werden ersichtlich, wenn sie unter Bezugnahme auf die folgende Beschreibung von Ausführungsformen und beigefügten Figuren betrachtet wird. Die folgende Beschreibung schränkt die vorliegende Erfindung nicht ein; der Umfang der Erfindung wird durch die angehängten Ansprüche und Äquivalente definiert.
AUSFÜHRLICHE BESCHREIBUNG
Aspekte der Erfindung bieten einen cloud-basierten Dienst für Datenverwaltung und Integration über einen weiten Bereich von Anwendungen hinweg. Gemeinschaften von Benutzern sind somit in der Lage, bei der Datenverwaltung über mehrere Unternehmen hinweg zusammenzuarbeiten. Wie weiter unten noch ausführlicher diskutiert, sind Benutzer in der Lage, sehr große Tabellendaten-Dateien (z. B. Tabellenkalkulationen oder CSV-Dateien) von bis zu 100 MB oder mehr hochzuladen. Verschiedene Arten der Visualisierung der Daten (Z. B. Diagramme, Karten, Zeitachsen) sind aktiviert.
Benutze werden zur Abfrage durch Filtern und Aggregieren der Daten befähigt. Die Integration von Daten aus mehreren Quellen wird durch Ausführung von Join-Operationen über mehrere Tabellen, die zu verschiedenen Benutzern gehören können, unterstützt. Benutzer können die Daten vertraulich halten, sie mit einem ausgewählten Kreis von Mitarbeitern gemeinsam nutzen, oder sie öffentlich zugänglich machen. Wenn Daten öffentlich gemacht werden, können Sie von Suchmaschinen durchsucht werden.
Eine Diskussionsfunktion gestattet Mitarbeitern, detaillierte Diskussionen der Daten auf der Ebene von einzelnen Zeilenspalten oder Zeilen zu führen. Aspekte der Erfindung bieten ein Tool, dass die Datenverwaltung erleichtert und daher einem größeren Kreis von Benutzern zugänglich ist. Benutze sind nicht unbedingt in der Anwendung von Datenbanksystemen geschult und haben normalerweise keinen Zugang zu Fachkräften als Datenbankadministratoren (DBAs).
Weitere Aspekte umfassen Mechanismen zum Anbieten von Anreizen für die gemeinsame Nutzung von Daten zwischen Benutzern oder Gruppen von Benutzern. Weiterhin kann bei der gemeinsamen Nutzung von Daten durch Mitarbeiter das Abfragen nur einen Teil der Aktivitäten ausmachen. Somit unterstützen Aspekte auch den Prozess des Verständigens auf eine Bedeutung von Daten und die Diskussion möglicher in Daten enthaltener Fehler.
1A–B zeigen schematische Diagramme eines beispielhaften Computersystems und bilden verschiedene Computergeräte ab, die allein oder in einer Netzwerkkonfiguration gemäß Aspekten der vorliegenden Erfindung verwendet werden können. Zum Beispiel zeigt 1A ein Computernetzwerk 100, das eine Vielzahl von Computern 102, 104, 106 und 108 sowie andere Arten von Geräten wie tragbare elektronische Geräte umfassen kann, zum Beispiel ein Mobiltelefon 110 und einen PDA 112. Solche Geräte können über einen lokalen Bus oder eine direkte Verbindung 114 miteinander verbunden und/oder über ein Kommunikationsnetzwerk 116 wie ein LAN, WAN, das Internet usw. gekoppelt sein, das verkabelt oder drahtlos sein kann.
Jedes Gerät kann zum Beispiel eines oder mehrere Verarbeitungsgeräte und Benutzereingabegeräte wie eine Tastatur 118 und Maus 120 und/oder verschiedene andere Arten von Eingabegeräten wie Eingabestifte, Joysticks, Tasten, Trackballs, Touchscreens usw. sowie ein Anzeigegerät 122 beinhalten, das zum Beispiel eine CRT, LCD, einen Plasmabildschirm-Monitor, ein TV-Gerät, einen Projektor usw. beinhalten könnte. Jeder Computer 102, 104, 106 und 108 kann ein Personalcomputer, Server usw. sein. Nur zum Beispiel kann der Computer 102 ein Server (z. B. ein Web-Server), der Computer 104 ein Desktop-Personalcomputer sein, die Computer 106 können einen Cluster 107 von Anwendungsservern in einer Cloud-Umgebung bilden und der Computer 108 kann ein Laptop, Palmtop oder Tablet sein.
Wie in 1B dargestellt, enthält jeder Computer wie die Computer 102 und 104 einen Prozessor 124, einen Speicher 126 und weitere normalerweise in einem Computer vorhandene Komponenten. Zum Beispiel speichert der Speicher 126 Informationen, die über den Prozessor 124 zugänglich sind, darunter Anweisungen 128, die von dem Prozessor 124 ausgeführt, und Daten 130, die die von dem Prozessor abgerufen, manipuliert oder gespeichert werden können. Der Speicher kann von einem beliebigen Typ oder ein beliebiges Gerät sein, das zum Speichern von für einen Prozessor zugänglichen Informationen in der Lage ist, zum Beispiel eine Festplatte, ROM, RAM, CD-ROM, DVD-ROM, Flash-Speicher usw. der Prozessor 124 kein eine beliebige Anzahl an bekannten Prozessoren wie den Prozessoren der Intel Corporation oder von Advanced Micro Devices umfassen. Alternativ dazu kann der Prozessor ein speziell dafür vorgesehener Controller, wie etwa eine ASIC, sein.
Die Anweisungen 128 können einen beliebigen Satz von Anweisungen umfassen, die direkt (z. B. Maschinencode) oder indirekt (z. B. Skripte) von dem oder den Prozessor(en) ausgeführt werden. In dieser Hinsicht können die Begriffe „Anweisungen”, „Schritte” und „Programme” hierin austauschbar verwendet werden. Die Anweisungen können in einer beliebigen Computersprache oder einem beliebigen Format gespeichert sein, zum Beispiel in Objektcode oder Modulen von Quellencode. Die Funktionen, Verfahren und Routinen der erfindungsgemäßen Anweisungen werden nachstehend eingehender erläutert.
Die Daten 130 können vom Prozessor 124 gemäß den Anweisungen 128 abgerufen, gespeichert oder bearbeitet werden. Die Daten können als Datensammlung gespeichert sein. Obwohl die Erfindung nicht durch eine bestimmte Datenstruktur eingeschränkt wird, können die Daten beispielsweise in Computerregistern, in einer relationalen Datenbank als Tabelle mit einer Vielzahl von verschiedenen Feldern und Datensätzen, als XML-Dokumente oder Flat Files, wie z. B. Keyhole Flat Files (KFF) gespeichert werden.
Die Daten können auch in jedem beliebigen computerlesbaren Format formatiert sein, wie unter anderem Binärwerten, ASCII oder Unicode. Darüber hinaus können die Daten alle Informationen zur Kennzeichnung der relevanten Informationen umfassen, wie beschreibende Texte, proprietäre Codes, Zeiger, Verweise zu in anderen Speichern abgelegten Daten (einschließlich anderer Netzstandorte) oder Informationen, die von einer Funktion zur Berechnung der relevanten Daten genutzt werden.
Obwohl in 1B der Prozessor 124 und Speicher 126 funktional als in zum gleichen Block gehörend dargestellt werden, versteht es sich, dass Prozessor und Speicher in der Praxis mehrere Prozessoren und Speicher umfassen können, die in dem gleichen physischen Gehäuse untergebracht werden können oder nicht. So können beispielsweise einige oder alle Anweisungen und Daten auf einem auswechselbaren Aufzeichnungsmedium wie einer CD-ROM, DVD oder Blue Ray Disc oder einem Flash-Speicher gespeichert sein, während andere Anweisungen und Daten in einem schreibgeschützten Computerchip gespeichert sein können. Einige oder alle Anweisungen und Daten können an einem Standort gespeichert werden, der physisch vom Prozessor entfernt ist, zu dem der Prozessor aber trotzdem Zugang hat. Desgleichen kann der Prozessor eine Reihe von Prozessoren umfassen, die parallel betrieben werden können oder nicht. Daten können über mehrere Speicher 126 wie Festplatten oder dergleichen verteilt gespeichert sein. Zum Beispiel kann der Cluster 107 von Computern 106 einen oder mehrere Serverfarmen zur Behandlung von großen Datenmengen und Benutzerabfragen umfassen.
Gemäß einem Aspekt kann der Server 102 mit einem oder mehreren Clientcomputern 104 und anderen Clientgeräten wie Computer 108, Mobiltelefon 110 und PDA 112 kommunizieren. Client-Computer oder sonstige Clientgeräte können wie der Computer 104 mit einem Prozessor, Speicher und Anweisungen sowie einem oder mehreren Benutzereingabegeräten 118, 120 und einem Benutzerausgabegerät wie der Anzeigevorrichtung 122 konfiguriert sein. Jedes Clientgerät kann ein Allzweckcomputer zur Verwendung durch eine Person sein, der all die normalerweise in einem Personalcomputer vorhandenen Komponenten aufweist, wie eine Zentraleinheit („CPU”), Anzeigevorrichtung, CD-ROM- oder DVD-Laufwerk, Festplatte, Maus, Tastatur, Berührungsbildschirm, Lautsprecher, Mikrofon, Modem und/oder Router (Telefon, Kabel oder sonstiges) sowie all die Komponenten die zur Verbindung dieser Elemente untereinander verwendet werden.
Wie in 1B dargestellt, können die Daten 130 eines Benutzergeräts wie des Computers 104 Benutzerdaten 132 wie Anwendungsdaten oder sonstige Daten zur Verwendung in einem kollaborativen Prozess umfassen. Je nach Anwendung können manche oder alle Benutzerdaten 132 gemeinsam genutzt werden, zum Beispiel mit dem Browser 134, mit einer Fernanwendung oder einem Ferndienst, die/der sich auf einem Server 102 und/oder dem Cluster 107 befindet oder von diesem verwaltet wird.
Die Server, Benutzercomputer und anderen Geräte sind zur direkten und indirekten Kommunikation miteinander über das Netzwerk 116 fähig. Obwohl nur wenige Computer in den 1A–B dargestellt sind, sollte klar sein, dass ein typisches System eine große Anzahl von verbundenen Computern beinhalten kann, wobei sich jeder dieser Computer an einem anderen Knoten des Netzwerks befindet. Das Netzwerk 116 und die dazwischenliegenden Knoten können verschiedene Konfigurationen und Protokolle umfassen, wie Internet, Intranet, virtuelle private Netzwerke, Wide Area Networks und lokale Netzwerke.
Eine Kommunikation über das Netzwerk einschließlich der dazwischen liegenden Knoten kann von jedem Gerät ermöglicht werden, das in der Lage ist, Daten von einem zum anderen Computer zu übertragen, wie Modems (z. B. Dial-up oder Kabel), Routern und dergleichen. Obgleich gewisse Vorteile erzielt werden, wenn Informationen wie oben angegeben übertragen oder empfangen werden, sind andere Aspekte der Erfindung nicht auf eine besondere Art und Weise der Informationsübertragung eingeschränkt. Gemäß manchen Aspekten können Informationen zum Beispiel über ein Medium wie eine Platte, ein Band, CD-ROM oder direkt zwischen zwei Computersystemen über ein Wählmodem gesendet werden. Gemäß anderen Aspekten können die Informationen in einem nicht-elektronischen Format übertragen und manuell in das System eingegeben werden.
Das in 1A dargestellte Netzwerk 100 kann auch eine Datenbank 136 umfassen. Die Datenbank 136 kann direkt oder indirekt mit einem Server 102 gekoppelt sein. Als Alternative kann die Datenbank 136 Teil des Servers 102 oder anderweitig logisch mit ihm verbunden sein. Die Datenbank 136 kann verschiedene Sätze oder Typen von Daten beinhalten. Nur zum Beispiel kann die Datenbank 136 eine Kartendatenbank für die Pflege von Orts- und/oder kartenbezogenen Daten sein. Solche Daten können in einer oder mehreren KFF-Dateien oder anderen Kartenformaten gespeichert sein. Wichtige Daten und weitere Informationen, darunter Satellitendaten, Luftbildaufnahmen, digitale Karten, Höhenangaben, GPS-Koordinaten usw. können von einer oder mehreren Quellen (nicht dargestellt) bezogen werden. Die Datenbank 136 kann alternativ Informationen zu kollaborativen Daten enthalten, wie unten ausführlich erläutert wird.
2 zeigt eine beispielhafte Architektur gemäß Aspekten der Erfindung. Wie dargestellt, kann ein Server wie ein Computer 102 mit dem Cluster 107 von Computern 106 zusammenwirken. Anforderungen können von mehreren Quellen wie einer Website oder einem Webbrowser 200, Standalone-Anwendungen über eine API 202 und Visualisierungen 204, die in anderen Webseiten (z. B. Diagrammen) eingebettet sein können, usw. stammen oder anderweitig empfangen werden. Im Falle eines Web-Browsers können Anweisungen/Code vom Server 102 zum Browser eines Clientgeräts geliefert werden, wenn der Client eine gegebene Webseite lädt. Es ist bevorzugt, dass Anforderungen zum Beispiel von Clientgeräten eines Benutzers aus dem Netzwerk vom Server 102 empfangen werden. Auf der Grundlage dieser Anforderungen werden Schichten für die Karten 206 anhand von räumlichen/strukturierten Abfragen in vom System, zum Beispiel der Datenbank 136 oder dem Cluster 107, unterhaltenen Tabellen generiert. Ein Frontend-Dispatchermodul 208 konvertiert Anforderungen in eine allgemeine Darstellung und leitet sie an das Abfrageverarbeitungsmodul 210 weiter, das einen Abfrageplan erstellt. Der Plan wird durch ein Backend-Modul 212 für strukturierte Daten ausgeführt, dass mit einem Satz von synchron replizierten Servern 106 im Cluster 107 zur Speicherung kommunizieren kann. Wie dargestellt, können die Module 208, 210 und 212 Teil des Servers 102 sein. In einer Alternative kann der Web-Browser 200 auch Teil des Servers 102 sein, während die API 202, Visualisierungen oder Diagramme 204 und Karten 206 extern vom Server 102 angeordnet sein können. In anderen alternativen können manche oder alle diese Komponenten Teil des Servers 102 sein oder können sie alle extern vom Server 102 angeordnet sein.
Eine wichtige Anforderung an die Speicherschicht ist die Fähigkeit, eine große Menge von Daten, zum Beispiel hunderttausende von Tabellen mit verschiedenen Schemata, Größen und Abfragelastkennwerten behandeln zu können. Um diese Anforderungen zu erfüllen, wird ein verteiltes Speichersystem für strukturierte Daten genutzt Bevorzugt wird hier eine verteilte Architektur wie Bigtable von Google genutzt. Einzelheiten des Bigtable-Speichersystems siehe in dem Artikel von Chang et. al., „Bigtable: A Structured Storage System for Structured Data", OSDI S. 205–218, 2006, dessen gesamte Offenbarung durch Verweis hierin einbezogen ist.

In der Bigtable-Architektur werden Tupel der Form nach (Schlüssel, Wert) gespeichert. Diese Paare sind nach Schlüssel sortiert und zwischen mehreren Servern aufgeteilt („sharded”). Das Sharding basiert auf Schlüsselbereichen. Eine vorgesehene Schreiboperation fügt automatisch ein neues Tupel hinzu. Es sind drei Leseoperationen vorgesehen. Diese sind „Nachschlagen nach Schlüssel”, die ein einzelnes Paar mit dem gegebenen Schlüssel abruft, „Nachschlagen nach Schlüsselpräfix”, die alle Paare mit dem gegebenen Schlüsselpräfix abruft, und „Nachschlagen nach Schlüsselbereich”, die alle Zeilen zwischen einem Start- und Endeschlüssel abruft. Für jedes Tupel wird ein Verlauf festgehalten. Zum Beispiel wird ein Tupel intern als (Schlüssel, Wert, Zeitstempel) gespeichert, wobei der Zeitstempel eine Zeit darstellt, zu der das Tupel geschrieben wurde. Ein einzelner Schlüssel kann mehrere Einträge haben, einen für jede Version des Tupels. Vorzugsweise sind alle Zeilen in allen Benutzertabellen in einer einzelnen zusammengesetzten Tabelle gespeichert, wie die in Tabelle 2 unten gezeigten „Zeilen”.

Zeilenschlüssel (Tabelle Nr., Zeile Nr.)	Indizierte Eigenschaften	Nicht indizierte Eigenschaften
(123, 1)	Modell = 328i, Farbe = rot, Typ = Limousine	Anm. = verkauft sich schnell
(123, 2)	Modell = 330i, Farbe = rot,
(124, 1)	Preis = 20, Standort = Lager, UPC = 500
(124, 2)	Preis = 32, Standort = Regal UPC = 430	Anm. = muss nachbestellt werden
...	...	...

Tabelle 1: Tabelle „Zeilen”

Jeder Eintrag in dieser Tabelle stellt eine Zeile in einer Benutzertabelle dar. Der Schlüssel ist die Aneinanderreihung einer Kennung für die Benutzertabelle und für die Zeile. Bevorzugt wird die Tabellen- und Zeilenkennung intern generiert, da Benutzer eventuell keinen Primärschlüssel eingeben müssen. Der Wert der Zeile ist ein Satz von indizierten und nicht indizierten Eigenschaften. Eine Eigenschaft ist ein Paar der Form (Eigenschaftsname, Eigenschaftswert). Jeder Eigenschaftsname ist wiederholt in der Zeile gespeichert. So können mehrere Zeilen in einer einzelnen Tabelle eine unterschiedliche Menge von Eigenschaften haben. Gemäß einem Aspekt werden alle indizierten Eigenschaften für eine effiziente Abfrageverarbeitung zu einem Index hinzugefügt.

Eine exemplarische Teilmenge der Tabelle „Zeilen”, nämlich eine „Schematabelle”, ist in der folgenden Tabelle dargestellt.

Tabelle	Schema	Genehmigungen
123	Name: Auto, Spalten: (Modell, Zeichenkette) (Farbe, Zeichenkette) (Typ, Zeichenkette) (Anm., Zeichenkette)	Betrachter: (Bob, Jane) Mitarbeiter: (Jim, Alex)
124	Name: Produkt, Spalten: (Preis, Zahl) (Standort, Zeichenkette) (UPC, Zahl)	öffentlich

Tabelle 2: Schematabelle

Das in Tabelle 2 gezeigte Beispiel enthält Zeilen für zwei Tabellen: 123 und 124. Die erste Zeile in Tabelle 123 enthält Eigenschaften für Modell, Farbe, Typ und Anmerkungen. Die zweite Zeile, ebenfalls in Tabelle 123, enthält die gleichen Eigenschaften außer für Typ und Anmerkungen. Es wurde beobachtet, dass diese Art von Schemaflexibilität für die Unterstützung von echten Benutzerdaten wichtig ist, weil diese sich nicht strikt an ein festes Schema halten. Das Schema der einzelnen Benutzertabellen ist bevorzugt in einer einzelnen Tabelle vom Typ Bigtable gespeichert. In einer Ausführungsform ist pro Tabelle eine einzelne Zeile gespeichert. Der Schlüssel ist hier die Tabellenkennung. Der Wert enthält Angaben zu Spalte und Genehmigung. Für jede Spalte ist deren Name und der bevorzugte Datentyp gespeichert. Der Typ kann als wertvoller Hinweis zur Bestimmung der natürlichen Sortierreihenfolge und verfügbare Visualisierung genutzt werden, doch ist dies nicht erforderlich. Gemäß einem weiteren Aspekt werden für die Genehmigungen eine oder mehrere Zugangskontrolllisten (ACL) verwendet. Der Benutzerkreis für jede Tabelle ist unter Betrachter (Lesegenehmigung) und Mitarbeiter (Lese-/Schreibgenehmigungen) aufgeführt Vorzugsweise haben öffentliche Tabellen eine spezielle Kennzeichnung, die angibt, dass die Tabelle von jedem angezeigt werden kann. Tabelle 3 zeigt ein beispielhaftes Schema für die in Tabelle 2 gezeigten Datenzeilen.

Tabelle	Eigenschaftsname	Eigenschaftswert	Zeile Nr.
123	Farbe	rot	1
123	Farbe	rot	2
123	Modell	328i	1
123	Modell	330i	2
124	Standort	Lager	1
124	Standort	Regal	2
124	Preis	20	2
124	Preis	32	1
...	...	...	...

Tabelle 3: Eigenschaftsindex

Ein wichtiger Aspekt besteht darin, dass die erfindungsgemäßen Systeme und Verfahren mehreren Benutzern das Verschmelzen ihre Tabellen in eine gestatten, selbst wenn sie nicht zum gleichen Unternehmen gehören oder beim Erstellen der Tabellen nichts voneinander wussten. Eine durch Verschmelzen („Equi-Join”) aus mehreren Basis Tabellen konstruierte Tabelle ist eine „Ansicht”. Es ist bevorzugt, dass Ansichten nicht ausgeführt werden und nur Angaben zu ihrer Definition und Genehmigung gespeichert sind. Gemäß einem Aspekt haben Ansichten ihre eigenen Genehmigungen mit den gleichen Rollen wie eine Tabelle sowie mit einer Zusatzrolle: Beitragender. Ein Beitragender ist ein Benutzer, der die Definition der Ansicht bearbeiten kann.
Zum Aktivieren der Zusammenarbeit dürfen Benutzer Kommentare zu Reihen, Spalten, Zellen oder Tabellen liefern. Alle Kommentare für alle Tabellen werden bevorzugt in einer einzelnen Tabelle gespeichert. Der Schlüssel der Kommentartabelle ist das Thema des Kommentars, ein Datentriplett (Tabelle, Zeile, Spalte) und benennt das Element, zu dem der Kommentar gegeben wird. Der Wert der Zeile ist der Text des Kommentars, der Autor und das Datum des Kommentars.
In einer Ausführungsform wird eine sehr restriktive SQL-Teilmenge akzeptiert, zum Beispiel die SQL-Teilmenge, die effizient mit der Bigtable-Architektur implementiert werden kann. Komplexere Abfragen, die kein SQL verwenden, können von den einzelnen Anwendungen über die API implementiert werden. Gemäß einem Aspekt bildet die allgemeine Abfrageausführungsstrategie eine High-Level-Abfrage in drei Grundoperationen ab: Schlüsselsuche, Präfix-Scan und Bereichs-Scan. Hier können die Abfrageverarbeitung einen Eigenschaftsindex verwenden, der einen weiten Bereich von Abfragen beschleunigt. Zum Beispiel kann der Index eine Bigtable-Tabelle sein, die nur Zeilenschlüssel und keine Daten enthält. In diesem Fall ist der Schlüssel für eine Reihe die Aneinanderreihung von Tabellennummer, Eigenschaftsname, Eigenschaftswert und Zeilennummer.
Tabelle 4 stellt ein Fragment eines Transaktionsprotokolls dar.

Tabelle Zeitstempel Unangewendet Mutationsliste

123 3:00 1 (1, k1, v1) (1, k3, v3)

124 3:05 (4, k4, v4) (4, k1, v2)

... ... ... ...

Tabelle 4: Tabellenebenenprotokoll
Im Folgenden werden ein paar allgemeine Abfragepläne beschrieben. „Präfix-Scan” wird für Abfragen wie „wählen * aus 123 Grenzwert 100” verwendet. Dies ist ein häufiger Abfragetyp, denn er entspricht der Standardsicht auf eine Tabelle. Mit dem oben angegebenen Beispiel besteht eine Strategie darin, einen Präfix-Scan in der Tabelle „Zeilen” mit dem Präfix = 123 durchzuführen. Eine weitere Abfrage ist der „Index-Präfix-Scan”, der für Abfragen wie „wählen·aus 123 wobei Farbe = rot” verwendet wird. Hier besteht die Strategie darin, einen Präfix-Scan am Index durchzuführen, wobei Präfix = (Farbe, rot), um die relevanten Zeilen aufzufinden und diese dann aus der Tabelle in „Zeilen” abzurufen. Im Falle von mehreren Bedingungen kann man einen separaten Index-Scan für jede einzelne Bedingung durchführen und dann die Schnittmenge aus den Zeilennummern bilden bzw. den Satz von Zeilennummern zusammenführen. Ein „Indexbereichs-Scan” wird für Abfragen wie „wählen * aus 124 wobei Preis > 10 und Preis < 20”. Die Strategie besteht hier darin, einen Bereichs-Scan am Eigenschaftsindex durchzuführen, dessen Startschlüssel (124, Preis, 10) und Endschlüssel (124, Preis, 20) ist und dann die relevanten Zeilen aus der Tabelle „Zeilen” abzurufen.
Und „Index Join” wird für Abfragen wie „wählen * aus A, B verwendet, wobei A. key = B. key” ist. Dies ist die typische Ansicht die sich beim Zusammenführen von mehreren Basistabellen ergibt. Es gibt zwei Grundstrategien zur Beantwortung dieser Art von Abfrage. Wenn eine der Tabellen klein ist wird jede ihre Schlüssel in der zweiten Tabelle nachgeschlagen. Andernfalls wird die Operation „Index Merge Join” ausgeführt. Hier wird ein gleichzeitiger Index-Präfix-Scan mit den Präfixen (A, A. key) (B, B. key) durchgeführt, und die übereinstimmenden Paare von Zeilen werden berechnet. Die Paare werden dann aus der Tabelle „Zeilen” abgerufen. Aspekte der Erfindung bieten Transaktionsunterstützung für Operationen an einer einzelnen Tabelle. In einer Ausführungsform basiert das auf der Megastore-Schicht des Speicherstapels von Google. Transaktionen sind atomar, konsistent, isoliert und dauerhaft (ACID). Es ist bevorzugt, dass eine Implementierung Write Ahead Logging und eine optimistische Parallelsteuerung nutzt.
In der Ausführungsform, die Megastore nutzt, wird bevorzugt eine Bigtable-Konfiguration verwendet, um das Write Ahead-Protokoll für die einzelnen Tabellen aufzuzeichnen. In diesem Fall kann eine einzelne Zeile pro Tabelle verwendet werden. Der Schlüssel ist die Tabellenkennung. Der Wert enthält die folgenden Informationen: Zeitstempel der zuletzt übertragenen Transaktion, Liste unangewendeter Aufgaben und Mutationsliste. Jede Mutation ist ein Tupel der Form (Aufgabennummer, Zeilenschlüssel, Zeilenwert). Hier ist die Aufgabennummer die Nummer der Transaktion. Und das Paar Zeilenschlüssel/Wert ist die Datenzeile nach der Mutation.
Tabelle 4 oben zeigt ein beispielhaftes Protokoll. In dieser Tabelle enthält der erste Eintrag (Zeile) das Protokoll für Tabelle 123, die letzte erfolgte Transaktion war um 3:00, und es gibt zwei unangewendete Mutationen, nämlich (1, k1, v1) und (1, k3, v3). Der zweite Eintrag (Zeile) enthält das Protokoll für Tabelle 124, die letzte erfolgte Transaktion war um 3:05, und es gibt zwei angewendete Mutationen, nämlich (4, k4, v4) und (4, k1, v2).
In einem Szenario durchläuft eine Transaktion die folgenden Stadien. Erstens Initialisierung. Hier wird der Protokolldatensatz für die Tabelle gelesen. Es wird geprüft, ob es unangemeldete Transaktionen gibt; wenn das der Fall ist, werden sie angewendet. Und der Zeitstempel für die letzte Hinzufügung wird gelesen. Es folgt das Wortstadium. Hier werden Datensätze für die Tabelle gelesen und geschrieben. Alle Leseoperationen können isoliert sein. In einem Beispiel werden Bigtable-Versionen verwendet, um zu gewährleisten, dass die Transaktion nur Daten von dem Zustand liest, als die Transaktion gestartet wurde. Vorzugsweise wird eine Liste aller Mutationen geführt. Das nächste Stadium ist das Commit-Stadium. Hier wird der Protokolldatensatz für die Tabelle gelesen und gesperrt. Es wird geprüft, ob eine andere Transliteration hinzugefügt wurde, seit der Prozess gestartet wurde. Wenn ja, schlägt der Prozess fehl. Wenn nein werden Protokolleinträge für jede Mutation geschrieben und wird die Aufgabe als hinzugefügt markiert. Es folgt das Anwendungsstadium. Hier werden die Mutationen analysiert und angewendet und die Aufgabe wird als angewendet markiert.
Während der Initialisierungsphase werden die Tabellen-Metadaten gelesen. Im Commit-Stadium werden Protokolleinträge geschrieben und der Zeitstempel für die letzte erfolgte Transaktion gesetzt. Nachdem die Aufgabe angewendet wurde, wird das Protokoll gelesen und einmal geschrieben. Die Ergebnisse insgesamt sind 2 Lesevorgänge und 2 Schreibvorgänge. Zur Reduzierung von Latenz wird bevorzugt, dass beim Anwenden der Aufgabe parallel alle Schreibvorgänge zu einer Bigtable gesendet werden.
Eine der leistungsfähigsten Aspekte der Erfindung besteht darin, dass ein Benutzer seine Daten unmittelbar nach dem Hochladen einer Tabelle visualisieren kann. Die Menge von verfügbaren Visualisierungen wird anhand der in der Tabelle gefundenen Datentypen und der für die Visualisierung erforderlichen Typen berechnet. Zum Beispiel kann eine Punktwolke nur dann verfügbar sein, wenn es mindestens zwei Zahlenspalten gibt, eine für die x-Achse und eine für die Y-Achse. Gleichermaßen kann eine Karte nur dann verfügbar sein, wenn d eine Ortsspalte ist, z. B. eine Spalte mit Straßenadressen, oder wenn eine Spalte mit Breiten- und Längenwerten erkannt wird.
Visualisierungen auf der Clientseite können durch eine API wie die Visualisierungs-API von Google bereitgestellt werden. Dies ist ein gut etablierter Rahmen zur Visualisierung von Daten auf einem Benutzergerät. Zum Beispiel kann die Visualisierung auf dem Browser mit Javascript oder Flash wiedergegeben werden, und die von der Visualisierung geforderten Daten können von einer Datenquellen-Schnittstelle bezogen werden.
Gemäß Aspekten der Erfindung können unterschiedliche Dienste in einem Rahmen bereitgestellt werden. In einem Szenario können Tabellen und Ansichten als eine Datenquelle für Visualisierungen angeboten werden. Es können Abfragen für Daten akzeptiert werden, die ein ordnungsgemäß kodiertes Ergebnis zurückgeben, das in einer beliebigen Visualisierung verwendet werden kann.
Benutzern kann auch anhand der Datentypen in ihren Tabellen automatisch Unterstützung bei der Konfiguration von Visualisierungen gegeben werden. Zum Beispiel kann eine Tabelle mit einer Standortspalte und einer Zahlenspalte eine Intensitätskarte umfassen, die vorab so konfiguriert ist, dass die Standortspalte als geographische Information und die Zahlenspalte als Intensität verwendet wird. Zur Förderung der Zusammenarbeit können Visualisierungen für die Publikation in Webseiten aktiviert sein. Auf diese Weise erscheinen die Daten an der natürlichen Stelle, wo andere Inhalte vorhanden sind. Ein Benutzer kann ein kleines Fragment von Javascript oder einem anderen Code in die Quelle einer bestimmten Webseite kopieren (z. B. einen Blogeintrag des Benutzers), und die Visualisierung wird mit einem Live-Link zu den Daten angezeigt. Das heißt, dass die Visualisierung jedes Mal dann aktualisiert wird, wenn die Daten mit dem System aktualisiert werden.
Tabelle 5 unten zeigt ein exemplarisches Fragment des Javascript-Codes zur Einbettung einer Visualisierung in eine Webseite. Zeile 4 definiert die Abfrage, die zum Server oder zur Anwendung gesendet wird, in diesem Fall die Auflistung des Gesamtgehalts nach Abteilung. Zeile 13 nimmt die erhaltenen Daten und gibt sie als Tortendiagramm wieder. Für Benutzer, die keinen Java Skript-Code schreiben möchten, können ein Fragment des Codes (Gadget) direkt in eine Webseite eingebettet werden.
Tabelle 5: Eingebetteter Visualisierungscode
Ein weiterer Aspekt ist die Wiedergabe großer geographischer Datensätze. In einem Beispiel können Benutzer Daten mit Straßenadressen, Punkten, Linien oder Polygonen hochladen. Die Daten können in verschiedenen Formaten wie csv, xls, ods oder trix vorliegen, und sie werden bevorzugt in Tabellen für die kollaborative Manipulation hochgeladen.
Eine Tabelle hat ein festes Schema, nämlich einen Satz von Spalten, jede mit einem Datentyp. Zum Beispiel ist ein Datentyp für Kartenanwendungen der Standort. Ein Standort kann mindestens zwei Komponenten umfassen, zum Beispiel Zeichenkettendarstellung (z. B. „1600 Amphitheatre Pkwy, Mountain View, CA”) Und ein paar von Breiten- und Längenangaben (z. B. 37,423269, –122,082667). Tabellen mit Standortspalten können auf einer Karte visualisiert werden. In einem Beispiel ermöglicht die Karte die Wiedergabe der einzelnen Zeilen als Ortsmarke auf der Clientseite. Solche Karten können paginiert sein, zum Beispiel mit 200 Zeilen pro Seite.
Tabellen nach Aspekten der Erfindung können als Kartenschichten wiedergegeben werden. Die Wiedergabe erfolgt bevorzugt auf der Serverseite. Zum Beispiel können räumliche Merkmale wie Punkte, Linien und Polygone durch den/die Server wiedergegeben werden. Es werden auch räumliche und strukturierte Abfragen unterstützt, z. B. Filtern und Aggregation über nicht räumliche Merkmale.
In diesem Fall der Wiedergabe von Kartenschichten auf der Serverseite wird eine Sammlung von kleinen Bildern (Kacheln), die die wiedergegebene Karte enthalten, an den Client gesendet. Nur als ein Beispiel zeigt 3A eine exemplarische Wiedergabe von Radwegen mit einer Länge von unter 20 Meilen im Bereich der San Francisco Bay. 3B zeigt einen Teil der grafischen Benutzeroberfläche eines Browsers, in der eine Anzahl von verschiedenen Radwegen nach einer Rangfolge geordnet sind, zum Beispiel nach der Kennnummer. Wie dargestellt, können die dem Benutzer angebotenen Informationen auch eine Bewertung, Namen und einen Reise-Link sowie weitere mit den geographischen Daten verbundene Informationen wie Gefälle, Anstieg und Mindesthöhenlage umfassen. Diese Angaben können zum Filtern der gemeinsam genutzten Daten verwendet werden. Zu weiteren Filteroptionen gehören das Filtern nach Wegkennung, Benutzerkennung, maximaler Höhenlage, Bild-Link, Geometrie und Entfernung. Somit kann der Benutzer, wie in 3A dargestellt, Radwege mit einer Länge von weniger als 20 Meilen auswählen. Und der Benutzer kann, wie in 3C dargestellt, die Ergebnisse in Form einer Heatmap anzeigen.
Wie oben angemerkt befähigen Aspekte verschiedene Benutzer zur Zusammenarbeit mit einem gemeinsam genutzten Satz von Daten, zum Beispiel Informationen über Radwege. Angenommen, eine Gruppe von Mountainbikern arbeitet an der Erstellung einer weltweiten Liste von Radwegen. Die Gruppe wäre in der Lage, eine Tabelle der Form „Radwege” zu erstellen, die Informationen wie Name des Radwegs, Beschreibung, Länge, Geländetyp, technische Schwierigkeit, sportliche Schwierigkeit und Linie umfasst, wobei Linie die den Radweg definierende Polylinie ist. Nicht-räumliche Attribute können ebenfalls Teil der kollaborativen Tabelle sein.
In einem Beispiel möchte ein Benutzer vielleicht nach Reitwegen mit der technischen Schwierigkeit < 3, Länge > 10 (z. B. Meilen) und Geländetyp = „Wald” in der Gegend um San Francisco suchen. Der Benutzer kann mit dem Browser zu einer Webseite gehen, die Radwegtabelle auf der Webseite öffnen, sie in einer Karte anzeigen, die Karte auf San Francisco zentrieren/zoomen und die genannte Abfrage eingeben. Das System zeigt alle Radwege an, die in das gegebene Ansichtsfenster (Gegend um San Francisco) fallen und den angegebenen Prädikaten entsprechen. Während dieses Beispiel auf Radwege zutrifft, versteht sich, dass die Mapping- und Filteroptionen nicht darauf beschränkt sind und auf andere Arten von Daten angewendet werden können.
Zur Wiedergabe einer clientseitigen Visualisierung über den Browser oder eine andere Anwendung werden alle Daten an den Client gesendet. Der Browser des Clientgeräts gibt dann die Visualisierung wieder. Dieser Modelltyp kann jedoch schwer anzuwenden sein, wenn ein großer Datensatz auf einmal bildlich dargestellt werden muss. Es bestehen zwei Hauptschwierigkeiten. Erstens kann der Browser nicht leistungsstark genug sein, um Tausende von Merkmalen in Echtzeit zu zeichnen. Zweitens kann die Übertragung eines großen Datensatzes an das Clientgerät nicht praktikabel sein.
Die Informationen, die ein Benutzer auf einer Kartenanwendung wie Google Maps sieht, setzen sich aus mehreren übereinander angeordneten Schichten zusammen. Zum Beispiel sind Straßen-, Satelliten-, und Geländekarten getrennte Schichten. Ein auf einer Karte anzuzeigendes Abfrageergebnis wird als Schicht dargestellt. Wenn ein Benutzer eine Anforderung zur Anzeige einer Karte eingibt, wird eine entsprechende Anforderung an die Backend-Server gesendet, die die aktuell sichtbaren Schichten, die geographischen Koordinaten des auf dem Browser des Clientgeräts sichtbaren Fensters und die aktuelle Zoomstufe angeben. Das Backend (z. B. der Server 102 oder Cluster 107) erstellt dann Kacheln (Bilder) durch Zusammenstellen der Daten in den verschiedenen Schichten und liefert diese Kacheln als Antwort auf die ursprüngliche Abfrage.
Gemäß einem Aspekt werden geographische Merkmale in einen räumlichen Index eingefügt. Der räumliche Index unterstützt Abfragen der Form „alle Merkmale in der gegebenen s2cell einholen”. Eine „s2cell” wird verwendet, wenn Teile der Erde auf einen Würfel projiziert werden. Hierbei wird eine rekursive Hilbert-Kurve über jede Seite des Würfels gelegt. Eine s2cell wird als Zellenkennung („S2CellID”) dargestellt. Bei der S2CellID kann es sich z. B. um eine 64-Bit-Kennung handeln, wobei die ersten 3 Bits angeben, zu welcher Seite des Würfels die Zelle gehört, die nächsten mehreren Bits angeben, wie weit rekursiv in die Hilbert-Kurve zu gehen ist, und die restlichen Bits die Zellen beschreiben, denen beim Gehen in die Hilbert-Kurve gefolgt werden soll. Ein separater Index kann für die in den einzelnen Standortspalten einer Tabelle enthaltenen Merkmale erstellt werden. Der Index ist eine geordnete Liste von s2 cell IDs, zum Beispiel index[S2CellID] → Merkmale in S2CellID. Eine S2CellID stellt eine rekursive Raumunterteilung dar.
Der räumliche Index ist bevorzugt vollständig im Speicher gespeichert (z. B. in der Kartendatenbank 136 aus 1A) und kann von mitarbeitenden Benutzern dynamisch bearbeitet werden, sodass Merkmale hinzugefügt, gelöscht oder aktualisiert werden können. In einem Beispiel kann ein Merkmal Informationen wie Tabellennummer, Merkmalsnummer und Geometrie enthalten. Wenn „Tabellennummer” die Nummer der Tabelle ist, die das Merkmal enthält, ist „Merkmalsnummer” eine global einheitliche Nummer für das Merkmal und Geometrie ist eine Liste von Punkten, die den Punkt, die Linie oder das Polygon beschreiben.
Jede Zeile in der Datenbank speichert bevorzugt die folgenden Angaben: Tabellennummer – die Tabelle, in der das Merkmal auftritt; Spaltennummer – die Spalte in der Tabelle, in der das Merkmal auftritt; Merkmalsnummer – die Nummer des Merkmals, die über Tabellen und Spalten hinweg gleich ist; und einen oder mehrere Protokollpuffer wie Datenstrukturen zum Speichern von Daten.
Der Index verwendet eine raumfüllende Kurve, um Punkte auf der Erdoberfläche auf einer eindimensionalen Kurve abzubilden. Die Erde wird in die sechs Flächen eines Würfels projiziert. Jede Fläche wird rekursiv in Zellen unterteilt. Zellen werden mit einer raumfüllenden Kurve von 2D in 1D abgebildet, wobei jeder Zelle eine Kennung zugewiesen wird, die ihre Position in der Kurve angibt.
Die Ebene einer Zelle entspricht der Anzahl von Malen, die die Unterteilung angewendet wurde. Jede Unterteilung teilt die Zelle in 4 Quadranten. In einem Beispiel ist die höchste Ebene 30, was grob einem Quadratzentimeter entspricht. Zellenkennungen werden in Hilbert-Reihenfolge sortiert.
Im Folgenden sind mehrere Operationen angegeben, die vom Index unterstützt werden können. Eine Operation lautet „Punkt P einfügen”. Hierbei ist eine Zelle gleich einer S2CellID des Punktes P (Zelle der untersten Ebene). Diese Operation fügt den Punkt zum Index [Zelle] hinzu. Die nächste lautet „Linie/Polygon einfügen”. Hier vereinfacht der Prozess die Linie durch Sampling zu maximal 100 Punkten, obwohl auch andere Höchstwerte verwendet werden können. Dann wird die Menge von Zellen, die die vereinfachte Linie bedecken, berechnet, wobei sich die Zellen auf einer beliebigen Ebene befinden können. Für jede Zelle in der Abdeckung wird eine Linie zum Index [Zelle] hinzugefügt. Eine weitere Operation lautet „Abfrage nach Merkmalen in Zelle q”. Hier berechnet der Prozess die Anfangs- und Endzelle (auf der untersten Ebene) für Zelle q. Alle Merkmale im Bereich Index[Start-Ende] (zwischen der Anfangs- und Endzelle) werden dann abgerufen. Bevorzugt werden alle Merkmale in Zellen erhalten, die Vorgänger von q sind. In einem Beispiel ist die Höchstzahl der Vorgängersuchen auf 30 eingestellt. Hier gibt es eine Hierarchie der Zellen, wobei eine Zelle ganz unten in der Hierarchie maximal 30 Vorgänger haben kann. Die Kosten des Abrufens von Vorgängern können so auf 30 Suchläufe begrenzt werden. Hieraus erhält man die Vereinigungsmenge zwischen den Merkmalen im Bereichsindex und den Merkmalen in Zellen, die Vorgänger von q sind.
Die rekursive Definition von Zellen ist wie folgt. Auf der obersten Ebene befindet sich jede Seite des Würfels in einer einzelnen Zelle, wobei eine Zelle auf jeder nachfolgenden Ebene in vier kleinere Zellen unterteilt ist. Die Anzahl von Ebenen richtet sich nach der gewünschten Granularität. 4 zeigt ein Beispiel eine Hilbert-Kurve mit zwei Ebenen. Der Index ist eine geordnete Liste von Zellenkennungen. Jede Zellenkennung weist auf alle Merkmale, die diese Zelle überlappen. Tabelle 6 stellt einen exemplarischen räumlichen Index mit drei Merkmalen dar In dieser Tabelle ist f₁ eine Polylinie, f₂ ein kleines Polygon und f₃ ein Punkt.

Zelle Merkmale

5.0.0 f₁, f₂

5.0.0.1 f₃

5.0.2 f₁

5.0.3 f₁

5.3.0 f₁, f₂

5.3.1 f₁

Tabelle 6: Räumlicher Index
Ein Merkmal enthält bevorzugt die folgenden Informationen: eine Kennung, die eine Merkmalsnummer ist (einheitlich über Tabellen und Spalten hinweg), eine Tabellennummer, die die das Merkmal enthaltende Tabelle darstellt, eine Spaltennummer, die die das Merkmal enthaltende Spalte angibt, einen Mindestdetaillierungsgrad (level of detail, LOD), auf dem das Merkmal sichtbar sein sollte, und eine Geometrie, die ein S2Point, eine S2Polyline oder ein S2Polygon sein kann. Der Speicherbedarf eines Merkmals kann in der folgenden Größenordnung liegen: 24 + (24·Anzahl_an_Punkten). Somit kann ein Computer mit 8 GB RAM um die 450.000 Linien/Polygone zu 100 Punkten oder um die 20 Millionen Einzelpunkt-Merkmale fassen.
Merkmale können wie folgt wieder in den Index eingefügt werden. Das Merkmal wird in dem Satz von Zellen, die es bedecken, abgebildet. Die Abdeckung eines Merkmals kann Zellen auf verschiedenen Ebenen umfassen, z. B. hat ein Polygon, das einen großen Teil eines Bundesstaats abdeckt, große Zellen in der Mitte und nur feinere Zellen an den Grenzen. Die die Abdeckung bildenden Zellen werden in den Index eingefügt oder dort aktualisiert, sodass sie auf das Merkmal weisen.
Die räumliche Abfrageverarbeitung kann wie folgt erfolgen. Eine allgemeine Abfrage für einen räumlichen Index kann lauten „welche Merkmale fallen in einen Begrenzungsrahmen?” Der Begrenzungsrahmen ist als ein paar von Breiten- und Längenkoordinaten definiert. Die Strategie zur Beantwortung der Abfrage sieht wie folgt aus. Zunächst den Begrenzungsrahmen in einen Bereich (oder Bereiche) in der raumfüllenden Kurve umwandeln. Dann alle die Merkmale für einen solchen Bereich abrufen, die in Zellen zwischen dem Anfang und Ende des Bereichs enthalten sind.
Über Karten werden räumliche und strukturierte Abfragen unterstützt. Zum Beispiel kann ein Benutzer nach allen Radwegen fragen, die in das Gebiet San Francisco Bay fallen (eine räumliche Abfrage) und eine Bewertung von 4 Sternen oder mehr (eine strukturierte Abfrage) haben. Diese Fragen können durch parallele Ausführung der räumlichen und strukturierten Abfrage und anschließendes Bilden der Schnittmenge aus den Ergebnissen beantwortet werden.
Ein Beispiel für diesen Prozess wird unten dargestellt. Eine Abfrage kann eine Sammlung von Prädikaten und eine Aggregationsspezifikation enthalten. Antworten auf Abfragen geben den Satz von Merkmalsnummern zurück, die die Prädikate erfüllen. Zum Beispiel verläuft der Prozess des Empfangens und Beantwortens einer bestimmten Anforderung wie folgt: Zunächst wird eine Anforderung der Form (S2cell, SQL) von einer Clientanwendung (z. B. Browser) empfangen. Dann werden die Merkmale innerhalb s2cell im räumlichen Index nachgeschlagen. Dann wird der Satz von Merkmalen, die die SQL-Abfrage erfüllen, im Speicher für strukturierte Daten nachgeschlagen. Die Schnittmenge aus den Ergebnissen der Merkmale in der s2cell und den Merkmalen aus dem Speicher für strukturierte Daten wird gebildet und dem Benutzer bereitgestellt.
Um schnelle Kartenvisualisierungen zu gewährleisten, kann ein Grenzwert für die Anzahl an Merkmalen, die in einer Kachel gezeichnet werden können gesetzt werden. Wenn die Anzahl an eine Benutzerabfrage erfüllenden Merkmalen für eine Kachel diesen Grenzwert überschreitet, kann/können der/die Server den Mapping-Servern nur eine Probe der Elemente in der Antwort zurückgeben.
In einem Beispiel kann die Anzahl an für eine Kachel zurückgegebenen Merkmalen auf einen Höchstwert von 500 begrenzt werden. Zur Ladezeit des Index wird ein Ausdünnungsalgorithmus/-prozess durchgeführt, der den Mindestdetaillierungsgrad festlegt, bei dem die einzelnen Merkmale sichtbar werden. Dieser Prozess garantiert, dass keine Kachel mehr als 500 Merkmale enthält. Tabelle 7 zeigt einen beispielhaften Prozess für ein kachelbasiertes Ausdünnungsverfahren für einen räumlichen Index.
Tabelle 7: Kachelbasiertes Ausdünnungsverfahren für den räumlichen Index
Wie in der Tabelle dargestellt werden zunächst die Merkmale zu entsprechenden Kacheln zugeordnet. Dies geschieht für jedes Merkmal im Index. In Zeile 4 wird der Satz von Merkmalen in einer gegebenen Karte so aktualisiert, dass jedes in der dieser Karte wiedergebbare Merkmal eingeschlossen ist. Dann werden für jede Kachel für einen gegebenen Detaillierungsgrad (beginnend mit dem niedrigsten Detaillierungsgrad) unterschiedliche Parameter bestimmt. Zum Beispiel wird in Zeile 8 eine Liste von Merkmalen („free”) in der Kachel eingestellt, wobei der Detaillierungsgrad höher als der Detaillierungsgrad für die Kachel ist. In Zeile 9 wird eine Liste von Merkmalen („taken”) in der Kachel eingestellt, wobei der Detaillierungsgrad niedriger als der Detaillierungsgrad für die Kachel ist. Für die Gesamtanzahl von ausgewählten Merkmalen (Samples „s”) bis zum Höchstwert (z. B. 500) kann das System den Höchstwert minus der Anzahl von Merkmalen, die bereits für die Anzeige in der Kachel festgelegt wurden, einbeziehen. Und in Zeile 11 wird für jedes Merkmal f im Satz s der Detaillierungsgrad, bei dem das Merkmal zuerst erscheinen sollte, auf den der Kachel eingestellt.
Die Merkmalsauswahl (Sampling) sollte einheitlich sein. Der für einen gegebenen Detaillierungsgrad zurückgegebene Merkmalssatz darf sich nicht von Anforderung zu Anforderung ändern. Der Grund liegt darin, das zwei verschiedene Server (zum Beispiel im Cluster 107) mit der Berechnung von benachbarten Kacheln beauftragt werden können. Wenn die Menge von sichtbaren Kacheln nicht gleich ist, kann es geschehen, dass Merkmale an der Grenze von Kacheln nur in einer von beiden dargestellt werden. Daher werden Samples bevorzugt so ausgewählt, dass Punkte niemals verschwinden, wenn ein Benutzer das Ansichtsfenster verschiebt oder in es hinein zoomt. Das Sampling kann wie folgt erfolgen. Jedes Merkmal wird bewertet, und alle Kacheln, in denen es (auf jeder Zoomebene) erscheint, werden berechnet. Das Merkmal wird jeder solchen Kachel zugewiesen.
Wenn eine Gesamtanzahl von Ergebnissen für eine strukturierte Abfrage für den gegebenen Detaillierungsgrad zu klein ist, kann das Ausdünnen deaktiviert werden. Es kann auch ein merkmalsbasiertes Ausdünnen angewendet werden. Wenn Linien und Polygone wiedergegeben werden, hängt die Anzahl der zur Anzeige des Merkmals verwendeten Punkte vom Detaillierungsgrad ab. Bei niedrigen Detaillierungsgraden, die z. B. weit entfernte Interessenschwerpunkte darstellen, kann eine kleine Anzahl an Punkten verwendet werden. Bei hohen Detaillierungsgraden, die z. B. nahe gelegene Interessenschwerpunkte darstellen, können mehr Punkte verwendet werden. In einem Beispiel kann das Polygon einheitlich abgetastet werden, um die zu verwendenden Punkte zu bestimmen. Als Alternative kann die Abtastrate an die Winkelveränderungen zwischen Kanten angepasst werden.
Die Hierarchie der Kacheln wird von geringer Zoomstufe (weit entfernt) zur hohen Zoomstufe hin (nahebei) durchlaufen. Auf jeder Stufe wird eine Merkmalsauswahl einer Kachel zugeordnet. Wenn geringere Zoomstufen bewertet werden, werden neue Merkmale den der Kachel bereits durch übergeordnete Kacheln zugewiesenen Merkmalen hinzugefügt. Dieser Prozess garantiert, dass eine Kachel nicht mehr als den im Voraus definierten Grenzwert von Merkmalen hat und dass die Auswahl einheitlich erfolgt. Am Ende des Prozesses enthält jedes Merkmal nur ein weiteres Attribut: die Mindest-Zoomstufe, bei der das Merkmal erscheint.
Wie in 3C dargestellt, unterstützt das System auch die Wiedergabe von Heatmaps. Dies ist sinnvoll, wenn ein Benutzer eine Karte entsprechend der Merkmalsdichte im Raum gefärbt haben möchte. Sie können auch zur bildlichen Darstellung sehr großer Datensätze verwendet werden, bei denen die Merkmalsauswahl subtile Unterschiede in der Merkmalsdichte von Kachel zu Kachel eventuell nicht erfasst.
Gemäß einem Aspekt können Heatmaps wie folgt aufgebaut werden. Mit dem räumlichen Index wird der Satz der in das Ansichtsfenster fallenden Merkmale abgerufen. Das Ansichtsfenster wird als feines Raster abgerufen, und es wird die Anzahl an Merkmalen in den einzelnen Rasterzellen gezählt. Rasterzellen können entsprechend der Anzahl an sie schneidenden Merkmalen zum Beispiel mit einer Palette gefärbt werden, die helle Farben einer geringen Zellenanzahl und dunkle Farben einer hohen Zellenanzahl zuweist. Zellen ohne Merkmale werden nicht gefärbt. Der Benutzer kann eine Heatmap erzeugen, die nur eine Teilmenge von Merkmalen enthält, die einer gegebenen strukturierten Abfrage entsprechen.
Wie Client-Visualisierungen können auch Karten auf Webseiten veröffentlicht werden. Ein Benutzer kann ein kleines Fragment von Javascript oder einem anderen Code in die Quelle einer bestimmten Webseite kopieren, und die Karte wird mit einem Live-Link zu den Daten angezeigt. Tabelle 8 zeigt ein exemplarisches Fragment des Javascript-Codes zur Einbettung einer Karte in eine Webseite.
Tabelle 8: Eingebetteter Kartencode
Zeile 2 erstellt die schicht mit dem Namen ft:tableId. Bevorzugt hat jede Tabelle ihre eigene Schicht. Mehrere Tabellen können zur gleichen Karte hinzugefügt werden, indem einfach ihre entsprechenden Schichten hinzugefügt werden. Line 4 weist die Anwendung an, die Schicht als Merkmale und nicht als Heatmap zu zeichnen. Zeile 7 stellt eine SQL-Abfrage ein, die den Satz der relevanten Merkmale filtert.
Eine wichtige Komponente einer Plattform für Datenverwaltung und Zusammenarbeit besteht darin, Entwicklern eine Möglichkeit zur Erweiterung der Funktionalität der Website zur Hand zu geben. Dies erfolgt durch eine API. Die API gestattet externen Entwicklern, Anwendungen zu schreiben, die das System als Datenbank nutzen. Zum Beispiel kann eine Anwendung eine Sammlung von Radwegen mit einer Tabelle synchronisieren. Die API unterstützt die Abfrage von Daten durch ausgewählte Anweisungen. Die Aktualisierung der Daten erfolgt über Einfüge-, Lösch- und Aktualisierungsanweisungen. Datendefinitionen können durch eine Anweisung „Tabelle erstellen” gegeben werden. Der Zugang zu den Daten durch die API kann mit vorhandenen Standards gestattet werden. Ein Beispiel dafür ist das OAuth-Protokoll.
In einem Beispiel enthält jede mit einer kollaborativen Anwendung verbundene Anforderung einen Parameter mit einer SQL-Abfrage. Hier sollten nur Merkmale zurückgegeben werden, die die Abfrage erfüllen. In einer Alternative kann das System pro Ansichtsfenster etwa 12–20 Anforderungen ausgeben. Jede dieser Anforderungen enthält die gleiche SQL-Abfrage. Um den Speicher für strukturierte Daten nicht zu überfordern, können Abfrageergebnisse im Cache gespeichert werden. Die Caching-Strategie führt eine Tabelle mit Schlüssel = Tabellennummer, SQL und Inhalt = Liste der Merkmalsnummern. Wenn eine Anforderung ankommt, wird zuerst der Cache untersucht. Ist die Antwort dort, wird sie zurückgegeben. Wenn nicht, wird der Speicher für strukturierte Daten um Antwort gebeten, die dann zum Cache hinzugefügt wird. Wenn die Tabelle geändert wird, werden alle ihre Cache-Einträge ungültig gemacht.
Zugangskontrollinformationen für eine Zugangskontrollliste können ebenfalls im Cache gespeichert werden. In dieser Alternative können Anforderungen von Benutzern die Benutzer-ID des aktuellen Benutzers liefern. Hier prüft das System, ob der Benutzer Lesezugang zur Tabelle hat. Diese Prüfung erfordert das Lesen von Tabellen-Metadaten aus der Datenbank. Zugangskontrolllisten können für die Tabelle geführt werden, um zu bestimmen, ob der Benutzer Zugang hat. Zur Reduzierung der Latenz wird für jede Tabelle ein In-Memory-Cache (LRU) mit Authentifizierungsinformationen unterhalten. Für nicht-öffentliche Tabellen wird eine Liste von Paaren der Form (Benutzer-ID, berechtigt) geführt, wobei „berechtigt” wahr oder falsch sein kann. Bei öffentlichen Tabellen kann ein spezieller Marker angeben, dass sie jeder lesen kann.
Die Back Office-Anwendungsserver oder Clusterserver können auf die folgenden zwei Abfragen antworten. Eine ist eine Anforderung von Schichten, die in einer Kachel (s2-Zellen) sichtbare Merkmale zurückgeben, und einer SQL-Abfrage entspricht. Wie oben ausgeführt, wird die Abfrage durch Bilden der Schnittmenge aus dem Satz von Merkmalen, die die räumliche Abfrage erfüllen, und dem Satz von Merkmalen, die die SQL-Abfrage erfüllen, beantwortet. Die Gesamtzahl der Ergebnisse kann auf eine vorbestimmte Anzahl begrenzt sein oder ausgedünnt werden (z. B. 100, 500 oder 1.000). Eine weitere Anforderung fragt nach dem Merkmalsinhalt. Die Antwort auf diese Anforderung kann einen Link für das Fenster eines gegebenen Merkmals zurückgeben. Der Speicher für strukturierte Daten kann stets abgefragt werden, um die Details dieses Merkmals abzurufen.
Die Server können auch auf Aktualisierungsaufrufe reagieren. Zum Beispiel kann es eine Anforderung geben, alle Merkmale für die Tabellen neu zu laden und den räumlichen Index neu zu erstellen. Ebenso kann es eine Anforderung geben, alle Merkmale hinzuzufügen oder zu löschen. Im letzteren Fall können die Merkmale nicht wirklich aus dem Index gelöscht werden, sondern nur als gelöscht markiert und bei Abfragen nicht zurückgegeben werden. Der Grund hierfür liegt darin, dass das Löschen eines Merkmals aufwändig sein kann, denn es muss aus jedem Eintrag entfernt werden, in dem es im Index erscheint. Eine weitere Anforderung an die Back Office-Server kann in der Eliminierung des Cache mit Berechtigungsangaben für eine gegebene Tabelle bestehen. Der Cache kann als Antwort auf Genehmigungsaktualisierungen ungültig gemacht werden
Alle Datenänderungen können über einen einzigen Server, zum Beispiel den Server 102 von 1A erfolgen. Die Back Office-Server wie die Computer 106 in Cluster 107 können nur Lesezugang zum Datenspeicher haben. Zum Beispiel gibt es zwei Fälle, in denen der Speicher gelesen wird: (1) wenn der Server startet, liest er alle Merkmale und baut den räumlichen Index auf, und (2) wenn der Back Office-Server eine Anforderung vom Server mit Änderungsverantwortung zum Neuladen einer gegebenen Tabelle erhält. Der zur Durchführung der Änderungen konfigurierte Server ist verantwortlich für das Schreiben neuer Merkmale in den räumlichen Speicher. Merkmale können für die folgenden Fälle hinzugefügt werden: (1) wenn eine neue Datei importiert wird und geographische Merkmale enthält, und (2) eine vorhandene Datei geändert wird und geographische Merkmale enthält. In beiden dieser Fälle wird der Back Office-Server benachrichtigt und gebeten, die notwendigen Aktualisierungen an seinem Index vorzunehmen.
Die Back Office-Server wie jene vom Cluster 107 von 1A können geshardet und repliziert werden. Zum Beispiel kann jeder Shard für eine Teilmenge von Schichten (Tabellen) verantwortlich sein. Die Back Office-Server können mit zwei Datenzentren implementiert werden. In eine Alternative verkörpert ein erster Server einen ersten Shard und ein zweiter Server verkörpert einen zweiten Shard. Hier wird Verkehr von globalen Servern zu bestimmten Servern in den einzelnen Datenzentren geleitet. Die globalen Server leiten den Verkehr bevorzugt zum Datenzentrum, dass sich dem Standort des Endbenutzers am nächsten befindet. Dies kann anhand der IP-Adresse der Benutzer, die über einen Browser auf die Karte zugreifen, erfolgen.
Die Anzahl an Shards kann erhöht werden, um mehr Tabellen behandeln zu können. Eine bereichsbasierte Sharding-Funktion kann N Shards erstellen, von denen jeder einen Bereich von Tabellennummern behandelt. Wenn es zum Beispiel 5 Shards gibt, kann die Einrichtung nach Schichten organisiert wein, zum Beispiel: Shard 0 '^ft:. *[0–1] ' Shard 1 '^ft:. *[2–3]' Shard 2' '^ft:. *[4–5]' Shard 3 '^ft:. *[6–7]' Shard 4 '^ft:. *[8–9]'. Hier beginnen Schichtkennungen mit „ft” und werden von einer Tabellennummer gefolgt. Bevorzugt kann jeder Shard Daten in einer Größenordnung von 20 Millionen Punkten oder mehr bewältigen.
Die genannten Architekturen und Alternativen bieten eine robuste Umgebung für die Zusammenarbeit. Benutzer können Datensätze aus entfernten Standorten hochladen und auf sie zugreifen, die Daten gemeinsam nutzen und in Echtzeit zusammenarbeiten. Es sind unterschiedliche Dateitypen (z. B. CSV- oder KML-Dateien) oder Strukturen (z. B. Tabellenkalkulationsformate) zulässig. Jeder Benutzer kann große Dateien in einer Größenordnung von 100 MB, 250 MB oder mehr hochladen.
Die Daten werden auf der Serverseite bevorzugt in Echtzeit verarbeitet, wodurch Benutzer die Daten auf einer Karte oder in einem Diagramm anzeigen können, sobald sie hochgeladen sind. Spalten von Daten mit Standortinformationen können automatisch interpretiert werden, und ein Benutzer kann sie bei Bedarf direkt auf einer Karte anpassen. Mit Filtern und aggregierten Tools können selektivere Visualisierungen erzeugt werden. Zum Beispiel können Tabellen mit Daten über Radwege anhand der Länge und/oder des Standorts der Radwege gefiltert werden.
Als Teil des kollaborativen Prozesses kann anderen Benutzern Zugang zum Anzeigen, Beitragen oder Bearbeiten von Daten gegeben werden. In einem Beispiel werden die E-Mail-Adressen von Benutzern, denen Zugang gewährt wird, in das System eingegeben. Zugang kann zu allen Daten oder zu einer Teilmenge davon, wie bestimmten Spalten (z. B. Radwegbewertung, Name des Radwegs, Anstieg oder Gefälle usw.) gewährt werden. Eine verknüpfte Tabelle kann ihre eigenen Freigabeberechtigungen haben, die die aktuellen Datenwerte des Erstellers zeigen.
In einem weiteren Beispiel können Tabellen zusammengeführt werden, wenn zwei oder mehr Tabellen Informationen über die gleichen Einheiten oder Elemente haben, um alle Informationen an einer Stelle sehen zu können. In diesem Fall zeigt die zusammengeführte Tabelle die letzten aktualisierten Informationen, wenn eine Datentabelle aktualisiert wird. In diesen Szenarios können mehrere Benutzer die Daten anzeigen und kommentieren. Die Kommentare der Benutzer und eventuelle Änderungen der Daten im Laufe der Zeit können über Diskussions-Threads angezeigt werden.
Wenn Daten importiert oder anderweitig ins System hochgeladen werden, kann der die Daten hochladen der Benutzer Zurechnung für die Daten angeben. In einem Beispiel wird die Zurechnung sogar eingegeben, wenn die Daten in anderen Tabellen zusammengeführt werden. Weiterhin können Karten oder Diagramme von Daten in eine Webseite oder einen Blog-Post eingebettet werden. Eingebettete Karten oder Diagramme werden bevorzugt so konfiguriert, dass sie stets die neuesten Datenwerte für die Information anzeigen.
Obwohl die Erfindung hierin mit Bezug auf bestimmte Ausführungsformen beschrieben wurde, versteht sich, dass diese Ausführungsformen lediglich die Grundsätze und Anwendungen der vorliegenden Erfindung darstellen. Es versteht sich daher, dass zahlreiche Modifizierungen an den darstellenden Ausführungsformen vorgenommen werden können, und dass andere Anordnungen konzipiert werden können, ohne vom Erfindungsgedanken und Umfang der vorliegenden Erfindung, wie durch die hinzugefügten Ansprüche definiert, abzuweichen. Außerdem können verschiedene Prozesse gemäß Aspekten der Erfindung in einer anderen Reihenfolge oder gleichzeitig ausgeführt werden, sofern dies hierin nicht ausdrücklich anderweitig erklärt wurde.
INDUSTRIELLE ANWENDBARKEIT
Die vorliegende Erfindung erfreut sich einer breiten industriellen Anwendbarkeit, darunter unter anderem für die Datenverwaltung und kollaborative Anwendungen, zum Beispiel für die Behandlung von räumlichen und strukturierten Abfragen in großen Datenbanken.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 12/796142 [0001]

Zitierte Nicht-Patentliteratur

Artikel von Chang et. al., „Bigtable: A Structured Storage System for Structured Data”, OSDI S. 205–218, 2006 [0036]

Claims

System zur Behandlung von Benutzerabfragen und zur Durchführung von Datenverwaltung, umfassend: Mittel zum Speichern von mit Benutzerabfragen verbundenen Daten; und ein logisch mit dem Speichermittel gekoppeltes Prozessorgerät, das betrieben werden kann zum: Empfangen von Datensätzen von einer Vielzahl von Benutzergeräten; Speichern der einzelnen Datensätze als mit einem jeweiligen Benutzer verbundene Tabelle; Generieren einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile einer gegebenen einen aus der Gruppe von Tabellen darstellt; Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; Beantworten einer oder mehrerer aus der Vielzahl von Benutzerabfragen durch Erzeugen einer Visualisierung von ausgewählten Daten für die Anzeige auf einem oder mehreren der Benutzergeräte, wobei die Visualisierung anhand von in der zusammengesetzten Tabelle vorgefundenen Datentypen und den für die einzelnen Visualisierungen erforderlichen Datentypen bestimmt wird; und Einfügen von geographischen Merkmalen der einzelnen Datensätze in einen räumlichen Index.
System nach Anspruch 1, worin das Prozessorgerät ein Dispatcher-Modul zum Umwandeln der Benutzerabfragen in eine allgemeine Darstellung, ein Abfrageverarbeitungsmodul zum Erstellen eines Abfrageplans, und ein Backend-Modul zum Kommunizieren mit einem Satz von entfernten Computern für das Speichern und Verwalten der Datensätze und der zusammengesetzten Tabelle.
System nach Anspruch 1, worin der räumliche Index für die dynamische Modifizierung durch kollaborative Benutzer konfiguriert wird, sodass Merkmale zu dem räumlichen Index hinzugefügt, darin gelöscht oder aktualisiert werden können.
System nach Anspruch 3, worin der räumliche Index eine raumfüllende Kurve verwendet, um Punkte auf der Erdoberfläche in einer eindimensionalen Kurve abzubilden.
System nach Anspruch 3, worin das Prozessorgerät weiterhin betriebsfähig zum Ausdünnen des räumlichen Index zur Reduzierung einer Anzahl der in einer gegebenen Kartenkachel sichtbaren Merkmale auf einen Satz von Merkmalen, der nicht größer als eine vorbestimmte Merkmalsmenge ist.
System nach Anspruch 5, worin die Visualisierung den Merkmalssatz des ausgedünnten räumlichen Index umfasst und worin der Merkmalssatz unter den Antworten auf verschiedene Benutzerabfragen übereinstimmend ist.
Datenverwaltungssystem, umfassend: Mittel zum Speichern von mit Benutzerabfragen verbundenen Daten; und ein logisch mit dem Speichermittel gekoppeltes Prozessorgerät, das betrieben werden kann zum: Generieren einer zusammengesetzten Tabelle aus einer Gruppe von Tabellen, die mit den jeweiligen Benutzern verbunden sind, wobei die zusammengesetzte Tabelle alle Zeilen aus jeder Tabelle der Gruppe umfasst und jeder Eintrag der zusammengesetzten Tabelle eine Zeile einer gegebenen einen aus der Gruppe von Tabellen darstellt; Empfangen einer Vielzahl von Benutzerabfragen von einem oder mehreren der Benutzergeräte; und Beantworten von mindestens einer der Benutzerabfragen durch Ausführen einer räumlichen Abfrage zum Erhalt eines Ergebnisses einer räumlichen Abfrage, Ausführen einer strukturierten Abfrage zum Erhalt eines Ergebnisses einer strukturierten Abfrage, Bilden der Schnittmenge aus den Ergebnissen der räumlichen und der strukturierten Abfrage, und Senden der Schnittmengenergebnisse an mindestens eines der Benutzergeräte zur Anzeige.