Unterstützung für georeferenzierte Aggregierung

Die visuelle Analyse großer Daten wird für SQL Server-Punktrelation unterstützt. Sie können diese Analyse mit XY-Spalten (wobei Längengrad und Breitengrad oder XY-Werte als separate Skalarwerte gespeichert werden) und Geometry-Spalten (wobei Punkt-Geometrys als SQL Server-Type „Geometry“ oder „Geography“ gespeichert werden) durchführen. Spectrum Spatial unterstützt räumliche Aggregation (auch bekannt als räumliches Clustering) unter Verwendung einer Geohash-ID. Dadurch werden Relationen maßstabsorientiert, was eine bessere Visualisierung von großen Datenmengen ermöglicht. So können Sie beispielsweise eine Summe von Verkäufen oder eine Gesamtanzahl von Punkten aggregieren, die Sie in einer Karte darstellen möchten. Da die geclusterten Punktdaten vom Client als Vektordaten (im GeoJSON-Format) abgerufen werden, kann die Client-Anwendung verschiedene Stile auf die Daten anwenden (einschließlich abgestufter Symbole und unterschiedlicher Farbbereiche) und die Daten auch als client-seitige Heatmaps darstellen.

Die Option Räumliche Aggregation aktivieren ist nur aktiviert, wenn die räumliche Aggregation anwendbar ist. Im Fall von XY-Relationen ist diese Option nur aktiviert, wenn eine Datenbankverbindung ausgewählt ist und X- und Y-Spalten bereits im Kartenkatalog definiert sind.

Anmerkung: Wenn Sie XY-Relationen ändern, bleibt die Option Räumliche Aggregation aktivieren deaktiviert, falls Sie während der Durchführung von Änderungen zu einer anderen Relation wechseln. Dies gilt nur für XY-Relationen. Bei einer SQL-basierten Relation bleibt die Option aktiviert, auch wenn Sie zu einer anderen punktbasierten Relation wechseln.

Verstehen von Geohash

Geohash ist eine Rasterungstechnik, die die Welt rekursiv in Rasterzellen unterteilt und jeder Zelle einen eindeutigen ID-Wert zuweist. Es gibt 12 Geohash-Längen. Die erste Länge unterteilt die Welt in 32 Rasterzellen (8x4 Zellen). Die nächste Länge unterteilt die Rasterzellen in weitere 32 Zellen (4x8 Zellen), was 1024 Zellen ergibt, die die Welt abdecken, usw.

Verstehen des Maßstabs

Wenn eine Relation maßstabsorientiert ist, wurde jedem Punkt in der Relation eine Geohash-ID zugewiesen, sodass diese in Zellen mit geringerer Länge aggregiert werden können. Wenn Client-Anwendungen Feature-Anforderungen an eine maßstabsorientierte Relation senden, wird erwartet, dass sie den gewünschten Maßstab als Teil des gesendeten MI SQL-Ausdrucks übergeben. Der Wert für diesen Maßstab wird als Wert in „Meter pro Pixel“ gesendet und wird in Mapping-Bibliotheken wie OpenLayers auch „Auflösung“ genannt. Die Auflösung ist ein Wert, der normalerweise in client-seitigen Mapping-Bibliotheken jederzeit verfügbar ist.

Serverseitig wählt Spectrum Spatial dann die entsprechende Geohash-Länge aus, die zur Aggregierung der Daten verwendet wird. Die Tabelle unten zeigt, wie die Geohash-Länge auf Basis des Eingabewerts in Metern pro Pixel ausgewählt wird.
Zur Aggregation ausgewählte Geohash-Länge Mit Metern pro Pixel gleich
2 >= 19000
3 >= 2400 und < 19000
4 >= 600 und < 2400
5 >= 80 und < 600
6 >= 10 und < 80
7 >= 2 und < 10
8 >= 0,3 und < 2
9 >= 0,06 und < 0,3
10 < 0,06

Wenn die Auflösung der Karte des Clients beispielsweise 600 Meter pro Pixel oder mehr beträgt (und unter 2400 liegt), dann wird die Geohash-Länge 4 als Aggregierungslänge für die Daten ausgewählt. Diese Beziehung stellt sicher, dass eine angemessene Anzahl aggregierter Features zurückgegeben wird, damit im Client eine ausreichend detaillierte Karte als Vektor-Layer gerendert werden kann. Die genaue Anzahl aggregierter Features, die zurückgegeben werden, variiert abhängig von der Größe der Karte auf dem Client-Gerät und der Dichte und Verteilung der zu aggregierenden Features.

Feature-Begrenzung

Bei den meisten maßstabsorientierten Abfragen für eine client-seitige Karte mit einer Breite von 1.024 Pixeln und einer Höhe von 780 Pixeln enthält die Antwort weniger als 1.000 Features. Bei einigen Auflösungen kann die Abfrage jedoch mehr als 1.000 Features zurückgeben. Wenn Ihre Client-Karte höher oder breiter ist als 1.024 Pixel, besteht eine höhere Wahrscheinlichkeit, dass mehr als 1.000 Features zurückgegeben werden. Es wird empfohlen, die Feature-Begrenzung in Spatial Manager unter Services > Features auf einen Wert zwischen ungefähr 5.000 und 10.000 zu erhöhen, um sicherzustellen, dass Antworten mit über 1.000 Features ohne Fehler zurückgegeben werden.

