Lorsque vous téléchargez et utilisez une carte hors connexion qui contient un service d’entités modifiable utilisant des données inscrites en versionnement classique, une version de réplica est créée à partir de la version utilisée par les données publiées et un service d’entités de réplica est créé et associé à la version de réplica. Lorsqu’un client synchronise les mises à jour avec le service d’entités de réplica, les mises à jour du client sont appliquées à la version de réplica. Par conséquent, vous devez effectuer des opérations de réconciliation et de réinjection supplémentaires pour intégrer les mises à jour dans la version publiée et partager les mises à jour.
Si la carte contient un service d’entités en lecture seule (seules les fonctions de requête et de synchronisation sont activées sur le service d’entités), et si le service d’entités contient des données versionnées, aucune version de réplica n’est créée lorsque la carte est téléchargée. De même, aucune version de réplica n’est créée lorsque les données sont copiées au cours de processus de collaboration distribuée. Lorsque les clients synchronisent leurs données avec le service d’entités dans ce cas, ils ont accès à des mises à jour des données source.
Remarque :
Même si le service d’entités est en lecture seule (seules les requêtes et la synchronisation sont activées), l’utilisateur de base de données qui se connecte à la géodatabase lors de la publication doit disposer de privilèges pour modifier les données.
Les deux options décrites ci-dessous permettent au propriétaire du service d’entités ou à l’administrateur ArcGIS Server de choisir la façon dont les versions traditionnelles sont créées pour un service d’entités modifiable particulier. L'éditeur définit ces options lors de la publication du service d'entités.
Créer une version pour chaque carte hors connexion
Il s’agit de l’option par défaut. Avec cette option, une version de réplica est générée à partir de la version publiée chaque fois que vous utilisez hors connexion une carte contenant un service d’entités modifiable. Le nom de la version de réplica inclut les éléments suivants :
- le nom de l'utilisateur qui télécharge la carte ;
- le nom du service d’entités ;
- un identifiant unique (ID).
Ces trois composants garantissent que le nom de version de réplica est unique. Par exemple, si l’utilisateur nommé Bob télécharge une carte contenant le service d’entités NetFs, le nom de la version de réplica créée pourrait être Bob_NetFS_1404578882000. Si le même utilisateur télécharge la carte à plusieurs reprises (par exemple, pour plusieurs périphériques), différentes versions de réplica sont utilisées lorsque l’utilisateur synchronise les données à partir de chaque périphérique. Un périphérique ne pourra pas accéder aux mises à jour à partir des autres périphériques. Toutefois, les cartes récemment téléchargées seront actualisées avec la version publiée. Si de nombreuses cartes ont été téléchargées, il existera de nombreuses versions de réplica. Étant donné que les cartes téléchargées sont supprimées de l’application utilisée pour les mises à jour hors connexion, leurs versions de réplica peuvent être réconciliées, réinjectées et supprimées.
Remarque :
Si vous avez publié le service d'entités synchronisable sur un site ArcGIS Server autonome qui ne possède pas de compte utilisateur individuel, le nom de la version de réplica sera Esri_Anonymous_<nom du service d'entités>_<ID>.
Les noms des versions de réplica ne doivent pas inclure plus de 30 caractères. La portion service d'entités du nom va être tronquée pour respecter cette limite.
Créer une version pour chaque utilisateur
Avec cette option, une version de réplica est générée pour chaque utilisateur qui télécharge une carte contenant un service d’entités modifiable. Par exemple, si 10 utilisateurs téléchargent la même carte, 10 versions de réplica sont générées. Chaque version de réplica est spécifique à un utilisateur individuel et le nom de la version de réplica est composé du nom d’utilisateur et du nom de service (par exemple, Joe_InspectionFS). Si un utilisateur télécharge la carte à plusieurs reprises (par exemple, pour plusieurs périphériques), la même version de réplica est utilisée lorsque l’utilisateur synchronise les données à partir de chaque périphérique. Un périphérique peut accéder aux mises à jour à partir des autres périphériques. Toutefois, les cartes téléchargées récemment refléteront uniquement la dernière réconciliation de la version de réplica par l’utilisateur. Une version de réplica d’un utilisateur est conservée tant que l’utilisateur dispose d’une carte téléchargée.
Remarque :
Si vous utilisez cette option, fédérez votre site ArcGIS Server avec un portail ou configurez les comptes utilisateur dans ArcGIS Server. Si vous ne procédez pas ainsi, le nom de la version de réplica créée sera Esri_Anonymous_<nom du service d’entités> et chaque utilisateur se connectant au portail pour utiliser la carte Web contenant le service d’entités hors connexion utilisera la même version de réplica.
Exemples de processus
Les exemples de processus suivants utilisent les options de version décrites dans les deux sections précédentes :
- Télécharger des cartes pour la maintenance des données
- Télécharger des cartes pour un projet de courte durée
- Télécharger des cartes pour un projet en cours
Les composants de chaque workflow sont comparés dans le tableau suivant :
| Télécharger pour la maintenance des données | Télécharger pour un projet de courte durée | Télécharger pour un projet en cours | |
|---|---|---|---|
Version de géodatabase à partir de laquelle le service d’entités est publié | |||
Une version de réplica est créée pour chacun | Carte téléchargée | Utilisateur | Utilisateur |
Nombre de versions de réplica créées | Plusieurs | Quelques-unes | Quelques-unes |
Latence entre les mises à jour hors connexion et les mises à jour dans la version par défaut | Faible | Elevée (1 semaine) | Elevée (quotidienne) |
Cartes impliquées dans l’assurance-qualité | Une carte | Toutes les cartes | Toutes les cartes |
Fréquence de suppression des versions de réplica | Tous les jours | A l'issue du projet | Jamais |
Télécharger des cartes pour la maintenance des données
Ce processus implique qu’un membre de l’organisation utilise ArcGIS Pro ou une application mobile personnalisée sur le terrain pour confirmer les mises à jour fournies par des cartes annotées. Dans ce cas, les données sont inscrites pour participer au versionnement traditionnel et les utilisateurs ont besoin de la carte qu’ils téléchargent pour disposer des données les plus récentes de la version par défaut dans la géodatabase. De retour au bureau et sur le réseau, les employés synchronisent les mises à jour effectuées sur le terrain, suppriment la carte, puis réconcilient et réinjectent la version de réplica de la carte avec la version de la géodatabase par défaut. Ce processus peut être répété plusieurs fois par jour. Une fois le processus terminé, les employés suppriment la version de réplica.
Pour ce faire, une carte Web est disponible dans le compte organisationnel de la société pour les membres du groupe d'utilisateurs du bureau. Un utilisateur qui est membre de ce groupe peut accéder à la carte Web à l’aide de l’application fonctionnant sur un appareil mobile sur le réseau interne du bureau. Avant de quitter le bureau, l’utilisateur télécharge la carte sur l’application. L'utilisateur se rend alors sur le terrain et inspecte les mises à jour demandées, bien que déconnecté du réseau. De retour au bureau, les corrections de l’utilisateur sont synchronisées avec le service d’entités, réconciliées et réinjectées avec la version par défaut.
Les sections suivantes décrivent ce workflow :
- Publication d'un service d'entités
- Création d'une carte Web
- Télécharger la carte Web
- Synchroniser les mises à jour
Publication d'un service d'entités
Pour créer la carte Web, un service d'entités doit d'abord être publié.
L’éditeur démarre ArcGIS Pro et ajoute des données à une carte à partir de la version par défaut. Dans cet exemple, les données incluent de nouveaux capteurs d'une classe d'entités de la géodatabase d'entreprise de la société. La classe d'entités a été inscrite comme versionnée.
L’éditeur publie une couche d’entités nommée NetFS qui référence les données inscrites à partir de ArcGIS Pro.
Lors du processus de publication, l’éditeur met à jour les paramètres suivants sur l’onglet Configuration de la couche d’entités pour pouvoir mettre la couche hors connexion et la modifier :
- Sous Enable editing and allow editors to (Activer la mise à jour et autoriser les éditeurs à), Add, update, and delete features (Ajouter, mettre à jour et supprimer des entités) permet une mise à jour complète des données.
- Enable Sync (Activer la synchronisation) permet de mettre la couche hors connexion.
- Sous Sync (Synchroniser), Create a version for each downloaded map (Créer une version pour chaque carte téléchargée) permet de créer une version de réplica portant un nom unique pour la carte hors connexion lorsque l’opérateur de terrain télécharge la carte. Cette version de réplica est alors utilisée lorsque l’opérateur synchronise des mises à jour.
L’éditeur partage également le service avec le groupe d’utilisateurs du bureau de sorte que les données puissent être accessibles à d’autres personnes de l’entreprise.
Création d'une carte Web
L'étape suivant la création d'un service d'entités consiste à créer une carte Web. Pour ce faire, l’éditeur se connecte à l’organisation (ArcGIS Enterprise ou ArcGIS Online), crée une carte web, ajoute une couche d’entités à la carte et partage la carte avec le groupe d’utilisateurs du bureau. La propriété de mode hors connexion de la carte Web est activée, afin de permettre son utilisation hors connexion. Les membres du groupe d'utilisateurs du bureau peuvent désormais télécharger la carte.
Télécharger la carte Web
Avec la carte Web mise à leur disposition, les utilisateurs peuvent la télécharger dans une application de leur appareil mobile, puis se rendre sur le terrain pour contrôler les mises à jour demandées. Pour ce faire, un utilisateur nommé Bob démarre l’application sur son appareil mobile tout en étant connecté au réseau, se connecte à l’organisation et télécharge la carte Web sur son appareil.
Lorsque le processus de téléchargement commence, une version de réplica nommée Bob_NetFS_1404578882000 est créée à partir de la version publiée (version par défaut) dans la géodatabase principale. Le service ayant été défini pour créer une version de chaque carte téléchargée, un nom de version unique est généré. Ce nom est composé de l’identifiant de l’opérateur de terrain (Bob), du nom du service d’entités (NetFS) et d’un ID unique. Cette version de réplica est utilisée lorsque la carte téléchargée est synchronisée.
Les données sont ensuite téléchargées sur l’appareil et l’application bascule vers la carte pour référencer les données locales. À ce stade, la carte peut être mise à jour sans se trouver sur le réseau.
Synchroniser les mises à jour
Alors qu'il se trouve sur le terrain, Bob note que l'un des capteurs est positionné de manière incorrecte et se trouve du mauvais côté de la route. Bob effectue cette correction dans l’application mobile.
Au cours de la journée, Bob peut visiter d'autres lieux et effectuer d'autres corrections. S’il dispose d’une connectivité, Bob peut également synchroniser les mises à jour sur le terrain. De retour au bureau, Bob se connecte au réseau interne sur l’appareil de terrain et effectue une synchronisation finale. Cela garantit que toutes les corrections effectuées sur le terrain sont appliquées à la version de réplica Bob_NetFS_1404578882000.
Les mises à jour du terrain étant synchronisées avec la source, Bob supprime la carte locale de l’appareil mobile et remet l’appareil en place. Le processus de retrait de la carte locale marque la version de réplica Bob_NetFS_1404578882000 comme n’étant plus associée à une carte hors connexion. Bob se connecte alors à la version de réplica Bob_NetFS_1404578882000 dans ArcGIS Pro et la réconcilie, puis la réinjecte dans la version par défaut. Bob utilise la détection des conflits basée sur les attributs et les résout manuellement, le cas échéant.
Une fois que les mises à jour ont été enregistrées et que Bob est retourné à la version par défaut, ce dernier supprime la version de réplica Bob_NetFS_1404578882000.
Bob découvre que davantage de déplacements sur le terrain sont nécessaires pour mettre à jour les données correctement. Chaque déplacement sur le terrain nécessite une nouvelle carte téléchargée et une nouvelle version de réplica Bob_NetFS_<ID>. Chaque nouvelle version de réplica inclut les dernières mises à jour de la version par défaut. Ces versions de réplica sont conservées dans la géodatabase jusqu’à ce qu’elles soient dissociées d’une carte, réconciliées et réinjectées.
Outre Bob, d'autres utilisateurs du bureau peuvent réaliser des tâches similaires en même temps que lui.
Une fois que les modifications de Bob ont été réconciliées et réinjectées dans la version par défaut, Bob supprime les versions de réplica Bob_NetFS_<ID>.
Télécharger des cartes pour un projet de courte durée
Dans cet exemple, des opérateurs de terrain utilisent des données versionnées hors connexion pour procéder à des mises à jour. Les données versionnées dans la géodatabase source référencent une version de projet qui est un enfant de la version par défaut.
Les opérateurs de terrain synchronisent les mises à jour, le matin ou en fin de journée, avec la version de projet. Un processus de réconciliation et de réinjection se déroule la nuit afin que les versions de réplica des opérateurs de terrain intègrent les mises à jour réalisées par d’autres opérateurs de terrain. Lorsque chaque opérateur de terrain effectue une synchronisation le matin suivant, chacun voit les mises à jour réalisées par les autres opérateurs de terrain. Une fois le projet terminé, toutes les mises à jour réalisées depuis le terrain ont été synchronisées et appliquées à la version du projet. La version du projet est alors vérifiée, puis réconciliée et réinjectée dans la version de la géodatabase par défaut. À l’issue du projet, un employé supprime le service d’entités et les versions de réplica des opérateurs de terrain.
Dans ce processus, la latence des données des opérateurs de terrain est inférieure à une semaine.
Les sections suivantes décrivent les étapes requises pour terminer ce workflow :
- Publication d'un service d'entités
- Création d'une carte Web
- Télécharger la carte Web
- Synchroniser les mises à jour
- Lancer le traitement nocturne de la géodatabase
- Supprimer les cartes hors connexion et exécuter des processus finaux de réconciliation et de réinjection
Publication d'un service d'entités
Dans cet exemple, un chef de projet a besoin de déployer des utilisateurs sur le terrain pour réaliser des inspections de capteurs. Les inspections de capteurs sont réalisées périodiquement tout au long de l'année. Au cours de ces dernières, les opérateurs de terrain vérifient et enregistrent des informations comme les dommages subis et l’accessibilité des capteurs. Ces informations sont utilisées pour planifier des réparations et déterminer les capteurs qui sont facilement accessibles. Le projet doit durer une semaine. Pour la collecte des données, chaque opérateur de terrain s’est vu remettre une tablette exécutant une application mobile personnalisée.
Pour ce projet, le gestionnaire de projet prévoit de créer et de partager une carte web pour les inspections de capteurs dans le compte d’organisation de la société. La carte Web référencera un service d’entités s’exécutant sur le site ArcGIS Server des locaux de la société.
Pour créer le service d’entités, le gestionnaire de projet ajoute la classe d’entités du capteur à partir de la version par défaut de la géodatabase d’entreprise source à une carte dans ArcGIS Pro. La classe d’entités a été inscrite pour un versionnement classique. Les capteurs marqués en vue de l'inspection sont de couleur jaune.
Pour organiser le travail, le gestionnaire de projets crée une version à partir de la version de la géodatabase par défaut. Le gestionnnaire nomme la version enfant Inspection et change la carte pour faire référence à cette version.
Ensuite, le gestionnaire de projets publie un service d’entités InspectionFS depuis ArcGIS Pro.
Lors du processus de publication, le gestionnaire de projet met à jour les paramètres suivants sur l’onglet Configuration de la couche d’entités pour pouvoir mettre la couche hors connexion et la modifier :
- Sous Enable editing and allow editors to (Activer la mise à jour et autoriser les éditeurs à), Add, update, and delete features (Ajouter, mettre à jour et supprimer des entités) permet une mise à jour complète des données.
- Enable Sync (Activer la synchronisation) permet de mettre la couche hors connexion.
- Sous Sync (Synchroniser), Create a version for each user (Créer une version pour chaque utilisateur) permet de créer une version de réplica pour l’utilisateur la première fois qu’un opérateur de terrain télécharge une carte. Cette version de réplica est utilisée lorsque l’opérateur synchronise des mises à jour.
Création d'une carte Web
Une fois que le service d’entités a été publié, le gestionnaire de projet crée une carte Web dans le portail ArcGIS Enterprise et la partage avec un groupe dont tous les opérateurs de terrain sont membres.
Le chef de projet exécute les étapes suivantes :
- Connectez-vous à l'organisation.
- Création d'une carte Web.
- Ajoutez le service d’entités que vous venez de publier à la carte web.
- Enregistrez la carte Web.
- Partagez la carte Web et le service d’entités avec le groupe qui inclut les opérateurs de terrain.
- Activez la propriété de mode hors connexion de la carte Web pour permettre son utilisation hors connexion.
Télécharger la carte Web
Chaque opérateur de terrain accède à la carte Web en se connectant à son compte dans l’organisation à partir de l’application mobile tout en étant toujours sur le réseau, puis télécharge la carte et les données sur son appareil.
Dans le schéma ci-dessous, l’un des opérateurs de terrain (Joe) lance le processus de téléchargement.
Joe choisit alors l’étendue et la résolution du fond de la carte.
Lorsque le processus de téléchargement commence, une version de réplica est créée à partir de la version publiée dans la géodatabase source appelée Joe_InspectionFS. Le service d’entités ayant été défini pour créer une version pour chaque utilisateur, le nom de la version de réplica est basé sur l’identifiant de l’opérateur de terrain (Joe) et le nom du service à partir duquel il a été créé (InspectionFS). Cette version de réplica est utilisée lorsque la carte téléchargée est synchronisée.
Remarque :
À chaque fois que Joe télécharge une carte du service InspectionFS, celui-ci se réfère à la version de réplica Joe_InspectionFS. Par exemple, à un certain stade, Joe peut avoir besoin de supprimer la carte locale et de la recréer avec une étendue plus importante. Lorsque Joe télécharge à nouveau la carte, toutes les mises à jour qui étaient synchronisées à partir de la version de réplica Joe_InspectionFS apparaissent dans la carte.
Dès que la carte et les données sont téléchargées, l’appareil mobile bascule vers la carte pour référencer les données locales. À ce stade, Joe peut mettre à jour la carte sans se trouver sur le réseau.
Un second opérateur de terrain (Mary) exécute les mêmes étapes que Joe. Ceci aboutit à la création d’une version de réplica Mary_InspectionFS dans la géodatabase source.
Synchroniser les mises à jour
Alors qu'il se trouve sur le terrain, Joe se voit affecter un travail sur la partie Est de la carte. Joe met à jour les états des entités du capteur tout en effectuant des inspections. Si le capteur satisfait aux critères d'inspection, il apparaît en vert. S'il est endommagé et nécessite une réparation, il apparaît en rouge.
À la fin de la journée, Joe se connecte au réseau à partir de l’appareil de terrain et procède à la synchronisation avec le service d’entités. Ceci applique les mises à jour à la version de réplica Joe_InspectionFS dans la géodatabase source.
A la fin de la journée, Mary synchronise également ses inspections de capteurs réalisées dans la partie Ouest de la carte.
Lancer le traitement nocturne de la géodatabase
Le soir, un processus automatique est exécuté pour réconcilier et réinjecter les mises à jour des opérateurs de terrain. Le processus commence par réconcilier chaque version de réplica avec la version Inspection avant de la réinjecter. Le processus applique une règle de résolution des conflits selon laquelle la dernière mise à jour est conservée et la détection des conflits est basée sur les attributs.
Lorsque toutes les mises à jour sur le terrain sont appliquées à la version Inspection, des scripts de validation sont exécutés sur les données. Ces scripts identifient et corrigent les mises à jour contenant des valeurs invalides ou des entités hors limite. Par exemple, le champ d'état doit comporter une valeur d'état valide. Si la valeur est incorrecte, l'état repasse au réglage Nécessite une inspection, ce qui est symbolisé par des points jaunes. À l’issue de la validation, le processus réconcilie les versions de réplica des opérateurs de terrain avec la version Inspection, afin que chacune intègre bien les dernières modifications.
Lorsque Joe et Mary effectuent une synchronisation le matin suivant, ils voient les mises à jour réalisées par l’autre.
Remarque :
Le processus nocturne pourrait également réconcilier les données avec la version par défaut pour inclure des mises à jour apportées à la version par défaut depuis le début du projet. Au lieu de cela, le gestionnaire de projet a choisi de ne procéder à la réconciliation avec la version par défaut qu’à la fin du projet. Cela permet la détection des conflits et une vérification manuelle avant réinjection dans la version par défaut. Si ce processus est effectué avant la fin du projet, les utilisateurs peuvent apporter des mises à jour supplémentaires à ces entités qui n’apparaîtront pas comme des conflits au niveau du processus de réconciliation final.
Notez également que, dans cet exemple, le processus automatisé permettant de réconcilier et de réinjecter les mises à jour des opérateurs de terrain se déroule la nuit. Cela signifie qu’un opérateur de terrain ne verra pas les mises à jour les plus récentes réalisées par les autres avant le jour suivant. Pour réduire cette latence, le processus peut être lancé plus fréquemment. Par exemple, s’il était lancé toutes les heures, un opérateur de terrain pourrait procéder à une synchronisation chaque heure pour récupérer les dernières mises à jour réalisées par les autres.
Supprimer les cartes téléchargées et exécuter des processus finaux de réconciliation et de réinjection
Le processus décrit ci-dessus se déroule sur une période d’une semaine du projet. Le projet est terminé lorsque tous les capteurs ont été inspectés. À la fin du projet, il est demandé aux opérateurs de terrain de synchroniser leurs dernières mises à jour et de supprimer la carte locale de l’application mobile. Une fois que les cartes locales ont été supprimées de l’application mobile, les versions de réplica des opérateurs de terrain ne sont plus associées à une carte téléchargée. Le chef de projet arrête et supprime ensuite le service d'entités.
Le gestionnaire de projets exécute les processus de réconciliation et de réinjection finaux sur toutes les versions de réplica des opérateurs de terrain et supprime chacune d’elles. Le chef de projet réconcilie, puis réinjecte la version Inspection avec la version par défaut. Le chef de projet examine et résout manuellement les conflits pendant ce processus. Une fois que ce dernier est terminé, les informations d’inspection des capteurs les plus récentes sont disponibles pour tous les utilisateurs dans la version par défaut. La dernière étape que doit accomplir le chef de projet consiste à supprimer la version Inspection.
Télécharger des cartes pour un projet en cours
Cet exemple de processus est similaire au processus précédent (Télécharger des cartes pour un projet de courte durée), dans la mesure où les opérateurs de terrain synchronisent les mises à jour qu’ils ont effectuées hors connexion. Ils se connectent au réseau et synchronisent leurs données le matin et en fin de journée. Comme dans le processus précédent, dans ce processus, le service d’entités est publié à partir d’une version d’assurance qualité plutôt que directement à partir de la version par défaut. Cela signifie que des processus de vérification, de réconciliation et de réinjection supplémentaires sont requis. En revanche, contrairement au processus précédent, la version d’assurance qualité demeure dans la géodatabase : elle n’est pas limitée à la vie d’un projet.
Les sections suivantes décrivent les étapes requises pour terminer ce processus :
- Publication d'un service d'entités
- Création d'une carte Web
- Télécharger la carte Web
- Synchroniser les mises à jour
- Lancer le traitement nocturne de la géodatabase
Publier le service d'entités
Pour ce projet, le gestionnaire de projets crée et de partage une carte Web pour les inspections de capteurs dans le compte d’organisation de la société. La carte Web référence un service d’entités s’exécutant sur le site ArcGIS Server des locaux de la société.
Pour créer le service d’entités, le gestionnaire de projet ajoute la classe d’entités du capteur à partir de la version par défaut de la géodatabase d’entreprise source à une carte dans ArcGIS Pro. La classe d’entités a été inscrite pour un versionnement classique. Les capteurs marqués en vue de l'inspection sont de couleur jaune.
Pour organiser le travail, le gestionnaire de projets crée une version enfant à partir de la version par défaut et nomme la version enfant Inspection. Le gestionnaire change la carte pour faire référence à la version Inspection.
Ensuite, le gestionnaire de projets publie un service d’entités InspectionFS à partir de la carte dans ArcGIS Pro.
Le chef de projet vérifie la fonctionnalité Sync (Synchronisation) dans la page Service Editor (Éditeur de services) dans ArcGIS Server Manager, car le service doit être utilisé dans une carte hors connexion. Le chef de projet clique également sur Options avancées pour afficher les Options avancées du service d'entités.
Dans les Options avancées du service d'entités, le chef de projet choisit l'option Créer une version pour chaque utilisateur. Avec cette option, la première fois qu’un opérateur de terrain télécharge une carte, une version de réplica est créée pour cet utilisateur. Cette version de réplica est alors utilisée lorsque l’opérateur synchronise des mises à jour.
Lors du processus de publication, le gestionnaire de projet met à jour les paramètres suivants sur l’onglet Configuration de la couche d’entités pour pouvoir mettre la couche hors connexion et la modifier :
- Sous Enable editing and allow editors to (Activer la mise à jour et autoriser les éditeurs à), Add, update, and delete features (Ajouter, mettre à jour et supprimer des entités) permet une mise à jour complète des données.
- Enable Sync (Activer la synchronisation) permet de mettre la couche hors connexion.
- Sous Sync (Synchroniser), Create a version for each user (Créer une version pour chaque utilisateur) permet de créer une version de réplica pour l’utilisateur la première fois qu’un opérateur de terrain télécharge une carte. Cette version de réplica est utilisée lorsque l’opérateur synchronise des mises à jour.
Création d'une carte Web
Une fois que le service d’entités a été publié, le gestionnaire de projet crée une carte Web dans le portail ArcGIS Enterprise et la partage avec un groupe dont tous les opérateurs de terrain sont membres.
Le chef de projet exécute les étapes suivantes :
- Connectez-vous à l'organisation.
- Création d'une carte Web.
- Ajoutez le service d’entités que vous venez de publier à la carte.
- Enregistrez la carte Web.
- Partagez la carte Web et le service d’entités avec le groupe qui inclut les opérateurs de terrain.
- Activez la propriété de mode hors connexion de la carte Web pour permettre son utilisation hors connexion.
Télécharger la carte Web
Chaque opérateur de terrain accède à la carte Web en se connectant à son compte à partir de l’application mobile tout en étant toujours sur le réseau, puis télécharge la carte et les données sur son appareil.
Dans le schéma ci-dessous, l’un des opérateurs de terrain (Joe) lance le processus de téléchargement.
Joe choisit alors l’étendue et la résolution de la carte.
Lorsque le processus de téléchargement commence, ArcGIS crée une version de réplica (Joe_InspectionFS) à partir de la version publiée (Inspection) dans la géodatabase source. Le service d’entités ayant été défini pour créer une version pour chaque utilisateur, le nom de la version de réplica est basé sur l’identifiant de l’opérateur de terrain (Joe) et le nom du service à partir duquel il a été créé (InspectionFS). Cette version de réplica est utilisée lorsque la carte est synchronisée.
Remarque :
À chaque fois que Joe télécharge une carte du service InspectionFS, celui-ci se réfère à la version de réplica Joe_InspectionFS. Par exemple, à un certain stade, Joe peut avoir besoin de supprimer la carte locale et de la recréer avec une étendue plus importante. Lorsque Joe télécharge à nouveau la carte, toutes les mises à jour qui étaient synchronisées à partir de la version de réplica Joe_InspectionFS apparaissent dans la carte.
Dès que les données et la carte sont téléchargées, l’appareil mobile bascule vers la carte pour référencer les données locales. À ce stade, Joe peut mettre à jour la carte sans se trouver sur le réseau.
Un second opérateur de terrain (Mary) exécute les mêmes étapes que Joe. Ceci aboutit à la création d’une version de réplica Mary_InspectionFS dans la géodatabase source.
Tandis que Mary et Joe mettent les données à jour sur le terrain, un nouveau capteur est ajouté à la version de géodatabase par défaut par un utilisateur au bureau. Le nouveau capteur est le résultat d’un nouveau projet dans la surface. Lorsque de nouveaux capteurs sont installés, une inspection est requise, elle apparaît alors en jaune.
Synchroniser les mises à jour
Alors qu'il se trouve sur le terrain, Joe se voit affecter un travail sur la partie Est de la carte. Joe met à jour l’état de chaque entité de capteur lors de l’inspection des capteurs. Si le capteur satisfait aux critères d'inspection, il apparaît en vert. S'il est endommagé et nécessite une réparation, il apparaît en rouge.
À la fin de la journée, lorsque l’appareil mobile est connecté au réseau, Joe procède à la synchronisation avec le service d’entités. Ceci applique les mises à jour à la version de réplica Joe_InspectionFS dans la géodatabase source.
A la fin de la journée, Mary synchronise également ses inspections de capteurs réalisées dans la partie Ouest de la carte.
Lancer le traitement nocturne de la géodatabase
Le soir, un processus automatique est exécuté pour réconcilier et réinjecter les mises à jour des opérateurs de terrain. Ce processus commence par réconcilier la version de chaque opérateur de terrain avec la version de réplica Inspection avant de la réinjecter. Le processus applique une règle de résolution des conflits selon laquelle la dernière mise à jour est conservée et la détection des conflits est basée sur les attributs.
Lorsque toutes les mises à jour sur le terrain sont appliquées à la version Inspection, des scripts de validation sont exécutés sur les données de cette version. Ces scripts identifient et corrigent les mises à jour contenant des valeurs invalides ou des entités hors limite.
Remarque :
À ce stade du processus, la version de réplica Mary_InspectionFS inclut les mises à jour de Joe, mais la version de réplica Joe_InspectionFS n’inclut pas les mises à jour de Mary. Ceci est dû au fait que la version de réplica Joe_InspectionFS a été réconciliée et réinjectée avant la version de réplica Mary_InspectionFS.
L'étape suivante du processus automatique implique la réconciliation et la réinjection de la version Inspection avec la version par défaut. Le processus utilise une détection des conflits basée sur les attributs et résout automatiquement les conflits. Le processus de réconciliation intègre les mises à jour de la version par défaut (nouveau capteur) dans la version Inspection, tandis que le processus de réinjection applique les mises à jour de la version Inspection (mises à jour de Joe et Mary) à la version par défaut.
La version de réplica de chaque opérateur de terrain est réconciliée une seconde fois avec la version Inspection pour terminer le processus automatisé. La version de réplica de chaque opérateur de terrain est désormais mise à jour.
Conseil :
Afin d’obtenir les dernières modifications des opérateurs de terrain, le processus de réconciliation est requis, mais le processus de réinjection ne l’est pas. Certaines organisations peuvent avoir besoin d'un processus séparé pour réinjecter les mises à jour dans la version par défaut, car cela permet aux personnes extérieures au projet d'y accéder.
Le matin suivant lorsque Joe et Mary procèdent à une synchronisation, ils voient les capteurs mis à jour par les autres opérateurs de terrain et le nouveau capteur de la version par défaut. Le nouveau capteur se trouvant du côté Est de la carte, Joe l’inspecte et synchronise les résultats. Le jour suivant, après l'exécution des processus nocturnes lancés, les informations d'inspection de Joe concernant le nouveau capteur sont intégrées à la version par défaut.
Ce processus se répète de façon permanente et quotidienne. Les versions de réplica Joe_InspectionFS et Mary_InspectionFS sont conservées aussi longtemps que Joe et Mary continuent leurs inspections de capteurs. Si, à un moment donné, ils arrêtent de travailler sur le projet, les versions de réplica peuvent être supprimées une fois que Joe et Mary ont procédé à une synchronisation finale et annulé l’enregistrement de leurs cartes locales, et que les processus de réconciliation et de réinjection finaux ont été effectués sur les versions de réplica Joe_InspectionFS et Mary_InspectionFS.
Vous avez un commentaire à formuler concernant cette rubrique ?