Disponible avec une licence Network Analyst.
Plusieurs éditeurs peuvent modifier simultanément les entités source d'un jeu de données réseau stockées dans une géodatabase de groupe de travail ou d'entreprise. 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 de groupe de travail ou d'entreprise :
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.
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.
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.