Le portail francophone de la géomatique

Bonjour,

Je me suis permis de déplacer ce sujet ici [données] pour essayer de regrouper les sujets de la COVADIS.
S'agissant de ce géostandard, il a le mérite d'exister et un travail conséquent a été produit, mais je ne suis pas sûr qu'il soit très répandu...les éditeurs n'ayant pas attendu que les acteurs se parlent.

Bruno

Bonjour,

Je suis également en train de travailler avec ce standard sans être forcement un spécialiste de la COVADIS, voici quelques éléments de réponse à ces questions que nous nous sommes également posées.
- pour les raccords je les ai ajouté dans la table appareillage avec un nouveau type créé : raccord
- pour les bornes incendies je n'ai pas utilisé les piquages de brts, ni renseigné le type de cana en branchement. J'ai juste créé des cana normales
- le champ nbbranche correspond à mon avis au nombre de départ de brts individuels sur une cana principale et est donc renseigné uniquement sur des cana de type BRANCHEMNT=N
- pour les champs IDINI et IDNTERM, attention cela a évolué dans la dernière version du standard : maintenant il y a 4 champs
   - IDNINIA :Identifiant du noeud de début (AMONT) de la canalisation correspondant à un appareillage
   - IDNINIO : Identifiant du noeud de début de la canalisation correspondant à un ouvrage
   - IDNTERMA : Identifiant du noeud de fin (AVAL) de la canalisation correspondant à un appareillage
   - IDNTERMO : Identifiant du noeud de fin de la canalisation correspondant à un ouvrage
Du coup j'y inscrit les identifiants soit de l'ouvrage soit de l'appareillage placé au début ou à la fin de ma cana
- pour la cana principale, je pense que ce champ est fait pour les branchemnets particuliers

Voila comment j'ai interprété ce standard, après nous l'avons fait un peu évolué pour mieux coller au métier (ajout de valeur dans les listes + ajout de champs) ... Mais nous avons gardé tous les éléments de base nécessaire aux échanges.

Bonjour,

Je suis également en cours d'analyse du standard 1.1 pour l'implémenter dans ma structure.
Voici quelques remarques générales (d'un géomaticien) et précisions sur les interrogations déjà soulevées :

Remarques générales

# Classes d'objet et attributs

* précisions x,y,z

(p31, 32,34,35,36) Le type déclaré prévoit de gérer les infos au millimétre. Est ce une nécessité d'être aussi fin. le cm n'était t-il pas suffisant ?

* l'attribut filGen (p14) décrivant "la profondeur moyenne de la génératrice supérieur de la canalisation" est considéré comme une spécialisation de la classe d'objet <Canalisation AE>. Ceci nous interroge car cet attribut devrait plutot relever d'une propriété générique de canalisation AEP et ASS. Par ailleurs, sauf à considérer que cet attribut est destiné à faciliter rapidement un accès à l'information (étiquettage ?), le terme profondeur est dangereux car relatif à la surface donc la gestion peut être indépendante de celui qui a en charge le réseau. Il aurait mieux valu utiliser la référence de l'altitude (ngf) de la génératrice supérieure qui doit pouvoir être déduite des z amont et aval de la cana.

* l'attribut DIAMETRE (p30 et p33) des tables RAEPA_APPARAEP_P et RAEPA_APPARASS_P n'est pas référencé dans la partie conceptuelle. Il devrait être placé au niveau de la sous classe appareillage ou alors être supprimé des tables implémentées.

* l'attribut LONGCANA décrivant la longueur de la canalisation en mètre est de type entier  dans la partie implémentée (p29 et p33) mais décimal dans la partie conceptuelle (p13). Le type entier sous entend une simplification de mesures (pour étiquettage ?) et tend à renvoyer à l'emploi de la géométrie pour une mesure calculée décimale. Est ce bien ceci qui est sous entendu ?


# Domaines de valeurs / liste

Les domaines de valeur posent des problématiques de reclassement des données existantes et 2 cas se rencontrent :

* le domaine RAEPA est plus riche, plus détaillé que les données sources.

C'est par exemple le cas de la liste des matériaux (p20) qui est extremement riche et très très fine (ex : 4 valeurs possibles pour du béton). N'aurait il pas mieux valu avoir soit une liste à emboitements (ex : 10=béton, 11=béton âme tôle, 12=béton armé, 20=PVC, 21=PVC ancien, 22=PVC BO ...) soit employer un type et sous-type comme dans d'autre standard (ex : prescriptions et information des documents d'urbanisme). Cette finesse engendre un reclassement avec une perte d'information car pour une valeur "béton" dans les données actuelles, la migration stricto census au standard RAEPA, la fait passer à 99=autre.

