Skip To Content

Cartes en mode hors connexion et données versionnées traditionnelles

Lorsque vous téléchargez et utilisez hors connexion une carte qui contient un service d'entités modifiable utilisant des données inscrites en versionnement classique, une nouvelle version de la géodatabase est créée à partir de la version utilisée par les données publiées. Lorsqu'un client synchronise les mises à jour avec le service d'entités, les mises à jour sont appliquées à la nouvelle version. 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 avec d'autres.

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é contient des données versionnées, aucune version n'est créée lorsque la carte est téléchargée. De même, aucune version n'est créée lorsque les données sont copiées au cours de workflows 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.

Les deux options suivantes sont fournies pour permettre au propriétaire du service d'entités ou à l'administrateur ArcGIS Server de choisir la façon dont les versions 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.

Remarque :

Ces options ne s’appliquent pas aux données inscrites en tant que branche versionnée.

Créer une version pour chaque carte hors connexion

Il s'agit de l'option par défaut. Avec cette option, une version 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 version comporte 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 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 créé 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 sont utilisées lorsque l'utilisateur synchronise ses données à partir de chaque périphérique. Par conséquent, un périphérique ne pourra accéder aux mises à jour à partir de l'autre périphérique. 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 carte. Etant donné que les cartes téléchargées sont supprimées de l'application utilisée pour les mises à jour hors connexion, leurs versions peuvent être réconciliées, réinjectées et supprimées.

Remarque :

Si votre service d'entités a été publié sur un site ArcGIS Server qui n'est pas fédéré avec le portail ou si vous ne disposez pas de comptes utilisateur individuels dans ArcGIS Server, le nom de la version de carte sera Esri_Anonymous_<nom du service d'entités>_<ID>.

Créer une version pour chaque utilisateur

Avec cette option, une version est générée pour chaque utilisateur qui télécharge une carte contenant un service d'entités modifiables. Par exemple, si 10 utilisateurs téléchargent la même carte, 10 versions sont générées. Chaque version est spécifique à un utilisateur individuel, et le nom de la version 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 est utilisée lorsque l'utilisateur synchronise les données à partir de chaque périphérique. Par conséquent, un périphérique peut accéder aux mises à jour à partir de l'autre périphérique. Toutefois, les cartes téléchargées récemment refléteront uniquement les modifications de la dernière réconciliation effectuée par l'utilisateur. Une version d'utilisateur est conservée tant que l'utilisateur dispose d'une carte téléchargée.

Remarque :

Si vous utilisez cette option, vous devez soit fédérer votre site ArcGIS for Server avec un portail ou configurer les comptes utilisateur dans ArcGIS for Server. Si vous ne procédez pas ainsi, le nom de la version de carte créée sera Esri_Anonymous_<nom du service d'entités> et chaque utilisateur se connectant au portail utilisera la même version.

Exemples

Les sections suivantes vous guident dans des workflows d'exemple à l’aide des options de version décrites dans les deux sections précédentes :

Les sections suivantes comparent les composants de chaque workflow :

Workflow 1

Workflow 2

Workflow 3

Version à partir de laquelle le service d'entités est publié

Version par défaut

Version enfant

Version enfant

Une version hors connexion est créée pour chaque carte

Carte téléchargée

Utilisation

Utilisation

Nombre de versions créées

Plusieurs

Quelques-unes

Quelques-unes

Latence entre les mises à jour hors connexion et les mises à jour dans la version par défaut

Basse

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 hors connexion

Quotidien

A l'issue du projet

Jamais

Workflow 1 : Télécharger des cartes pour la maintenance des données

