Fusion de 2 tableaux différents

Bonjour

papicx a écrit :

J'ai visionné le code et dans la version geodae2.xls , la case A1 pointait vers un fichier csv local ( T:\TEMP\geodae.csv) ,
et, si je ne me trompe pas, dans ce cas il fallait faire le job en 2 étapes :

• télécharger le fichier .csv de 57 Mo, l'enregistrer en local dans un dossier dédié
• faire un nouveau fichier excel où là on peut travailler sur le csv pour extraire les infos.
  Je me trompe ?

Dans geodae2 oui il fallait téléchargé mais pas dans geodae2b

Non on ne travaille pas sur un nouveau classeur, on garde le même toujours

papicx a écrit :

Avec PowerQuery, depuis le site, en voulant sélectionner le code postal, ça ne fonctionne pas car il y plus de 1000 lignes à traiter et c'est la limite du logiciel.
L'objectif était de charger un fichier cvs ne contenant que les infos de ma commune.
Visiblement c'était un point de blocage à ma compréhension du fonctionnement de PowerQuery.

À présent, si j'ai bien compris, avec PowerQuery je peux ajouter des colonnes (mes fameuses jaunes) pour "refaire" mon tableau de travail et ainsi les données GeoDAE s'actualiseront à chaque fois que :

1. je mettrais à jour le lien si besoin
2. je cliquerai sur le bouton "actualiser tout"

C'est bien ça ?

Non 1000 lignes n'est pas la limite de traitement (on peut traiter des millions de lignes, c'est la limite d'affichage.
Mais comme déjà dit, dans mon exemple le filtre du CP est passé en paramètre donc on s'en fout...

Et le chargement réel ne se fera qu'à l'issue de la requête donc filtré...
Sinon il faudrait que le site permette un filtre en amont (certains le permettent)

Non on ne crée pas les colonnes jaunes dans PowerQuery si on doit faire des mises à jour (sauf colonne calculée depuis les données sources)

Il faut charger les données, dans un onglet, ajouter les colonnes. Ce qui donnera le fichier de travail initial(version 1).

Ensuite on croisera le fichier téléchargé avec le fichier de travail pour générer un nouveau fichier de travail à jour.
Une fois vérifié le résultat, on fera une copie des données (donc déconnectée de la requête) de cette version 2 pour écraser la version 1 afin que la source de la prochaine MAJ soit la version amendée.

Pour le message suivant :

On ne touche pas au code global mais au étapes

Il faut définir clairement comment on veut filtrer sur les deux ou sur l'un des 2 ou 3 ?

Si le CP ne correspond qu'à une ville le CP est fiable sinon on a n VILLE. Donc à clarifier...

Bonjour 78chris.

Merci de toutes ces infos. J'y vois un peu plus clair.

Pour les filtres c'est "ou" a chaque fois.

Peux tu me donner des indications comment faire stp ?

Lorsque j'ai voulu toucher à ça, en cliquant dessus, ça supprimait la ligne. Et quand je cliquais sur "ajouter une étape" je la renommais (pour travailler propre) et c'était le nom de la précédente qui s'affichait. J'étais perdu.

