Opération de traitement par lots ou opération Point-In-Polygon transactionnelle

Le choix entre une opération de traitement par lots et une opération point-in-polygon transactionnelle est essentiellement fonction de la situation : soit vous disposez déjà de toutes vos données de point et de géométrie, soit vos données de point et de géométrie parviennent au stage une à la fois, dans un scénario en temps réel. Si votre application comporte des points originaires de l'exécution (par exemple, l'emplacement d'une police d'assurance générée par une requête client) et que seules les données de polygone existent, elle est dite transactionnelle. En revanche, un cas d'application de traitement par lots dispose déjà de données de point et de polygone conservées dans des tables. Le module Location Intelligence comporte deux stages pour résoudre les cas d'application point-in-polygon : Query Spatial Data et Centrus Point In Polygon (Legacy Point In Polygon). Lors d'une application de traitement par lots ou d'une application point-in-polygon transactionnelle, chaque stage présente des différences en termes de performances. Pour plus d'informations sur les stages Query Spatial Data et Legacy Point In Polygon, reportez-vous à la section :

Pour les cas d'application point-in-polygon transactionnelle, il est préférable d'utiliser le stage Centrus Point In Polygon au stage Query Spatial Data. Le stage Point In Polygon offre de meilleures performances en cas de lecture de données en temps réel au sein du stage. Tandis que les performances du stage Query Spatial Data dépassent celles du stage Centrus Point en termes de traitement par lots et d'évolutivité. Query Spatial Data offre davantage de flexibilité en ce qui concerne le lieu de vie des données de point et de polygone et la table sur laquelle vous pouvez effectuer des itérations. Si vous connaissez les caractéristiques de vos données (y compris la complexité des polygones et le nombre de points et de polygones), vous pouvez structurer votre flux pour obtenir des performances optimales.

Pour des exemples montrant comment créer un flux de traitement par lots Query Spatial Data et un flux Point in Polygon transactionnel, reportez-vous à la section :

Quel format de données pouvez-vous utiliser ? Le type et le format de vos données vont également déterminer l'opération à utiliser dans Spectrum. L'opération Centrus Point in Polygon prend uniquement en charge le format GSB. Si vous effectuez une opération point-in-polygon transactionnelle, si vous avez besoin de performances et si vous pouvez convertir vos données au format GSB, l'opération Centrus Point in Polygon est la méthode la plus performante et la plus rapide. Il est recommandé de convertir vos données au format GSB uniquement si cela est nécessaire pour des raisons de performances. Il existe d'autres différences susceptibles d'affecter vos besoins. Par exemple, les fichiers TAB prennent en charge plusieurs langues et un plus grand nombre de systèmes de coordonnées. Tandis que GSB est en anglais uniquement et prend en charge un plus petit nombre de systèmes de coordonnées.

Si vous pensez que l'opération Centrus Point in Polygon va améliorer votre solution et que le format de vos données est autre que GSB, un utilitaire, inclus dans Spectrum, permet de transformer vos données existantes au format GSB. Spatial Import est un utilitaire de ligne de commande Windows utilisé pour convertir des fichiers SHP, TAB. MIF/MID et DBF en un fichier de base de données Centrus (GSB). Il peut être téléchargé depuis la section Spectrum Spatial de la page d'accueil, sous Spatial Import dans l'onglet Utilitaires. Une fois que vous avez téléchargé le fichier zip, vous avez la possibilité d'utiliser la version 32 bits (x86) ou 64 bits (x64). Reportez-vous à la section Utilitaire de conversion du module Location Intelligence pour de plus amples informations sur l'utilisation de cet utilitaire.

Remarque : Si, pour quelque raison que ce soit, vous ne souhaitez pas convertir vos données au format GSB (par exemple, à cause du risque de duplication des données), vous pouvez utiliser le stage Query Spatial Data pour les cas d'application transactionnelle et accéder à vos données tabulaires stockées dans des fichiers TAB natifs ou dans des sources de base de données spatiales.

Pourquoi utiliser le stage Query Spatial Data pour un traitement par lots ? Comme indiqué précédemment, le stage Query Spatial Data offre davantage de flexibilité et plus d'options de performances. Prenons les deux flux de scénario de traitement par lots suivants (supposons que les polygones et les points soient les mêmes) :

Read Spatial Data lit une liste de points d'un fichier TAB (millions de points).