Ce workflow implique qu'un membre de l'organisation utilise Collector for ArcGIS sur le terrain pour confirmer les mises à jour fournies par des cartes annotées. Dans ce cas, les données sont versionnées et l'utilisateur a besoin de la carte qu'il ou elle télécharge pour disposer des données les plus récentes de la version par défaut de la géodatabase. De retour au bureau, l'employé synchronise les mises à jour effectuées sur le terrain, supprime la carte, puis réconcilie et réinjecte la version 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é, l'employé supprime la version hors connexion de la carte.

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 Collector for ArcGIS fonctionnant sur l'un des périphériques du bureau. Avant de quitter le bureau, l'utilisateur télécharge la carte à l'aide de Collector. L'utilisateur se rend alors sur le terrain et inspecte les mises à jour demandées. Les corrections sont effectuées sur le terrain à l'aide de Collector. De retour au bureau, les corrections de l'utilisateur sont synchronisées avec le service d'entités, puis réconciliées et réinjectées avec la version par défaut.

Les sections suivantes décrivent ce workflow :

Publier le service d'entités

Pour créer la carte Web, un service d'entités doit d'abord être publié.

L'éditeur démarre ArcMap et ajoute des données à la carte à partir de la version par défaut. Dans cet exemple, les données incluent quelques 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é enregistrée sous forme versionnée.

Version par défaut

L'éditeur publie un service d'entités nommé NetFS depuis ArcMap.

Service d'entités publié à partir de la version par défaut

Pendant la publication, il vérifie la fonctionnalité Synchroniser de l'Editeur de services puisque le service est destiné à être utilisé dans une carte hors connexion. L'éditeur vérifie également les fonctionnalités Requête, Mettre à jour, Créer et Supprimer car les données seront mises à jour. L'éditeur clique également sur Options avancées pour afficher les Options avancées du service d'entités.

L'option Créer une version pour chaque option est activée dans la boîte de dialogue Options avancées. Pour cet exemple, l'éditeur vérifie la Carte téléchargée. Avec cette option activée, une version portant un nom unique est créée pour la carte hors ligne lorsqu'un utilisateur sur le terrain utilise une carte hors connexion. Cette version est alors utilisée lorsque l'utilisateur procède à une synchronisation.

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 son entreprise.

Créer 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é du mode hors connexion de la carte Web est définie afin de permettre son utilisation hors connexion dans Collector for ArcGIS. 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 télécharger la carte dans Collector for ArcGIS, puis se rendre sur le terrain pour contrôler les mises à jour demandées. Pour ce faire, un utilisateur nommé Bob doit démarrer Collector et se connecter à l'organisation. La nouvelle carte Web partagée apparaît.

Etant donné que le mode hors connexion de la carte Web est activé, il apparaît dans Collector avec un bouton de téléchargement. Bob clique sur ce bouton pour lancer le processus de téléchargement.

Se connecter à la carte depuis Collector for ArcGIS pour la télécharger

Bob choisit alors l'étendue et la résolution du fond de la carte téléchargée.

Lorsque le processus de téléchargement commence, une version nommée Bob_NetFS_1404578882000 est créée à partir de la version publiée (version par défaut) dans la géodatabase principale. Etant donné que le service a é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'utilisateur sur le terrain (Bob), du nom du service d'entités (NetFS) et d'un ID unique. Cette version est utilisée lorsque la carte téléchargée est synchronisée.

Version créée lorsque la carte est téléchargée vers Collector

Les données sont alors téléchargées vers l'appareil. Une fois ces données téléchargées, Collector bascule vers la carte pour référencer les données locales. A ce stade, la carte peut être mise à jour sans nécessairement se trouver sur le réseau. Un bouton de synchronisation apparaît sur la carte dans Collector pour indiquer qu'elle est en train de procéder au référencement des données locales.

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. Il effectue la correction sur le terrain, à l'aide de Collector.

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 choisir de synchroniser les mises à jour sur le terrain. De retour au bureau, Bob se connecte au réseau interne sur son appareil et effectue une synchronisation finale. Ceci garantit que toutes les corrections effectuées sur le terrain sont appliquées à la version Bob_NetFS_1404578882000.

Se connecter au réseau et synchroniser les mises à jour