* le domaine RAEPA est plus "ramassé" que les donnée sources

La problématique est donc celle d'une reventilation dans le standard (et l'ajout d'un sous type pour conserver l'info plus fine de départ). Par exemple, comment reclassé un ouvrage de sépateur d'hydrocarbure ? Il s'agit d'un ouvrage de traitement des eaux usées et la correspondance la plus proche dans le domaine <Ouvrage ASS> (p22) semble être la 02=Station d'épuration. Je pense que le standard devrait plus expliciter les sous types d'ouvrage ou d'appareillage que chaque valeurs du domaine peut recouvrir ou NON.


Précisions sur les questionnements précédents

Pour ma part, à ce stade, j'en déduis qu'un noeud dépourvu d'un appareillage ou d'un ouvrage est donc un raccord. Ceci reste à examiner après discussions avec des gens du métier AEP/ASS.

Du point de vue de la modélisation, normalement ces information sont directement héritées et déduites de la classe noeud

Même analyse pour ma part. Info à ne renseigner que dans le cas d'une canalisation de branchement, surtout en cas de piquage (noeud pas forcement coupant)

Sur les gabarits prêts à emploi, attention mais le téléchargement complet du "paquet" transmet la doc du v1.0 du standard et non la v1.1. Pour ma part, il ne me semble pas y avoir eu de modifications de ce dernier depuis février 2017.

Cordialement

Florent

Dernière modification par florent vanhoutte (Mon 22 October 2018 14:13)

Bonjour,

ce standard a eu une histoire particulièrement compliquée mais, à ma surprise, il semble être de plus en plus exploité. Ce fil en est l'expression. A mon avis, c'est l'illustration de ce que nous disons depuis longtemps, à savoir que, plutôt qu'inventer un modèle, il est plus efficace (et sûr) d'en prendre un national.

Cordialement

Bonjour,

Effectivement, évolution qu'on ne remarque d'ailleurs pas si on s'en tient seulement à la lecture de la doc sans parcourir les catalogues d'attributs au format xml ou les fichiers gabarits au format SHP.

Comment est-il possible que la dernière version (1.1) de la doc disponible sur le site de l'espace interministériel "GéOInformations" n'ait pas été mise à jour de cette évolution ?...

Bonjour à tous,

pour partage de notre interprétation et avis.

Sur la transcription du réseau assainissement (boite de branchement > branchement > piquage à la canalisation principale) au modèle RAEPA,

____                                |
|       |  Branchement         |
| BB  |------------------------x Piquage sur la canalisation principale (sans regard)
|____|                               |
                                         | Canalisation principale

notre traduction est :


____                                |
|       |  [branchemnt=O]    |
| BB  |------------------------x Piquage : Appareillage de type point de branchement  [fnappass=01]
|____|                               |
Ouvrage                             | Canalisation principale : canalisation [branchemnt=N]
type regard
[fnouvass=02] 


Interprétez vous ceci également de cette manière ?

Cordialement

Florent

Dernière modification par florent vanhoutte (Wed 27 February 2019 10:15)

Bonjour,

Sur la transcription du réseau assainissement, nous avons interprété cela exactement de la même manière.

