Import Bd-Topo > Batch ?

[Sylvain M.]

Bonjour à vous,

Je progresse doucement sur PostGreSQL / PostGis, et ayant récupéré la Bd-Topo 2015 (shapefiles), je m'apprête à l'importer dans PostGis.
Je viens d'importer un SHP avec succès avec la commande suivante :

C:\Program Files\PostgreSQL\9.3\bin\shp2pgsql -I -s 2154 -W LATIN1 "E:\ign\BDTOPO2015\BDTOPO_2-1_TOUSTHEMES_SHP_LAMB93_D050_2015-03-26\BDTOPO_2-1_TOUSTHEMES_SHP_LAMB93_D050_2015-03-26\BDTOPO\1_DONNEES_LIVRAISON_2015-04-00253\BDT_2-1_SHP_LAMB93_D050-ED151\A_RESEAU_ROUTIER\ROUTE.SHP" manche_2015.route | psql -U postgres -d bd_topo

Comme il y a plus de 50 SHP dans la Bd-Topo (bon certains sont il est vrai redondants...), et que j'ai plusieurs départements à traiter, j'aimerai pouvoir automatiser la tâche sur une sélection de fichiers (histoire de partir plus tôt en pause café, pendant que mon PC esclave travaille ).

Je ne sais cependant pas comment enchainer plusieurs commandes d'import shp2pgsql dans une même commande : quelle est la syntaxe / procédure à suivre ? (je peux facilement lister la liste des SHP / destinations dans un TXT).

Merci à vous pour vos conseils.

A+

Sylvain M.

[L.Jégou]

La programmation par batch est toujours possible mais, perso., dans ces cas-là, ce que je fais c'est un fichier Excel avec une commande par ligne : je peux recopier les portions de commandes identiques et copier-coller la liste des fichiers (issue d'un dir > liste.txt) dans la colonne qui correspond. Ensuite export en format texte et remplacement de l'extension pour en faire un .bat.

[Lud]

je fais c'est un fichier Excel avec une commande par ligne

Je fais pareil, c'est très pratique et très rapide (moins élégant peut être mais bon)

[Sylvain M.]