Une fois de retour au bureau et ses mises à jour synchronisées, Bob supprime la carte locale de Collector et remet l'appareil en place. Le processus de retrait de la carte locale marque la version Bob_NetFS_1404578882000 comme n'étant plus associée avec une carte hors connexion. Bob se connecte alors à la version Bob_NetFS_1404578882000 dans ArcMap 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.

Effectuer une réconciliation avec la version par défaut, résoudre les conflits et réinjecter les mises à jour dans la version par défaut

Une fois les mises à jour enregistrées et Bob revenu à la version par défaut, il doit supprimer la version Bob_NetFS_1404578882000.

Alors que Bob vérifie les mises à jour annotées au bureau, il se peut qu'il soit obligé d'effectuer d'autres déplacements sur le terrain. Chaque déplacement sur le terrain nécessite une nouvelle carte téléchargée et une nouvelle version Bob_NetFS_<ID>. Chaque nouvelle version inclura les dernières mises à jour à partir de la version par défaut. Ces versions seront conservées dans la géodatabase jusqu'à ce qu'elles soient dissociées d'une carte, puis 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 les modifications de Bob réconciliées et réinjectées dans la version par défaut, il doit supprimer les versions Bob_NetFS_<ID>.

Workflow 2 : Télécharger des cartes pour un projet de courte durée

Dans cet exemple, des utilisateurs sur le terrain utilisent des données versionnées hors connexion pour procéder à des mises à jour. Ils synchronisent leurs mises à jour le matin et en fin de journée. Un processus de réconciliation et de réinjection se déroule la nuit afin que les versions des utilisateurs sur le terrain intègrent les mises à jour réalisées par d'autres utilisateurs sur le terrain. Lorsque chaque utilisateur sur le terrain effectue une synchronisation le matin suivant, chacun voit les mises à jour réalisées par d'autres utilisateurs sur le 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. A l'issue du projet, un employé supprime le service d'entités et les versions de l'utilisateur sur le terrain. Dans ce workflow, la latence des données de l'utilisateur sur le terrain est inférieure à 1 semaine.

Les sections suivantes décrivent les étapes requises pour terminer ce workflow :

Publier le 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 utilisateurs sur le 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 utilisateur sur le terrain s'est vu remettre un smartphone sur lequel Collector for ArcGIS est installé.

Pour ce projet, le chef 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 fera référence à un service d'entités fonctionnant dans ArcGIS for Serveur dans les locaux de la société.

Pour créer le service d'entités, le chef de projet démarre ArcMap et ajoute la classe d'entités du capteur à partir de la version par défaut de la géodatabase d'entreprise source. La classe d'entités a été enregistrée sous forme versionnée. Les capteurs marqués en vue de l'inspection sont de couleur jaune.

Pour organiser le travail, le chef de projet crée une version nommée Inspection et change la carte pour référencer cette version.

Créer la version Inspection à partir de la version par défaut

Ensuite, le chef de projet publie un service d'entités InspectionFS depuis ArcMap.

Réinjecter le service d'entités à partir de la version Inspection

Le chef de projet vérifie la fonction Synchronisation de l'Editeur de services puisque le service sera 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 utilisateur télécharge une carte sur le terrain, ArcGIS crée une version pour cet utilisateur. Cette version est utilisée lorsque l'utilisateur synchronise des mises à jour.

Créer 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 utilisateurs sur le terrain sont membres.

Le chef de projet exécute les étapes suivantes :

  1. Connectez-vous à l'organisation.
  2. Création d'une carte Web.
  3. Ajoutez le service d'entités tout juste publié depuis ArcGIS for Server.
  4. Enregistrez la carte Web.
  5. Partagez la carte Web et le service d'entités avec le groupe qui inclut les utilisateurs sur le terrain.
  6. Activez la propriété hors connexion de la carte Web pour permettre son utilisation hors connexion dans Collector for ArcGIS.

Télécharger la carte Web

Chaque utilisateur sur le terrain accède à la carte Web en se connectant à son compte avec Collector for ArcGIS.

