Le blog francophone consacré
aux technologies Esri

Les règles attributaires, une révolution pour les utilisateurs ArcGIS !


Pour quelqu'un qui, comme moi, utilise au quotidien depuis 25 ans les solutions Esri, il y a des évolutions technologiques que l'on apprécie plus que d'autres. C'est clairement le cas pour la notion de règles attributaires tant elle répond aux problématiques récurrentes d'amélioration de la qualité des données et aux besoins d'automatisation de certaines mises à jour sur ces données. Qui n'a pas rêvé d'avoir sur ses classes d'entités (ou tables), des attributs avec des formules de calcul dynamique "à la Excel" ?

Depuis leur apparition dans les Géodatabases Enterprise avec ArcGIS Pro 2.2, les règles attributaires ont suscité énormément d'enthousiasme. Disponibles désormais dans les Géodatabases Fichier, leur usage va pouvoir s'étendre à tous les utilisateurs d'ArcGIS. Il est donc temps de présenter cette nouvelle notion.
   
   
Un bref historique

Par le passé, Esri a proposé différentes évolutions pour améliorer la productivité et la qualité des opérations de saisie (ou mise à jour) des données dans votre SIG. La notion de "valeur par défaut" a fourni un moyen d'accélérer la collecte de données. Ensuite, la notion de "domaines" dans les classes d'entités et les tables de vos Géodatabases ont permis de réduire les erreurs ou les incohérences de saisie grâce aux listes de valeurs prédéfinies ou aux plages de valeurs. La notion de "sous-types" a complété ces notions précédentes pour permettre d'associer des valeurs par défaut et des domaines différents en fonction de la catégorie (sous-type) à laquelle appartient l'entité. 

Un peu plus tard, la notion de "modèles de mise à jour" a considérablement simplifié l’expérience de saisie et de mise à jour, en permettant aux utilisateurs de définir des modèles d'entités prédéfinis (souvent basés sur les sous-types) et de pour créer ainsi des entités avec des valeurs d'attribut prédéfinies. 

On rappellera aussi que des outils comme "Attribute Assistant" et "Data Reviewer" contribue aujourd'hui encore à faciliter les opérations de mise à jour de données dans de nombreuses organisations en permettant aux utilisateurs de créer des règles renseignant automatiquement les attributs et générer des erreurs pour les saisies qui ne seraient pas non valides. Cela a permis aux utilisateurs d'être beaucoup plus productifs et d'améliorer la qualité de leurs données. Cependant, les fonctionnalités de Data Reviewer et d'Attribut Assistant peuvent montrer des limites dans le sens où ces règles ne sont appliquées que lors de la modification et, surtout, uniquement par les applications bureautiques ArcMap ou ArcGIS Pro. Les modifications réalisées via d'autres applications telles que des applications web ou mobiles telles qu'ArcGIS Collector peuvent potentiellement ne pas honorer ces contraintes, et ainsi créer une situation où des données de mauvaise qualité peuvent toujours figurer dans la Géodatabase.
  
Esri a donc décidé d’aller plus loin dans cette logique d'associer des règles de calcul ou de validation sur les attributs. L'idée a été de développer un mécanisme évaluant ces règles au niveau le plus bas dans le processus de mise à jour, c'est à dire: dans la Géodatabase.
 
 
 
Les règles attributaires

Les règles attributaires sont des scripts qu'un utilisateur peut définir sur des jeux de données et qui se déclenchent automatiquement lors de modifications d'une couche ou d'une table. Elles peuvent être utilisées soit pour contraindre des valeurs autorisées sur les champs (y compris sur la géométrie) ou simplement exécuter une expression pour calculer des valeurs à partir d'autres champs.
      
