Le portail francophone de la géomatique

Bonjour,

Concernant PostGIS tu peux faire des triggers qui vont gérer l'historique des modifications. L'idée est la suivante :

1. ta table contient un champ timestamp (nommé update_date), un champ update_by si tu veux savoir quoi, éventuellement un champ update_fields et un champ actif (booléen)
2. tu écris des triggers qui vont reécrire tes requêtes UPDATE. Celui-ci va dans un premier temps désactiver la vielle ligne (actif = false) puis reécrire la requête UPDATE en requête INSERT
3. Même chose pour les requêtes DELETE qui vont seulement faire un update sur le champ actif = false.

Autre solution : avoir une deuxième table archive qui va être mise à jour avant chaque mise à jour/suppression des lignes pour copier les lignes modifiées/supprimées.

Y.

Bonjour,

de mon point de vue, la migration d'un SIG fichier vers un sgbd doit se faire dans un serveur de base de données spatiales.
PostgreSQL/PostGIS est tout indiqué : licence, cout, performances et dans votre cas un lien facilité avec geoconcept.

Les possibilités d'interfaces sont nombreuses (clients lourds, légers).

Avec Qgis par exemple : http://rootabagis.blogspot.com/2010/06/ … -qgis.html
En web avec les librairies et langages courants ou avec des outils de génération de formulaire (http://www.postgresql.org/about/news.1190)

Concernant l'historisation des modifications sur les données un exemple est donné dans le document ci dessous, dans la partie "PLPGSQL FUNCTION SAMPLES"

http://www.postgresonline.com/special_f … ormat=html

--Sample logging trigger taken from docs
 CREATE TABLE emp_audit( 
    operation         char(1)   NOT NULL,
    stamp             timestamp NOT NULL,
    userid            text      NOT NULL,
    empname           text      NOT NULL,
    salary integer
);
 CREATE OR REPLACE FUNCTION process_emp_audit() RETURNS TRIGGER AS $$
    BEGIN
        -- Create a row in emp_audit to reflect the operation performed on emp,
        -- make use of the special variable TG_OP to work out the operation.
        IF (TG_OP = 'DELETE') THEN
            INSERT INTO emp_audit SELECT 'D', now(), current_user, OLD.*;
            RETURN OLD;
        ELSIF (TG_OP = 'UPDATE') THEN
            INSERT INTO emp_audit SELECT 'U', now(), current_user, NEW.*;
            RETURN NEW;
        ELSIF (TG_OP = 'INSERT') THEN
            INSERT INTO emp_audit SELECT 'I', now(), current_user, NEW.*;
            RETURN NEW;
        END IF;
        RETURN NULL; -- result is ignored since this is an AFTER trigger
    END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER emp_audit
AFTER INSERT OR UPDATE OR DELETE ON emp
    FOR EACH ROW EXECUTE PROCEDURE process_emp_audit();

Bonne migration,

Dernière modification par Mathieu BOSSAERT (Thu 21 October 2010 12:55)

L'objectif est triple.
Nous migrons entièrement la BDD (spatiales+ attributaires)

-  gérer l'historique de modification
- créer une application webcarto [intranet/internet] (c'est pourquoi postgis m'intéresse tout particulièrement, toutefois access-géoconcept fonctionne bien en stockant la géométrie en texte aux normes GCES [format géoconcept]). La base access reste à l'ordre du jour si nous utilisons GCIS (module webcarto de géoconcept) mais il sera vraisemblablement trop onéreux (+/- 30 000€). 
- traiter/MàJ des données depuis Géoconcept mais aussi depuis une interface non cartographique (traitement sur la base de données où la cartographie est inutile).


La question matériel va également se poser. Nous disposons actuellement de deux licences géoconcept (pour plusieurs utilisateurs allant de novice à bonne maitrise). L'intranet pourrait corriger le problème puisque la plupart des utilisateurs ne feront que consulter les données ou de petites modifications. La question que je me pose concerne notamment les choix à faire en matière d'architecture réseau (rôle et puissance du serveur [dédié...],  je pense me faire conseiller par un informaticien mais je maîtrise peu cette aspect et ai toujours crainte des commerciaux...). nous avons 6 postes informatiques.

Dernière modification par renard (Thu 21 October 2010 14:57)

Bonjour,

Les intervenants précédents vous ayant clairement décrit les avantages de PostGis et du multi plateforme, je me pencherai sur le coté Windows.

Coté Access : Pas de cartouche spatiale native. Les bases de plus de 500 Mo sont ingérables. (temps de réponse). Quel est le format d'ACCESS ? Car le passage de 97-2000 à 2007 au niveau interface de programmation c'est pas simple.(DAO vers ADO.Net).
Deuxièmement Access n'est pas un SGBD "client/serveur".

Je vous conseille fortement de passer par PostGis (nb : sous windows via npgsql il est très facile de ce connecter à partir de .Net).

Pour ma part dans un même applicatif développé en .NET je me connecte indifféremment sur des bases access ou sur des bases PostGis suivant mes besoins. Mais la data spatiale est forcément dans une base PostGis.

En matière d'architecture réseau, pour 6 personnes, vous pouvez soit utiliser un serveur existant, soit un serveur dédié (c'est le mieux). Pour ma part j'ai installé postgis sur le serveur Active Directory en Win 2008 pour 8 personnes connectées, cela ce passe sans soucis. De plus PostGres est connu pour pouvoir être réglé très finement aux niveau des paramètres de communications.
En matière de techno un XEON avec 4 Go de RAM c'est le minimum après ... Je viens de commander une machine type double Xeon quadcore avec 8 Go de RAM et il y en a pas pour très cher (3000 € environ).

