Import - TOPO: formatage des données MAJIC pour commune et voie

[mdouchin]

Import MAJIC - Abandon du support des fichiers FANTOIR au bénéfice des fichiers TOPO

Travail en cours... A faire

• Modifier les tests pour utiliser des données de 2024 (là ils passent car se basent sur 2019
• Ajouter la méthode d'import du/des fichiers TOPO via ogr2ogr (pour l'instant, requête sur table vide)

• Ticket : evolution dgfip -> plus de FANTOIR en 2022, remplacé par TOPO #345
• Financé par le CRAIG https://www.craig.fr/

[mdouchin]

@landryb Je poursuis la discussion ici.

Est-ce que je corrige les fichiers majic3_formatage_donnees.sql pour les années 2024 et 2023 ou uniquement pour 2024 ?

Je vais travailler sur l'import via ogr2ogr du fichier topo dans la base. Pour l'instant, ce PR se base sur un import local sur ma machine.

[landryb]

Est-ce que je corrige les fichiers majic3_formatage_donnees.sql pour les années 2024 et 2023 ou uniquement pour 2024 ?

2024 je pense, en 2023 fantoir était encore publié/mis a jour il me semble.

Je vais travailler sur l'import via ogr2ogr du fichier topo dans la base. Pour l'instant, ce PR se base sur un import local sur ma machine.

tu veux dire qu'on part du principe que l'utilisateur a téléchargé le fichier TOPO (france entière) en CSV sur son poste?

[mdouchin]

Est-ce que je corrige les fichiers majic3_formatage_donnees.sql pour les années 2024 et 2023 ou uniquement pour 2024 ?

2024 je pense, en 2023 fantoir était encore publié/mis a jour il me semble.

Ce que je veux dire, c'est que j'ai enlevé dans le code du plugin toute mention de Fantoir. Donc la prochaine version ne permettra pas d'importer du FANTOIR, seulement du TOPO. Je n'ai pas envie de maintenir plein de IF dans le code pour supporter ce format qui est devenu obsolète.

Donc OK pour changer seulement le fichier 2024, mais de toute façon l'import ne fonctionnera plus avec la prochaine version du plugin pour ces années 2023, 2022, etc., même s'il mettent du FANTOIR et choisissent 2023 (ou plus vieux). Ils devront récupérer le ZIP du plugin de la version 1.20.0 s'il veulent vraiment importer des données anciennes (normalement, c'est interdit de conserver des millésimes anciens, donc cela ne me gêne pas d'imposer cela)

Je vais travailler sur l'import via ogr2ogr du fichier topo dans la base. Pour l'instant, ce PR se base sur un import local sur ma machine.

tu veux dire qu'on part du principe que l'utilisateur a téléchargé le fichier TOPO (france entière) en CSV sur son poste?

Non pas du tout, cela voulait juste dire "je travaille dessus". Je vais mettre à jour le PR prochainement, avec du code fonctionnel. J'ai testé en plaçant dans le répertoire MAJIC un fichier TOPO_xx.csv issu de https://drive.opendata.craig.fr/s/opendata?path=%2Fadresse%2Ftopo et tout me semble OK. Je dois compléter la documentation avant de te demander de tester ce PR.

[Gustry]

Ce que je veux dire, c'est que j'ai enlevé dans le code du plugin toute mention de Fantoir. Donc la prochaine version ne permettra pas d'importer du FANTOIR, seulement du TOPO. Je n'ai pas envie de maintenir plein de IF dans le code pour supporter ce format qui est devenu obsolète.

Très bien. Il faudra juste bien documenter cette partie la.
Je peux rajouter sur la page d'accueil de https://docs.3liz.org/QgisCadastrePlugin/ une mention spéciale. J'imagine que cela sera une version majeure aussi ?

[mdouchin]

@landryb Je viens de pousser une version compatible avec TOPO. J'ai testé avec PostGIS et Spatialite. Peux tu tester de ton côté avec qq données volumineuses (un ou 2 départements) sur PostgreSQL et SQLite ?

NB: maintenant le champ natvoi peut contenir des valeurs NULL. Il faudra peut-être adapter les outils tiers (ajout de Coalesce() lors de concaténations).

Au passage, j'ai découvert que le contenu du champ libelle du fichier TOPO ne respecte pas toujours la nomenclature. Selon le PDF Description_fichier_TOPO_20241003.pdf le libellé contient pour les voies

Code nature de voie sur 4 caractères, libellé de voie sur 26 caractères et 40 caractères à blanc pour les voies.

Or c'est souvent faux, notamment pour les "type voie" = 3, cad les toponymes. Si on applique tel quel, on peut se retrouver avec des mauvaises données en parsant pour isoler natvoi (c'était aussi le cas avec le script topo2fantoir). Par exemple un JARDINS DU MACHIN devient natvoi = JARD et libelle = IN DU MACHIN

