En attendant de plus amples explications sur la réorganisation de la base de données (création de schémas), en voici déjà le dictionnaire de données généré avec ireport :
Ce travail fait l'objet d'un stage de fin d'étude de Master 2 IFPRU de l'université de Montpellier 2. En lire plus...
Cette migration est l'occasion de mener une réflexion sur la structuration et les évolutions à apporter à la structure de la base et d'opérer un nettoyage de printemps (tables temporaires et vues “de travail”)… Le travail mené sur la gestion de métadonnées et sur le parcours des données sera l'occasion d'y réfléchir vraiment. En lire plus...
Le serveur de base de données est fonctionnel depuis le début du mois. Postgresql 8.4.2 et postgis 1.5 tournent sur une redhat 5.4. PostGIS gère le lambert 93. Jusqu'à ce que je lise ce post et le site lambert93.ign.fr, je pensais que l'utilisation du code EPSG “2154” suffisait…
Les vues “export_tous_*_*_selon_format_esri” sont gourmandes et ne sont pas compatible avec une visualisation en direct depuis GVSIG ou QGIS. Nous allons donc procéder à la création de tables destinées à recueillir le résultat de ces vues dés lors que de nouvelles données seront ventilées dans la base de données. En lire plus...
Comment intégrer la BD TOPO, livrée per département, en MIF/MID et en lambert 93 à la base de données, dans le schéma ign_bd_topo, en lambert 2 étendu. En lire plus
UPDATE point_flore_a_importer SET geometrie=transform(st_multi(geometryfromtext('POINT('||coord_x||' '||coord_y||')',4326)),27572) WHERE id_entite IS NULL AND geometrie IS NULL;
- Création d'une base de données contenant les thèmes de la BDCARTO mis à disposition dans le cadre du SINP
Un renommage des tables et des colonnes pourrait être envisagé!
Transformer les shapes en sql : ”“for /R %F IN (*.shp) DO shp2pgsql -s 27572 -g geometrie -I ”%F” ”%~nF”>“ign_bdcarto_%~nF.sql””“
Chargement dans la base de données : ”“for /R %F IN (*.sql) DO psql -f ”%F” -h addresse_ip_hote -U utilisateur base_de_donnée”“
- Amélioration de l'import de données faune
- Gestion de l'historique des envois de données aux partenaires
CREATE TABLE structure_a_recu_ese( id_structure integer, id_entite integer, date_envoi date, CONSTRAINT pk_structure_a_recu_ese PRIMARY KEY (id_structure, id_entite), CONSTRAINT fk_id_structure_est_structure FOREIGN KEY (id_structure) REFERENCES structure (id_structure) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT fk_id_entite_est_entite FOREIGN KEY (id_entite) REFERENCES entite_spatiale_ecologique (id_entite) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION);
- Insertion dans la base de données des cantons de la région. Création de 2 tables et remplissage avec les données INSEE de 2008
CREATE TABLE canton ( num_insee character varying(3) NOT NULL, -- Le numéro du canton. departement_num_insee character varying(3) NOT NULL, -- le numéro insee du département. arrondissement_num_insee character varying(3) NOT NULL, chef_lieu_num_insee character varying(5) NOT NULL, type_canton character varying(1) NOT NULL, toponyme character varying(50), CONSTRAINT pk_canton PRIMARY KEY (num_insee, departement_num_insee), CONSTRAINT fk_canton_dans_dept FOREIGN KEY (departement_num_insee) REFERENCES departement (num_insee) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT fk_chef_lieu_est_commune FOREIGN KEY (chef_lieu_num_insee) REFERENCES commune (num_insee) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) COMMENT ON TABLE canton IS 'Permet le stockage des cantons.'; COMMENT ON COLUMN canton.num_insee IS 'Le numéro du canton.'; COMMENT ON COLUMN canton.departement_num_insee IS 'le numéro insee du département.'; CREATE TABLE commune_est_sur_canton ( commune_num_insee character varying(5) NOT NULL, -- Le numéro insee de la commune. departement_num_insee character varying(3) NOT NULL, -- Le numéro insee du département du canton. canton_num_insee character varying(3) NOT NULL, -- Le numéro insee du canton. CONSTRAINT pk_commune_est_sur_canton PRIMARY KEY (commune_num_insee, departement_num_insee, canton_num_insee), CONSTRAINT fk_canton_est_canton FOREIGN KEY (departement_num_insee, canton_num_insee) REFERENCES canton (departement_num_insee, num_insee) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT fk_commune_est_commune FOREIGN KEY (commune_num_insee) REFERENCES commune (num_insee) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) COMMENT ON TABLE commune_est_sur_canton IS 'Etablit la composition des cantons.'; COMMENT ON COLUMN commune_est_sur_canton.commune_num_insee IS 'Le numéro insee de la commune.'; COMMENT ON COLUMN commune_est_sur_canton.departement_num_insee IS 'Le numéro insee du département du canton.'; COMMENT ON COLUMN commune_est_sur_canton.canton_num_insee IS 'Le numéro insee du canton.';
- intégration des différentes couches de la BD CARTHAGE
La version mise à disposition sur le site du sandre introduit des accents dans le nommage des colonnes.
Après téléchargement des couches (ici au format mif/mid, si shp alors passer à l'étape suivante), les transformer en shp à l'aide de la console (windows): ”“for /R %F IN (*.MIF) DO ogr2ogr -f “ESRI ShapeFile” -s_srs “EPSG:2154” -t_srs “EPSG:27582” ”%~nF.shp” %F”“
Transformer ces shapes en sql : ”“for /R %F IN (*.shp) DO shp2pgsql -s 27582 -S -g geometrie -I ”%F” “ign_bdc_%~nF”>“prefixe_%~nF_suffixe.sql””“
Les charger dans la base de données : ”“for /R %F IN (*.sql) DO psql -f ”%F” -h addresse_ip_hote -U utilisateur base_de_donnée”“
- Procédure d'intégration de la base d'occupation du sol ocsol (adaptez les noms de fichiers à votre cas)
http://ocsol.siglr.net/index.php?option=com_docman&task=cat_view&gid=14&Itemid=5
shp2pgsql -s 27572 -g geometrie -I V0_OCSOL_LR_POLY_2006_L2E_SHP_NOBD.shp occsol_2006>occsol_2006.sql puis psql -f occsol_2006.sql -h addresse_ip_hote -U utilisateur nom_base_de_donnée
CREATE TABLE poste_occsol ( id_poste character varying(3) NOT NULL, libelle character varying(100), description text ); ALTER TABLE poste_occsol ADD CONSTRAINT libelle_occsol_pkey PRIMARY KEY (id_poste); INSERT INTO poste_occsol (SELECT DISTINCT cde_06, intit_06, NULL FROM occsol_2006); ALTER TABLE occsol_2006 DROP COLUMN bd06_; ALTER TABLE occsol_2006 DROP COLUMN bd06_id; ALTER TABLE occsol_2006 DROP COLUMN niv1_06; ALTER TABLE occsol_2006 DROP COLUMN niv2_06; ALTER TABLE occsol_2006 DROP COLUMN niv3_06; ALTER TABLE occsol_2006 DROP COLUMN intit_06; ALTER TABLE occsol_2006 DROP COLUMN int_06; ALTER TABLE occsol_2006 RENAME gid TO id_entite_occsol; ALTER TABLE occsol_2006 ALTER COLUMN cde_06 TYPE character varying(3); ALTER TABLE occsol_2006 RENAME cde_06 TO id_poste; ALTER TABLE occsol_2006 ADD CONSTRAINT fk_id_poste_est_occsol FOREIGN KEY (id_poste) REFERENCES poste_occsol(id_poste);
Les données, valides sous mapinfo sont transformées par shp2pgsql. Lors de leur insertion dans la base postgis, un
##select count(*) from occsol where isvalid(geometrie) is false;## retourne le résultat 983!!!
Ce qui présage des erreurs lors de l'exécution de requêtes géographiques. Une première tentative de correction avec la requête suivante :
##update occsol set geometrie=buffer(geometrie,0) where isvalid(geometrie) is false;## nous permet d'avoir 0 comme résultat à la requête précédente.
Cependant, une première requête spatiale calculant la part de chaque poste d'occupation du sol de différents périmètres retourne une surface totale supérieure à la surface de l'aire d'étude.
Les géométries sont corrigées mais la couche contient des objets superposés!
Le wiki de PostGIS et particulièrement cette page nous apportent la solution : http://wiki.postgis.org/support/wiki/index.php?CleanPolygons