#1 Thu 12 May 2016 09:07
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Données MAJIC EDIGEO DVF ...
Bonjour,
Un coup de gueule, car depuis quelques années je m'énerve mais là la coupe est pleine.
Chaque année les données MAJIC évoluent dans leur format. Le problème c'est qu'il n'y a aucune logique dans le codage et pas mal de bêtises dans le fichier descriptif.
Première des choses, écrire dans le fichier descriptif que les enregistrements ont une longueur fixe de n caractères est faux, le premier qui me trouve un fichier MAJIC avec des longueurs fixe ... (et encore ces dernières années ils ont enfin mis un CR/LF en fin)
En 2015 ils nous sortent l'enregistrement commune, qui ne sert à rien d'ailleurs, mais lui il ne correspond çà aucun critères de codage (utilisation d'un article par exemple), la seule façon de trouver cette enregistrement 'est de constater que de la position 6 à la position 16 ont a que des espaces ... joyeux !
Autre superbe normalisation:
Edigéo : la section est codée '0A'
Majic : ' A'
DVF 'A'
Le tout provient du même producteur !
Suivant les département on vous livre de l'édigéo à la section, ou à la feuille de section...
Bref BRUNO me répondra que cela fait vivre les consultants et les entreprises privées qui tous les ans doivent reprogrammer leur logiciel ...
Et bientôt pour la plus grande joie de des agents devant le constat d’obsolescence technique on confiera cette mission à des entreprises privées ?
Si une boite privée se permettait ce genre d'erreur qualité dans son produit, elle disparaîtrait du marché de mort économique naturelle.
Là c'est moins grave puisque c'est nous citoyens qui finançons ...
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#2 Thu 12 May 2016 10:03
- fbecir
- Participant assidu
- Lieu: Saint-Mandé
- Date d'inscription: 16 Sep 2008
- Messages: 512
Re: Données MAJIC EDIGEO DVF ...
Le tout provient du même producteur !
Tiens, pour une fois ce n'est pas l'IGN qui trinque ... ;-)
Si une boite privée se permettait ce genre d'erreur qualité dans son produit, elle disparaîtrait du marché de mort économique naturelle.
Là c'est moins grave puisque c'est nous citoyens qui finançons ...
De la même manière, quand un grand constructeur automobile a "quelques erreurs de qualité" sur ses mesures anti-pollution, le citoyen arrête d'acheter des voitures de ce constructeur ... Ah non, cela ne se passe pas comme çà ??? Il faut croire que les boites privées font aussi des erreurs (qui me semble bien plus grave qu'une erreur de codification dans un fichier) et arrivent à survivre.
Hors ligne
#3 Thu 12 May 2016 11:56
- Francois Gueydon
- Participant actif
- Lieu: Castelnaud la Chapelle
- Date d'inscription: 17 Jun 2015
- Messages: 69
Re: Données MAJIC EDIGEO DVF ...
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)
La cartographie sans SIG existe encore: http://www.cartographersguild.com/content.php
Site perso: http://francoisgueydon.jimdo.com/
Hors ligne
#4 Thu 12 May 2016 13:42
- Jean-Michel
- Membre
- Lieu: An Oriant /Lorient
- Date d'inscription: 3 Oct 2005
- Messages: 3909
Re: Données MAJIC EDIGEO DVF ...
Hello,
Je plussoie...
Et en aval de tout çà, des traducteurs/moulinettes propriétaires, open source ou "maison" qui structurent leurs modèles de différentes manières, qui en mettant par exemple un code commune sur 3, 5 ou 6 caractères, qui, en codifiant à leur sauce les identifiants...
...sans évoquer les bugs des traducteurs, ou les mauvais calibrages par les utilisateurs...faute de comprendre précisément les formats (EDIGEO et MAJIC) des données (et leurs contenus et finalités ) , leurs évolutions d'un millésime à l'autre...
Tiens, pour une fois ce n'est pas l'IGN qui trinque ... ;-)
On a suffisamment de fois abordé les sujets MAJIC et/ou EDIGEO ici, et pas spécialement à l'heure de l'apéro ...
Jean-Michel
GeoRezo, c'est des blogs, un wiki, un Netvibes ...
GeoRezo vous aide ==> Aidez GeoRezo !
Hors ligne
#6 Thu 12 May 2016 20:39
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4779
Re: Données MAJIC EDIGEO DVF ...
Hello les Pros
Question BETE d'un Beotien : pourquoi la DGI (ou le ministere "correspondant") pour le cadastre, n'a pas choisi (A l'epoque - Quand d'ailleurs ??) un format standard : SHP par exemple !
MA reponse cela aurait ete "trop bete/simple" ...
OU Quand on peut faire "complique" (surtout en France) pourquoi faire simple !?
En effet il faut faire vivre les SSIs, les Consultants, les Addins/Plugins par dessus ESRI, FME, MapInfo, AutoCAD MAP, GeoConcept, etc ...
GeoBye, Pat
(Autodesk Expert Elite Team)
Hors ligne
#7 Thu 12 May 2016 21:53
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Re: Données MAJIC EDIGEO DVF ...
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)
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#8 Fri 13 May 2016 08:59
- Jean-Michel
- Membre
- Lieu: An Oriant /Lorient
- Date d'inscription: 3 Oct 2005
- Messages: 3909
Re: Données MAJIC EDIGEO DVF ...
Bonjour,
Question BETE d'un Beotien : pourquoi la DGI (ou le ministère "correspondant") pour le cadastre, n'a pas choisi (A l'epoque - Quand d'ailleurs ??) un format standard : SHP par exemple !
La première version de la norme EDIGEO a dû sortir en 1995 (donc norme élaborée, sous la responsabilité du CNIG depuis le début des années 1990), et comme c'est une norme (nationale), elle aurait dû s'imposer à tous les producteurs et utilisateurs de données géographiques.
Elle n'est pas, en principe, limitée aux objets "Cadastre", mais devait (devrait) être le standard d'échanges de données en toute indépendance, neutralité vis à vis des progiciels et formats d'exploitation.
Elle a été très difficile à mettre en application (absence de volonté ?) et la DGFiP a été très vite quasiment le seul producteur à persister dans ce format d'échanges.
On peut reprocher plein de choses à ce format d'échanges, mais il faut se rappeler (désolé pour ceux qui étaient à peine nés !) que, au début des années 1990, l'interopérabilité, les formats de fichiers et les capacités aux multiples logiciels/outils à lire/traduire les différents formats existant étaient très limités...
Et comme le souligne Christophe, les données EDIGEO "Cadastre" sont très riches et certainement sous-exploitées par les utilisateurs (mais en l'état des usages, en ont-ils besoin...)
Géomatiquement
Jean-Michel
GeoRezo, c'est des blogs, un wiki, un Netvibes ...
GeoRezo vous aide ==> Aidez GeoRezo !
Hors ligne
#9 Fri 13 May 2016 10:44
- Francois Gueydon
- Participant actif
- Lieu: Castelnaud la Chapelle
- Date d'inscription: 17 Jun 2015
- Messages: 69
Re: Données MAJIC EDIGEO DVF ...
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.
La cartographie sans SIG existe encore: http://www.cartographersguild.com/content.php
Site perso: http://francoisgueydon.jimdo.com/
Hors ligne
#10 Sat 14 May 2016 00:46
Re: Données MAJIC EDIGEO DVF ...
Bon, je ne sais trop si je dois alimenter le troll (c'est dans le dictionnaire maintenant ) en donnant mon opinion qui ne vaut pas grand chose d'ailleurs
J'ose à peine imaginer ce que ca aurait été si on avait numérisé au format SHP (ou d'ailleurs tout autre format actuel des SIG qui définit les objets indépendamment les uns des autres) : parcelles qui se chevauchent, formes géométriques incorrectes.... L'avantage du format EDIGEO était que le prestataire avec ce format ne pouvait fournir que quelque chose de correct, j'entends une définition topologique du parcellaire.
Donc cette idée de format partait d'une excellente idée, mais comme beaucoup d'idées, elle n'aboutissent pas pleinement pour tout un tas de raisons... (certains diront : c'est la france...) et je regrette qu'on n'ai pas développé ceci.
@ christophe:
le paradoxe français : quand on veut qu'une norme se développe, on la rend publique et gratuite : la norme Edigeo se payait 1000 francs il me semble à l'époque (94)
@ francois:
Les priorités des uns ne sont pas forcément celles des autres... t'es tu demandé quelles sont les priorités de la DGFIP ?
Cela dit, ne vous illusionnez pas, ce n'est pas avec le meilleur RPCU possible que cela changera.... il y aura toujours des discordances tant que la loi francaise sur la propriété ne changera pas (et qui dure depuis plus de 200 ans) Mais on peut tout de même espérer une amélioration notable grace à la définition numérique de la propriété.
Hors ligne
#11 Sat 14 May 2016 09:53
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Re: Données MAJIC EDIGEO DVF ...
Bonjour,
le paradoxe français : quand on veut qu'une norme se développe, on la rend publique et gratuite : la norme Edigeo se payait 1000 francs il me semble à l'époque (94)
Oui les joie de l'AFNOR. Et bien évidemment il faut la rendre libre.
il y aura toujours des discordances tant que la loi francaise sur la propriété ne changera pas (et qui dure depuis plus de 200 ans)
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.
en donnant mon opinion qui ne vaut pas grand chose d'ailleurs wink
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
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#12 Sat 14 May 2016 12:24
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4779
Re: Données MAJIC EDIGEO DVF ...
Hello
1) Merci les Pros
2) Je sais bien que le format EDIGEO est en principe "parfait" topologiquement ...
Je manipule souvent du cadastre en DWG (sous AutoCAD MAP avec les donnees attributaires EDIGEO) provenant de la norme EDIGEO
En plus on a de magnifiques MPolygons (ou Poly-Polygons) sur les Parcelles et Batiments
Dans le genre, j'admire souvent le cadastre du centre historique d'Avignon ...
3) Mais on aurait tres bien pu "imposer" du SHP "parfait" topologiquement (sans chevauchement)
Les outils existaient/existent pour verifier ce genre de choses !
Bon WE, GeoBye, Pat
(Autodesk Expert Elite Team)
Hors ligne
#13 Sat 14 May 2016 15:37
Re: Données MAJIC EDIGEO DVF ...
Hello
Mais on aurait tres bien pu "imposer" du SHP "parfait" topologiquement (sans chevauchement)
Les outils existaient/existent pour verifier ce genre de choses !
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)
Hors ligne
#14 Sat 14 May 2016 15:50
Re: Données MAJIC EDIGEO DVF ...
Hello
Je manipule souvent du cadastre en DWG (sous AutoCAD MAP avec les donnees attributaires EDIGEO) provenant de la norme EDIGEO
Hum!!! hum!!! Je me tairai sur le format DXF de la DGFIP (reserve oblige...)
(tonton ! pourquoi tu tousses...)
Dernière modification par christian (Sat 14 May 2016 15:52)
Hors ligne
#15 Sat 14 May 2016 16:32
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4779
Re: Données MAJIC EDIGEO DVF ...
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)
(Autodesk Expert Elite Team)
Hors ligne
#17 Sun 15 May 2016 08:30
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Re: Données MAJIC EDIGEO DVF ...
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.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#18 Sun 15 May 2016 09:59
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4779
Re: Données MAJIC EDIGEO DVF ...
Hello Christophe
YES le DWG résultant (Voir le Micro-DWG - Exemple de Parcelles & Batiments - attaché avec mon Msg precedent) est un PUR vectoriel avec les données attributaires EDIGEO (en Donnees d'Objet de ACAD MAP) sur les Parcelles, les Bâtiments (UN attribut: 1/2 ou Dur/Léger), les Axes de certaines Voiries (avec 10 attributs Texte = une horreur), etc...
Questions ?
Q1 - Je crois que la norme EDIGEO n'a pas beaucoup évoluée ?!
Q2 - Alors que la norme MAJIC bouge "un peu" ?!
GeoBye, Pat
Dernière modification par Patrice (Sun 15 May 2016 11:13)
(Autodesk Expert Elite Team)
Hors ligne
#19 Mon 16 May 2016 16:54
Re: Données MAJIC EDIGEO DVF ...
Questions ?
Q1 - Je crois que la norme EDIGEO n'a pas beaucoup évoluée ?!
Q2 - Alors que la norme MAJIC bouge "un peu" ?!
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 )
Hors ligne