Concernant le code postal, certains propriétaires de DAE n'ont pas saisi le code postal lors de l'enregistrement. :(

D'où je suis oblige de faire des recherches complémentaires.

Comme tu as vu j'ai essayé d'ajouter des variables (comme tu as fait pour le code postal. De ce que j'ai cru comprendre. Mais visiblement ce n'était pas la bonne méthode.

Pour en revenir sur le croisement des nouvelles infos avec les "anciennes" , je suppose que c'est avec des formules RECHERCHEV ? que je ne maîtrise pas encore. J'apprends chaque jour...

Bonjour

J'ai

• ajouté 2 champs dans le tableau de paramètres
• récupéré leurs valeurs dans la requête
  On clique sur Fx et on remplace par ce qu'on veut dans la barre de formule.
  = PStep[Code Postal]{0} indique, pour la table à l'étape précédente nommée PStep, la colonne Code Postal et {0} la 1ère ligne (cela démarre à 0).
• Modifié le filtre
  = Table.SelectRows(#"Type modifié", each ([c_com_cp] = Text.From(CP) or [c_com_insee]=Text.From(INSEE) or [c_com_nom]=VILLE))

Bizarrement les noms de champs de la source semblent avoir évolué : un champ avec euro se mettait en erreur, j'ai supprimer son typage mais j'espère que leur structure est stable...

Ok MERCI

A un moment donné dans mes essais je n'était pas loin.

Sf que je me focalisais sur la variable.

Là je suis sur mon phone. Je regarderai ça en détail. Bien entendu je te ferai un retour.

Et pour croiser les données, stp ?

J'ai lu il y a qq temps qu'il existe une fonction similaire a la recherchev avec vba. ( + puissante du coup et surtout plus facile à manipuler).

C'est ça qu'il va falloir utiliser ? J'suis chaud :)

RE

Croiser des données dans la logique base de données utilisée par PowerQuery c'est simple, puissant et efficace (en cours les stagiaires Access sont toujours époustouflées par rapport à RECHERCHEV et consort)

Il suffit d'un ID commun pour fusionner 2 requêtes (tables) d'où ma première question https://forum.excel-pratique.com/s/goto/1213209

Il existe plusieurs sortes de fusion ou jointure :

• equijointure ou Interne dans PQ : seules les lignes qui matchent sont conservées
• gauche ou Externe gauche dans PQ : pour les tables où on peut établir une relation 1 à N (exemple une personne dans une tables Clients et ses factures dans une table Factures)
  PQ propose Externe droite mais c'est la même logique tenant compte de l'ordre inversé des 2 tables dans la fenêtre de fusion
• Externe entière : on prend tout de chaque table (cas rarement utilisé)
• Gauche opposée ou Droite opposée : on élimine de la 1ère table (gauche) ou de la seconde (droite) tout ce qui est commun.

Dans ton cas pour croiser le fichier du net et ta base de travail ce sera Interne car tu as besoin des infos du net pour compléter tes lignes pas de nouvelles lignes.

Mais comme il manque des ID pour les nouveaux, il faudra gérer 2 cas :

• ID communs
• pour les nouveaux voir si on peut croiser sur tout ou partie des champs nom corrigé, lat. corrigée, long. Corrigée sur ton tableau avec les champs c_nom c_lat_coor1 c_long_coor1 de la la table du net

Bonjour 78chris

J'avais répondu à cette question dans ma réponse suivante :

Le champs commun est le c_gid.

Le problème est aussi que quand j'ajoute un NOUVEAU DAE à la base officielle, le site GeoDAE lui attribue un N° de c_gid qu'il n'a évidement pas au départ.
Ce sera cas pour le square de Normandie et l'école DOLTO.

D'ailleurs, j'apporte une petite correction à la procédure de mon coté qui répond à ta question :

Mais comme il manque des ID pour les nouveaux, il faudra gérer 2 cas :

ID communs

Les "nom corrigé" "c_nom" de mon tableau sera alors le champs commun avec "ç_nom" de la nouvelle extraction de la base GeoDAE pour
pouvoir attribuer le N° c_gid sur mon tableau.
Comme nous n'avons aucune autorisation pour modifier les DAE qui ne nous appartiennent pas mais qui sont tout de même sur la commune, il y aura logiquement des DAE qui s'ajouteront à la liste de mon tableau.

De plus, je ne connais pas encore la configuration du site GeoDAE quand on est connecté pour mettre à jour les DAE nous appartenant ( à la mairie s'entend ).
Vu les erreurs constatées, je pense qu'on n'indique pas les coordonnées GPS directement, mais par un glisser-déposer sur une carte géographique. On ne peut donc pas se fier à cela. Ce n'est pas précis au sens mathématique du terme.

J'ai fait une première approche de la façon dont vba devra traiter le tableau filtré du site GeoDAE.
Ton œil d'expert verra sûrement des incohérences. Voici le fruit de ma réflexion ( il est interdit de se moquer )

sub private MAJ tableau DAE
    ' croisement des tableaux GeoDAE et DAE de la mairie

    Rechercher dans les tableaux le champ commun c_gid

    dans les résultats trouvés,
        si le champ c__edit_datemaj ' (note au passage la présence de 2 tirets __ dans le nom) 
            est supérieur à c__edit_datemaj de mon tableau, alors

            mettre à jour tous les champs communs

        next

        si c_gid n’existe pas ' ( cas des nouveaux DAE de la mairie de Courbevoie que nous gérons )

            rechercher dans la table GeoDAE si des valeurs  c_nom existent dans la table DAE

                si VRAI alors ' copier tous les champs y compris c_gid 

                si FAUX alors ' ajouter la ligne complète dans DAE (cas des nouveaux DAE qui n'appartiennent pas à la mairie)
                endif
        endif
end sub

Je regarde ton tableau version 3 après déjeuner et je te fais un retour précis. Je n'ai pas eu le temps de l'ouvrir avec mon pc encore.

Bon, j'ai repris ton tableau version 3 et, avec beaucoup de peine, j'ai réussi à ajouter un filtre supplémentaire. Plus pour apprendre que par nécessité.

À l'étape d'ajouter un "Step", je cafouille grave. Là j'y suis arrivé en ajoutant d'abord une condition à la ligne filtrée et remonté à l'étape des Step pour y parvenir.
À coup de renommage et modifications de code direct. Un peu brutal comme procédé.
il s'agit de la colonne "proprio" qui ferait référence à la colonne AR ( c_expt_rais ) du tableau. D'ailleurs, là ça marche QUE si ça commence par le mot rechercher.
si je mets "mairie" j'ai bien ceux de la mairie de courbevoie et bien d'autre d'ailleurs, mais si je mets "COURBEVOIE" tout seul, pour trouver ceux de "MAIRIE DE COURBEVOIE" et "COMMUNE DE COURBEVOIE" , ça ne fonctionne pas. Je n'arrive pas à trouver comment mettre l'opérateur "contient" .
sur "STEP"

quand je clique sur la colonne pour indiquer que c'est du texte, il m'alerte que ce sera une étape intermédiaire et ça part en sucette.
C'est quoi la bonne méthode ?

un tout petit ajout dans la procédure. ajouter une mention dans la bdd locale.

sub private MAJ tableau DAE
    ' croisement des tableaux GeoDAE et DAE de la mairie

    Rechercher dans les tableaux le champ commun c_gid

    dans les résultats trouvés,
        si le champ c__edit_datemaj ' (note au passage la présence de 2 tirets __ dans le nom) 
            est supérieur à c__edit_datemaj de mon tableau, alors

            mettre à jour tous les champs communs

            ajouter le texte "MAJ GéoDAE récente" dans le nouveau champs "Maj_Bdd_Loc" de ma bdd. 

        si c_gid n’existe pas ' ( cas des nouveaux DAE de la mairie de Courbevoie que nous gérons )

            rechercher dans la table GeoDAE si des valeurs  c_nom existent dans la table DAE

                si VRAI alors ' copier tous les champs y compris c_gid 

                si FAUX alors ' ajouter la ligne complète dans DAE (cas des nouveaux DAE qui n'appartiennent pas à la mairie)
                endif
        endif
end sub

Bonjour

papicx a écrit :

À l'étape d'ajouter un "Step", je cafouille grave. Là j'y suis arrivé en ajoutant d'abord une condition à la ligne filtrée et remonté à l'étape des Step pour y parvenir.
...

quand je clique sur la colonne pour indiquer que c'est du texte, il m'alerte que ce sera une étape intermédiaire et ça part en sucette.

PStep : c'est juste un renommage de l'étape (clic droit renommer) pour ne pas avoir des noms tordus à utiliser dans les formules

Les types dont déjà définis à l'étape Type modifié : si on doit modifier le type d'un champ ou compléter, il faut se positionner sur cette ligne, sinon cela crée une nouvelle étape et comme il y en d'autres après il vérifier que c'est bien ce que l'on veut faire

Toute valeur stockée par
= Nom étape[Nom champ]{0}

n'est pas typable cra pas un champ de table. C'est un typage automatique. D'où le typage dans le filtre par Text.From(CP) car CP est interprété par défaut comme numérique. D'ailleurs sur des département inférieure à 10 il faudrait forcé à 5 caractères avec Number.ToText(CP,"00000") plutôt que Text.From(CP).

Contient c'est Text.Contains mais si le champ n'est pas rempli, la velur est null donc pas utilisable dans une fonction texte. Donc on remplace par null par une chaîne vide :

Text.Contains([c_expt_rais],if PROPRIO= null then "" else PROPRIO)

Dans ta table de travail tu sembles avec prévu, en ligne10 et 11, 2 nouvelles entées mais la colonne c_nom étant vide tu ne peux la comparer, ce pourquoi je posais la question sur les champs remplis : si les coordonnées GPS ne sont pas fiables, ne reste que ce champ.

Il y a donc 3 cas :

• communs à corriger,
• attendus à compléter/corriger
• nouveaux

sinon ces ligne 10 et 11 ne servent à rien...

Comme déjà dit, on croise par jointures, pas par VBA : les boucles sont 1000 fois moins efficaces...

Bonjour 78cris

J'ai modifié le filtre comme suggéré, mais apparemment il manquait quelques parenthèses autour de PROPRIO.
vu l'heure à laquelle tu as posté, tu es tout pardonné. et puis, il faut bien que je bosse un peu non ?

ton code

Text.Contains([c_expt_rais],if PROPRIO= null then "" else PROPRIO)

J'ai aussi trouvé sur les pages officielles de msOffice la fonction "Comparer.OrdinalIgnoreCase"

https: // learn.microsoft.com /fr-fr/ powerquery-m/text-from

Voici le filtre qui fonctionne pour être insensible à la casse de PROPRIO. bizarrement, j'ai essayé de modifier pour le nom de la ville et ça ne fonctionne pas.
d'ailleurs tout aussi bizarrement le filtre du code postal ne fonctionne plus non plus.

= Table.SelectRows(#"Type modifié", each ([c_com_cp] = Text.From(CP) or [c_com_insee]=Text.From(INSEE) or [c_com_nom]=Text.From(VILLE)
 or Text.Contains([c_expt_rais],if (PROPRIO)= null then "" else (PROPRIO), Comparer.OrdinalIgnoreCase)))

Peut-être faut il séparer les filtres ?

Pour en revenir à mon tableau, je vais changer de procédure :

Quand notre équipe aura un nouveau DAE à vérifier (contrôle de toutes les informations sur place) , le nom ne sera pas mis dans la case c_ntant que les infos complémentaires ne seront pas renseignées, comme ça, pas de problème pour notre tableau.
C'est le cas du garage des mille bornes que j'ai ajouté pour illustrer mon propos en ligne 12. J'ai corrigé en conséquence les lignes 10 et 11.

Nous avons donc bien 3 cas.

ce sera possible de faire ça ? (voir la seconde proposition de mise à jour d'hier (11/08/2024 à 18h03)

 ajouter le texte "MAJ GéoDAE récente" dans le nouveau champs "Maj_Bdd_Loc" de ma bdd. 

RE

Si on ne remplit pas l'un des critères c'est la même chose que pour PROPRIO il faut encapsuler un if ...= null then "" else ...

Mais il me semblait avoir compris que ou CP ou INSEE étaient obligatoire car un libellé c'est très risqué (j'ai trouvé par mal de DOLTO...)

Est-on sûr de orthographe de ville ? je rencontre souvent dans le classeurs des noms de villes qui ne suivent pas la norme INSEE) donc pas sûr du
ou VILLE et PROPRIO semble également risqué... Mais si c'est limité à Courbevoie ça va.