Avec la carte Web disponible, chaque utilisateur sur le terrain doit démarrer Collector et se connecter à l'organisation. La nouvelle carte Web partagée apparaît.

Etant donné que le mode hors connexion de la carte Web est activé, il apparaît dans Collector avec un bouton de téléchargement (le nuage avec une flèche). Un des utilisateurs sur le terrain (Joe) clique sur le bouton de téléchargement pour lancer le processus de téléchargement.

Se connecter depuis Collector for ArcGIS pour télécharger la carte

Joe choisit alors l'étendue et la résolution du fond de sa carte.

Lorsque le processus de téléchargement commence, une version est créée à partir de la version publiée dans la géodatabase source appelée Joe_InspectionFS. Etant donné que le service d'entités a été défini pour créer une version pour chaque utilisateur, le nom de la version est basé sur l'identifiant de l'utilisateur sur le terrain (Joe) et le nom du service à partir duquel il a été créé (InspectionFS). Cette version est utilisée lorsque la carte téléchargée est synchronisée.

Version de carte créée lorsque la carte est téléchargée

Remarque :

A chaque fois que Joe télécharge une carte depuis le service InspectionFS, elle est identifiée par la version Joe_InspectionFS. Par exemple, à un certain stade, il peut avoir besoin de supprimer la carte locale et de la recréer avec une étendue plus importante. Lorsqu'il téléchargera à nouveau la carte, Joe verra toutes les mises à jour qu'il a précédemment synchronisées à partir de la version Joe_InspectionFS.

Une fois la carte et les données téléchargées, Collector bascule vers la carte pour référencer les données locales. A ce stade, Joe peut mettre à jour la carte sans nécessairement se trouver sur le réseau. Un bouton Sync apparaît sur la carte dans Collector pour indiquer que le référencement des données locales est en cours.

Un second utilisateur sur le terrain (Mary) exécute les mêmes étapes que Joe. Ceci génère la création d'une version Mary_InspectionFS dans la géodatabase source.

Seconde version de carte créée lorsqu'un autre client télécharge la carte

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. Lorsque Joe réalise une inspection des capteurs, il note l'état de l'entité du capteur de façon appropriée. 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.

Une fois qu'il dispose d'une connectivité réseau en fin de journée, Joe clique sur le bouton Sync de Collector. Ceci applique les mises à jour à la version Joe_InspectionFS dans la géodatabase source.

Joe se connecte et synchronise les mises à jour

A la fin de la journée, Mary synchronise également ses inspections de capteurs réalisées dans la partie Ouest de la carte.

Mary se connecte et synchronise les mises à jour

Lancer le traitement nocturne de la géodatabase

Le soir, un processus automatique démarre pour réconcilier et réinjecter les mises à jour des utilisateurs sur le terrain. Le processus commence par réconcilier chaque version sur le terrain 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 recherchent 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. Une fois la validation terminée, le processus réconcilie les versions de l'utilisateur sur le terrain avec la version Inspection afin de garantir que chacune intègre bien les dernières modifications.

Mises à jour réconciliées et réinjectées avec la version Inspection

Lorsque Joe et Mary effectuent une synchronisation le matin suivant, ils voient les mises à jour réalisées par d'autres utilisateurs.

Joe et Mary réduisent le nombre de mises à jour réconciliées

Remarque :

Le processus nocturne pourrait également réconcilier les données avec la version par défaut pour appliquer des mises à jour apportées à la version par défaut depuis le début du projet. Au lieu de cela, le chef de projet a choisi de procéder à la réconciliation avec la version par défaut à la fin du projet uniquement. Ceci permet la détection des conflits et une vérification manuelle avant la 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 utilisateurs sur le terrain se déroule la nuit. Ceci signifie qu'un utilisateur sur le terrain ne verra pas les mises à jour les plus récentes réalisées pour les autres pendant la journée. Pour réduire cette latence, le processus peut être lancé plus fréquemment. Par exemple, s'il était lancé toutes les heures, un utilisateur sur le 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 un processus de réconciliation et de réinjection final

