[Général] La recherche de parcelle ne porte que sur les parcelles de la matrice foncière

[MaelREBOUX]

Un pb : la recherche de parcelle ne porte que sur les parcelles de la matrice foncière. Pas optimal : il faut que cela porte sur les parcelles de la matrice UNION les parcelles du plan. Sinon impossible de tout trouver.

CREATE MATERIALIZED VIEW #schema_cadastrapp.parcelle AS
  SELECT parcelle.parcelle, 
  ...
    FROM dblink('host=#DBHost_arcopole dbname=#DBName_arcopole user=#DBUser_arcopole password=#DBpasswd_arcopole'::text, 
    'select
      codparc as parcelle,
    ...
    from #DBSchema_arcopole.dgi_nbati'::text) 
  parcelle(
    parcelle character varying(19), 
...

C'est l'utilisation exclusive de la table dgi_nbati qui m'embête.

[MaelREBOUX]

problème lié pcq on ne tape que la table dgi_nbati : erreur 500 sur infobulle sur une parcelle rejetée.

Parcelle rejetée = parcelle apparaissant sur le plan mais sans équivalent dans la base foncière.

[pierrejego]

Il faudrait faire une UNION entre edi_parc et dgi_nbati. On a pas ce problème sur QGIS car on utilise directement la table geo_parcelle

[MaelREBOUX]

@pierrejego certain ? pcq #216 ?

[MaelREBOUX]

@pierrejego on doit forcément avoir le pb inverse sur le modèle QGIS : ça ne cherche que sur les parcelles du plan et pas sur les parcelles foncières.

Je suis parvenu à une solution qui me permet de disposer d'une vue matérialisée qui contient TOUTES les parcelles cadastrales.

1. on crée une vue matérialisée _parcelleunion qui va chercher dans les tables edi_parc et dgi_nbati pour n'en faire qu'une. Elle contient tous les attributs communs possibles (code ommune, code parcelle, section, numéro, surface)
2. on modifie la création de la vue matérialisée parcelle pour que la source d'appui soit la vue _parcelleunion et non plus dgi_nbati. Et on va rechercher les attributs spécifique / en plus dans dgi_nbati dans une sous-requête qui embarque le dblink

Cela rajoute 30 Mo en volume pour 200 000 parcelles.

[MaelREBOUX]

J'ai fait quelques tests ce matin sur le module avec ces nouvelles données. Ca passe bien. J'ai eu une crainte car j'ai un surnombre de 54 parcelles sur 198 542 attendues.

Ces 54 parcelles correspondent à des cas où la seule différence porte sur le fait que l'attribut supf de edi_parc est à '0' là où j'ai une surface dans dgi_nbati.

Dans le module la recherche de 3 parcelles concernées produit ceci :

Un double-clic ou une localisation sur l'une ou l'autre des lignes produit l'effet normal attendu : localisation sur ou affichage de la fiche d'info. Normal : les enregistrements correspondants existants dans les 2 tables.

SELECT * from cadastre.edi_parc where supf = 0 rend 61 parcelles concernées.

Vu le très petit nombre de parcelles concernées (0.03 % pour cette maj) je ne touche à rien.

[MaelREBOUX]

Maintenant je fais une PR sur une branche spécifique pour patcher uniquement arcopole dans un premier temps ? ou je patche que sur arcopole uniquement ?

Je ferais bien une branche + PR spécifique en laissant l'issue ouverte pour que vous vous y penchiez un jour où vous avez le temps.

[MaelREBOUX]

fait ici : https://github.com/sigrennesmetropole/cadastrapp/commit/fc1ad827ec337f82f508fa5fa8a5c8ec1d63929c

reste à reporter sur modèle QGIS pour pouvoir faire une PR.

[MaelREBOUX]

Zut : fermé trop vite : on en est où @jusabatier ? Faudrait que je trouve une parcelle pour test sur la PF de test de GFi.

[jusabatier]

Je n'avais pas encore eu le temps de m'y pencher, mais le fait de remonter une parcelle de la matrice sans équivalent géométrique (ou l'inverse) ne pose-t-il pas de problème à l'ouverture de la fiche de parcelle ? Car il ne peut normalement pas trouver de données.

[MaelREBOUX]

Zut : cette issue est passée sous les radars. Je croyais que c'était réglé mais @catmorales qui maj en ce moment notre PF de prod vient de me rappeler l'existence de cette vue spécifique arcOpole. Et je viens de vérifier que c'est pas dans master !

Les tests que j'avais fait en août étaient concluants : cela n'avait pas d'impact. Si on essaie de zoomer une parcelle 100% foncière on obtient le message d'erreur que tu as rajouté sur l'absence de géométrie. A l'inverse : fiche info d'une parcelle 100% graphique : on ne voit que les infos localisante / générale (pcq les vues remontent rien). Dit autrement : ça ne cassait rien.

Maintenant depuis août les données ont changé. Il faut que je retrouve des cas !

[MaelREBOUX]

A faire : liste des cas à checker :

• clic sur carte
• bordereau parcellaire
• relevé de propriété

@jusabatier regarde la portabilité sur QIS

[jusabatier]

Equivalent QGis : https://github.com/georchestra/cadastrapp/pull/291

Si présent dans EDIGEO mais pas dans MAJIC :

• Apparait dans la liste de parcelle
• Possibilité de zoomer dessus
• Adresse avec "0 null null"
• Fiche d'info complètement vide
• Impression BP renvoie un code 204

Si présent dans MAJIC mais pas EDIGEO :

• Apparait dans la recherche
• Impossible de zoomer dessus (message d'erreur)
• Fiche d'info parcelle complète
• Erreur 500 sur la génération des BP
• RP sont bien générés

[MaelREBOUX]

Je vais donc retester ici mais j'attend retour @catmorales pour cela.

[pierrejego]

@MaelREBOUX est-ce que tu avais pu tester ?

[MaelREBOUX]

Testé ce jour sur master.

La fenêtre de recherche de parcelles liste bien dorénavant les parcelles EDIGEO en plus des parcelles MAJIC.

Testé en arcOpole et peux pas tester en QGIS.

@jusabatier ou @landryb pourrait confirmer ?

@pierrejego quel commit ?

[MaelREBOUX]

Ha ok :

https://github.com/georchestra/cadastrapp/commit/984dbfa668bd847493b9d4c04d1277edef04cc61 https://github.com/georchestra/cadastrapp/commit/a29532415e2939917c1ad006448ecef11a0bfb80 https://github.com/georchestra/cadastrapp/commit/108a4387799e7ce89e7921b5896b3cc2654eab5e

Principalement :

full outer join #DBSchema_arcopole.edi_parc on dgi_nbati.codparc = edi_parc.id_parc'::text) 

full outer join #DBSchema_arcopole.edi_parc on dgi_nbati.codparc = edi_parc.id_parc'::text) 

[MaelREBOUX]

Normalement ceci est OK. Je ferme. Yahou.