Prise en charge de l’agrégation spatiale

L'analyse visuelle de données volumineuses est prise en charge pour les tables de points SQL Server. Vous pouvez effectuer cette analyse sur les colonnes XY (où la longitude et la latitude et/ou les valeurs XY sont stockées sous forme de valeurs scalaires distinctes) et sur les colonnes de géométrie (où les géométries de points sont stockées à l’aide du type Géométrie ou Géographie SQL Server). Spectrum Spatial prend en charge l’agrégation spatiale (également connue sous le nom de mise en cluster spatiale) à l’aide d’un ID geohash pour que les tables prennent en charge l'échelle, ce qui offre une meilleure visualisation de grandes quantités de données. Cela vous permet, par exemple, d'agréger une somme de ventes ou un nombre total de points que vous souhaitez représenter sur une carte. Comme les données de point en cluster sont accessibles par le client sous forme de données vectorielles (au format GeoJSON), l’application client peut appliquer différents styles aux données (y compris des plages de couleurs différentes et des symboles gradués) et peut également présenter les données sous forme de cartes thermiques côté client.

L'option Activer l'agrégation spatiale est activée uniquement lorsque l'agrégation spatiale est applicable. Dans le cas de tables XY, l'option Activer l'agrégation spatiale est activée uniquement lorsqu'une connexion à une base de données est sélectionnée et que les colonnes X et Y sont déjà définies dans le catalogue de cartes.

Remarque : En cas de modification de tables XY, l'option Activer l'agrégation spatiale reste désactivée lorsque vous passez à une autre table lorsque vous effectuez des modifications. Ceci est applicable dans le cas de tables XY uniquement. Pour la table basée sur SQL, l'option Activer l'agrégation spatiale reste activée, même lorsque vous passez à une autre table basée sur des points.

Compréhension de geohash

Geohash est une technique de mise en grille qui divise le monde de manière récursive en cellules de grille et assigne à chaque grille une valeur d’ID unique. Il existe 12 longueurs de geohash. La première longueur divise le monde en 32 cellules de grille (8 x 4 cellules). La longueur suivante divise les cellules de grille en encore 32 (4 x 8 cellules), ce qui donne 1 024 cellules couvrant le monde, etc.

Compréhension de l’échelle

Lorsqu’une table est définie pour prendre en charge l'échelle, chaque point de la table reçoit un ID geohash lui permettant d’être agrégé dans des cellules de longueur supérieure. Lorsque les applications client exécutent des requêtes de fonctions sur une table prenant en charge l'échelle, elles sont supposées passer dans l'échelle qu'elles souhaitent utiliser dans le cadre de l'expression MI SQL envoyée. La valeur de l’échelle est envoyée comme valeur « mètres par pixel », également appelée résolution dans les bibliothèques de mappage telles qu'Openlayers. La résolution est une valeur qui est généralement accessible aux bibliothèques de mappage côté client.

Côté serveur, Spectrum Spatial sélectionne alors la longueur de geohash appropriée à utiliser pour agréger les données. Le tableau ci-dessous montre la manière dont la longueur de geohash est sélectionnée en fonction de la valeur mètres par pixel saisie.

Longueur de geohash sélectionnée pour l’agrégation	Où mètres par pixel est
2	>= 19 000
3	>= 2 400 et < 19 000
4	>= 600 et < 2 400
5	>= 80 et < 600
6	>= 10 et < 80
7	>= 2 et < 10
8	>= 0,3 et < 2
9	>= 0,06 et < 0,3
10	< 0,06

Par exemple, si la résolution de la carte du client est de 600 mètres par pixel ou plus (et moins de 2 400), la longueur de geohash 4 est sélectionnée comme longueur d’agrégation des données. Cette relation garantit qu’un nombre approprié de fonctions agrégées est renvoyé pour permettre d'afficher une carte suffisamment détaillée dans le client sous forme de couche vectorielle. Le nombre exact de fonctions agrégées renvoyées varie en fonction de la taille de la carte sur le périphérique client ainsi que de la densité et de la distribution des fonctions de la carte en cours d'agrégation.

Limite de fonctions

