Les modèles INTERLIS étendus dans QGIS

Le lancement de QGIS Model Baker Release 7.6 est arrivé et apporte plusieurs fonctionnalités utiles qui rendront votre travail avec les modèles de données INTERLIS dans QGIS encore plus efficace. L’une de ces fonctionnalités concerne la gestion des modèles INTERLIS avancés, qui pouvait être assez fastidieuse jusqu’à présent. Mais ce n’est plus le cas…

Du problème à la solution

Lorsqu’un modèle INTERLIS contient des sous-classes qui étendent les fonctionnalités d’une classe de base, celles-ci, y compris la classe de base, sont matérialisées dans la base de données physique…

… et par conséquent, des couches sont créées dans QGIS.

De plus, lorsque les classes ont les mêmes noms, il devient difficile de s’y retrouver. C’était assez fréquent.

Exemple

Imaginons le modèle fictif Ortsplanung_V1_1 avec le topique Konstruktionen et la classe Gebaeude. Dans le modèle cantonal, cette classe est étendue avec plusieurs attributs via une sous-classe Kantonale_Ortsplanung_V1_1.Konstruktionen.Gebaeude. Ensuite, un modèle communal a été créé où cette sous-classe s’est vu attribuer deux thèmes différents : Staedtische_Ortsplanung_V1_1.Freizeit.Gebaeude et Staedtische_Ortsplanung_V1_1.Gewerbe.Gebaeude.

Confus? Si c’est le cas, ne vous inquiétez pas. Car c’est précisément à cela que vise cette nouvelle versionde ModelBaker. Nous avons donc quatre implémentations de la classe Gebaeude. Jusqu’à présent, Model Baker les ajoutait de manière équivalente dans le projet QGIS.

Ainsi, si la classe Gebaeude dans le modèle de base Ortsplanung_V1_1 avait une relation avec la classe BesitzerIn – et donc toutes ses sous-classes – une relation était créée dans QGIS pour chaque extension.

Lorsque des catalogues sont impliqués, les formulaires associés deviennent particulièrement compliqués.

Mais après tout, vous ne voulez pas voir tous ces calques, seulement ceux qui sont pertinents pour le modèle sur lequel vous travaillez actuellement. Devriez-vous vraiment vous embêter à gérer manuellement ces couches?

Non.

C’est fini à présent

Désormais, lors de la création du projet avec Model Baker, vous pouvez déterminer comment optimiser le projet.

Voilà, un projet clair et sans couches superflues est généré. Par exemple, vous travaillez sur le modèle urbain avec les deux sous-classes de Gebaeude.

… et les relations sont dorénavant plus concises.

Stratégies (Masquer/Grouper)

Cependant, les couches non pertinentes ne doivent pas toujours être masquées. Même si c’est la norme, il se peut que vous souhaitiez un projet optimisé, mais que vous vouliez simplement « ne pas voir » certaines couches. C’est pourquoi il existe l’option de regrouper toutes les couches non pertinentes dans un groupe.

Dans ce cas, toutes les relations des couches sont créées, mais les widgets ne sont pas ajoutés aux formulaires. Cela rend le travail très agréable.

Au fait : les couches sont désormais renommées de manière unique. Ainsi, dès qu’une couche du même nom existe, le nom du thème ou, si nécessaire, le nom du modèle est ajouté en préfixe.

Si cela vous convient, vous pouvez maintenant vous consacrer à des tâches plus pertinentes 😊 Mais si vous souhaitez en savoir plus sur le fonctionnement, voici quelques informations complémentaires 🧑‍🏭

Comment ça fonctionne ?

Pendant la phase de mise en œuvre, on a rapidement remarqué :

Model Baker ne peut pas toujours savoir ce que les utilisateurs veulent voir et ce qu’ils ne veulent pas voir.

Comme il est presque impossible de prendre en compte tous les cas, certaines hypothèses ont dû être formulées.

Hypothèses

On suppose que :

• Si vous étendez une classe de base avec le même nom, vous voulez la « remplacer », sinon vous la renommeriez.
• Si vous étendez une classe de base plusieurs fois (ce que l’on fait avec des noms différents), vous voulez également la « remplacer ».
• Exception des deux cas : si vous étendez la classe dans le même modèle, mais dans un autre thème (car si vous aviez l’intention de la « remplacer », vous l’auriez rendue ABSTRACT).

Approche

Donc, techniquement formulé, voici ce qui a été mis en place :

• Les classes de base avec des extensions portant le même nom sont considérées comme non pertinentes.
• Les classes de base avec plusieurs extensions sont considérées comme non pertinentes.
• Sauf si les extensions se trouvent dans le même modèle, elles ne sont pas considérées comme non pertinentes.

Les stratégies

Selon ce que vous choisissez lors de la génération du projet, l’une des stratégies est mise en œuvre.

Stratégie 1 : Masquer

• Les couches de classes de base avec des extensions portant le même nom sont masquées, de même que les couches de classes de base avec plusieurs extensions. Sauf si l’extension se trouve dans le même modèle, elle n’est pas masquée, mais renommée.
• Les relations des couches masquées ne sont pas créées, donc aucun widget n’est ajouté.

Stratégie 2 : Grouper

• Les couches de classes de base avec des extensions portant le même nom sont regroupées, de même que les couches de classes de base avec plusieurs extensions. Sauf si l’extension se trouve dans le même modèle, elle n’est pas regroupée, mais renommée.
• Les relations des couches regroupées sont créées, mais les widgets ne sont pas appliqués dans le formulaire.

Sans stratégie ?

Si une couche porte le même nom, le nom du thème est ajouté. S’il n’est toujours pas unique, le nom du modèle est également ajouté.

Baskets pour les classes étendues

Un bref rappel sur les baskets (paniers) : Un basket est une instance d’un thème et représente l’intersection avec l’ensemble de données actuelles. Un basket peut contenir des objets basés sur des classes qui sont autorisées dans le thème actuel. Il s’agit donc des classes définies dans le thème actuel et de celles définies dans le thème étendu par le thème actuel. Lorsque vous saisissez des objets dans le basket du thème actuel, vous devez également saisir les objets des classes définies dans le basket du thème actuel du thème de base.

Si cela semble un peu déroutant, nous avons de bonnes nouvelles pour vous :

Dans les projets optimisés, seuls les baskets pertinents seront proposés à l’avenir.

Cela signifie que même si la classe est définie dans un autre topique, seuls les baskets que vous voulez vraiment saisir seront proposés pour la couche. Selon la stratégie choisie, ce sont les instances sur lesquelles vous travaillez.

Voilà, c’est tout

Pour plus d’informations sur la mise en œuvre avec les modèles concernés, consultez la documentation et la liste de toutes les autres fonctionnalités géniales de Model Baker 6.7 dans le journal des modifications.

D’ailleurs, cette super fonctionnalité a été financée par le groupe d’utilisateurs QGIS Suisse. Donc, par la communauté, c’est-à-dire par vous. Merci beaucoup 🙂 »