Modifier la méthode de création des attributs géométriques lors de la création des tables

3liz / QgisCadastrePlugin

A QGIS plugin which helps users to import the french land registry ('cadastre') data into a database. It is meant to ease the use of the data in QGIS by providing search tools and appropriate layer symbology.

GNU General Public License v2.0

60 stars 41 forks source link

Modifier la méthode de création des attributs géométriques lors de la création des tables #241

Open MaelREBOUX opened 3 years ago

MaelREBOUX commented 3 years ago

Pointé par @mdouchin dans https://github.com/3liz/QgisCadastrePlugin/issues/237#issuecomment-669824723

Nous devons en effet adapter le code et ne plus utiliser cette fonction (issue d'un historique), mais directement créer les géométries via la syntaxe geometry(Point, 2154)

Tous les attributs géométriques créés par les requêtes SQL disponibles dans https://github.com/3liz/QgisCadastrePlugin/tree/master/scripts/plugin sont en effet créés après la création de la table, en 2 temps.

Exemple :

CREATE TABLE geo_commune
(
  geo_commune text NOT NULL,
  annee text NOT NULL,
  object_rid text,
  idu text,
  tex2 text,
  creat_date date,
  update_dat date,
  commune text,
  lot text,
  ogc_fid serial NOT NULL
);
SELECT AddGeometryColumn ( current_schema::text, 'geo_commune', 'geom', 2154 , 'MULTIPOLYGON', 2 );

MaelREBOUX commented 3 years ago

Question pour @mdouchin à propos des systèmes de coordonnées.

Dans commun_create_metier.sql toutes les tables sont créées en Lambert93 (2154) (exemple avec geo_commune)

Puis on charge les données EDIGEO via la fonction importEdigeoThfToDatabase dans cadastre_import.py A cette étape on récupère et utilise 2 variables sourceSridFull et targetSridFull récupérées depuis l'interface QGIS.

Vu le code j'en déduis qu'on charge (pour notre cas) des données en 3948 alors que les tables sont spécifiées en 2154. Or, quand je regarde après le chargement, l'attribut geom est bien en 3948 pour toutes les tables / couches.

A quel moment la redéfinition du système de projection se fait ?

Gustry commented 3 years ago

Je suppose qu'il y a un remplacement à la volée du système de projection dans le fichier SQL quand il est lu par Python : https://github.com/3liz/QgisCadastrePlugin/blob/89b8e11247d0b08ae34cd1fc09e19cc871aa54d7/cadastre_import.py#L244 et 10 lignes plus bas https://github.com/3liz/QgisCadastrePlugin/blob/89b8e11247d0b08ae34cd1fc09e19cc871aa54d7/cadastre_import.py#L254

MaelREBOUX commented 3 years ago

okay ! merci @Gustry

Pour savoir si on devait retoucher la gestion des projections en passant ou pas... Donc : pas. Mais on va rajouter une ligne de commentaire ;)

@EtienneRouvin est sur le coup

MaelREBOUX commented 3 years ago

@mdouchin ou @Gustry Vous pourriez nous redire où se trouve le fichier / la fonction qui reformate les requêtes SQL natives PostGIS en requêtes compatibles spatialite SVP ?

[edit] Retrouvé : https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre_common_base.py#L229

EtienneRouvin commented 3 years ago

La syntaxe geometry(Multipolygon, 2154) ne fonctionne pas sous Spatialite, on doit donc passer par du SELECT AddGeometryColumn ( current_schema::text, 'geo_commune', 'geom', 2154 , 'MULTIPOLYGON', 2 );