Le portail francophone de la géomatique

Bonjour,

les GDB fichier ne proposent pas le versionnement à ma connaissance, mais la mise à jour des données de ce type de GDB se fait sans cette fonctionnalité, vous ouvrez les données dans ArcMap vous démarrez une session d'édition et c'est parti.

Oui, on peut migrer une GDB fichier dans une base SDE par un simple "import", mais le passage à SDE entraine un stockage dans une base de type SGBDR (oracle, SQL server, etc) et a donc des conséquences qui vont bien au-delà de l'aspect fonctionnel, il s'agit de la mise en place d'une architecture complètement différente. En fait pour définir SDE, je dirai qu'il s'agit d'un cartouche spatial de SGBDR..
Effectivement ESRI propose ArcSDE dans la produit ArcGIS Server mais il s'agit d'un logiciel payant (avec un coût non négligeable) mais il s'agit vraiment d'un SIG d'un tout autre niveau que les GDB fichier.
Les GDB fichier et les GDB SDE c'est pas du tout la même chose à part le fait qu'il s'agit de données SIG à l'intérieur.

Cordialement

C'est un supplément... la version la plus basique de SDE est autour des 10 keurs, mais le mieux est de demander directement à ESRI France. Sachant qu'une fois ArcGIS for serveur workgroup basic (= SDE de base) acheté vous n'avez fait que 5% du boulot.
Il vous faut un serveur physique ou une machine virutelle sur un serveur existant pour l'installer. En plus vous avez besoin d'un SGBDR (il existe des gratuits mais aussi des payants et Oracle ou SQL server sont chers).
Il y aussi les coûts humains, pour administrer tout ça le serveur et le SGBDR. Un SIG server ne se gère pas non plus comme des fichiers shp, il vous faut un admin SIG avec au minimum ArcEditor pour gérer SDE.
On est donc sur quelque chose qui coute cher à mettre en place, qui necessite des moyens techniques importants, des investissements importants, des embauches ou des montées en compétences de gens en interne... est-ce que le jeu en vaut vraiment la chandelle?

Sachant que votre problème est la mise à jour de données je vous donne mon retour d'expérience. Malgré les bases SDE dans mon entreprise, les mises à jour sont faites en dehors de SDE dans des shapefiles tracés qui sont ensuite controlés par l'admin SIG et importés dans la base SDE. Nous trouvons notre intérêt à SDE ailleurs que dans la mise à jour de données. Nous avions pensé utiliser SDE mais on a vite laissé tomber.

De plus, vous vous posez la mauvaise question, je m'explique, si aujourd'hui il y a 2-3 aller-retour pour non conformité, ça signifie que demain si les gens modifient directement dans SDE ce contrôle n'existera plus.. donc que les données dans SDE seront non conformes. Vous aurez juste gagné l'info de version et de tracking (à savoir qui a fait la modif).
Conclusion :vous allez perdre par rapport à la situation actuelle.

De mon point de vue vous ne pouvez travailler que sur le processus de validation, vous avez entendu parler de performance opérationnelle? de lean 6 sigma? de process mapping? c'est plutôt ça qu'il faut creuser je pense, plus que du côté logiciel.

Bon courage
Benoit

Bonjour,

Je rejoins Benoit en tous points, sauf peut-être sur ce passage :

Avec le mécanisme de versionnement, l'utilisation de versions "filles" et le contrôle par un administrateur lors de la réconciliation avec la version "mère", il est tout à fait possible de contrôler les données et de rejeter celle qui ne conviennent pas avant leur intégration dans la version de référence.

Cependant, ma conclusion est la même que celle de Benoit : il vaut mieux que vous vous orientez vers la mise en place de mécanismes (semi)-automatiques de contrôle puis d'intégration des seules données valides.
Avec ModelBuilder, vous aurez un aperçu de ce qu'il est possible de faire. Sachez que l'on peut aller encore plus loin grâce aux scripts Python et qu'il existe enfin, si les contrôles sont très complexes (topologie, formats de données différents, etc.), des outils tels que l'extension ArcGIS Data Interoperability ou bien encore l'ETL (Extract-Transform-Load) FME de Safe.

Cordialement,
Kevin

