Conception de modèles de données efficaces pour la collecte de données sur le terrain

Les cartes SIG (système d'information géographique) incluent des couches opérationnelles et des couches de fond de carte. Les couches opérationnelles servent à mettre à jour et à identifier les entités. Les couches de fond de carte fournissent des informations de référence visibles à l'arrière-plan. Par exemple, un projet de terrain consistant à collecter des emplacements et attributs XY de nouvelles vannes dans une subdivision se composera d'une couche opérationnelle de vannes. Cette couche sera mise à jour sur le terrain. Vous pouvez également utiliser une couche opérationnelle de conduites pour aider le personnel de terrain à identifier des conduites spécifiques. Sous ces couches opérationnelles, vous pouvez ajouter une couche de fond de carte qui regroupe l'imagerie aérienne sur cette zone d'exécution des opérations sur le terrain pour afficher les rues, parcs et autres points d'intérêt en arrière-plan.

Pour les projets de terrain, assurez-vous que la carte est aussi simple que possible. Évitez l'emploi de couches inutiles et d'autres comportements ArcGIS for Desktop sophistiqués. Tenez compte des contraintes de votre périphérique mobile et des conditions dans lesquelles la carte mobile sera utilisée sur le terrain.

Prise en charge des géodatabases

Le service mobile et le cache mobile créés par l'outil Créer un cache mobile, ArcGIS for Windows Mobile prend en charge la mise à jour de données dans des géodatabases fichier et ArcSDE multi-utilisateurs. Votre carte mobile peut contenir des couches qui référencent d'autres sources de données, mais pour rendre une couche modifiable, sa source de données de la couche doit au moins être une classe d'entités stockée dans une géodatabase. Pour plus d'informations concernant les conditions requises pour une couche modifiable, consultez la section Conditions requises pour la structure de données en vue de définir la fonction des couches opérationnelles ci-après.

Remarque :

Notez également qu'une classe d'entités ne peut pas porter des noms de champ réservés par le langage SQL.

Un service d'entités hébergé présente moins de restrictions qu'un service mobile en termes de conditions requises pour la source de données. Vos données peuvent provenir d'une géodatabase fichier, d'une géodatabase ArcSDE, d'un fichier CSV ou d'un fichier de formes. Les données provenant de ces sources sont modifiables par les applications de terrain si vous les publiez en tant que services d'entités hébergées. Cependant, lorsqu'un jeu de données est publié en tant que service d'entités hébergé, les données sont copiées dans ArcGIS Online pour les organisations ou le stockage en ligne de Portal for ArcGIS. Par conséquent, toute modification effectuée par l'équipe de terrain ne retourne pas à la base de données source, mais vers le stockage en ligne.

Structure de données et fonctions des couches de carte opérationnelles

Lorsque vous concevez la structure des couches de carte opérationnelles, tenez compte de l'utilisation à laquelle vous destinez chaque couche et notez les conditions de structure requises de chacune d'elles. Vous devez également prendre en compte les propriétés des champs de couches.

Conditions requises pour la structure de données en vue de définir la fonction des couches opérationnelles

Les utilisations auxquelles vous pouvez destinez une couche opérationnelle sont décrites ci-dessous : Vous pouvez utiliser une couche à l'une des fins suivantes uniquement :

• Collecte de donnéesPour les services mobiles, le type de référentiel de données utilisé peut avoir une incidence sur la façon dont l'équipe de terrain effectue la collecte de données. Si les données proviennent d'une géodatabase fichier, une fois qu'elles sont hébergées sur un serveur ArcGIS Server, elles sont en lecture seule, même si vous leur avez ajouté un GlobalID. Dans ce cas, vous pouvez utilisez l'outil Créer un cache mobile pour générer un cache mobile et l'ajouter au cache de votre projet en vue de la collecte de données. Si toutefois les données proviennent d'une géodatabase ArcSDE et que vous ne les avez pas inscrites auprès du serveur avant la publication, elles sont également en lecture seule. Ces restrictions ne s'appliquent toutefois pas aux services d'entités, c'est-à-dire que les données sont toujours modifiables même si elle n'ont pas de GlobalID ou sont stockées dans une géodatabase fichier.
• Diffusion d'informations de référence en lecture seule - La structure d'une couche en lecture seule ne présente aucune restriction.
• Identification de l'utilisateur actuel - Une couche d'identité doit être une couche de points avec deux champs de texte, l'un pour stocker l'identité, l'autre le nom d'affichage de l'utilisateur. Si le personnel de terrain n'a pas l'intention de mettre la couche à jour, il n'est pas nécessaire d'utiliser le GlobalID. Si la couche doit être modifiée, vous pouvez l'héberger sur un serveur ArcGIS en tant que service mobile, sur ArcGIS Online pour les organisations ou Portal for ArcGIS en tant que service d'entités, ou la mettre en cache à l'aide de l'outil Créer un cache mobile.
• Couche de consignation - Cette couche de points doit être modifiable, elle doit contenir un champ de date/heure et un champ de texte pour le nom d'une machine (ou les informations d'identité si votre projet comporte une couche d'identité). Vous pouvez héberger la couche sur un serveur ArcGIS en tant que service mobile, sur ArcGIS Online pour les organisations ou Portal for ArcGIS en tant que service d'entités, ou la mettre en cache à l'aide de l'outil Créer un cache mobile.
• Couche de l'équipe sur le terrain - Similaire à la couche de consignation, cette couche de points doit être modifiable, elle doit contenir un champ de date/heure et un champ de texte pour le nom de la machine ou les informations d'identité. Comme cette couche synchronise et actualise régulièrement les dernières positions connues du personnel de terrain, elle doit provenir d'un service mobile/service d'identités, et non pas d'un cache mobile local.
• Masquée pour l'utilisateur - La structure d'une couche masquée ne présente aucune restriction.

Pour plus d'informations sur la fonction d'une couche, reportez-vous à la rubrique Propriétés de la couche opérationnelle.

Champs de couches et propriétés de champ

Le comportement des géodatabases pris en charge dans les applications ArcGIS for Windows Mobile englobe les éléments suivants :

• Sous-types - Utilisés pour classer les entités stockées dans une classe d'entités unique. Par exemple, vous pouvez classer trois entités en fonction du type d'arborescence. Lors de la création d'une entité d'arborescence, le personnel de terrain peut choisir le type d'arborescence à créer, ce qui lui évitera de le saisir comme attribut distinct.
• Domaines - Les domaines de valeurs précodées et les domaines de plage sont pris en charge. Chaque domaine de valeurs précodées s'affiche sous forme d'une liste de sélection lorsque vous rassemblez ou mettez à jour des valeurs attributaires. Les domaines par plage indiquent la plage de valeurs valides pouvant être saisies pour un attribut numérique et/ou de date.
• Valeurs par défaut - Lorsqu'une valeur par défaut est attribuée pour un champ attributaire, les applications de champ renseignent automatiquement le champ avec la valeur par défaut. Par exemple, un champ attributaire de hauteur pour une arborescence peut être défini sur 10. La valeur de hauteur pour les nouvelles entités d'arborescence se verront automatiquement attribuer la valeur 10. Si l'arborescence est inférieure ou supérieure à 10, l'équipe de terrain peut mettre à jour le champ de hauteur. Il est possible d'attribuer une valeur par défaut à n'importe quel champ attributaire d'une classe d'entités.
• Pièces jointes - En permettant aux classes d'entités de stocker des pièces jointes, vous pouvez gérer les informations relatives aux entités. Pour pouvoir utiliser les pièces jointes sur le terrain, vous devez d'abord les ajouter aux classes d'entités de géodatabase. Les pièces jointes servent souvent à stocker la photo numérique d'une entité. Vous pouvez collecter et afficher plusieurs pièces jointes pour une seule entité.
• Raster/BLOB (non pris en charge par le service d'entités) - Les champs de type raster/BLOB sont des champs spéciaux pouvant servir à stocker des photographies. Vous pouvez rechercher des photos et les ajouter à votre champ raster ou utiliser directement la caméra intégrée dans votre périphérique mobile. A noter que pour chaque entité, vous pouvez uniquement avoir une image par champ raster/BLOB.
  Attention :

  Pour stocker des images à l'aide d'un champ BLOB, utilisez esri_picture ou picture_ as comme préfixe du nom du champ. Par exemple, esri_picture et picture_Vanne.

• Dates - Les champs attributaires peuvent stocker des valeurs de dates. Sur le terrain, l'équipe peut mettre à jour un champ de date/heure en sélectionnant la valeur appropriée dans le calendrier qui s'affiche.
• Numéro de téléphone - Si vous utilisez un champ de texte pour stocker des numéros de téléphone et formater votre numéro de téléphone en (XXX)XXX-XXXX pour qu'il soit reconnu par un appareil Windows Mobile doté d'une puce cellulaire intégrée, vous pouvez mettre le téléphone sous tension et appeler directement le numéro à partir de l'application ArcGIS.

Remarque :

Les classes d'entités compatibles avec les valeurs z ou m peuvent être modifiées, mais les valeurs z et m ne sont pas conservées. Pour les entités collectées récemment, les valeurs z - et m ne sont pas définies.

ArcGIS for Windows Mobile ne permet pas de créer une nouvelle couche ou de modifier la structure des champs attributaires sur un périphérique mobile. Si vous prévoyez de capturer des entités qui n'existent pas dans votre modèle de données actuel ou si vous devez capturer des informations non structurées, telles que des annotations réalisées sur le terrain, il est recommandé de créer une classe d'entités supplémentaire dans votre structure de géodatabase afin de stocker ces informations.

Considérations en matière de conception de géodatabase

Remarque :

Si vous prévoyez de publier votre carte en tant que service d'entités, ignorez le reste de cette section.

Si vous prévoyez d'utiliser une géodatabase multi-utilisateurs existante pour un projet sur le terrain, effectuez l'une des opérations suivantes :

• Tirez parti de votre structure existante grâce à la réplication de géodatabase.
• Transformez votre géodatabase par un processus d'extraction, de transformation et de chargement (ETL).

Les sections suivantes décrivent les modèles de réplication de géodatabase et ETL qui permettent de gérer les applications de mise à jour sur le terrain à l'aide de géodatabases existantes.

Modèle de réplication de géodatabase

Vous pouvez publier le contenu de votre géodatabase multi-utilisateurs pour l'utiliser sur le terrain, puis utiliser le versionnement pour isoler les mises à jour sur le terrain de celles effectuées au bureau. Cependant, cette approche présente certaines difficultés. Par exemple, si vous avez besoin de synchroniser des mises à jour sur le terrain, votre géodatabase de production doit être accessible en dehors de votre pare-feu d'entreprise. Pour la plupart des organisations, cela s'avère impossible. Une meilleure approche consiste à utiliser la réplication de géodatabase et à isoler les informations collectées sur le terrain de celles qui sont continuellement mises à jour au bureau.

En utilisant la réplication de géodatabase, vous pouvez créer une instance de géodatabase d'entreprise distincte qui stocke les mises à jour sur le terrain et synchronise régulièrement les mises à jour avec la géodatabase parent. Avec cette approche, il vous suffit de répliquer les informations que vous devez emporter sur le terrain (et non l'intégralité de la géodatabase d'information) et vous pouvez isoler les services Web mobiles de votre géodatabase de production principale. La réplication peut s'avérer très utile dans un système distribué où des bureaux distants avec un personnel sur le terrain ne disposent pas de connexion au siège social ou lorsqu'un ordinateur portable embarqué contient une géodatabase répliquée et que les mises à jour sur le terrain sont synchronisées une fois l'appareil connecté au véhicule. Dans ces deux cas, vous pouvez stocker les métadonnées de chaque tâche de mise à jour sur le terrain ne figurant pas dans la géodatabase d'entreprise. Il peut s'agir, par exemple, des données de mesure GPS (Système de positionnement global) nécessaires à la correction différentielle des données collectées.

Modèle ETL

En général, vous ne représentez pas les informations spatiales dans une base de données d'entreprise de la même façon que lorsque vous les créez et les mettez à jour sur le terrain. La modélisation de polygones de lac comme entités linéaires de rivage permettant de les capturer en morceaux en est un exemple. Tout comme le fait de rassembler des tables de données normalisées ou des champs attributaires stockés dans la géodatabase d'entreprise en une table ou un attribut dans la géodatabase de terrain. Les informations attributaires de rue en est un autre exemple. Le nom de rue est souvent stocké dans plusieurs attributs (à savoir le numéro, préfixe, nom, suffixe, etc.). Dans ArcMap, vous utilisez une expression pour étiqueter le nom de rue complet. Si vous souhaitez afficher le nom de rue sur un périphérique mobile, rassemblez ces attributs dans un champ que vous pouvez étiqueter.

Vous pouvez utiliser des modèles de géotraitement pour gérer les processus ETL entre les géodatabases nomades et d'entreprise. Vous pouvez également utiliser l'extension Data Interoperability d'ArcGIS pour concevoir visuellement ces processus de transformation. Il est important de noter que les processus que vous définissez ne sont pas forcément bidirectionnels. Définissez un ensemble de modèles de géotraitement ou d'outils ETL spatiaux personnalisés pour transformer votre modèle de données pour un périphérique mobile et un deuxième ensemble de modèles pour réassembler les données de terrain et les rendre conformes à la structure d'entreprise.

Modèle de transaction nomade

Votre modèle de transaction tient compte de la façon dont vous comptez gérer vos mises à jour sur le terrain et les intégrer à votre géodatabase. Celui-ci est en partie défini par les décisions prises en termes de conception de géodatabase, mais également par le nombre de collaborateurs sur le terrain (éditeurs) à prendre en charge et le degré souhaité d'isolement de leurs mises à jour.

Voici quelques questions que vous devez vous poser concernant le modèle de transaction :

• Souhaitez-vous que les mises à jour sur le terrain s'appliquent à la version par défaut de la géodatabase ? Si la réponse est non, souhaitez-vous une version qui consolide toutes les mises à jour sur le terrain ou bien une version pour chaque éditeur sur le terrain ?
• Pouvez-vous mettre à jour la géodatabase sans avoir recours au versionnement ?
• Devez-vous archiver les modifications effectuées sur le terrain ?
• Comment allez-vous gérer les conflits entre les mises à jour effectuées sur le terrain ?

Les sections suivantes décrivent certaines fonctionnalités clés à prendre en compte lors de la conception d'une géodatabase destinée à être utilisée sur le terrain.

Mise à jour d'une géodatabase non versionnée

Si les équipes sur le terrain sont peu nombreuses et qu'elles exécutent des tâches de mise à jour simples (mise à jour d'attributs, par exemple) et qu'il y a peu, voire aucune chance que la même entité soit mise à jour, un modèle de transaction non versionné peut alors mieux convenir. Cette approche présente cependant un inconvénient potentiel : la mise à jour directe est la seule option disponible pour le personnel sur le terrain. Si pour quelque raison que ce soit, des mises à jour doivent être synchronisées mais ne sont pas complètes, la synchronisation devient problématique. Grâce au versionnement, la synchronisation des mises à jour par vos équipes sur le terrain devient plus souple.

A l'aide d'un modèle de transaction versionné, vous pouvez isoler les mises à jour effectuées sur le terrain, ajouter un post-traitement et un contrôle qualité supplémentaires avant de réconcilier les mises à jour. Selon la façon dont vous voulez isoler les mises à jour sur le terrain, vous pouvez créer une seule version qui stocke toutes les modifications ou une version par auteur des mises à jour. Si vous créez une version pour chaque éditeur, vous devez publier un service pour chacun d'eux. Une fois que les éditeurs ont terminé la capture ou la maintenance des données et synchronisé leurs mises à jour avec la géodatabase, ArcGIS for Desktop permet de réconcilier les modifications de versions avec la version parent du bureau.

Structure de mise à jour du client ArcGIS for Windows Mobile

Les applications ArcGIS for Windows Mobile n'ont pas de concept de démarrage, d'arrêt et de sauvegarde des modifications comme dans d'autres applications ArcGIS. Chaque mise à jour effectuée est stockée dans le cache mobile sur le périphérique jusqu'à la synchronisation des modifications avec le serveur. Vous pouvez choisir d'annuler une session de mise à jour dans l'application pour annuler toutes les modifications apportées sur le terrain et restaurer l'état d'origine de l'entité. En revanche, il est impossible d'annuler une seule modification à la fois.

La mise à jour de la couche d'entités ne permet pas de synchroniser directement vos modifications avec la géodatabase.

Réinjection des modifications

Les mises à jour effectuées sur le terrain sont stockées localement dans le cache du service mobile sur le périphérique mobile. Cet aspect est important, car les employés ne disposent pas toujours d'une connexion sur le terrain ou peuvent être amenés à éteindre et à recharger leurs appareils. Il est donc essentiel que les mises à jour ne soient pas perdues. Lorsque la connexion avec le serveur est établie, les mises à jour stockées dans le cache peuvent être synchronisées avec la base de données principale.

Lors de la réinjection des modifications depuis le périphérique mobile, seules les modifications, ou « deltas », sont envoyées au serveur. Par exemple, si vous modifiez un attribut sur une entité, seule la modification de ce champ spécifique est enregistrée plutôt que de signaler la modification de toute la ligne. Ainsi, lors de la synchronisation des modifications, seules les informations qui ont réellement été modifiées sont renvoyées au serveur.

Selon le nombre de modifications escomptées et le type de connexion aux données utilisé (service général de paquets radio GPRS, par exemple), vous souhaiterez peut-être activer les fonctions de réinjection uniquement lorsque vous serez de retour au bureau pour garantir une connexion haut débit stable.