Le processus décrit ci-dessous se déroule sur une période d'une semaine du projet. Une fois tous les capteurs inspectés, le projet est terminé. A la fin du projet, il est demandé aux utilisateurs sur le terrain de synchroniser leurs dernières mises à jour et de supprimer la carte locale de Collector for ArcGIS. Une fois les cartes locales supprimées de Collector, les versions des utilisateurs sur le 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 chef de projet exécute des processus de réconciliation et de réinjection finaux sur toutes les versions des utilisateurs sur le terrain et supprime chacune d'entre 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 ce dernier terminé, les informations d'inspection des capteurs les plus récentes sont disponibles pour tous dans la version par défaut. La dernière étape que doit accomplir le chef de projet consiste à supprimer la version Inspection.

Version Inspection réconciliée et réinjectée dans la version par défaut

Workflow 3 : Télécharger des cartes pour un projet en cours

Cet exemple de workflow est similaire au workflow précédent (Télécharger des cartes pour un projet de courte durée), dans la mesure où les utilisateurs sur le 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. Toutefois, dans ce workflow, le projet est en cours de sorte que 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.

Les sections suivantes décrivent les étapes requises pour terminer ce workflow.

Publier le service d'entités

Pour ce projet, le chef 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 fera référence à un service d'entités fonctionnant dans ArcGIS for Serveur dans les locaux de la société.

Pour créer le service d'entités, le chef de projet démarre ArcMap et ajoute la classe d'entités du capteur à partir de la version par défaut de la géodatabase d'entreprise source. La classe d'entités a été enregistrée sous forme versionnée. Les capteurs marqués en vue de l'inspection sont de couleur jaune.

Pour organiser le travail, le chef de projet crée une version nommée Inspection et change la carte pour référencer cette version.

Créer la version Inspection à partir de la version par défaut

Ensuite, le chef de projet publie un service d'entités InspectionFS depuis ArcMap.

Réinjecter le service d'entités à partir de la version Inspection

Le chef de projet vérifie la fonctionnalité Sync de l'Editeur de services puisque le service est destiné à ê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 utilisateur télécharge une carte sur le terrain, une version est créée pour cet utilisateur. Cette version est alors utilisée lorsque l'utilisateur synchronise des mises à jour.

Créer 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 utilisateurs sur le terrain sont membres.

Le chef de projet exécute les étapes suivantes :

  1. Connectez-vous à l'organisation.
  2. Création d'une carte Web.
  3. Ajoutez le service d'entités tout juste publié depuis ArcGIS for Server.
  4. Enregistrez la carte Web.
  5. Partagez la carte Web et le service d'entités avec le groupe qui inclut les utilisateurs sur le terrain.
  6. Activez la propriété hors connexion de la carte Web pour permettre son utilisation hors connexion dans Collector for ArcGIS.

Télécharger la carte Web

Chaque utilisateur sur le terrain accède à la carte Web en se connectant à son compte avec Collector for ArcGIS.

Avec la carte Web disponible, chaque utilisateur sur le terrain doit démarrer Collector et se connecter à l'organisation. La nouvelle carte Web partagée apparaît.

Etant donné que le mode hors connexion de la carte Web est activé, il apparaît dans Collector avec un bouton de téléchargement (le nuage avec une flèche). Un des utilisateurs sur le terrain (Joe) clique sur le bouton de téléchargement pour lancer le processus de téléchargement.

Se connecter depuis Collector for ArcGIS pour télécharger la carte

Joe choisit alors l'étendue et la résolution du fond de sa carte.

Lorsque le processus de téléchargement commence, ArcGIS crée une version (Joe_InspectionFS) à partir de la version publiée dans la géodatabase source. Etant donné que le service d'entités a été défini pour créer une version pour chaque utilisateur, le nom de la version est basé sur l'identifiant de l'utilisateur sur le terrain (Joe) et le nom du service à partir duquel il a été créé (InspectionFS). Cette version est utilisée lorsque la carte est synchronisée.

