====== Actualités de la base de données.======
===== Automne 2011 =====
[[integration_donnees:externes:inpn#referentiels_taxonomiques|Intégration de la v4 de TaxRef]]
===== Printemps 2011 =====
[[http://www.postgresql-sessions.org/2/mathieu_bossaert_-_postgresql_et_postgis_dynamisent_le_systeme_d_information_du_cen_languedoc_roussillon|le CEN L-R présent à la seconde Session PostgreSQL]]
===== Automne 2010 =====
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 :
  * [[http://sig.cenlr.org/documents/rapports/dictionnaire_de_donnees_2010_11.pdf|dictionnaire de données de novembre 2010]]
  * [[http://sig.cenlr.org/documents/rapports/dictionnaire_de_donnees_2010_10.zip|dictionnaire de données d'octobre 2010]]

===== Printemps été 2010 =====
==== Amélioration, optimisation du parcours des données produites au CEN ====
Ce travail fait l'objet d'un [[http://sig.cenlr.org/stages/2010/sicen|stage de fin d'étude de Master 2 IFPRU]] de l'université de Montpellier 2. [[:creation_bdd:evolution|En lire plus...]]
===== Avril 2010 =====
==== Migration de la bdd SICEN vers le nouveau serveur et postgis 1.5 ====
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 [[stages:2010:sicen|la gestion de métadonnées et sur le parcours des données]] sera l'occasion d'y réfléchir vraiment.
[[:interface:demarche| En lire plus...]]

===== Février 2010 =====
==== Nouveau serveur de base de données ====
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 [[http://www.forumsig.org/showthread.php?t=25834|ce post]] et le site [[http://lambert93.ign.fr|lambert93.ign.fr]], je pensais que l'utilisation du code EPSG "2154" suffisait... 

==== Création de tables de consultation des données en remplacement des vues ====
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.[[:creation_bdd:evolution#creation_de_tables_de_consultation_des_donnees_en_remplacement_des_vues| En lire plus...]]

===== Janvier 2010 =====
==== Intégration de la BDTOPO =====
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. [[:integration_donnees/externes:ign#integration_de_la_bd_parcellaire_dans_le_schema_ign_bd_parcellaire|En lire plus]]

=====avril 2009=====
===Création de points à partir de coordonnées en long/lat wgs 84===

<code sql>
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;
</code>
	
=====février 2009=====
- **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""**

=====décembre 2008=====
- **Amélioration de l'import de données faune**

- **Gestion de l'historique des envois de données aux partenaires**

<code sql>
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);
</code>

=====novembre 2008=====
- **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**

<code sql>
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.';



</code>
=====octobre 2008=====
- **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""**

=====septembre 2008=====
- **Procédure d'intégration de la base d'occupation du sol ocsol (adaptez les noms de fichiers à votre cas)**
	- Télécharger de l'archive qui nous intéresse sur la page : 
		http://ocsol.siglr.net/index.php?option=com_docman&task=cat_view&gid=14&Itemid=5
	- Transformer le shp obtenu aprés décompression de l'archive :
**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**
	- On peut maintenant supprimer la redondance et les attributs "inutiles" :

<code sql>

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);
</code>
  * [[http://wiki.postgis.org/support/wiki/index.php?CleanPolygons|CleanPolygons]] : résolution des problèmes d'intégration de la base d'occupation du sol (voir le site de siglr [[:wiki:http://ocsol.siglr.net/|ici]])

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 [[:wiki:www.postgis.org|PostGIS]] et particulièrement cette page nous apportent la solution :
http://wiki.postgis.org/support/wiki/index.php?CleanPolygons