Pour les requêtes prenant le plus en charge l'échelle sur une carte côté client type de 1 024 pixels de large et de 780 pixels de haut, la réponse est inférieure à 1 000 fonctions. Cependant, pour certaines résolutions, la requête peut renvoyer plus de 1 000 fonctions. Si votre carte client est supérieure à 1 024 pixels, il existe davantage de chances que plus de 1 000 fonctions soient renvoyées. Il est conseillé d'augmenter la limite de fonctions dans Spatial Manager sous Services > Fonctions à une valeur d’environ 5 000 à 10 000, pour garantir que les réponses supérieures à 1 000 soient renvoyées sans erreur.

Ajout d’un ID geohash à une table

Un ID geohash doit être ajouté manuellement à une table existante afin qu'elle prenne en charge l’échelle et par conséquent qu'elle soit disponible pour l’agrégation spatiale. Pour obtenir des instructions détaillées, reportez-vous à la section Ajout d’un index geohash à une table.

Activation des tables pour l'agrégation spatiale

L'agrégation spatiale peut être activée à l’aide de Spatial Manager lors de la création ou de la modification d’une table nommée (pour plus d’informations, reportez-vous aux sections Création d'une table et Création d'une table XY). Vous pouvez voir si l'agrégation spatiale d'une table est activée en affichant la page de détails de la table dans Spatial Manager. L’onglet Infos sur la ressource affiche la colonne geohash et le niveau de précision, tandis que l'onglet Colonnes affiche la colonne geohash ainsi que ses attributs (tels que son type et si elle est indexée, en lecture seule ou annulable).

Important : Si l’agrégation spatiale est activée pour une table, le nombre maximal de fonctions doit être augmenté par rapport à la valeur par défaut de 1 000 à 10 000 enregistrements. Cela est dû au fait que, dans certains cas, plus de 1 000 fonctions agrégées peuvent être renvoyées suivant le niveau de zoom, l’étendue spatiale de la carte du client et la distribution spatiale des fonctions en cours d’agrégation (bien que pas plus de 2 500 enregistrements soient généralement renvoyés pour les cartes dont la carte client est de 1 024 x 780 pixels). Utilisez Spatial Manager pour régler le paramètre MaximumFeatures de Feature Service (reportez-vous à la section Gestion de la configuration du service Feature).

Requête de fonctions d’une table prenant en charge l’échelle

Utilisez MI SQL dans une application client pour demander les fonctions d'une table prenant en charge l'échelle. La mise en cluster au niveau du serveur est disponible à l’aide de la version REST de la requête Search By SQL de Feature Service. Le client peut envoyer une requête à l’aide des méthodes d’agrégation MI SQL et de la clause SCALE.

Remarque : La fonction MI_Transform n’est pas prise en charge pour les requêtes d’agrégation sur la colonne de géométrie. La projection de la table de données dans Spectrum Spatial doit correspondre à la projection de la carte du client pour l’agrégation de données de grande taille sur la carte. Sinon, projetez la réponse GeoJSON dans le client avant de l'ajouter à une couche vectorielle.

Pour plus d’informations sur la clause SCALE (y compris des exemples de requêtes) et les méthodes d’agrégation telles que MI_AggregateCentroid, reportez-vous à la section Référence au langage SQL MapInfo du Guide Spectrum Spatial.

Exemples de requêtes prenant en charge l’échelle

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

Considérations en matière de performances

Prenez en compte ces points pour optimiser les performances :

Spectrum Spatial est conçu pour déléguer la plupart du travail de traitement au DBMS au moment de l’exécution. Lors de la conception de votre système, gardez à l'esprit que les performances et l'évolutivité dépendent fortement de la puissance de traitement et de la mémoire disponible sur le serveur de base de données.
Nous vous recommandons d’utiliser les outils d’optimisation des requêtes de base de données (tels que SQL Server Tuning Advisor) pour le réglage des performances. Contactez votre administrateur de base de données pour déterminer le meilleur moyen d'exécuter de petits tests et d'affiner les index de base de données.
De meilleures performances peuvent être obtenues avec des colonnes XY plutôt qu’avec des colonnes de géométrie (où les géométries de points sont stockées à l’aide de types SQL Server Géométrie ou Géographie). Si possible, pour les tables de données volumineuses, nous vous recommandons d’utiliser des tables XY avec les index suivants : LONGITUDE, LATITUDE (ou X et Y), la colonne de clé primaire (un index en cluster), la colonne GEOHASH et toute autre colonne d’agrégation utilisée dans la requête. Votre DBA ou un Tuning Advisor peut également recommander des index supplémentaires sur une combinaison de ces colonnes.