Spatial Calculator crée des valeurs de colonne de longitude et de latitude à partir des points.

Le stage Centrus Point In Polygon interroge une grand ensemble de polygones (GSB).
Read Spatial Data lit un grand ensemble de polygones d'un fichier TAB.

Query Spatial Data utilise un filtre Contains sur une table de points (millions de points).

Si l'on observe ces deux scénarios, avec une taille de pool 1 et 1 exécution, le stage Centrus Point In Polygon (scénario 1) est plus rapide que le stage Query Spatial Data (scénario 2). À mesure que les instances de mise en pool et les exécutions augmentent, les performances du scénario 1 restent cohérentes, tandis que les performances du scénario 2 évoluent de manière efficace. À 4 instances de mise en pool et 4 exécutions, Query Spatial Data est plus rapide que le stage Centrus Point In Polygon. Pour un traitement par lots, où vous disposez de tous vos polygones et de tous vos points en amont, et où vous souhaitez traiter toutes les géométries, le deuxième scénario avec le stage Query Spatial Data est beaucoup plus efficace. Dans les cas où les données de polygone ne changent pas et où les points arrivent un à la fois (à savoir, un utilisateur saisit une adresse, elle est géocodée, puis le secteur commercial de l'adresse est déterminé), le premier scénario avec le stage Centrus Point In Polygon constitue la solution la plus rapide.

Existe-t-il d'autres considérations sur les performances à prendre en compte ? Lorsque vous utilisez Query Spatial Data, vous devez prendre en compte le nombre de points et de polygones en cours de traitement. Lorsque vous avez plus de polygones que de points, envisagez des itérations sur les points (lecture d'un point à la fois à l'aide de Read Spatial Data et recherche sur la table de polygones à l'aide de Query Spatial Data). Lorsque vous avez plus de points que de polygones, envisagez des itérations sur les polygones (lecture d'un polygone à la fois à l'aide de Read Spatial Data et recherche sur la table de points à l'aide de Query Spatial Data).

Où se trouvent vos données ? Il est important de savoir où se trouvent vos données et le type de données dont vous allez disposer pour votre solution. Par exemple, le fait d'avoir des fichiers TAB sur le système de fichiers ou des données dans un DBMS modifie les performances de votre opération. Spectrum délègue le traitement de certaines opérations (jointures spatiales) à la base de données (par exemple, Oracle et SQL Server), ce qui améliore vos performances. Par exemple, des opérations comme celle-ci :

SELECT a.id, b.id FROM flood_plane a, customers b WHERE MI_Contains(a.geom, b.geom)

Remarque : Si vous souhaitez exécuter la même opération dans laquelle les deux tables sont des fichiers TAB natifs (pas des données dans une base de données), vous obtiendrez de meilleures performances si vous lisez les enregistrements un à la fois à partir de l'une des tables et si vous effectuez la requête sur l'autre table à l'aide de Query Spatial Data.

Vos données sont-elles statiques ou changent-elles ? Si vous savez que (tout ou partie de) vos données ne changent pas et que vous utilisez l'opération Query Spatial Data, il existe une option de configuration lors de la création de vos ressources nommées qui peut considérablement améliorer les performances. Dans Spectrum, on l'appelle la volatilité. Par défaut, la volatilité de toutes les ressources est définie sur true. Cela signifie que Spectrum part du principe que toutes les données peuvent changer à tout moment et qu'il doit vérifier les données chaque fois qu'il y a accès, pour déterminer si elles ont changé et décider s'il est nécessaire de charger les nouvelles données.

Comment la volatilité affecte-t-elle les opérations point-in-polygon ?. Si la volatilité est définie sur true, et même si la source de données n'a pas changé, le simple fait de vérifier la ressource a un impact négatif sur les performances. Si vous savez que vos données ne vont pas changer et que vous avez besoin d'un système performant, désactivez la volatilité. Si les performances sont un problème, et que vous savez qu'une partie de vos données vont changer (par exemple, des listes de clients ou des points de sondage), mais que d'autres ne vont pas changer (par exemple, des parcelles, des terrains ou des secteurs commerciaux), assurez-vous que la volatilité est désactivée pour vos données statiques. Cela peut considérablement augmenter vos performances générales. Pour plus d'informations sur la volatilité et sur la façon de modifier ce paramètre pour les ressources, reportez-vous à la section Volatilité de la source de données.