Yep !
En fait, c'est bien ce que je pensais faire, mais je ne savais pas qu'on pouvait enchainer les commandes SHP2PGSQL simplement en sautant une ligne (je n'avais pas encore essayé...).
Je viens d'importer tous les SHP de 4 départements entiers, ça a marché nickel !

Il ne me reste plus qu'à créer les assemblages inter-départementaux.
Maintenant, ce n'est pas si simple , car les données sont fournies pour le département + un petit buffer variable suivant les couches, et donc avec des objets en doublon.
Je vais voir comment gérer ça, mais si certains ont été confrontés à ce problème, je suis intéressé par leurs conseils !

A+

Sylvain M.

- - MISE A JOUR - -

Voici la requête que je viens de créer sur l'exemple des communes.
Je la partage ici si vous voyez des améliorations (sur 4 départements) :

CREATE OR REPLACE VIEW communes_bdtopo AS 
 WITH tmp as (SELECT *
 FROM manche_2015.admin_commune
 UNION
 SELECT *
 FROM mayenne_2015.admin_commune
 UNION
 SELECT *
 FROM orne_2015.admin_commune
 UNION
 SELECT *
 FROM sarthe_2015.admin_commune)
SELECT id, prec_plani, nom, code_insee, statut, canton, arrondisst, 
       depart, region, popul, multican, geom from tmp
GROUP BY id, prec_plani, nom, code_insee, statut, canton, arrondisst, 
       depart, region, popul, multican, geom
ORDER BY code_insee;

Rien de choquant ?

Merci pour vos avis.

Sylvain M.

[Sylvain M.]

Bon, finalement j'ai abandonné l'idée d'une vue (CREATE VIEW) pour l'union de 4 départements : la requête met plusieurs minutes à s'accomplir sur la couche végétations, donc il vaut mieux créer la couche "en dur".
Je créé donc une table (CREATE TABLE).
Voici ce que ça donne pour les routes par exemple :

CREATE TABLE public.route AS 
 WITH tmp as (SELECT *
 FROM manche_2015.route
 UNION
 SELECT *
 FROM mayenne_2015.route
 UNION
 SELECT *
 FROM orne_2015.route
 UNION
 SELECT *
 FROM sarthe_2015.route)
SELECT id, prec_plani, prec_alti, nature, numero, nom_voie_g, nom_voie_d, 
       importance, cl_admin, gestion, mise_serv, it_vert, it_europ, 
       fictif, franchisst, largeur, nom_iti, nb_voies, pos_sol, sens, 
       alias_g, alias_d, inseecom_g, inseecom_d, codevoie_g, codevoie_d, 
       codepost_g, codepost_d, typ_adres, bornedeb_g, bornedeb_d, bornefin_g, 
       bornefin_d, etat, z_ini, z_fin, geom from tmp
GROUP BY id, prec_plani, prec_alti, nature, numero, nom_voie_g, nom_voie_d, 
       importance, cl_admin, gestion, mise_serv, it_vert, it_europ, 
       fictif, franchisst, largeur, nom_iti, nb_voies, pos_sol, sens, 
       alias_g, alias_d, inseecom_g, inseecom_d, codevoie_g, codevoie_d, 
       codepost_g, codepost_d, typ_adres, bornedeb_g, bornedeb_d, bornefin_g, 
       bornefin_d, etat, z_ini, z_fin, geom
ORDER BY id;

59 secondes pour cette requête (650000 entités quand même !).
Si vous pensez que cette requête n'est pas optimisée, n'hésitez pas à me faire part des arrangements possibles !

En tout cas, "ça marche", donc si ça peut servir à d'autres !

A+

Sylvain M.

[L.Jégou]

Il faut vérifier qu'il existe bien un index pour chaque champ de regroupement et que les tables ont été vaccuum analysées

[Santanna]

Hello,
Est-ce que chaque entité de la BD-Topo n'est pas supposée avoir un unique identifiant? Auquel cas, est-ce qu'un simple select distinct id,... sur la table tmp ne ferait pas l'affaire?
Après, en termes de performance, je ne sais pas si c'est mieux...

Et pour aller plus loin, est-ce que les entités qui sont sur la table "manche" par ex mais hors de ce département sont intégrées en entier ou découpées par le buffer (je ne me souviens plus bien de ces données)? Dans le second cas, il y a un filtre sur la surface ou une fusion d'entités à rajouter.

[Sylvain M.]

Désolé, j'avais zappé vos réponses.

Est-ce que chaque entité de la BD-Topo n'est pas supposée avoir un unique identifiant?

Si ! Et effectivement, le SELECT DISTINCT fonctionne très bien et est plus propre (le gain de temps n'est pas énorme sur la couche communes, mais ça doit être utile quand même !).

CREATE TABLE public.admin_commune_test3 AS 
 WITH tmp as (SELECT *
 FROM manche_2015.admin_commune
 UNION
 SELECT *
 FROM mayenne_2015.admin_commune
 UNION
 SELECT *
 FROM orne_2015.admin_commune
 UNION
 SELECT *
 FROM sarthe_2015.admin_commune)
SELECT DISTINCT id, prec_plani, nom, code_insee, statut, canton, arrondisst, 
       depart, region, popul, multican, geom from tmp
ORDER BY code_insee;

Après, en termes de performance, je ne sais pas si c'est mieux...

> La requête a été exécutée avec succés : 1898 lignes modifiées. La requête a été exécutée en 2581 ms (contre 2762 ms en "group by").

Et pour aller plus loin, est-ce que les entités qui sont sur la table "manche" par ex mais hors de ce département sont intégrées en entier ou découpées par le buffer

En entier heureusement ! Donc pas besoin de fusion.

Il faut vérifier qu'il existe bien un index pour chaque champ de regroupement et que les tables ont été vaccuum analysées

Merci du conseil : je vérifie cela !

Bonne soirée !

Sylvain M.

[Sylvain M.]

Pour info, reçue à l'instant dans la lettre d'info de l'IGN (version en ligne), la Bd Topo est maintenant téléchargeable au format SQL pour PostGreSQL.
Le plus important, c'est que les objets ne sont plus dupliqués aux frontières départementales !

> BD TOPO®PostGreSQL
>
> Pour répondre aux souhaits exprimés par certains utilisateurs qui intègrent les données de la BD TOPO® sur une emprise nationale (France métropolitaine), l'IGN propose une version au format SQL, sans objets dupliqués dans plusieurs thèmes et/ou classes d'objets, pour une intégration facilitée de cette base de données.
>
> La BD TOPO®PostGreSQL est disponible en téléchargement sur l'Espace professionnel.

[yartostout]

Yep, j'ai vu ça dans la lettre d'info aussi, t'as fait le test avec un fichier SQL de la BD TOPO du coup ?

[Le Docteur]

Excellente nouvelle
Merci pour l'info, je vais ajouter la news sur l'article : http://portailsig.org/content/import...ans-postgresql

[Gilloutheboss]

Bonjour,
J'essaie d'intégrer les fichiers SQL de la BD Topo mais j'ai toujours la même erreur (exemple de la couche CHEF_LIEU):

ERREUR: erreur de syntaxe sur ou près de « 1 »
LINE 16: 1 PAIHABIT0000000037902980 SURFCOMM0000000039657801 BDNyme P...
^
********** Erreur **********

ERREUR: erreur de syntaxe sur ou près de « 1 »
État SQL :42601
Caractère : 737

Quelqu'un a essayé de faire un import ? Avez-vous le même problème que moi ?

Merci pour votre aide !

[sergio6663]

même erreur chez moi...

[Sylvain M.]

Salut à tous,

J'avais transmis l'info que la Bd Topo est maintenant téléchargeable directement en fichiers SQL (lien direct).

Malheureusement, n'étant qu'un débutant sur PostGreSQL, et particulièrement pas hyper à l'aise avec PSQL, je ne parviens pas non plus à les importer correctement...
Si quelqu'un à des conseils sur l'importation des fichiers SQL dans une BD postgresql, sur un PC Windows, je suis preneur d'une méthode "propre" !

Voila ce que j'ai fait pour l'instant, dans un fichier BAT :

c:
cd c:\Program Files\PostgreSQL\9.3\bin
psql -h localhost -p 5432 -U postgres -d test -v bd_topo_sql < "E:\TEMPO\BDTOPO_2016_SQL\BDTOPO_2-2_TOUSTHEMES_SQL_LAMB93_D027_2016-10-03\BDTOPO_2-2_TOUSTHEMES_SQL_LAMB93_D027_2016-10-03\BDTOPO\1_DONNEES_LIVRAISON_2017-02-00073\BDT_2-2_SQL_LAMB93_D027-ED162\B_VOIES_FERREES_ET_AUTRES\TRONCON_VOIE_FERREE.sql"
pause

Mais les problèmes sont :
- la table est créée dans le schéma public et non dans le schéma "bd_topo_sql"
- il serait à mon avis préférable de créer une "boucle" sur l'ensemble des fichiers SQL du dossier "E:\TEMPO\BDTOPO_2016_SQL\BDTOPO_2-2_TOUSTHEMES_SQL_LAMB93_D027_2016-10-03\BDTOPO_2-2_TOUSTHEMES_SQL_LAMB93_D027_2016-10-03\BDTOPO\1_DONNEES_LIVRAISON_2017-02-00073\BDT_2-2_SQL_LAMB93_D027-ED162\"
sinon, je peux lister les fichiers SQL (je peux facilement récupérer la liste via FileLister par exemple) et lancer autant de commandes SQL, mais ça ne me semble pas idéal...

Si jamais il y avait une méthode "presse bouton" depuis PG-Admin, ça me dirait bien aussi de la connaitre : je suis en train d'initier un collègue à PostGreSQL, mais les lignes de commandes lui sont pour le moment rédhibitoires
J'ai l'impression qu'en creusant du côté de "Clic-droit Schéma > Restaurer", ça devrait être possible, mais pour l'instant, le bouton "restaurer" reste grisé ???

Merci pour vos conseils !

Sylvain M.

[Le Docteur]

Je n'ai plus accès aux données IGN, donc je ne pourrai pas t'aider pour le reste mais concernant :

J'ai l'impression qu'en creusant du côté de "Clic-droit Schéma > Restaurer", ça devrait être possible, mais pour l'instant, le bouton "restaurer" reste grisé ???

Tu cliques sur le schéma ou la BDD ? Essayes sur la BDD.
Sous Linux, il faut t'assurer d'avoir le paquet postgresql-utils
Enfin il peut être grisé quand la version des postgresql client et coté serveur diffère.

Des pistes à creuser