Toute la problématique de votre réseau sera d'être équilibré car si vous avez un super serveur et des switches bas de gamme ...

A+

Bonsoir,

Un réseau pour 6 ou 8 postes peut-être une livebox (ou équivalent) et un HUB où architecture beaucoup plus évoluée.
Là encore les intervenants précédents pourront certainement vous donner une architecture libre, mais sur l'aspect technique vous pouvez aller ici chapitre 1-A pour vous faire une idée.
Sachant que l'ensemble peut-être réduit.
Des switches évolués comme indiqué dans ce CCTP possèdent une interface de programmation qui permet de régler le traffic de façon assez fine, par exemple rendre prioritaire les paquets circulant entre un PC et le serveur de BD par rapport à un traffic internet.

Je pense qu'un bon réseau LAN pour 6 personnes dans un cadre pro serait composé d'un routeur et d'un switch de qualité équivalente à celle indiqué dans le lien. Vous ajoutez un fire wall et une ligne SDSL, il ne vous reste plus qu'à connecter quelques serveurs et vous êtes paré pour un moment.
Si vous considérez uniquement l'aspect matériel (solution libre pour les serveurs) la solution peut évoluer entre 20 et 30 k€ suivant les options (fire wall particulièrement).

J'essaie d'estimer un peu le coût du matériel. Par contre comme je l'ai déjà je n'y connais rien en réseau. Dites-moi si je me trompe.

Solution possible.

- un serveur avec pour une bdd par si grande que ca (orthophoto d'un département) (3000€)
- la licence windows (pour un administré il faut une licence windows server non?) je n'arrive pas à trouver un prix.
- un routeur + firewall (+/- 700€)
le Hub nous l'avons déjà.
La connexion passe par une livebox (connecté directement au routeur?).

Ca vous semble complet? Je pense que nos besoins sont bien inférieurs en terme de stockage au CCTP que tu as proposé.

Dernière modification par renard (Fri 22 October 2010 10:23)

Je souhaite toujours dans le cadre du même projet faire le site web avec drupal et une BDD mysql et le portail cartographique avec une base postgis/ mapserver. Je suis contraint d'avoir deux bases de données car drupal ne semble pas très stable avec postgresql. Cependant est-ce que apache permet d'être connecté à la fois à mysql et mapserver (connecté à postgis)?

merci,

Dernière modification par renard (Tue 26 October 2010 11:19)

J'ai lu plusieurs mauvais retours d'expériences sur une connexion postgre-drupal et j'ai pu lire ceci

(source http://pgedit.com/install_drupal )

J'avais songé à basculer entièrement la base de donnée en mysql. Cependant, avec le rachat de sun par Oracle, j'ai lu pas mal de choses pessimistes quant au devenir de mysql.  A contrario l'avenir de postgresql/postgis semble plus radieux, c'est pourquoi je privilégiais ce support, d'autant plus que nos besoins en cartographie sont amenés à se développer. On utilisera aussi postgis pour Geoconcept.

Je ferais tout de même des essais drupal - postgresql/postgis, histoire de juger par moi-même, car en effet tu confirmes ce que je n 'osais pas me dire, avoir deux bases de données n'est pas le choix le plus judicieux.

Dernière modification par renard (Tue 26 October 2010 12:01)

Petit suivi qui n'a pas grand chose à voir avec la géomatique. Lors de l'installation de postgresql, il y a possibilité d'installer apachephp + drupal (+postgis) avec stackbuilder 3. Il est ainsi aisé d'utiliser drupal avec postgresql.