Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

#1 mar. 20 mars 2018 18:14

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour

Tumasgiu et moi même avons le plaisir de vous proposer une solution open source écrite en VB.net qui permet d'intégrer les données du plan cadastral au format Edigéo dans une base PostGis.

Il s'agit d'une version BETA.

Ce logiciel est fait pour Windows.

Il permet d'intégrer autant de communes et départements que l'on veut dans la même base de données. La seule limite étant le temps dont vous disposez. Commencez par un petit échantillon car une fois le processus lancé l'interrompre avant la fin conduit à un état instable de la base de donnée.

En test sur une BD locale, il nous faut 2 h 51 mm pour intégrer l'ensemble de la région Corse.

Nous vous laissons découvrir et attendons vos retours ...

https://github.com/ChristopheVergon/Integrateur_edigeo

NB: pour ceux qui voudraient modifier le code source, le module MDC doit être manipulé uniquement par des gens avertis ayant une connaissance intime des API WINDOWS graphiques, car les résultats pourraient être étranges.

Que la force soit avec vous wink


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#2 mar. 20 mars 2018 20:11

Theos2000
Membre
Date d'inscription: 15 juin 2015
Messages: 123

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Quelle chance, car je n'arrivais pas a intégrer certaines communes avec le plugin de postgis. Par contre concrètement cela marche comment #toto est content# ????
Par curiosité car lorsqu'on télécharge le cadastre en Edigeo en libre accès on a du .tar.bz2...on retrouve bien un fichier thf dans le tar.bz2, mais les autres fichiers sont intégrés et si oui quelle est la manip, car j'imagine qu'il faut égalent dezipper en masse...Et merci pour cet outils que j'ai hate d'essayer !!!

Hors ligne

 

#3 mar. 20 mars 2018 22:06

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#4 jeu. 22 mars 2018 17:26

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

Pour indiquer une mise à disposition de la doc d'utilisation.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#5 jeu. 22 mars 2018 20:12

Robin
GeoRezo Team
Lieu: France
Date d'inscription: 31 août 2005
Messages: 13597
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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


Association GeoRezo.net

Hors ligne

 

#6 jeu. 22 mars 2018 23:11

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonsoir,

Je viens de m'apercevoir que le SRID est codé en dur dans le code. Désolé. Je corrige rapidement pour la version compilée.
Pour ceux qui veulent c'est dans le module variables globales du code source. A noté que les sources peuvent être utilisées avec visual studio express c'est gratuit:
https://fr.wikipedia.org/wiki/Microsoft … io_Express

Avoir un SRID en 3942 pour toute la France c'est pas jacobin wink


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#7 jeu. 29 mars 2018 17:40

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#8 jeu. 29 mars 2018 18:12

Pascal Boulerie
Membre
Lieu: France
Date d'inscription: 12 sept. 2005
Messages: 1852
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

ChristopheV a écrit:

la DGFiP a fait le choix de laissé vide le champs réservé au SRID et utilise un champ alphanumérique dont le contenu est non normé...


Il me semble que ces points de suspension sont présents pour bien signifier : "dommage que le SRID (Spatial Reference System Identifier) ne soit pas renseigné dans le champ ad hoc"...


Mots-clés : "Action Publique 2022" ; AP2022


« L'État est désormais quasi déliquescent. » (José Cohen-Aknine, ingénieur X-Ponts, IGPEF, dans Déliquescence et renaissance de l'État.)

Hors ligne

 

#9 ven. 30 mars 2018 13:53

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#10 mar. 24 avril 2018 14:41

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

Une nouvelle mise à jour est disponible.

L'utilisateur peut maintenant quitter le programme (menu fichier quitter) pendant l’exécution, avant de se terminer le programme finit l'intégration de TOUS LES lots en cours d'intégration dans la base de données Postgis.

N'hésitez pas à faire remonter d'éventuels buggs, même si je suis pas toujours de bonne humeur, je ne mords pas wink


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#11 jeu. 17 mai 2018 13:01

pfj
Membre
Lieu: Groslée-St-Benoit
Date d'inscription: 14 déc. 2007
Messages: 3

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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

Hors ligne

 

#12 mar. 22 mai 2018 08:03

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

Merci wink

Manifestement la base de données n'est pas créée. J'ai eu la même remontée en privé.
Je rentre de congés donc je regarde ça dans la journée ...
A bientôt


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#13 mar. 22 mai 2018 10:07

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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 :

Code:

CREATE DATABASE  mabasecadastre;
CREATE EXTENSION postgis;

puis dans la base nouvellement crée :

Code:

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 (mar. 22 mai 2018 16:21)


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#14 mer. 23 mai 2018 18:47

Clothilde B
Membre
Lieu: Bastia
Date d'inscription: 18 janv. 2018
Messages: 2

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour Christophe et Tumasgiu,

Le problème persiste même en créant les tables au préalable avec le script que vous avez joint au-dessus !
Le programme cesse de fonctionner lors de l'écriture dans la base Postgis.