Voici les ajouts réalisés:
Pour toutes les tables :  nous avons ajouté un champ observation et comme je travaille pour le compte de 2 com com (qui n'ont pas encore la compétence) j'ai ajouté un champ sur chaque table pour identifier chaque territoire (pour les filtres, les exports...).

Assainissement :

Pour les regards (Ouvrage): nous avons ajouté la profondeur mesurée, la cote radier, la classe, le type (Chasse, tampon, regard recouvert...).
Pour les STEP (Ouvrage) : nous avons ajouté la capacité, son type et la présence de télégestion
pour les cana : nous avons ajouté la pente et la hauteur de chute

Eau Potable :

Pour les appareillages : nous avons ajouté une précision dans le type d'appareil de régulation (reducteur de pression, de débir, stab, surpresseur...), un état de la vanne (ouvert/fermé), un type d'hydrant (PI/BI...)
Pour les ouvrages : nous avons ajouté une précision sur le type de captage (forage/prise d'eau...) et une précision sur le type de reservoir.

Puis nous avons également ajouté quelques valeurs dans les listes afin de coller à notre réalité terrain.

Nous sommes en phase de création du SIG et nous n'avons pas encore la compétence donc j'ai encore assez peu de recul sur ces évolutions. L'idée était de coller au mieux avec ce standard lors de la création du SIG réseaux humides afin de s'éviter un maximum de soucis d'échange lorsque la compétence sera prise.

+1

En revanche, après relecture, cela ne semblent pas correspondre aux contraintes de modélisation posées en B.3.1 p13 qui indiquent que les 2 extrémités d'une canalisation sont des nœuds sauf s'il s'agit d'un branchement individuel.
Ceci reste à éclaircir car en B.1.3 p11, on parle au niveau du piquage, d'un nœud coupant ou d'un "simple point" non coupant. Par ailleurs, il est bien prévu de pouvoir saisir un appareillage de type point de piquage, ce qui sous-entend donc que cette entité n'existe QUE dans le cas d'un nœud sécant sur la canalisation principale ... et que donc, si pas sécant, et bien aucun nœud au lieu du piquage branchement-cana mais un simple point de construction sur la canalisation principale ...

Merci

Florent

Bonjour,
On vient de m'imposer ce standard REAPA de la COVADIS pour la construction d'un SIG d'un réseau d'assainissement.
La documentation technique mélange les type de couche avec les nom des couches, les définitions d'attributs sont mélangé d'une couche à l'autre (Canalisation, appareil, ouvrage, ect). Les noms des attributs ne correspondent pas entre la doc et les gabarits. Sur les gabarits centaine longueur d'attribut ne sont pas compatible avec les tableau de code.

Ça fait peur quand même.

Ca faisait 10 ans qu'on utilisait le standard du département qui n'était pas parfait mais au moins avait les bases, là on part de loin.

Bonjour,

pour ma part j'avais en début d'année recensé certaines incohérences entre le document et les gabarits mis à disposition.
J'avais listé cela dans un fichier Excel en indiquant les différences, puis envoyé ces éléments en passant par le secrétariat de la COVADIS que vous pouvez contacter à partir de la page suivante : http://www.geoinformations.developpemen … -r425.html (le lien en bas de page).

J'ai obtenu une réponse et un retour sur ces anomalies qui ont à priori fait partie de la version mineure 1.2 sortie en avril 2019.

Ainsi, vous pouvez éventuellement lister ce que vous avez décelé et l'envoyer.

Bonne soirée.

Bonjour,

pour ma part j'avais en début d'année recensé certaines incohérences entre le document et les gabarits mis à disposition.
J'avais listé cela dans un fichier Excel en indiquant les différences, puis envoyé ces éléments en passant par le secrétariat de la COVADIS que vous pouvez contacter à partir de la page suivante : http://www.geoinformations.developpemen … -r425.html (le lien en bas de page).

J'ai obtenu une réponse et un retour sur ces anomalies qui ont à priori fait partie de la version mineure 1.2 sortie en avril 2019.

Ainsi, vous pouvez éventuellement lister ce que vous avez décelé et l'envoyer.

Bonne soirée.

Bonjour,

Qu'on se le dise, même si je trouve étrange de commencer par la sémiologie graphique:
https://www.astee.org/groupe-de-travail … n-externe/

Enfin, le sujet est peut-être un tout petit peu plus consensuel

Bruno

Bonsoir,
Travaillant actuellement sur ce standard pour un projet de stage, certaines incohérences n'ont pas été évoqué ci-dessus et je me permets de les ajouter ici.

Dans une logique de topologie de réseau, d'une manière générale, nous ne dupliquons pas les géométries sur une même position, mais greffons sur un noeud unique l'ouvrage (ou non en cas d'absence) ainsi que le ou les appareillages associés.
Dans la partie de la modélisation du standard (Partie B), la compréhension que nous en avons faite ne suit pas cette logique.

En effet, les attributs anMESinf et anMESsup sont présent sur la classe de noeud, et non aux classes appareillages et ouvrages.
Nous ne pouvons pas considérer que tous les objets positionnés sur un noeud sont mis en service et hors service en même temps, c'est illusoire....
Par conséquent, tel qu'est modélisée la partie B, cela impliquerait donc des superpositions de géométrie de noeud, avec un noeud par objet.....

De plus, concernant ces deux attributs, ils ne sont pas nommés de la même façon dans la partie implémentation (Partie C).
On remarque qu'ils sont nommés comme pour les canalisations, par andebpose et anfinpose. On observe toutefois que la définition diffère entres les linéaires et ponctuels, avec, pour les linéaires, l'année de début et fin de pose de canalisation, et, pour les noeuds, l'année de début de mise en service et de fin de mise en service.
On remarque également que l'année de fin de mise en service est obligatoire a renseigner..... pour un appareil ou un ouvrage toujours en service, on met quoi ????

Il parait plus plausible d'obliger la saisie de l'année de début de mise en service d'un ouvrage ou d'un appareillage, et de rendre facultatif l'année de fin de mise en service...

Egalement, ne pourrions nous pas penser plus généralement à un objet de réseau quel qu’il soit, avec les attributs suivants ?
- andebpose, qui correspondrait à l'année de début de pose de l'objet
- anfinpose, qui correspondrait à l'année de fin de pose de l'objet
- enservice, qui reprendrait en fait l'attribut présent dans la classe des canalisations permettant de signifier si la canalisation est en service (O) ou abandonnée (N).

Nous pourrions tout à fait avoir ces informations pour tout objet d'un réseau, du linéaire au ponctuel.


Dans un autre temps, on peut remarquer de nombreuses coquilles dans le standard entre les parties B et C, notamment des type décimaux qui deviennent entier dans la partie C (attribut de longueur de canalisation), mais également des type entier (4) où la précision est inutile puisqu'il s'agit d'un entier...

De plus, un type décimal (1,2) pour l'attribut profgen, et un décimal (6,3) pour l'altitude sont indiqués. Comment interpréter cela ? D'un côté, on aurait pour profgen : a,aa et pour l'altitude aaaaaa,aaa ??? La première valeur ne correspond-t-elle pas au nombre total ? Dans ce cas, un décimal (1,2) est techniquement impossible... Au contraire, si la première valeur correspond au nombre d'entier, nous aurions la possibilité d'avoir des z de plus de 10 000 m ? Il semble y avoir des incohérences ici également....

Bien à vous,

Léandre Béron

Bonjour,
Mes compléments ci-dessous.

Effectivement, nous ne pouvons avoir de réponse qu'avec un des participants de ce projet. Nous avons remontés un certain nombre d'informations, mais à ce jour, plus personne ne s'en occupe... Il serait intéressant que le CNIG travail dessus, afin de répondre à cela...

Tout à fait. On peut même noter pour les attributs portant les coordonnées un type décimal (7,3), ce qui à mon sens, devrait être plutôt (10,3).

Comme évoqué plus haut, plus personne ne s'occupe de ce travail. Aucune modification ne sera donc apportée.
Un travail devrait être mis sur la table à partir d'Octobre prochain, selon la continuité du travail de l'ASTEE sur la symbologie, portant sur la modélisation d'une base nationale. Nous devrions donc avoir réponse, dans quelques temps..

Bien à vous,

Léandre Béron