J'ai essayé de limiter la casse en ajoutant un "type voie" != '3' car c'est surtout les toponymes qui sont concernés (mais il existe des voies, type 1, qui sont concernées)

[landryb]

j'ai toujours du mal a tester sur spatialite, je tombe toujours sur l'erreur de consommation mémoire, même en baissant le nb de lignes a 10k. Je vois pour faire un essai avec postgis ou la base serait sur un serveur distant.

[mdouchin]

j'ai toujours du mal a tester sur spatialite, je tombe toujours sur l'erreur de consommation mémoire, même en baissant le nb de lignes a 10k. Je vois pour faire un essai avec postgis ou la base serait sur un serveur distant.

Est-ce que tu peux stp faire remonter l'erreur (copier/coller le texte, l'erreur Python s'il y en a une, une copie d'écran) pour que je puisse investiguer ? Tu pourrais aussi tester avec l'option "DEFAULT" pour le stockage temporaire.

Sinon, l'idée est que tu testes la fonctionnalité, pas forcément les performances (ça n'a pas dû bouger beaucoup de ce côté là sur ce PR) . Et notamment voir si les données sont utilisables dans les outils tiers que vous pourriez utiliser (Cadastrapp par exemple)

[landryb]

je vais tester avec DEFAULT à la place de MEMORY, mais a ce stade, vu comment l'import d'un département entier prend comme temps, je vais me concentrer sur la comparaison de ce qui est en base entre l'import de fantoir et l'import de topo pour qqs communes.

[landryb]

j'ai pu tester sur une commune du 63, et pour la table commune:

• la ou ruract était vide il y'a maintenant NULL. j'ai l'impression que ca correspond aux communes avec typcom=R
• on a perdu clerivili, mais c'était attendu
• carvoi/indpop/poprel/poppart/popfict/annul/codvoi/typvoi/indldnbat/motclas sont NULL. ils étaient vide auparavant.
• dtcreart a la nouvelle date venant de TOPO, 1875 dans la majorité.

je ne sais pas si ces champs étaient utilisés qqpart, mais leur valeur avait peu de pertinence je pense.

la valeur la plus longue pour le champ libcom est mtn de 27 chars, c'était 30 chars avec fantoir, mais c'était de toute facon paddé avec des espaces a droite (eg pas de pertes de caracteres pertinents, c'est SAINT-QUENTIN-SUR-SAUXILLAN dans les 2 cas)

pour les 2 tables voies et communes j'ai été un peu surpris de voir toutes les voies du département importées, je me serais attendu à n'avoir que les voies de la commune présente dans MAJIC.. mais c'était déjà le cas avec FANTOIR. le FANTOIR que j'ai importé avait été crée depuis topo2fantoir, ce n'est pas un FANTOIR 'original'.

pour la table voie:

• il y'a des NULL dans natvoie la ou le champ était vide.
• il y'a des NULL dans codvoir
• on retrouve les mm valeurs dans dtecreart
• j'ai effectivement des cas ou l'import de TOPO est mieux que FANR: ex 'natvoie=MAIS, libvoi=ON ROUGE' devient 'natvoie=NULL, libvoi=MAISON ROUGE', ou 'natvoie=CLOS, libvoi=" CLIDOR"' (avec un espace) devient 'natvoie=NULL, libvoi=CLOS CLIDOR' donc ... je ne sais pas si c'est un mieux.

[landryb]

pour la recherche par adresse, j'ai des fois des entrées préfixées par un espace qui se retrouvent 'avant' les autres:

j'avoue que je ne sais pas si c'est normal, n'étant pas utilisateur fréquent du plugin :)

pour une adresse ou j'avais avec fantoir 'natvoi=CAMP' et 'libvoi= CESAR' et ou j'ai maintenant 'libvoi=CAMP CESAR' avec topo la recherche fonctionne.

[landryb]

une fois importé dans un schéma pour cadastrapp via les scripts de https://github.com/georchestra/cadastrapp/tree/master/database, j'ai l'impression de bien retrouver ce qui était natvoi/libvoi (du schéma QGIS) dans les champs cconvo/natvoi/dvoilib (du schéma cadastrapp), avec le code numérique de voie qui suit.. donc pour ce qui est de l'intégration 'descendante' on aurait l'air OK.

@MaelREBOUX @jusabatier il faudrait que vous testiez chez vous aussi ;)

[landryb]

@MaelREBOUX avec ces histoires de natvoi qui peuvent etre NULL, il faudra peut-etre juste adapter cette ligne et cette ligne pour remplacer v.natvoi par Coalesce(v.natvoi,'') (comme fait ici) ? moi ca me dépasse tout ce SQL :)