L'utilisation d'expressions conditionnelles dans votre projet de levé peut être un excellent moyen d'améliorer la précision de votre collecte de données sur le terrain. QGIS constituent un outil puissant pour améliorer la facilité d'utilisation de votre levé sur le terrain. Grâce à la flexibilité de QGIS, cet outil peut être utilisé de nombreuses façons, mais nous allons vous présenter quelques exemples pour vous aider à démarrer.
Exemple 1 - Restreindre des champs à l'aide d'expressions
Il arrive parfois que les formulaires d'enquête complexes soient encombrés ou prêtent à confusion pour les enquêteurs qui saisissent des données sur les petits écrans de leurs appareils. Une façon de simplifier vos formulaires consiste à utiliser des conditions pour n'afficher que les champs dont l'enquêteur a besoin.
Par exemple, vous réalisez peut-être une enquête immobilière qui nécessite de remplir des champs spécifiques en fonction du type de bien. Obliger l'utilisateur à faire défiler chaque section du formulaire jusqu'à ce qu'il trouve les champs nécessaires peut être source de confusion et prendre beaucoup de temps aux enquêteurs. Vous pouvez plutôt utiliser des expressions conditionnelles pour n'afficher que les champs obligatoires en fonction du type de bien faisant l'objet de l'enquête.
Commençons par un exemple de projet simple pour notre étude cadastrale. Nous disposons d'une carte de fond et d'une couche de points intitulée « survey » destinée à enregistrer les informations relatives à chaque propriété. Le tableau de la couche « survey » se présente comme suit :
| Champ d'application | Type | Description |
|---|---|---|
| fid | INT | clé_primaire |
| uuid | texte | Identifiant unique |
| géomètre | texte | Champ permettant d'enregistrer le nom d'utilisateur du géomètre |
équipe_d'enquête | texte | Enregistrer l'équipe de relevé affectée au bien immobilier |
| créé | date/heure | Horodatage de la date de création de l'enregistrement |
| dernière mise à jour | date/heure | Horodatage de la dernière mise à jour de la fonctionnalité |
| numéro de rue | INT | Numéro de rue |
| nom_de_rue | texte | Nom de la rue |
| code postal | texte | Code postal |
| étages | INT | Nombre d'étages |
| type | texte | Type de bien immobilier (commercial ou résidentiel) |
| nom_du_bus | texte | Nom de l'entreprise |
| type_de_bus | texte | Type d'entreprise |
| type_de_résidence | texte | Type de maison (maison de plain-pied, maison mitoyenne, cottage, etc.) |
| res_parking | texte | Type de stationnement disponible à la maison (dans la rue, dans l'allée, dans le garage) |
| res_occupé | Booléen | La résidence est-elle occupée ? |
Une façon de faciliter l'utilisation de ce formulaire pour l'enquêteur consiste à organiser les champs en onglets à l'aide du « Drag and Drop Designer ». Nous pouvons structurer notre enquête en trois onglets : « Propriété », « Entreprise » et « Résidentiel », avec un champ dédié aux informations de l'enquêteur dans le premier onglet :
Maintenant que les champs sont organisés, nous pouvons aller plus loin pour rendre le formulaire encore plus réactif aux actions de l'utilisateur. Nous pouvons utiliser une expression pour masquer les onglets « Commercial » et « Résidentiel » jusqu'à ce que l'utilisateur choisisse le type de bien immobilier. Pour ce faire, sélectionnez l'onglet et utilisez le champ « Contrôle de la visibilité par expression » pour définir une expression permettant d'afficher ou de masquer l'onglet.
Pour l'onglet « Entreprise », utilisez :
« Type » = 'entreprise'Et pour l'onglet « Résidentiel », utilisez :
« Type » = « résidentiel »
Désormais, lorsque l'utilisateur saisit des données dans le champ, il ne verra que l'onglet « Propriété » tant qu'il n'aura pas sélectionné une option dans le champ « Type ». Il est également conseillé de définir une contrainte « Not null » sur le champ « Type » afin que l'utilisateur pense à saisir une valeur pour la propriété ; sinon, il risque de ne pas savoir qu'il doit fournir d'autres informations !
Regardez la vidéo ici.
Exemple 2 - Limiter les modifications à l'aide d'expressions
Maintenant que nous avons amélioré notre interface de relevé à l'aide de quelques expressions, nous pouvons essayer une méthode plus avancée pour limiter les personnes autorisées à modifier les entités de notre projet. Dans notre exemple, nous voulons que seuls les géomètres puissent modifier les entrées créées par leur équipe de relevé ou qui lui ont été attribuées.
Nous disposons déjà d'un champ permettant d'enregistrer le nom d'utilisateur du géomètre et l'équipe de levé qui lui a été attribuée. Nous allons compléter cela par un tableau non spatial répertoriant le nom d'utilisateur et l'équipe de chaque géomètre, qui se présente comme suit :
| fid | INT | Clé primaire |
|---|---|---|
| identifiant_géomètre | texte | UUID de l'enregistrement du géomètre |
| nom d'utilisateur | texte | Valeur par défaut définie sur @mm_username pour enregistrer le nom d'utilisateur de l'enquêteur |
| équipe | texte | L'équipe attribuée au géomètre ; dans notre exemple, il y a trois équipes : rouge, bleue et verte |
Dans notre tableau d'enquête , le champ « enquêteur » est défini comme non modifiable et utilise une expression de valeur par défaut @mm_username ; ce champ est également configuré pour appliquer la valeur par défaut lors de la mise à jour.
Nous configurons ensuite le champ « survey_team » sous forme de widget texte avec l'expression de valeur par défaut suivante :
attribut(get_feature('géomètres','username',@mm_username), 'équipe')Dans cette expression, en procédant de l'intérieur vers l'extérieur, nous utilisons la fonction get_feature() pour récupérer l'entité de la table surveyors qui correspond au nom d'utilisateur @mm_username de l'utilisateur actuel. Nous utilisons ensuite la fonction attribute() pour renvoyer la valeur du champ team pour cette entité. Cette valeur par défaut n'est appliquée qu'une seule fois, lors de la création de l'entité. Nous désactivons la modification de ce champ, mais vous pouvez également utiliser une expression pour autoriser uniquement un utilisateur administrateur à modifier l'entité, par exemple avec une expression telle que (remplacez le texte entre parenthèses par les noms d'utilisateur des administrateurs) :
@mm_username IN ('liste', 'of', 'admin', « usernames »)
Dans cet exemple, nous ajoutons également un champ booléen à la couche d'enquête, nommé « can_edit ». Nous allons configurer ce champ avec une contrainte d'expression qui empêchera les utilisateurs d'enregistrer des modifications apportées à un élément s'ils ne font pas partie de l'équipe d'enquête qui a créé cet élément ou à laquelle il est attribué.
Tout d'abord, nous allons définir la valeur par défaut du champ « can_edit » à l'aide de l'expression suivante :
attribut(get_feature('géomètres', 'username', @mm_username),'team') ILIKE "survey_team"
OU
@mm_username IN (« remplacez ceci par »,'admin','utilisateurs')L'expression ci-dessus utilise la même fonction que celle employée pour la valeur par défaut dans « survey_team » afin de récupérer l'équipe à laquelle l'utilisateur actuel est associé, puis vérifie si celle-ci correspond à la valeur de l'équipe de sondage attribuée à l'élément. L'instruction suivant l'opérateur OR vérifie si l'utilisateur est un administrateur. Si l'utilisateur actuel est un administrateur ou un membre de l'équipe associée à l'entité, la valeur du champ sera définie sur true; s'il n'appartient à aucun de ces groupes, elle sera définie sur false. Assurez-vous que la valeur par défaut est configurée pour être appliquée lors de la mise à jour.
Nous allons ensuite créer une contrainte basée sur une expression afin que l'élément ne puisse être enregistré que si la valeur du champ can_edit est « true » :
« can_edit » = trueEnfin, veillez à désactiver la modification de ce champ. Vos paramètres devraient ressembler à ceci :
Comme on peut le voir dans notre exemple, cet utilisateur, qui fait partie de l'équipe « enquête » ( en rouge ), ne peut modifier que les entités attribuées à cette équipe. Voir l'exemple ici.
De nombreuses autres utilisations des paramètres conditionnels
Ce ne sont là que quelques exemples illustrant comment vous pouvez utiliser les conditions dans votre projet pour optimiser le flux de travail et garantir la qualité des données. L'utilisation des conditions vous permet de personnaliser davantage votre projet, notamment grâce à la symbologie conditionnelle, aux contraintes temporelles, au remplissage automatique des champs en fonction de certaines valeurs, et bien plus encore. En exploitant toute la puissance de QGIS vous QGIS le meilleur parti de votre Mergin Maps !