Benoit, je suis d'accord avec ce que vous dites. Je me suis peut-être mal exprimé, je ne remets absolument pas en cause la nécessité d'un contrôle manuel, pas plus que d'identifier toutes les étapes du cycle de vie des données, au contraire. Mais je voulais juste signaler qu'il existait des outils et des méthodes automatiques permettant d'aider cette analyse.
Quelques exemples de contrôles automatiques qui facilitent la vie de l'administrateur des données, lui permettant de se focaliser sur d'autres critères de validité qu'aucun automatisme ne pourra jamais traiter :
- contrôler qu'un attribut contient des valeurs valides (éventuellement contenues dans une liste, dans une autre table ou dans un domaine de valeurs)
- contrôler que les données ont une géométrie valide : vous ne pouvez pas savoir le nombre de fois où ce simple contrôle m'a permis de détecter des erreurs (polygone non fermé, vertex coïncidants, etc.)
- détection de superposition de données qui ne devrait pas l'être (ex: des parcelles cadastrales)
- etc.

C'est vrai et faux à la fois Si tous les utilisateurs effectuent leur mise à jour sur la version de référence (SDE.DEFAULT), alors oui le dernier qui valide sa mise à jour gagne. Mais si les mises à jour sont faites dans des versions "enfant", c'est l'administrateur qui décide, lors de la phase de réconciliation avec la version "parent", qui a raison. Je vous invite à consulter la description qui est faite dans l'aide et qui est je trouve bien illustrée : http://help.arcgis.com/fr/arcgisserver/ … 160t000000
Nous pouvons aussi en discuter par mail si vous le souhaitez.

Bonne soirée,
Kevin.

Kevin, en fait j'avais bien compris les contrôles automatiques dont vous parlez, j'étais déjà dans l'étape suivante
Ok pour les versions de GDB filles mais il n'est quand même pas possible de "fusionner" les modifs faites dans une version A avec celles faites dans une version B n'est ce pas?
Pour le reste je pense que Camille a pas mal d'éléments pour faire du bon travail.

Ok ok... pour les histoires de réconciliation je me pencherai à nouveau dessus, mais je me souviens qu'en 2009, on avait vite écarté le sujet à cause des remontées non conflictuelles où la dernière version remontée écrasait les ajouts réalisés dans une autre version..
Merci pour les infos, il est temps de me mettre à jour

Je pense que Camille a dans les mains un super sujet qui si il est bien traité fera la différence au moment de l'embauche plus tard, mais cet avis n'engage que moi.

Bonjour Kevin et Benoit,

Excusez moi pour le retard de ma réponse, j'ai pris le temps de bien lire et décortiquer vos réponses.

Tout d'abord merci pour vos conseils très enrichissants et encourageants. Concernant la base de donnée, je pense proposer une base de données PostGre/PostGis. Concernant les mises à jours, je pense scinder en deux le processus (c'est déjà ce qui est en place, mais je pense que ça doit être renfoncer).
Une partie contrôle et vérification avant intégration dans la base de donnée:  j'ai commencé à récolter les manipulations de création de données des différents acteurs qui enrichissent la base ainsi que leurs problèmes. Suite à quoi, je pense proposer:
- Un protocole commun de vérification "manuelle", pour ce qui ne peut pas être fait par la machine (incohérence liées à la thématique dans les tables attributaires)
- semi-automatisation pour par exemple dans un premier temps détecter les erreurs topologiques (superposition d'objets etc) qui seront à corriger manuellement.
- des moulinettes python ou modelbuilder pour ce qui peut être automatisé.

Dans un deuxième temps: Concernant les mises à jour de la base avec , il y a sans-doute des solutions qui doivent exister dans postgre/postgis pour la mise à jour (je dois explorer ce point car je n'y connais absolument rien pour le moment ;-), un comme pour les BD postgre/postgis d'ailleurs, mais c'est ça qui est intéressant)

Je poserai la question pour la diffusion de mon rapport, mais je pense qu'il n'y aura pas de soucis!

Merci encore,

Bonne journée

Camille

J'ajoute que si vous mettez en place tout un système autour d'un SGBD type PostGre/PostGIS ou même Oracle et que seule vous possédez la compétence et savez comment l'utiliser, le sujet ne vous survivra pas... à moins que l'entreprise se décide à vous embaucher.

Le mot d'ordre est de répondre à la question posée avec les étapes suivantes :
- identifier le problème,
- apporter une solution au problème,
- s'assurer que la solution soit réaliste tant techniquement que financièrement (coûts matériels et humains à court, moyen et long terme),
- garantir la perennité de la solution...

Vous avez discuté de tout ça avec votre maitre de stage?

Dernière modification par benulti (Fri 26 April 2013 15:24)

Bah justement, c'est plutôt finement joué de la part de Camille .

Si ce n'est pas indiscret Camille, quand avez-vous commencé votre stage et quand doit-il se terminer ?

Dernière modification par Kevin Jousseaume (Fri 26 April 2013 15:45)