Elles peuvent également être exécutées à la demande pour calculer des valeurs ou générer des erreurs pour les entités qui ne respectent pas les règles (nouveauté d'ArcGIS Pro 2.3 / ArcGIS Enterprise 10.7). Cela peut être fait après la phase de mise à jour, par exemple dans le cadre d'un script exécuté chaque nuit.

Les règles attributaires sont conçues pour s'exécuter dans l'ensemble de l'écosystème ArcGIS. Cela est rendu possible par l'utilisation du langage de script Arcade. Le langage Arcade permet le calcul d'expressions pour des étiquetages évolués, des contenus pour vos fenêtres contextuelles, des valeurs pour vos rendus cartographiques, des paramètres dynamique pour l'affichage et, désormais, des règles d'attributs avancées. Arcade fonctionne sur tous les environnements: poste bureautiques, serveurs, navigateurs web, appareils mobiles, etc. C'est un langage qui évolue et s'enrichit continuellement (en savoir plus sur Arcade).

Depuis la version 2.3, il est possible d'utiliser les entités (géométrie et attributs) d'une autre couche de la carte ou de la Géodatabase dans les expressions Arcade. Il est également possible, depuis l'expression Arcade, de mettre à jour les entités d'une autre couche. Ceci permet des comportements très avancés pour vos calculs ou vos tests de validation


Les règles de calcul

Les règles de calcul permettent d'appliquer une expression Arcade à un attribut pour calculer des valeurs qui peuvent être issues d'autres attributs de l'entité. Par exemple, je souhaite ajouter la date actuelle de la plantation d'un arbre et automatiquement, dans un second attribut, la date de première taille de ce dernier en fonction de la date plantation.

L'expression Arcade de la règle peut également utiliser les valeurs de tout ou partie des entités de la couche pour réaliser un calcul de statistique (une somme des valeurs par exemple). Ainsi, si vous ajouter une nouvelle entreprise avec le nombre d'emplois correspondant, il sera possible de calculer automatiquement le ratio que ce nombre d'emploi représente par rapport à la totalité des entreprises de votre couche.

Plus puissant encore, votre règle peut utiliser des entités et des attributs venant d'autres classes d'entités de la Géodatabase. Par exemple, à chaque ajout d'une école dans votre couche, vous souhaitez renseigner le nombre d'élèves potentiels à partir des informations démographiques des IRIS situés à 1 km autour de cette école.

Ci-dessous quelques exemples de règle de calcul:

     
   
     
  
Pour les Géodatabases Enterprise, les règles de calcul peuvent être exécutées immédiatement (lors de l'ajout, la mise à jour ou la suppression des entités) ou "par lots" de manière différée. Cette seconde option permet de programmer l'exécution de la règle sur l'ensemble du jeu de données. Elle  est notamment intéressante pour des règles intensives en calculs (géométriques, statistiques, ...) sur chaque entités. 
  
  
Les règles de contrainte

Les règles de contrainte permettent de forcer le respect de certaines conditions lors de la modification des entités d'une couche (ajout, mise à jour, suppression). L'expression Arcade alors utilisée renvoie une valeur booléenne (true ou false) indiquant si la condition est respectée. Si ce n'est pas le cas, un message d'erreur (que vous définissez) est retourné à l'utilisateur et la modification de l'entités n'est pas acceptée. Les règles de contraintes constituent un moyen puissant pour assurer la qualité des données saisies. Par exemple, vous pouvez ajouter une règle de contrainte vérifiant que les équipements d'un réseau d'eau saisies dans votre couche sont bien connectés géométriquement aux conduites de votre réseau. Autre exemple, vous pouvez valider que les bâtiments de votre couche sont bien entièrement inclus dans les entités surfaciques de la couche des parcelles.

Exemple de règle de contrainte:


   
Règles de validation

Les règle de validation permettent de signaler les entités ne respectant pas certaines exigences, sans pour autant bloquer l'opération de modification de ces entités si elles ne les respectent pas. Accessibles pour le moment uniquement dans les Géodatabases Enterprise, elles mettent en évidence les entités afin de les corriger ultérieurement. Ce type de règle est également intéressant pour analyser la qualité d'un jeu de données existant et définir, dans un second temps, des règles attributaires strictes (règles de calcul ou règles de contrainte).

Les règles de validation sont obligatoirement évaluées "par lots" permettant ainsi de valider la totalité d'un jeu de données. Les entités en erreurs sont ajoutées dans les couches d'erreurs de la Géodatabase Enterprise.

Exemple de règle de validation:

     
 
Important

Avant de commencer à créer des règles attributaires dans vos Géodatabases, il est important de noter que les classes d'entités possédant des règles attributaires ne peuvent pas être utilisées dans ArcMap ou dans les versions antérieures à ArcGIS Pro 2.1.

La création de règles "par lots" (calcul ou validation) ajoutera un champ ValidationStatus qui sera utilisé pour suivre l'état de l'entité. Les règles "par lots" ne sont disponibles que pour l'évaluation côté serveur avec ArcGIS Enterprise 10.7 et ne peuvent pas être publiées ni évaluées avec des versions antérieures.


Pour démarrer avec les règles attributaires

Pour en savoir plus sur le fonctionnement des règles attributaires, je vous recommande la lecture de cette page de l'aide en ligne d'ArcGIS Pro. Il est également important de bien maîtriser le langage d'expression Arcade dont vous trouverez la documentation ici.
  

Partager cet article:

Rejoindre la discussion

    Les commentaires à propos de cet article:

4 comments :

x. lhomme a dit…

Bonjour
Techniquement, quel est le composant qui valide et exécute la règle ?
-est ce ArcGIS Pro / ArcGIS Server avant l'import dans l'Enterprise Geodatabase? Dans ce cas la que ce passe-t-il si il y a une modification d'attribut via un outil externe comme PgAdmin.

-ou est-ce appelé via un trigger de la base de données qui déclenche une fonction spécifique? Et du coup où se trouve le moteur ? une fonction de la lib ST_Geometry ?

Cordialement

Anonyme a dit…

Un mécanisme de contraintes et de programmation côté base de données, ça rappelle étrangement quelque chose... On réinvente la norme SQL mais avec un langage propriétaire ? En 2019 ? o_O

Gaëtan Lavenu a dit…

Bonjour,

J'ai l'impression que vous n'avez pas bien compris le mécanisme proposé par Esri avec ces règles et le langage Arcade. Je vous recommande de lire la documentation pour découvrir la puissance des expressions Arcade et vous constaterez que cela n'a rien à voir avec le potentiel fonctionnel et la portabilité cross-SGBD du SQL que la plateforme ArcGIS utilise largement et depuis bien plus longtemps que la plupart des SIG du marché. Clairement, SQL ne pourrait être utilisé dans le contexte des règles attributaires puisque ces expressions doivent pouvoir s'exécuter sur tout type d'environnement client et serveur que l'on soit dans des application desktop, mobile et web, et que l'on soit connecté ou pas. C'est ça à terme le périmètre des règles attributaires ArcGIS. Oui en 2019, des innovations sur la maintenance et le traitement des données spatiales et non-spatiales ça existe, et pour le coup vous avez raison c'est une technologie propriétaire.

Gaëtan Lavenu a dit…

Bonjour Xavier,

Pour essayer de détailler un peu le mécanisme...

La définition des règles attributaires sont stockées dans une table système de la Géodatabase (GDB_Items dans le champs "documentation". Pour les règles de calcul ou les règles de contrainte dont l'évaluation est paramétrée en "immédiate" alors c'est l'application cliente qui exécute la règle sauf si l'option "Exclude from application evaluation" a été choisie lors de la définition de la règle. Pour les règles dont l'évaluation est paramétrée "par lot" alors c'est le service d'évaluation d'ArcGIS Enterprise qui réalise la tâche.