Disponible avec la licence Location Referencing.
La prévention des conflits améliore la prise en charge de la mise à jour multi-utilisateur en coordonnant les mises à jour d’itinéraire et d’événement dans un système de référencement linéaire (LRS) de géodatabase d’entreprise. ArcGIS Location Referencing coordonne les mises à jour en appliquant un ensemble de conditions et de comportements exigeant l’acquisition d’un verrou par les éditeurs préalablement à la mise à jour d’un itinéraire ou d’un événement.
Le principe de base de la prévention des conflits Location Referencing est le suivant : si un itinéraire ou un événement est verrouillé par un éditeur dans une version de base de données, cet itinéraire ou événement ne peut pas être mis à jour par la même personne dans une autre version de base de données ou par d’autres personnes dans n’importe quelle version.
Activer la prévention des conflits
La prévention des conflits est uniquement prise en charge sur un jeu de données LRS qui utilise le versionnement de branche.
Le versionnement traditionnel est pris en charge dans Location Referencing, mais la prévention des conflits n’est pas disponible dans les jeux de données versionnés de manière traditionnelle.
Une fois que le jeu de données utilise le versionnement de branche, exécutez l’outil Modifier le système LRS avec l’option Conflict Prevention (Prévention des conflits) définie sur Enable (Activer).
Si la prévention des conflits est activée, chaque outil de mise à jour acquiert automatiquement des verrous, le cas échéant, ou vous alerte lorsqu’il n’est pas possible d’en acquérir.
Mettre à jour un itinéraire et créer un verrou pour la prévention des conflits
Le processus de prévention des conflits suivants illustre l’utilisation de Retire Route (Retirer un itinéraire). RouteX, RouteY et RouteZ font partie de LineXYZ. RouteX va être retiré.
- Cliquez sur le bouton Identify Route (Identifier un itinéraire)
sur l’onglet Location Referencing, puis cliquez sur RouteX.La boîte de dialogue Identify Route (Identifier un itinéraire) apparaît.
L’identifiant d’itinéraire indique qu’il n’existe aucun verrou. - Vérifiez qu’il n’existe aucun verrou sur la ligne ou l’itinéraire sélectionné.
L’exemple précédent n’affiche aucun verrou, ce qui indique qu’il n’existe aucun verrou pour RouteX.
- Après avoir vérifié qu’il n’existe aucun verrou sur l’itinéraire, cliquez sur Retire (Retirer)
sur l’onglet Location Referencing.La fenêtre Retire Route (Retirer un itinéraire) apparaît.
- Dans la fenêtre Retire Route (Retirer un itinéraire), cliquez sur le bouton From Route Name (Nom de l’itinéraire de départ), puis cliquez sur l’itinéraire que vous souhaitez retirer.
Lorsque le nom d’un itinéraire est sélectionné, un message d’acquisition de verrou apparaît en haut de la fenêtre.
Les itinéraires acquis sont confirmés dans la fenêtre Retire Route (Retirer un itinéraire). Le message de verrouillage contient les informations suivantes :
- Le verrou a été acquis sur LineXYZ.
Remarque :
RouteX fait partie de LineXYZ.
Puisque RouteY et RouteZ font partie de LineXYZ, ils sont également verrouillés pour mise à jour.
- Le verrou a été acquis par l’utilisateur du portail, User11.
- Le verrou sur LineXYZ pour la version de base de données, Version1, a été acquis par User11.
Remarque :
Vous transférez automatiquement un verrou de ligne ou d’itinéraire existant depuis une autre personne à vous-même si les conditions suivantes sont remplies :
- La version possédée par l’autre personne est publique.
- Vous effectuez la demande dans la même version que celle dans laquelle l’autre personne possède le verrou.
- Si la version du verrou est une version enfant, le propriétaire du verrou ne possède pas de session de mise à jour actuellement ouverte dans cette version. Si la version du verrou est la version par défaut, le propriétaire du verrou ne possède pas de session de lecture actuellement ouverte dans la version par défaut.
- Le verrou a été acquis sur LineXYZ.
- Vous pouvez vérifier l’existence du verrou en cliquant sur Identify Route (Identifier un itinéraire) sur l’onglet Location Referencing, puis à nouveau sur RouteX.
L’identifiant d’itinéraire indique que l’itinéraire a été verrouillé. L’icône Locked by you (Verrouillé par vous-même)
confirme également que vous possédez des verrous sur l’itinéraire identifié et que vous pouvez le mettre à jour. - Si vous souhaitez identifier les verrous existants, cliquez sur le bouton LRS Locks (Verrous LRS)
sur l’onglet Location Referencing.La table LRS Locks (Verrous LRS) apparaît.
La table LRS Locks (Verrous LRS) indique l’existence du verrou récemment acquis.
Prévenir les conflits
Comme décrit précédemment, la logique de prévention des conflits autorise la mise à jour d’un itinéraire ou d’une ligne et d’un événement par une seule personne dans une seule version à la fois.
Par exemple, si User22 tente de retirer le même RouteX alors que RouteX est verrouillé par User11, le message suivant apparaît :
Le message fournit les informations suivantes :
- LineXYZ ne peut pas être mis à jour car le verrou appartient à une autre personne.
Remarque :
RouteX fait partie de LineXYZ.
- Le verrou a déjà été acquis par l’utilisateur du portail, User11.
- Le verrou sur LineXYZ pour la version de base de données, Version1, a déjà été acquis par User11.
L’identifiant d’itinéraire affiche le résultat suivant :
La table LRS Locks (Verrous LRS) apparaît et répertorie les verrous.
Vérifier que la version la plus récente du jeu de données est mise à jour
Mettez à jour la version la plus récente de la base de données pour que toutes les modifications récentes apportées aux données figurent dans la version mise à jour. Pour identifier la version la plus récente, Location Referencing vérifie si une réconciliation avec la version par défaut est nécessaire avant l’acquisition d’un verrou. Si une version doit être réconciliée avec la version par défaut, le message suivant apparaît :
Si vous cliquez sur Yes (Oui) lorsque la boîte de dialogue Acquire Locks (Acquérir les verrous) apparaît, la version de l’éditeur est réconciliée avec la version par défaut.
Remarque :
Assurez-vous que tous les conflits avec la version par défaut sont réconciliés avant de mettre à jour les itinéraires ou les événements.
Vous pouvez choisir de procéder automatiquement à la réconciliation avant l’acquisition des verrous. Lorsque la réconciliation automatique est activée, vous pouvez acquérir un verrou sans procéder à la réconciliation sauf si des conflits sont détectés lors de la réconciliation.
La logique globale de prévention des conflits lors de la mise à jour d’un itinéraire est illustrée dans le diagramme suivant :
Types de verrous
La prévention des conflits dans Location Referencing fait appel à deux types de verrous :
- Verrous d’itinéraire et de ligne
- Verrous d’événement
Verrous d’itinéraire et de ligne
Les verrous d’itinéraire et de ligne empêchent d’autres personnes de mettre à jour un itinéraire et des événements sur cet itinéraire lorsque l’itinéraire est mis à jour.
Les verrous d’itinéraire et de ligne possèdent les propriétés suivantes :
- Un verrou est appelé verrou d’itinéraire lorsqu’un itinéraire d’un réseau continu est mis à jour.
- Un verrou de ligne est acquis lorsqu’un itinéraire d’un réseau d’ingénierie prenant en charge des lignes est mis à jour. La totalité de la ligne et tous ses itinéraires sont verrouillés. Un verrou de ligne signifie que si une personne met à jour l’un des itinéraires qui constituent une ligne, personne d’autre ne peut mettre à jour un autre itinéraire sur cette ligne.
- Un itinéraire verrouillé signifie que seule la personne possédant le verrou peut mettre à jour l’itinéraire et ses événements dans la version dans laquelle le verrou a été acquis, sauf si des conditions de transfert de verrou sont remplies.
Verrous d’événement
Les verrous d’événement empêchent d’autres personnes de mettre à jour une couche d’événements d’un itinéraire spécifique. Un verrou d’événement est acquis pour la couche d’événements d’un itinéraire ou d’une ligne.
Si User1 a verrouillé Event Layer1 pour Route1 dans Version1, le comportement suivant s’applique :
- Personne d’autre ne peut mettre à jour Event Layer1 pour Route1 dans aucune version.
- User1 ne peut pas mettre à jour Event Layer1 pour Route1 dans une version autre que Version1.
- D’autres personnes peuvent acquérir des verrous sur d’autres couches d’événements (à l’exception d’Event Layer1) pour Route1 ou pour tout autre itinéraire s’il n’existe pas de verrou d’itinéraire pour cet itinéraire.
- Personne ne peut acquérir de verrou d’itinéraire si plusieurs personnes possèdent des verrous pour cet itinéraire.
- D’autres personnes peuvent acquérir des verrous sur Event Layer1 pour n’importe quel autre itinéraire pour lequel l.acquisition de verrou est possible.
- Si la mise à jour concerne un événement (point ou ligne) inscrit sur un réseau prenant en charge les lignes, un verrou d’événement est acquis sur une ligne.
- Si la mise à jour concerne un événement (point ou ligne) inscrit sur un réseau ne prenant pas en charge les lignes, un verrou d’événement est acquis sur un itinéraire.
Remarque :
- S’il existe plusieurs tranches horaires d’un itinéraire ou d’un événement, le verrou acquis est valide pour toutes les tranches horaires.
- Les verrous sont acquis par les outils de géotraitement selon les besoins.
En présence d’événements pour un itinéraire, la logique de prévention des conflits est la suivante :
Prévention des conflits lors de la mise à jour d’axes médians
Lorsqu’il existe des itinéraires coïncidents, ils sont verrouillés selon des axes médians communs. La figure ci-après illustre ce concept :
- Si Route X est mis à jour, le verrou est acquis sur Route X et personne d’autre ne peut acquérir de verrou sur Route Y car ils partagent un axe médian commun, C2.
- Si Route Y est mis à jour, le verrou est acquis sur Route Y et personne d’autre ne peut acquérir de verrou sur Route X car ils partagent un axe médian commun, C2.
- Si l’axe médian C1 est mis à jour (réalignement cartographique ou axe médian fractionné), seul Route X est verrouillé.
- Si l’axe médian C3 est mis à jour, seul Route Y est verrouillé.
- Si l’axe médian C2 est mis à jour, Route X et Route Y sont verrouillés car C2 est un axe médian partagé entre ces deux itinéraires.
Libérer les verrous
Les verrous sont automatiquement libérés dans les cas suivants :
- La version contenant les verrous est réinjectée dans la version par défaut.
- La version contenant les verrous est supprimée.
- Les verrous acquis dans la version par défaut en raison d’une opération de mise à jour d’itinéraire, de mise à jour d’axe médian ou de l’utilisation d’outils de géotraitement sont libérés une fois l’exécution terminée.
Vous pouvez libérer manuellement les verrous en fonction de leur statut indiquant s’ils sont libérables.
Si la valeur du statut libérable indique Yes (Oui), vous pouvez libérer le verrou en procédant comme suit :
- Cliquez sur le bouton Release Locks (Libérer les verrous)
sur l’onglet Location Referencing. - Cliquez sur le bouton Release Locks (Libérer les verrous) disponible dans la table LRS Locks (Verrous LRS).
Si la valeur du statut libérable indique No (Non), le verrou ne peut pas être libéré.
Si la valeur du statut libérable est On Post (Sur réinjection), le verrou peut être libéré uniquement après la réinjection dans la version par défaut.
Résumé des règles de prévention des conflits
Lorsque la prévention des conflits est activée, vous pouvez mettre à jour un itinéraire après avoir acquis un verrou sur cet itinéraire dans les conditions suivantes :
- Personne ne possède de verrou sur cet itinéraire dans aucune des versions de la base de données.
- La même personne possède déjà un verrou d’itinéraire sur cet itinéraire présent dans la même version de la base de données utilisée.
Lorsque la prévention des conflits est activée et si les conditions de transfert de verrou ne sont pas remplies, vous ne pouvez pas mettre à jour d’itinéraire dans les cas suivants :
- La réconciliation avec la version par défaut est nécessaire.
- Il existe des conflits de géodatabase dans la version actuelle.
- L’itinéraire est déjà verrouillé par une autre personne.
- La même personne possède déjà un verrou d’itinéraire sur cet itinéraire dans une autre version de la base de données actuellement utilisée.
- Une autre personne possède des verrous d’événement sur cet itinéraire (si les conditions de transfert de verrou ne sont pas remplies).
- La même personne possède des verrous d’événement sur cet itinéraire dans une autre version de la base de données.
Lorsque la prévention des conflits est activée, vous pouvez mettre à jour un événement après l’acquisition d’un verrou sur cette couche d’événements dans les cas suivants :
- Personne ne possède de verrou sur cette couche d’événements pour l’itinéraire sur lequel se trouve l’événement dans aucune des versions de la base de données (si les conditions de transfert de verrou ne sont pas remplies).
- La même personne possède déjà un verrou d’événement dans la même version de la base de données utilisée (pour l’itinéraire sur lequel se trouve l’événement).
- La même personne possède déjà un verrou d’itinéraire ou de ligne dans la même version (pour l’itinéraire ou la ligne sur lequel se trouve l’événement).
Lorsque la prévention des conflits est activée, vous ne pouvez pas mettre à jour un événement dans les cas suivants :
- La réconciliation avec la version par défaut est nécessaire.
- Il existe des conflits de géodatabase dans la version actuelle.
- La couche d’événements est déjà verrouillée par une autre personne pour l’itinéraire sur lequel se trouve l’événement (si les conditions de transfert de verrou ne sont pas remplies).
- La couche d’événements est déjà verrouillée par la même personne pour l’itinéraire sur lequel se trouve l’événement, mais dans une version différente.
- L’itinéraire sur lequel se trouve l’événement est déjà verrouillé par une autre personne (si les conditions de transfert de verrou ne sont pas remplies).
- L’itinéraire sur lequel se trouve l’événement est déjà verrouillé par la même personne, mais dans une version différente.
Vous avez un commentaire à formuler concernant cette rubrique ?