{"id":14010,"date":"2023-10-31T07:00:00","date_gmt":"2023-10-31T06:00:00","guid":{"rendered":"https:\/\/www.opengis.ch\/?p=14010"},"modified":"2023-11-01T12:45:43","modified_gmt":"2023-11-01T11:45:43","slug":"erweiterte-interlis-modelle-in-qgis","status":"publish","type":"post","link":"https:\/\/www.opengis.ch\/fr\/2023\/10\/31\/erweiterte-interlis-modelle-in-qgis\/","title":{"rendered":"Les mod\u00e8les INTERLIS \u00e9tendus dans QGIS"},"content":{"rendered":"\n

Le lancement de QGIS Model Baker Release 7.6<\/a> est arriv\u00e9 et apporte plusieurs fonctionnalit\u00e9s utiles qui rendront votre travail avec les mod\u00e8les de donn\u00e9es INTERLIS dans QGIS encore plus efficace. L’une de ces fonctionnalit\u00e9s concerne la gestion des mod\u00e8les INTERLIS avanc\u00e9s, qui pouvait \u00eatre assez fastidieuse jusqu’\u00e0 pr\u00e9sent. Mais ce n’est plus le cas…<\/em><\/strong><\/p>\n\n\n\n

Du probl\u00e8me \u00e0 la solution<\/h3>\n\n\n\n

Lorsqu’un mod\u00e8le INTERLIS contient des sous-classes qui \u00e9tendent les fonctionnalit\u00e9s d\u2019une classe de base, celles-ci, y compris la classe de base, sont mat\u00e9rialis\u00e9es dans la base de donn\u00e9es physique…<\/p>\n\n\n\n

… et par cons\u00e9quent, des couches sont cr\u00e9\u00e9es dans QGIS.<\/p>\n\n\n\n

De plus, lorsque les classes ont les m\u00eames noms, il devient difficile de s’y retrouver. C’\u00e9tait assez fr\u00e9quent.<\/p>\n\n\n\n

\"image\"\/<\/a><\/figure>\n\n\n\n

Exemple<\/h4>\n\n\n\n

Imaginons le mod\u00e8le fictif Ortsplanung_V1_1<\/a><\/code> avec le topique Konstruktionen<\/code> et la classe Gebaeude<\/code>. Dans le mod\u00e8le cantonal<\/a>, cette classe est \u00e9tendue avec plusieurs attributs via une sous-classe Kantonale_Ortsplanung_V1_1.Konstruktionen.Gebaeude<\/code>. Ensuite, un mod\u00e8le communal<\/a> a \u00e9t\u00e9 cr\u00e9\u00e9 o\u00f9 cette sous-classe s\u2019est vu attribuer deux th\u00e8mes diff\u00e9rents : Staedtische_Ortsplanung_V1_1.Freizeit.Gebaeude<\/code> et Staedtische_Ortsplanung_V1_1.Gewerbe.Gebaeude<\/code>.<\/p>\n\n\n\n

Confus? Si c’est le cas, ne vous inqui\u00e9tez pas. Car c’est pr\u00e9cis\u00e9ment \u00e0 cela que vise cette nouvelle versionde ModelBaker. Nous avons donc quatre impl\u00e9mentations de la classe Gebaeude<\/code>. Jusqu’\u00e0 pr\u00e9sent, Model Baker les ajoutait de mani\u00e8re \u00e9quivalente dans le projet QGIS.<\/p>\n\n\n\n

Ainsi, si la classe Gebaeude<\/code> dans le mod\u00e8le de base Ortsplanung_V1_1<\/code> avait une relation avec la classe BesitzerIn<\/code> \u2013 et donc toutes ses sous-classes \u2013 une relation \u00e9tait cr\u00e9\u00e9e dans QGIS pour chaque extension.<\/p>\n\n\n\n

\"image\"\/<\/figure>\n\n\n\n

<\/a><\/p>\n\n\n\n

Lorsque des catalogues sont impliqu\u00e9s, les formulaires associ\u00e9s deviennent particuli\u00e8rement compliqu\u00e9s.<\/p>\n\n\n\n

Mais apr\u00e8s tout, vous ne voulez pas voir tous ces calques, seulement ceux qui sont pertinents pour le mod\u00e8le sur lequel vous travaillez actuellement. Devriez-vous vraiment vous emb\u00eater \u00e0 g\u00e9rer manuellement ces couches?<\/em><\/p>\n\n\n\n

Non.<\/em><\/p>\n\n\n\n

C’est fini \u00e0 pr\u00e9sent<\/h4>\n\n\n\n

D\u00e9sormais, lors de la cr\u00e9ation du projet avec Model Baker, vous pouvez d\u00e9terminer comment optimiser le projet.<\/p>\n\n\n\n

\"Screenshot<\/a><\/figure>\n\n\n\n

Voil\u00e0, un projet clair et sans couches superflues est g\u00e9n\u00e9r\u00e9. Par exemple, vous travaillez sur le mod\u00e8le urbain avec les deux sous-classes de Gebaeude.<\/p>\n\n\n\n

\"image\"\/<\/a><\/figure>\n\n\n\n

… et les relations sont dor\u00e9navant plus concises.<\/p>\n\n\n\n

\"image\"\/<\/a><\/figure>\n\n\n\n

Strat\u00e9gies (Masquer\/Grouper)<\/h3>\n\n\n\n

Cependant, les couches non pertinentes ne doivent pas toujours \u00eatre masqu\u00e9es. M\u00eame si c’est la norme, il se peut que vous souhaitiez un projet optimis\u00e9, mais que vous vouliez simplement \u00ab\u00a0ne pas voir\u00a0\u00bb certaines couches. C’est pourquoi il existe l’option de regrouper toutes les couches non pertinentes dans un groupe.<\/p>\n\n\n\n

\"image\"\/<\/a><\/figure>\n\n\n\n

Dans ce cas, toutes les relations des couches sont cr\u00e9\u00e9es, mais les widgets ne sont pas ajout\u00e9s aux formulaires. Cela rend le travail tr\u00e8s agr\u00e9able.<\/p>\n\n\n\n

\n

Au fait : les couches sont d\u00e9sormais renomm\u00e9es de mani\u00e8re unique. Ainsi, d\u00e8s qu’une couche du m\u00eame nom existe, le nom du th\u00e8me ou, si n\u00e9cessaire, le nom du mod\u00e8le est ajout\u00e9 en pr\u00e9fixe.<\/em><\/p>\n<\/blockquote>\n\n\n\n

Si cela vous convient, vous pouvez maintenant vous consacrer \u00e0 des t\u00e2ches plus pertinentes \ud83d\ude0a Mais si vous souhaitez en savoir plus sur le fonctionnement, voici quelques informations compl\u00e9mentaires \ud83e\uddd1\u200d\ud83c\udfed<\/p>\n\n\n\n

Comment \u00e7a fonctionne ?<\/h3>\n\n\n\n

Pendant la phase de mise en \u0153uvre, on a rapidement remarqu\u00e9 :<\/p>\n\n\n\n

Model Baker ne peut pas toujours savoir ce que les utilisateurs veulent voir et ce qu’ils ne veulent pas voir.<\/em><\/em><\/p>\n\n\n\n

Comme il est presque impossible de prendre en compte tous les cas, certaines hypoth\u00e8ses ont d\u00fb \u00eatre formul\u00e9es.<\/p>\n\n\n\n

Hypoth\u00e8ses<\/h4>\n\n\n\n

On suppose que :<\/p>\n\n\n\n