Remarque :

A chaque fois que Joe télécharge une carte depuis le service InspectionFS, elle est identifiée par la version Joe_InspectionFS. Par exemple, à un certain stade, il peut avoir besoin de supprimer la carte locale et de la recréer avec une étendue plus importante. Lorsqu'il téléchargera à nouveau la carte, Joe verra toutes les mises à jour qu'il a précédemment synchronisées à partir de la version Joe_InspectionFS.

Une fois ces données et la carte téléchargées, Collector bascule vers la carte pour référencer les données locales. A ce stade, Joe peut mettre à jour la carte sans nécessairement se trouver sur le réseau. Un bouton Sync apparaît sur la carte dans Collector pour indiquer que le référencement des données locales est en cours.

Un second utilisateur sur le terrain (Mary) exécute les mêmes étapes que Joe. Ceci génère la création d'une version Mary_InspectionFS dans la géodatabase source.

Seconde version de carte créée lorsqu'un autre client télécharge la carte

Tandis que Mary et Joe mettent les données à jour sur le terrain, un nouveau capteur est ajouté à la géodatabase par défaut par un utilisateur au bureau. Le nouveau capteur est le résultat d'un nouvel événement de projet dans la surface. Lorsque de nouveaux capteurs sont installés, une inspection est requise, elle apparaît alors en jaune.

Mises à jour apportées à la version par défaut avant que les équipes sur le terrain ne synchronisent les mises à jour

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. Lorsque Joe réalise une inspection des capteurs, il note l'état de l'entité du capteur de façon appropriée. 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.

Une fois qu'il dispose d'une connectivité en fin de journée, Joe clique sur le bouton Sync de Collector. Ceci applique les mises à jour à la version Joe_InspectionFS dans la géodatabase source.

Joe synchronise les données et les mises à jour de la version de sa carte.

A la fin de la journée, Mary synchronise également ses inspections de capteurs réalisées dans la partie Ouest de la carte.

Mary synchronise les données et les mises à jour de la version de sa carte.

Lancer le traitement nocturne de la géodatabase

Le soir, un processus automatique démarre pour réconcilier et réinjecter les mises à jour des utilisateurs sur le terrain. Le processus commence par réconcilier et réinjecter la version de chaque utilisateur sur le terrain avec la version Inspection. 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 recherchent et corrigent les mises à jour contenant des valeurs invalides ou des entités hors limite.

Remarque :

À ce stade du processus, la version Mary_InspectionFS intègre les mises à jour de Joe, mais la version Joe_InspectionFS n'intègre pas les mises à jour de Mary. Ceci est dû au fait que la version Joe_InspectionFS a été réconciliée et réinjectée avant la version Mary_InspectionFS.

Les mises à jour des champs synchronisés sont réconciliées et réinjectées dans la version Inspection

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 depuis la version Inspection (mises à jour de Joe et Mary) à la version par défaut.

La réconciliation fait passer le nouveau capteur de la version par défaut à l'inspection

La version de chaque utilisateur sur le terrain est réconciliée une seconde fois avec la version Inspection pour terminer le processus automatisé. La version de chaque utilisateur sur le terrain est désormais mise à jour.

Astuce:

Afin d'obtenir les dernières modifications des utilisateurs sur le 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 ceci permet aux personnes extérieures au projet d'y accéder.

Versions clientes réconciliées avec la version Inspection

Le matin suivant lorsque Joe et Mary procèdent à une synchronisation, ils voient les capteurs mis à jour par les autres utilisateurs sur le terrain et le nouveau capteur de la version par défaut. Etant donné qu'il se trouve du côté Est de la carte, Joe inspectera le nouveau capteur et synchronisera 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 seront intégrées à la version par défaut.

Synchronisation des clients pour obtenir les mises à jour de la version Inspection

Ce processus se répète de façon permanente et quotidienne. Les versions 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 peuvent être supprimées une fois que Joe et Mary ont effectué 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 Joe_InspectionFS et Mary_InspectionFS.