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

[MaelREBOUX]

trafficstars

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]

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]

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]

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]

@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]

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 );

[landryb]

@EtienneRouvin quel est le fix potentiel finalement ? Je vais bientot devoir importer mes 12 départements dans postgis, et je passe sur la v3 justement... donc si je peux tester un fix je suis preneur

[landryb]

si je comprends bien AddGeometryColumn() existe toujours en postgis 3 (cf https://postgis.net/docs/AddGeometryColumn.html) c'est juste la signature qui est mauvaise dans les scripts SQL, et il faut rajouter des casts pour être compatible avec postgis 2 / postgis 3 / spatialite ?

[landryb]

je ne comprends pas bien #237 parce que jusqu'ici je n'ai pas de pbm pour faire d'imports simples/minimaux dans une base psql 12 avec postgis 3 et ma version 'cli' de la release 1.9.0, les colonnes spatiales semblent correctement créees en base.. je vais creuser.

[MathRobin]

T'as essayé avec une base postgre aws rds ? T'as quoi comme versions exactes ? Postgre, plugins, derniers fichiers de cadastre dispo ? Mon but dans #237 c'est de pouvoir importer les données dans une aws rds

[landryb]

non, c'est du postgres/postgis venant des paquets debian pgdg, jamais joué avec aws et encore moins rds. le ticket #226 montre qu'il y'a aussi ce pbm sur du postgis 2.1, donc je pense que ce n'est pas forcement lié a la version de postgis.. mais aux données ? A la version de python utilisée qui ne traite pas forcement les types de la meme facon, et requiert des casts dans certains cas ? mon test était sur une seule commune du dept 38, je vais voir en important un département..

[MathRobin]

Teste avec le département 33 stp, c'est dessus que je galère

[landryb]

oui ben désolé, je trouve que c'est déja pas mal d'avoir 12 départements, et le 33 n'en fait pas partie ;)

[MathRobin]

12 sont passés sans soucis ? Mais c'est trop injuste XD je vais réessayer avec un fichier de cadastre plus récent pour voir

[landryb]

euh, il faut un 'certain temps' pour importer 12 départements, mais jusqu'ici il m'en a fait 7 sans soucis manifeste.. de toute facon, une fois que la table est créee correctement, je pense que tout le reste roule tout seul;

[MathRobin]

Ça marche, je vais essayer avec un autre. Lesquels sont passés chez toi déjà ? Que je tente avec un de ceux là ?

[landryb]

01 03 07 15 26 38 42 43 depuis hier 15h, actuellement 63, reste 69 73 74..

[MathRobin]

OK merci pour les infos !

[mdouchin]

Je souhaite m'attaquer au support de PostGIS 3. Quelqu'un aurait un département de test EDIGEO qui défailleraient avec un PostGIS 3 ? Si oui, quelle version exacte de PostGIS utilisée ?

[MathRobin]

A l'époque j'avais regardé la Gironde (où je vis, j'ai fait simple). Par contre la version de postgis, aucune idée...