Le portail francophone de la géomatique

Un format de données tellement compliqué qu'il oblige les collectivités à s'équiper de logiciels payant pour pouvoir le transformer en quelque chose de compréhensible c'est quand mème un peu dommage.. mis bout à bout l'argent dépensé par toutes les collectivités de france pour pouvoir utiliser les majic, ça doit faire un bon paquet.
Cette complexité est d'autant plus dommage que cette donnée est très intéressante pour l'étude d'un territoire, mais combien de collectivités ne l'utilisent pas a cause de la complexité de son exploitation?

Dernière modification par Francois Gueydon (Thu 12 May 2016 12:01)

bienvenue dans le monde réel ! 

Bonsoir,

@Christian lol on y patauge depuis longtemps

Pat,
La question n'est pas bête, mais le choix du format, EDIGéO est le bon. La seule problématique est son apparente complexité, mais sa richesse permet d'exploiter pleinement les richesses du plan cadastral, n'est ce pas Christian ?
Pour la partie données littérales, il faut connaître l'histoire. MAJIC (Mise A Jour des Informations Cadastrales et pas un majic à la Johnson comme je l'entend trop souvent), est une base de données hiérarchiques des années 1980. Les cinq fichiers majic sont les cinq entrées de consultation de la base originelle. Ce qui implique une chose, l'intégrité référentielle des données n'est garantie qu'à l''intérieure d'une même entrée (arborescence) donc d'un fichier.
Coder l'insertion d'un nouvel objet par une simple séquence quand toutes les autres lignes utilisent un article pour s'identifier c'est coder comme un pied, alors établir une base de données relationnelles qui gère les ruptures d'intégrité ...

    Ce qu'il faudrait c'est comme pour la norme EDIGéO publier un modèle public qui outre le diagramme de classe fournirait les diagrammes de séquence d'intégration. J'insiste sur les séquences car les fonctionnalité de mise à jour de l'application ont permis lors des saisies manuelles des ruptures d'intégrité. Ces séquences permettent en outre de coder l'état de la donnée intégrée. Ce qui permet d'avoir à l'état zéro le reflet des données délivrées par le producteur et à partir de l'état n une intégrité référentielle garantie. Les états n+1 permettant de codifier a postriori
des états spécifiques. En outre cette garantie d'intégrité permet d'exploiter des clefs primaires et étrangères numériques, accélérant ainsi les recherches et les traitements de masse.

Avec mon collègue nous avons écrit deux intégrateurs, EDIGéO et MAJIC.
Le premier exploite la richesse de la norme pour intégrer le plan cadastral dans une base PostGis topologique. La DGFiP change les ponts de détails linéaires à détails surfaciques rien à réécrire, lire dans le dictionnaire qu'il existe objet pont, dans le SCD qu'il est composé d'un objet surfacique et là rien à dire, le changement est passé inaperçu. Perso je regrette que cette norme ne soit pas plus utilisée car elle permet une grande richesse dans la modélisation de l'information, je pense par exemple aux notions de classement, un fichier où les données sont relationnelles ça a une autre tête qu'un bête fichier à plat shp. (je m'égare).

Le second ne fait que créer quelques tables temporaires dans une base postgis, simple lecture de fichier texte ASCII dont chaque enregistrement ...comme vendu avec le produit. Le reste c'est un script SQL qui intègre dans une base relationnelle, soit en fusionnant avec le plan soit seul.

C'est pour cela que ça m'énerve, les gens qui ont pris la décision de coder l'entité commune n'ont pas eu le respect, ou la compréhension, du code de ceux qui les ont précédé. Code qui lui est robuste et fonctionne, et qui malgré ses contraintes, offre de nombreuses possibilités.

Dernière modification par ChristopheV (Thu 12 May 2016 21:54)

Données riches peut être, mais quand je vois des erreurs dans les limites communales des couches edigeo de l'ordre de plusieurs centaines de metres, et qui persistent année après année, je me demandes s'il n'y a pas un petit souci dans les priorités.

Bonjour,

Oui les joie de l'AFNOR. Et bien évidemment il faut la rendre libre.

Les écrits du fondateur à son ministre des finances précisait que ce cadastre permettrait aussi de limiter les procès ...
La loi Taubira résultant de la commission Perrinet Marquet sur la réforme du droit des biens à été abandonnée suite à la position du sénat. C'est fort dommage, car tant en matière de droit de propriété que de limites, elle permettait des évolutions notables.

Le même poids citoyen que celui de chacun d'entre nous. Pour le format Edigéo et la connaissance du cadastre celui d'un spécialiste maîtrisant le panel complet

Pour vérifier, oui, ce qui prouve bien que le fichier fourni peut ne pas être topologique, ce qui n'est pas le cas dans l'edigeo grace à la manière de décrire les objets par relations. Cela dit tout est possible, mais dans le cas présent, cela permettait au récepteur des données de vérifier le strict minimum (et à l'émeteur de devoir faire un travail plus approfondi), surtout que le récepteur des données était loin d'avoir les compétences (informatiques et SIG) ni le temps et les outils  pour le faire.

(Pour information, le PCI n'accepte pas des fichiers Edigeo dont le modèle n'est pas topologique en entrée alors qu'il peut en fournir en sortie)

Dernière modification par christian (Sat 14 May 2016 15:40)

Hello

NON c est une conversion directe du format EDIGEO dans ACAD MAP (avec EDICAD-LT ou avec COVADIS) en DWG avec MPOLYGONs (si necessaire) + toutes les données attributaires EDIGEO en données d'objet ACAD MAP !

On trouve ces MPolygons principalement sur les couches Parcelles et Batiments

Cette conversion directe existe depuis longtemps et elle est Tip-Top !

Vous trouverez ci-joint un extrait DWG de cette "fameuse" conversion directe EDIGEO --> DWG (avec MPolygons et Donnees d'Objet de MAP)
N'importe quel ACAD, ACAD LT, ACAD MAP, etc, peut "apprecier / voir" les MPolygons !

MAIS seul un ACAD MAP (ou ACAD CIVIL) peut voir (et modifier) les Donnees d'Objet de MAP (Attributs EDIGEO) en bas de la palette des proprietes quand un Objet "concerne" est selectionne ...

GeoBye, Pat

Dernière modification par Patrice (Sat 14 May 2016 18:12)

Bonjour,

Sur l'aspect topologique il ne faut pas confondre la modélisation et les mathématiques. Je ne vais pas dévoiler tout nos petits secrets mais représenter un objet sous forme d'arc,faces,nœuds, ne veut pas dire que l'objet métier est composé d'une face.

Deuxièmement, j'ai pas de AcadLt sous la main, mais en matière de traducteur edigéo, il en existe beaucoup, mais la majorité ne fait que lire la partie vectorielle, pas les relations.

La norme n'a absolument pas évolué bien qu'elle aurait pu, pour écarter certains illogismes et apporter de la précision sur le modèle de donnée décrit, qui conserve ainsi des possibilités d’interprétation différentes (le SCD est donc incomplet).
Le modèle pci décrit a, quant à lui, évolué un peu (pas forcément en bien dernièrement) mais surtout pas sur des besoins importants comme tout ce qui concerne la voirie (numéros de voirie, voies publiques linéaires, voies privées surfaciques, ensembles immobiliers) que l'on pourrait espérer être liée au code RIVOLI (pardon! FANTOIR )