(Je pense que la parenthèse manquante d'après toi est celle de fin instruction que je n'ai pas citée puisque je me limitais à expliquer ce champ)

Cependant la base contient moult codes INSEE vides, CP vides, Villes vides et des critères tout aussi vides, il va falloir s'y prendre autrement car avec des ou ça ramène n'importe quoi.

Il y a aussi un problème dans leur base avec les dates : on ne peut formater qu'en texte

A noter que Comparer.OrdinalIgnoreCase ne résout pas les éventuels problèmes d'accent et a une utilisation assez particulière.

Bonjour 78chris

Les parenthèses manquantes étaient celles qui entoure "PROPRIO" après le "if". Celle de fin, j'avais deviné et PQ ayant la coloration syntaxique, c'est facile à deviner dans ce cas.

J'avais pourtant bien fait tes suggestion pour VILLE, mais ça ne fonctionne pas. Le tableau retourné ne filtre plus rien, tout comme avec le CP comme indiqué hier.
Je n'arrive pas à trouver pourquoi.

= Table.SelectRows(#"Type modifié", each ([c_com_cp] = Text.From(CP) or [c_com_insee]=Text.From(INSEE)
 or Text.Contains([c_com_nom],if (VILLE)=null then "" else (VILLE), Comparer.OrdinalIgnoreCase)
 or Text.Contains([c_expt_rais],if (PROPRIO)= null then "" else (PROPRIO), Comparer.OrdinalIgnoreCase)))