Hinzufügen einer Geohash-ID zu einer Relation

Um eine vorhandene Relation maßstabsorientiert und damit für räumliche Aggregation verfügbar zu machen, müssen Sie ihr manuell eine Geohash-ID hinzufügen. Eine detaillierte Anleitung finden Sie unter Hinzufügen eines Geohash-Index zu einer Tabelle.

Aktivieren der räumlicher Aggregation für Relationen

Beim Erstellen oder Ändern einer benannten Tabelle kann über Spatial Manager die räumliche Aggregation aktiviert werden (weitere Informationen unter Erstellen einer Relation (benannte Tabelle) und Erstellen einer XY-Tabelle). Sie können feststellen, ob die räumliche Aggregation für eine Relation aktiviert ist, indem Sie sich in Spatial Manager die Seite der Relationsdetails ansehen. Auf der Registerkarte „Ressourceninformationen“ werden die Geohash-Spalte und der Genauigkeitsgrad angezeigt, und auf der Registerkarte „Spalten“ wird die Geohash-Spalte zusammen mit ihren Attributen (Typ, Indizierung, schreibgeschützt, Nullwerte zulässig) angezeigt.

Wichtig: Wenn für eine Relation räumliche Aggregation aktiviert ist, sollte die maximale Anzahl von Features von standardmäßigen 1.000 Datensätzen auf 10.000 Datensätze erhöht werden. Dies ist erforderlich, da in einigen Fällen abhängig von der Zoomstufe, der räumlichen Ausdehnung der Karte auf dem Client und der räumlichen Verteilung der zu aggregierenden Features mehr als 1.000 aggregierte Features zurückgegeben werden können (obwohl normalerweise bei Client-Karten mit 1.024 x 780 Pixeln nicht mehr als 2.500 Datensätze zurückgegeben werden). Verwenden Sie Spatial Manager, um die Einstellung „MaximumFeatures“ für den Feature-Dienst anzupassen (siehe Verwalten der Feature-Dienst-Konfiguration).

Abrufen von Features aus einer maßstabsorientierten Relation

Verwenden Sie MI SQL in einer Client-Anwendung, um Features aus einer maßstabsorientierten Relation abzurufen. Über die REST-Version der Abfrage „Search By SQL“ des Feature-Diensts ist Clustering auf Serverebene verfügbar. Der Client kann Abfragen über MI SQL-Aggregationsmethoden und die SCALE-Klausel stellen.
Anmerkung: Die MI_Transform-Funktion wird für aggregierende Abfragen der Geometry-Spalte nicht unterstützt. Die Projektion der Datentabelle in Spectrum Spatial sollte bei der Aggregation umfangreicher Daten auf einer Karte mit der Projektion der Clientkarte übereinstimmen. Projizieren Sie alternativ die GeoJSON-Antwort in den Client, bevor Sie sie zu einem Vektor-Layer hinzufügen.
Weitere Informationen zur SCALE-Klausel (einschließlich Beispielabfragen) und zu Aggregationsmethoden wie MI_AggregateCentroid finden Sie im Abschnitt „MapInfo SQL-Sprachreferenz“ des Spectrum Spatial-Handbuchs.

Beispiele für maßstabsorientierte Abfragen

http://152.144.226.251:8080/rest/Spatial/FeatureService/tables/features.json?
q=SELECT MI_AggregateCentroid(SP_GEOMETRY), Count(*) as feature_count FROM "/LargePoints" 
WHERE MI_EnvelopesIntersect(FromWKT('POLYGON((-8627389.58 4756566.36,-8627389.58 5196843.64,-7844674.42 5196843.64,
-7844674.42 4756566.36,-8627389.58 4756566.36 ))','EPSG:3857'), SP_GEOMETRY) SCALE 611.49622628141

Überlegungen zur Leistung

Berücksichtigen Sie folgende Punkte zum Optimieren der Leistung:

  • Spectrum Spatial wurde designt, um den Großteil der Verarbeitung zur Laufzeit an den DBMS zu delegieren. Beachten Sie bei Ihrem Systemdesign, dass Leistung und Skalierbarkeit stark vom Arbeitsspeicher und von der Verarbeitungsleistung des Datenbankservers abhängen.
  • Wir empfehlen den Einsatz von Optimierungstools für Datenbankabfragen (wie SQL Server Tuning Advisor), um die Leistung zu optimieren. Wenden Sie sich an Ihren Datenbankadministrator, um die beste Möglichkeit zu finden, kleine Tests auszuführen und die Datenbankindizes zu optimieren.
  • Sie erreichen mit XY-Spalten eine bessere Leistung als mit Geometry-Spalten (in denen Punkt-Geometrys als SQL Server-Typ „Geometry“ oder „Geography“ gespeichert werden). Wir empfehlen, bei großen Datenbankrelationen falls möglich XY-Relationen mit folgenden Indizes zu verwenden: LÄNGENGRAD, BREITENGRAD (oder X und Y), die Primärschlüsselspalte (geclusterter Index), die GEOHASH-Spalte und andere Aggregationsspalten, die in der Abfrage verwendet werden. Ihr Datenbankadministrator oder Optimierungsberater empfiehlt möglicherweise auch zusätzliche Indizes über eine Kombination dieser Spalten.