Le portail francophone de la géomatique

Bonjour,

Je n'ai pas de réponse à votre question mais juste quelques précisions à vous apporter s'agissant de l'implémentation du RAEPA en base de modèle selon le script de notre collectivité.
Le modèle de données présente des vues qui ne servent actuellement qu'à de la consultation car nous ne gérons pas en interne les données. Elles sont en effet issues des retours des concessionnaires sur notre territoire.
Avec notre implémentation, il n'est donc pas possible à ce stade d'utiliser les vues telles que dans un outil (QGIS ou autre) pour de la saisie, sans compléter le développement avec des triggers et fonctions triggers.
A défaut, il vous faudra donc bien repartir des tables métiers unitaires et des domaines de valeurs de la base pour permettre une saisie de données.
Attention toutefois, le modèle de notre collectivité est relationnel, ce qui imposera comme vous l'avez fait à priori, de réaliser les jointures depuis l'outil final, ici QGIS.

Bon courage

Cordialement
Florent

Dernière modification par florent vanhoutte (Mon 17 May 2021 17:24)

En effet, je tiens compte du fait existant, en l'occurrence de l'existence d'un projet de développement d'une base RAEPA de la COMCOM de Compiègne, celle-là dédiée à l'acquisition et la diffusion des données fournies par ses délégataires de services.

Mon souhait en effet, est d'utiliser la base de données relationnelle SQL, et de développer une interface (modèle) QGIS pour interagir, et donc exploiter cette première. La tâche est ardue, car toutes les relations logiques sont à reproduire côté client. D'ailleurs, certains aspects techniques liés à l'auto génération des ID par la base SQL semblent ne pas fonctionner dynamiquement avec QGIS...

Comme je n'aie pas le temps de développer une base relationnelle RAEPA adapté du COVADIS, je trouve le travail de la COMCOM de Compiègne bien avancé sur la mise en pratique du standard dans un S.I.G. J'utilise donc votre approche logique et fonctionnelle pour développer un outil QGIS standardisé.

Le canevas QGIS d'une table PostegreSQL est créé depuis le DBManager de QGIS. C'est la représentation d'une table PostgreSQL sous QGIS. Cependant, les canevas ne sont pas importés avec leurs relations issues de la base de donnée Posgres/Postgis. De plus, il me semble nécessaire de créer les relations du modèle logique directement sur les tables géométriques (de niveau 1 ici).

Le modèle logique dépend de fonctions déterminées en amont et les fonctionnalités des séquences semblent en effet incomplètes pour la transposition dans un client QGIS.

Comme je n'aie aujourd'hui jamais produit aucun Trigger, je vais donc réfléchir à cette solution, l'enjeu est de caractériser et de déterminer les Trigger à produire pour orienter la saisie dans le client QGIS.

Dans tous les cas, j'ai perdu beaucoup de temps en essayant de l'exploiter à des fins de production cartographique sous QGIS. L'adaptation du standard COVADIS est une base de travail libre d'interprétation pour les plus sages d'entre ceux-là, sachant développer des bases de données relationnelles géoréférencées.

Bien à vous.

Dernière modification par chrlscttw (Tue 18 May 2021 13:49)

Bonjour neskuik,

En effet, je suis intéressé par le développement d'un outil de bases de données comme un trigger. Ceci dit, il me faut aussi une petite explication sur son fonctionnement sous Postgres, et son comportement sous QGIS. L'outil que je cherche à coder est un générateur d'ID en fonction des producteurs d'entités, ouvrage, équipement, canalisation de type géométrique nœud.

Par exemple de l'identifiant du producteur 'idprod' dépend l'idnoeud' de l'objet (cela pour un ouvrage, un appareil ou une canalisation) pour rendre cela possible une classe de correspondance est créée 'an_raepal_correspondance' contenant l'id du producteur 'idprod' en contrainte clé primaire (PK) et un 'idnoeud' identifiant du nœud interne en contrainte obligatoire. Comment distribuer correctement cet 'idprod' à chaque création d'objet sous QGIS par exemple ?. Le trigger est donc la solution pour répondre à cette question ?


Merci.

Dernière modification par chrlscttw (Wed 19 May 2021 11:33)

Bonjour,

je pense qu'il faut insister sur ce point qu'a souligné neskuik

, la transaction est effective lorsque vous appuyez sur le bouton sauvegarde de la couche dans QGIS. Donc il ne faut pas s'attendre à voir apparaitre idprod dans vos formulaires QGIS tant que la sauvegarde n'est pas faite :

Pourriez-vous nous donner un cas concret pour y voir plus clair en plus de votre explication

Dernière modification par Franck2908 (Thu 20 May 2021 16:19)

, je suis d'accord avec neskuik, surtout si comme vous l'indiquez

.  Le standard RAEPA n'est pas figée.
Cela facilitera la reprise de données par le prestataire si votre collectivité souhaite par la suite faire l'acquisition d'une application collaborative de gestion de réseau.

La table 'an_raepa_correspondance' est peut-être la classe de jointure (n,n) entre les tables contenant le tuple 'idprod' et les tables contenant le tuple 'idnoeud' en modèle physique de données SQL...

Ces classes, Avaloirs et Bassins de stockage ainsi que toutes les autres tables complémentaires se rapportent aux caractéristiques des équipements ou aux ouvrages... ils sont implémentées dans la dernière version du modèle de la CC de Compiègne. S’ils permettent d'approfondir la maitrise de l'information sur les réseaux hydrauliques, je les trouve moi aussi un peu précoce si le lecteur les comparent au standard RAEPA national. Cela sans parler de la somme de travail de gestion des données qui augmente sensiblement.

Il faudrait en effet ajouter une table pour les producteurs/fabriquant d'ouvrage ou d'appareil, et leur ajouter un jeu de clés relationnels PK FK dans les tables qui les appellent.

Sinon, je souhaite rebondir sur cette dernière information. Les clés FK sont à automatiser ou pas en fonction des besoins de l'utilisateur sous QGIS ?

Cdlt

Dernière modification par chrlscttw (Fri 21 May 2021 14:34)

Bonjour,

A noter qu'il existe un plugin qui semble répondre à une partie des besoins exprimés dans ce sujet:
https://github.com/3liz/qgis-raepa-plugin

Bel été!

J'ai finalement trouvé comment, en utilisant le "Gestionnaire BD" dans le menu base de donnée. Il faut néanmoins les importer un à un, avec clic-de-droit sur le fichier et "ajouter au canevas".


Savez-vous s'il existe une méthode pour importer l'ensemble des couches non géométrique en seule fois ?

Cordialement.