Zones à valider et versionnement des jeux de données réseau

Plusieurs éditeurs peuvent modifier simultanément les entités source d'un jeu de données réseau stockées dans une géodatabase ArcSDE. Cette rubrique et les différents diagrammes qu'elle contient illustrent ce qu'il se passe au niveau des zones à valider des jeux de données réseau lorsque les versions sont réconciliées.

Voici certains des points principaux à retenir avant de commencer à utiliser des jeux de données réseau dans une géodatabase ArcSDE :

• Les entités Source d'un jeu de données réseau doivent être inscrites comme versionnées avant de pouvoir faire l'objet de modifications.

  Legacy :

  Avant ArcGIS 10, les jeux de données réseau ne pouvaient pas être versionnés. Autrement dit, les classes d'entités source pouvaient être modifiées en tant que simples classes d'entités. C'est-à-dire que les classes d'entités source pouvaient être enregistrées comme versionnées et qu'elles pouvaient être modifiées avec annulation et répétition des modifications possibles, ou conservées en tant que données non versionnées et modifiées sans annulation et répétition des modifications possibles.

  Avec ArcGIS 10, toutefois, vous n'avez plus la possibilité de modifier les entités source sans les inscrire comme versionnées.

• Lorsqu'un jeu de données réseau est enregistré comme versionné, les mouvements de structure sont impossibles. Vous devez annuler l'enregistrement du jeu de données réseau comme versionné avant de pouvoir effectuer des mouvements de structure. (Les mouvements de structure comprennent l'ajout ou la suppression de sources ; la modification des règles de connectivité, des autres règles ou des paramètres d'altitude ; l'ajout, la suppression ou la modification des attributs ou des évaluateurs d'attribut ; et la modification des paramètres de trajet.)

• Vous pouvez supprimer un jeu de données réseau indépendamment de son inscription ou non comme jeu versionné.

Par souci d'exhaustivité, les graphiques conceptuels de cette rubrique illustrent l'intégralité du processus, de la création du parent et de l'enfant à la réconciliation et à la réinjection des modifications et créations éventuelles. Pourtant, vous ne démarrerez pas toujours à partir de l'origine d'une version parent. Vous devez donc considérer toutes les étapes dans lesquelles une version enfant est créée comme le moment où une version enfant existante et son parent partagent le même état.

Bien que les graphiques indiquent comment publier un jeu de données réseau créé vers une version parent, il est parfaitement possible de réinjecter le réseau avec des zones à valider. Toutefois, notez qu'il peut être préférable qu'une personne disposant de privilèges de modification sur la version parent crée le jeu de données réseau.

La légende suivante vous aide à comprendre les diagrammes :

Réconciliation et réinjection sans modification des entités source

Cette section décrit comment les zones à valider se comportent dans différents scénarios de versionnement impliquant la modification, la création, la réconciliation et la réinjection de jeux de données réseau. Ces scénarios excluent les modifications des entités source du processus (la prochaine section les inclut). Il s'agit de vous faire comprendre quels workflows entraînent des jeux de données réseau construits ne contenant aucune zone à valider.

Scénario 1 : zone à valider introduite et créée dans la version parent

Supposez que la version enfant hérite d'une zone à valider de la version parent. Le jeu de données réseau est ensuite créé dans la version parent. Enfin, la version enfant effectue une opération de réconciliation. La zone à valider est supprimée de la version enfant (en supposant qu'aucune autre modification n'a été effectuée).

Scénario 2 : zone à valider introduite dans la version parent et créée dans la version enfant

Ce scénario est similaire au dernier car la version enfant hérite d'une zone à valider provenant de la version parent. Mais ensuite, le réseau est créé dans la version enfant, pas dans la version parent. La réconciliation suivant la création réintroduit les zones à valider de la version parent. Pour réinjecter un réseau créé sur la version parent, la version enfant doit être recréée avant la réinjection.

Scénario 3 : zone à valider introduite dans la version parent et créée dans les versions enfant et parent

Ce scénario est une combinaison des deux autres. La version enfant hérite de nouveau des zones à valider de la version parent. Les versions enfant et parent sont créées séparément avant la réconciliation. Le processus de réconciliation permet de supprimer toutes les zones à valider de la version enfant.

Réconciliation et réinjection avec modification des entités source

Les scénarios précédents se concentraient sur la création de jeux de données réseau sans modification des entités source. Dans les scénarios suivants, des modifications sont apportées aux entités source, et les zones à valider résultantes sont supprimées.

Scénario 4 : modifications de différentes entités source dans les versions parent et enfant

Le réseau est créé avant la version enfant dans ce scénario. Une fois la version enfant créée, la classe d'entités source Streets est modifiée afin d'ajouter des rues côté sud sur la carte. Entretemps, la version parent est modifiée afin d'ajouter les rues côté nord. Les deux versions contiennent alors des zones à valider à chaque extrémité de la carte. Le processus de réconciliation transfère les modifications et les zones à valider associées dans la version enfant. A partir de cet instant, le réseau est créé dans le but d'être réinjecté dans la version parent sans zone à valider.

Approfondissement :

Le jeu de données réseau du diagramme ci-dessus n'a pas été créé dans la version parent ou enfant immédiatement avant la réconciliation. Pourtant, s'il avait été créé dans les deux versions, la réconciliation aurait réintroduit la zone à valider dans la partie sud de la carte, comme le montre le graphique ci-dessous. Ce phénomène est dû au processus de réconciliation : ce dernier rend l'état de la version parent visible dans la version enfant afin que le processus de fusion puisse avoir lieu. Puisque les modifications apportées à la version enfant sont inédites pour le parent, la connectivité de ces dernières doit être recréée à partir des données parent réconciliées.

Scénario 5: Nouvelles entités source qui croisent à travers les versions enfants et parent

Ce scénario met en évidence une autre raison pour laquelle le jeu de données réseau doit être recréé après modification des entités source enfant et parent. Ici, les modifications effectuées dans les versions enfant et parent se recoupent. Bien que le réseau soit nettoyé dans les différentes versions, la réconciliation introduit une zone à valider car la connectivité des entités sécantes doit encore être déterminée.