Clothilde

Hors ligne

 

#15 lun. 28 mai 2018 16:25

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#16 mar. 29 mai 2018 21:43

pfj
Membre
Lieu: Groslée-St-Benoit
Date d'inscription: 14 déc. 2007
Messages: 3

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonsoir Christophe, merci pour les corrections effectuées sur le programme.

Je n'ai pas pu encore le tester et j'ai donc utilisé les codes fournis dans ton message du 22/05.

En 4 heures, l'intégrateur a permis la création d'une BD de l'ensemble du département de l'Ain. Moins quelques lots Edigeo qui demandent des corrections avant d'être acceptés par l'intégrateur.

Bien cordialement.

Pierre-Frédéric

Hors ligne

 

#17 mer. 30 mai 2018 08:21

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#18 ven. 08 juin 2018 16:49

pfj
Membre
Lieu: Groslée-St-Benoit
Date d'inscription: 14 déc. 2007
Messages: 3

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

l'intégrateur a permis l'incorporation en 4h14min6sec, sur un PC portable, de :
     - 409 communes
     - 7537 feuilles
     - 1 327 641 parcelles

Concernant les anomalies sur les lots Edigéo refusés par l'intégrateur, j'en détecte de deux sortes sur les fichiers .vec :
     - une "erreur" commune à tous les lots en échec : deux lignes vides en fin de fichier (après l' EOMT 00:)
     - et dans certains cas : absences de liens section-commune (T3.vec), subdsection-section (T2.vec), parcelles-subdsection (T1.vec), batiment-parcelle (S1.vec), borne-parcelle (S1.vec) et symblim-parcelle (S1.vec).

En espérant t'avoir renseigné.

Bien cordialement.

Pierre-Frédéric

Hors ligne

 

#19 mar. 12 juin 2018 16:35

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#20 sam. 29 septembre 2018 22:14

ogaquiere
Membre
Lieu: guadeloupe
Date d'inscription: 17 nov. 2009
Messages: 9
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour Christophe,

je viens d'essayer ton intégrateur pour les communes de la Guadeloupe.
J'ai suivi les instructions sur github :
- dezipper les fichiers dans un répertoire (2018). Je me retrouve avec les sous-répertoires des communes et les fichiers .bz2 dedans (voir PJ)
- charger les fichiers thf dans l'intégrateur, en indiquant 2018, et sélectionner le répertoire 2018
- sélectionner la bonne projection. Je suis d'ailleurs étonné que ce ne soit pas EPSG 32620 en lieu et place de 4559, qui a une ellipsoïde "GRS 1980" et non "WGS 84"
- Lancer l’intégration et renseigner les infos de connexion à Postgresql (9.4). Pour info, je travaille depuis une virtualbox win32 et tape sur le
postgresql de la machine hôte (Debian).

Résultats :
- la popup "fin de l'intégration" apparaît 1s après (voir PJ)
- les tables et les séquences ont bien été créées dans la BD mais sans ajout de données.

Quel problème vois-tu à priori ?

Merci d'avance

Dernière modification par ogaquiere (sam. 29 septembre 2018 22:15)


Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

GéoDeSIS

Hors ligne

 

#21 dim. 30 septembre 2018 12:15

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#22 dim. 30 septembre 2018 21:25

ogaquiere
Membre
Lieu: guadeloupe
Date d'inscription: 17 nov. 2009
Messages: 9
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

merci pour la réponse.
Ca marche mieux en effet.
Cependant, j'ai un autre problème en cours de traitement de toutes les communes d'un coup :
<<
Signature du problème :
  Nom d’événement de problème:    CLR20r3
  Signature du problème 01:    Integrateur_Edigeo.exe
  Signature du problème 02:    1.0.0.0
  Signature du problème 03:    5b0c0e59
  Signature du problème 04:    Npgsql
  Signature du problème 05:    2.2.1.0
  Signature du problème 06:    54228f78
  Signature du problème 07:    8d0
  Signature du problème 08:    680
  Signature du problème 09:    Npgsql.NpgsqlException
  Version du système:    6.1.7601.2.1.0.256.1
  Identificateur de paramètres régionaux:    1036
  Information supplémentaire n° 1:    0a9e
  Information supplémentaire n° 2:    0a9e372d3b4ad19135b953a78882e789
  Information supplémentaire n° 3:    0a9e
  Information supplémentaire n° 4:    0a9e372d3b4ad19135b953a78882e789
>>


J'ai aussi regardé les logs de postgres  et je vois une erreur. Est-elle liée ? probablement :
<<
ERREUR:  GEOSPointOnSurface: TopologyException: Input geom 1 is invalid: Self-intersection at or near point 645729.20059922105 1766168.1910879475 at 645729.20059922105 1766168.1910879475
2018-09-30 12:21:45 AST [18152-2] olive@cadastre INSTRUCTION :  SELECT st_asbinary(st_pointonsurface(st_geomfromwkb((('\x010300000001000000AF0E000000000000FC972341000000
.........................
>>


Erreur géo sur une entité  ?? Y aurait-il un moyen de rendre le code plus robuste ?

J'ai donc essayé avec une seule commune et le traitement arrive au bout. Après examen de la BD, table "parcelle", je vois que le champ "ptrsubsection" n'est en majorité pas renseigné. 59 seulement sur 16 000 parcelles. Bizarrement, cela correspond au nombre de sous-sections !!!  comme si 1 seule parcelle par "subsection" voyait sa clé externe renseignée.  Du coup, pas facile de faire des requêtes ensuite.
Est-ce un bug ?

Merci d'avance

Dernière modification par ogaquiere (dim. 30 septembre 2018 23:34)


GéoDeSIS

Hors ligne

 

#23 lun. 01 octobre 2018 08:50

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#24 lun. 01 octobre 2018 16:11

ogaquiere
Membre
Lieu: guadeloupe
Date d'inscription: 17 nov. 2009
Messages: 9
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour Christophe,

merci pour ces éclaircissements. J'attends donc la version corrigée.
J'ai une question d'ordre plus général : une fois ces fichiers EDIGEO importés, y a t-il un moyen simple d'établir des jointures
avec les fichiers MAJIC, dans une phase ultérieure ? ou bien faut-il passer par une autre procédure (plugin cadastre par exemple) pour
réimporter EDIGEO + MAJIC d'un coup ?

Concernant la projection de mes fichiers EDIGEO, j'ai vérifié et ils sont encore dans l'ancienne projection GUAD48UTM20 (EPSG 2970) avec un datum de 1948 (remplacé ensuite par le RRAF 1991).  bizarre quand même !
Si le projection choisie dans l'IHM ne correspond pas à la projection des fichiers sources, que fait l'intégrateur ?

Bonne journée

Dernière modification par ogaquiere (lun. 01 octobre 2018 17:43)


GéoDeSIS

Hors ligne

 

#25 lun. 01 octobre 2018 17:37

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

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


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#26 mar. 02 octobre 2018 13:09

ogaquiere
Membre
Lieu: guadeloupe
Date d'inscription: 17 nov. 2009
Messages: 9
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour Christophe,

ah oui ce serait pas mal l'intégration des MAJIC.

Une autre question : concernant la projection de mes fichiers EDIGEO, j'ai vérifié et ils sont encore dans l'ancienne projection GUAD48UTM20 (EPSG 2970) avec un datum de 1948 (remplacé ensuite par le RRAF 1991).  bizarre quand même mais bon !
Si la projection choisie dans l'IHM ne correspond pas à la projection des fichiers sources, que fait l'intégrateur ?

Cela vaudrait-il le coup de rajouter une fonction de reprojection lors de l'intégration en BD ? (à la manière du plugin cadastre)

Bonne journée


GéoDeSIS

Hors ligne

 

#27 mer. 03 octobre 2018 13:40

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 sept. 2005
Messages: 2721
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour,

Si la projection choisie dans l'IHM ne correspond pas à la projection des fichiers sources, que fait l'intégrateur ?


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.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#28 ven. 05 octobre 2018 10:31

Dof
Membre
Lieu: Grenoble
Date d'inscription: 28 oct. 2009
Messages: 311
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Dommage que les fichiers .GEO des lots ne respectent pas un standard, cela aurait permis d'éviter ce genre de choses.


Bonjour,
Voici la correspondance entre les codes du cadastre et les EPSG

const projections = {
    "LAMB93": { "epsg": 2154},
    "RGF93CC42": { "epsg": 3942 },
    "RGF93CC43": { "epsg": 3943 },
    "RGF93CC44": { "epsg": 3944 },
    "RGF93CC45": { "epsg": 3945 },
    "RGF93CC46": { "epsg": 3946 },
    "RGF93CC47": { "epsg": 3947 },
    "RGF93CC48": { "epsg": 3948 },
    "RGF93CC49": { "epsg": 3949 },
    "RGF93CC50": { "epsg": 3950 },
    "GUAD48UTM20": { "epsg": 2070 },
    "MART38UTM20": { "epsg": 2973 },
    "RGFG95UTM22": { "epsg": 2972 },
    "RGR92UTM": { "epsg": 2975 }
}

Hors ligne

 

#29 ven. 05 octobre 2018 14:52

ogaquiere
Membre
Lieu: guadeloupe
Date d'inscription: 17 nov. 2009
Messages: 9
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

Bonjour Dof,

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


GéoDeSIS

Hors ligne

 

#30 lun. 08 octobre 2018 16:00

Dof
Membre
Lieu: Grenoble
Date d'inscription: 28 oct. 2009
Messages: 311
Site web

Re: Intégrateur de données EDIGEO vers Postgis pour windows

ogaquiere a écrit:

Bonjour Dof,

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


Merci pour la correction ! Je corrige ça dans mon script...

Hors ligne

 

Pied de page des forums

Powered by FluxBB

Partagez  |