Peut-être des espaces en trop ou mal placés, des virgules manquantes ? J'ai essayé plein de forme de code, je ne trouve pas.

Est-on sûr de orthographe de ville ? je rencontre souvent dans le classeurs des noms de villes qui ne suivent pas la norme INSEE)

.../...

Cependant la base contient moult codes INSEE vides, CP vides, Villes vides et des critères tout aussi vides

C'est bien là toute ma problématique... concernant les noms de ville, le site GeoDAE devrait appliquer un correctif prochainement.
Les champs sont pourtant obligatoires, mais rien se semble obligé informatiquement pour contraindre le propriétaire à saisir ces champs.
Plutôt ne rien mettre que d'indiquer une info fausse semble être le choix fait par GeoDAE.

Je ne peut te mettre le résultat qui ne filtre plus rien du tout. D'où ma proposition de séparer les filtres.
Question : une fois la mise à jour faite, elle que celle-ci peut avoir supprimé des lignes de mon tableau ? C'est peut-être naïf de ma part de penser à ça.

suite

Il y a aussi un problème dans leur base avec les dates : on ne peut formater qu'en texte

il va falloir supprimer les indications d'heure etc. et ensuite ne garder que la date.
À moins que PQ pour comparer se base sur la date d'enregistrement de notre fichier local... ??

Bonjour

Si dans une colonne il y a un mélange de dates et de textes le typage en date provoque des erreurs (qu'on garde ou non l'heure)

Les dernières lignes de la base c'est du grand n'importe quoi... On a une dicton en bases de données : Mer.e in, Mer.e out...

Si on veut récupérer les dates il faut créer de nouvelles colonnes pour y remplacer tout ce qui ne peut être une date par null

J'ai avancé sur le filtre et sur l'extraction des communs et des nouveaux mais il me manque des infos pour aller plus loin : liste des colonnes de la base à conserver

A moins que j'ai mal compris la question, tous les champs de la base GeoDAE sont a conserver. Ça pose un problème ?

Actuellement sur mon tableau j'ai 101 champs. Tu veux le tableau en mp ?

RE

Oui pourquoi pas

Certains champs sont calculés ?

aucun