Le portail francophone de la géomatique

Bonjour,

Désolé il était tard, pas vu que j'avais laissé un fichier bidon pour test. La doc arrive ..
Il vous faut deziper les tar.bz2 deux fois (vers tar puis vers "normal" dans un répertoire, avec la commande chargez thf vous désignez le répertoire contenant les fichiers edigeo (en fait thf est le fichier "maître" d'où le nom de la fonction), ensuite dans option vous réglez le nombre de processus Edigéo, le nombre de processus Postgis, puis avec "intégration vous allez lancer réellement l'intégration qui se fait en multi threading.

Le principe:
L'ensemble des lots sont classés en fonction de la taille du plus gros fichier vecteur d'un lot. En désignant dans option le nombre de processus "petits" vous équilibrez la charge. Par exemple 15 processus Edigeo avec 10 petits, cinq processus vont attaquer le début de la liste en traitant les gros fichiers, pendant ce temps, les dix autres attaquent la fin de liste donc les "petits" lots.
les processus Edigéo lisent les fichiers edigeo d'un lot, les chargent en mémoire.
Dès qu'un lot est controlé et chargé, un controleur regarde s'il existe un processus postgis disponible, si oui il lui transmet le lot pour intégration si non il le dépose dans un tampon mémoire. Ce contrôleur vient régulièrement examiner si un lot est disponible dans ce tampon puis le donne au process postgis pour intégration.

Donc c'est à vous en fonction de la machine sur laquelle tourne le logiciel pour régler les options, sachant qu'un programme windows ne peut utiliser plus de deux giga de RAM. Faites des tests et activez le gestionnaire de programme windows pour connaitre la consommation mémoire et processeur.

J'ai oublié un point important, vous devez posséder des droit en écriture sur les répertoire où sont situés les fichiers Edigeo, car un fichier de log est écrit.(pas encore complet d'ailleurs).

NB: le programme cré lui même la base postgis.

Merci Beaucoup Christophe de ce partage. Il ne reste plus qu'à tester !!

Bonjour,

La mise à jour pour la gestion des SRID est faite.
Attention il est de la responsabilité de l'opérateur de savoir ce qu'il fait !!
Ne mixez pas deux jeux de données de projection différente dans la même base.
Vérifiez lors du choix du système de projection qu'il correspond à celui de votre jeux de données, car pas de contrôle du fichier .GEO dans le lot EDIGéO pour l'instant.
Et d'une manière ou d'une autre comme la DGFiP a fait le choix de laissé vide le champs réservé au SRID et utilise un champs alphanumérique dont le contenu est non normé ....

Pour une télécharger cette dernière version du logiciel :

https://github.com/ChristopheVergon/Int … o_1.01.zip

Joyeuses Pâques

Bonjour,

Ajout du MCD et de la documentation pour l'exploiter.

Et oui la suspension c'est pour les séances houleuses, les non-dits et éviter les chutes.

Bonjour Christophe, tout d'abord un grand merci à toi et Tumasgiu, de la part de tes anciens collègues, pour la mise à disposition de cet intégrateur.

Par contre, après plusieurs tentatives, je rencontre un bug au moment où le programme envoie les données vers la base postgis : le programme s'arrête et la base postgis n'est pas alimentée.

Toute la première partie se déroule sans problème et le test de connexion à la base est positif. La base postgis et le schéma existent déjà avant d'utiliser l'intégrateur.

Tu cherchais quelqu'un pour "inaugurer" les bugs : c'est fait ....

Bien cordialement, Pierre-Frédéric

Bonjour,

Si la base de données est existante il vous faut fournir un nom de schéma ne comportant aucune table. Les tables seront crées par le programme.

Si ça ne marche pas essayez de lancer ce script sql sous pgadmin par exemple, il permet la création du schéma et des tables remplacez SRID par la valeur numérique de votre système de projection et monschema par le nom de votre schéma.:

depuis une base quelconque :

CREATE DATABASE  mabasecadastre;
CREATE EXTENSION postgis;

puis dans la base nouvellement crée :

CREATE SCHEMA monschema;
CREATE TABLE monschema.parcelle (idparcelle serial, ptrsubsection integer, numero varchar(255),
contenance integer, dateacte varchar(8), primitive varchar(4),arpente boolean, nfp boolean, anomalie integer,ptrparcasspdl integer,
pdltype varchar(3), numvoie varchar(4), voiemajic varchar(5), rivoli varchar(5),inseemere varchar(3),
prefsecmere varchar(3), sectionmere varchar(2), numplanmere character varying(4), typefiliation varchar(1),millesime varchar(4),active boolean);
SELECT AddGeometryColumn('monschema','parcelle','the_geom',SRID ,'POLYGON',2);
CREATE TABLE monschema.textparcelle (idtextparcelle serial,ptrparcelle integer, numero varchar(255));
SELECT AddGeometryColumn ('monschema', 'textparcelle', 'the_geom',SRID,'POINT',2);
CREATE TABLE monschema.numvoie (idnumvoie serial,ptrparcelle integer, numero varchar(255));
SELECT AddGeometryColumn ('monschema', 'numvoie', 'the_geom',SRID ,'POINT',2);
CREATE TABLE monschema.symblim_parcelle (idsymblim_parcelle serial,sym_id integer,ori_id numeric(9,6), ptrparcelle int)
SELECT AddGeometryColumn ('monschema','symblim_parcelle', 'the_geom',SRID,'POINT',2);
CREATE TABLE monschema.borne_parcelle (idborne_parcelle serial,ptrparcelle int);
SELECT AddGeometryColumn ('monschema','borne_parcelle', 'the_geom',SRID,'POINT',2);
CREATE TABLE monschema.batiment (idbatiment serial, nom varchar (255), dur boolean, millesime varchar (4),active boolean);
SELECT AddGeometryColumn('monschema','batiment','the_geom', SRID ,'POLYGON',2);
CREATE TABLE monschema.subsection (idsubsection serial, nom varchar (10),ptrsection integer);
SELECT AddGeometryColumn('monschema','subsection','the_geom',SRID ,'POLYGON',2);
CREATE TABLE monschema.section (idsection serial, nom varchar (10),ptrcommune integer,fusion varchar(3));
SELECT AddGeometryColumn('monschema','section','the_geom',SRID,'POLYGON',2);
SELECT AddGeometryColumn('monschema','section','the_point',SRID,'POINT',2);
CREATE TABLE monschema.commune (idcommune serial, nom varchar (255),insee varchar(3));
SELECT AddGeometryColumn('monschema','commune','the_geom',SRID,'POLYGON',2);
SELECT AddGeometryColumn('monschema','commune','the_point',SRID,'POINT',2);
CREATE TABLE monschema.lieudit (idlieudit serial);
SELECT AddGeometryColumn('monschema','lieudit','the_geom',SRID,'POLYGON',2);
CREATE TABLE monschema.label (idlabel serial, valeur varchar (255),ptrobj integer,reftable smallint,ordre smallint,police varchar(255),hauteur real,angle real);
SELECT AddGeometryColumn('monschema','label','the_geom',SRID,'POINT',2);
CREATE TABLE monschema.voiep (idvoiep serial, valeur varchar (255),police varchar(255),hauteur real,angle real);
SELECT AddGeometryColumn('monschema','voiep','the_geom',SRID ,'POINT',2);
CREATE TABLE monschema.tronfluv (idtronfluv serial,ptrcommune integer);
SELECT AddGeometryColumn('monschema','tronfluv','the_geom', SRID ,'POLYGON',2);
CREATE TABLE monschema.zonecommuni (idzonecommuni serial,ptrcommune integer);
SELECT AddGeometryColumn('monschema','zonecommuni','the_geom',SRID,'LINESTRING',2);
CREATE TABLE monschema.tronroute (idtronroute serial,ptrcommune integer);
SELECT AddGeometryColumn('monschema','tronroute','the_geom',SRID,'LINESTRING',2);
CREATE TABLE monschema.topoline (idtopoline serial, nom varchar (255),ptrcommune integer,symbol integer);
SELECT AddGeometryColumn('monschema','topoline','the_geom',SRID ,'LINESTRING',2);
CREATE TABLE monschema.tpoint (idtpoint serial, ptrcommune integer,valeur varchar(255),symbol integer,ori real);
SELECT AddGeometryColumn('monschema','tpoint','the_geom',SRID,'POINT',2);
CREATE TABLE monschema.tsurf (idtsurf serial, valeur varchar(255), symbol integer,ptrcommune integer);
SELECT AddGeometryColumn('monschema','tsurf','the_geom',SRID,'POLYGON',2);

Dernière modification par ChristopheV (Tue 22 May 2018 16:21)

Bonjour à tous,

Après correction de deux anomalies majeures voici une version dite stable :
(dites non si ce n'est pas le cas) :

https://github.com/ChristopheVergon/Int … stable.zip

Précisions :

Premier bugg si le PC n'était pas configuré avec le séparateur décimal "." mais virgule plantage ! (corrigé)
Deuxième : si la BD était créée et le schema aussi pas de création de table: correction faite.
ATTENTION : Si vous souhaitez intégrer vos données dans une base et un schéma existant il ne faut pas que votre schéma contienne des données ou tout du moins il ne faut pas qu'il contienne de tables nommées :
commune
section
subsection
parcelle
batiment
lieudit
label
tronfluv
zonecommuni
tronroute
topoline
tpoint
voiep
tsurf
selectedparcelle

Autre point vous pouvez suivre les progrès de l'intégration en utilisant QGis et en rafraîchissant régulièrement la visu de la table parcelle par exemple.

Bonjour,

@pfj : Merci pour le retour.
Peux tu me dire combien de parcelles ont été intégrées en 4 h ?
Deuxièmement peux tu me donner le type d'erreur dans les lots edigéo ? J'ai constaté (et ETALAB aussi je crois) que la moulinette PCIVecteur vers EDIGéO est parfois fantasque ...
Erreur d'attribut manquant ? Erreur de géométrie ? (là dans notre cas cela devrait passer) Erreur de longueur d'attribut texte (là aussi c'est géré) ?
C'est pour pouvoir tester les erreurs manifeste les rattraper tout l'équilibre étant de permettre le signalement dans les logs sans interrompre le programme et la rapidité de l’exécution.

Nota : il n'est pas possible pour l'instant de créer une bd pour plusieurs départements car le nom des commune n'est pas renseigné dans EDIGéO. Donc il peut y avoir collision entre deux commune de même code insee de département différent. Dans ce cas la commune numéro deux n'est pas crée et les parcelles sont rattachées logiquement (dans la base) à la première même si leur géométrie reste correcte. Je ferai un correctif en utilisant un ficxhier insee des communes de France.

Bonjour,

Merci pfj !

Pour la première erreur c'est une non conformité par rapport à la norme, en effet EOMT signifie fin de fichier (couplée avec BOMT début fichier).
Pour le reste si le SCD edigéo indique une relation entre deux objets et que les fichiers vecteurs ne contiennent pas cette relation forcément ça plante.
La aussi c'est une non conformité par rapport à la norme.

C'est de la responsabilité de la moulinette PCI générant l'export EDIGéO de respecter la norme ! Peut-être faire une remontée chez le concepteur PCI-Vecteur ? En tout cas nous ne pouvons pas faire de supposition et d'adaptation, la norme est claire et nous nous référons au standard.

Pour les chiffres, ils confirment une chose, plus les fichiers vecteurs sont riches plus le temps d'intégration est long. Comparativement pour 360 communes et 1 million der parcelles nous mettons 2 h 30 en négligeant l'aspect puissance de la machine il est clair que nous avons beaucoup de planches cadastrales avec de grandes parcelles de montagne sans bâti, sans détails topo etc ...
Autre enseignement la constitution des lots EDIGéO pour des communes "riches" au sens vectoriel doit se faire à la feuille et non à la section.

Bonjour,

Il faut dezziper les .tar.bz2 deux fois pour obtenir les fichiers "lisibles" en format texte, pour un lot vous aurez alors des .thf, .vec, .qal ...
le premier problème vient de là.

Pour le SRID j'ai mis une liste provenant d'une page officielle IGN, s'il faut en ajouter pas de soucis nous ferons la modif.

Bonjour,

Pour l'erreur de topologie, cela vient des données sources de la DGFiP.
Je viens de regarder le code, il faut effectivement lever cette erreur. Dans la version que nous utilisons (topologie) ces polygones en erreur sont inscrit dans une table spécifique avec le N° de l'objet edigéo, et la référence du lot.
Je fais le nécessaire dès que possible pour la version "grand public", malheureusement pas avant fin de semaine, car emploi du temps un peu chargé.

Pour le ptrsubsection idem, c'est une modif récente qui ne fonctionne pas. Désolé.

Je m'en occupe au plus tôt.

Bonjour,

Il ne faut surtout pas utiliser le plugin cadastre avec notre modèle de données.

Nous faisons effectivement le lien avec les fichiers MAJIC, vous aurez peut-être remarquer que la structure de la table "parcelle" est déjà prête pour cela.
Nous réfléchissons à mettre en ligne le script d'intégration MAJIC, pas de décisions prise à ce jour.

En fait notre modèle "complet" c'est celui-la :

https://georezo.net/forum/viewtopic.php?id=109233

Bonjour,

Il utilise le SRID indiqué dans l'IHM pour les colonne géométrie, donc UpdateGeometrySRID() a posteriori permet de régler le pb.

https://postgis.net/docs/UpdateGeometrySRID.html

Je modifie l'interface, avec une case "autre SRID" qui ouvrira une boite de dialogue, l'utilisateur indiquera alors le SRID désiré.
Dommage que les fichiers .GEO des lots ne respectent pas un standard, cela aurait permis d'éviter ce genre de choses.

Bonjour Dof,

il y a au moins une erreur dans votre liste.
GUAD48UTM20 correspond au srid 2970