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. Evitez 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

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 si vous souhaitez capturer de nouvelles entités ou mettre à jour des entités existantes, la source de données de la couche doit être une classe d'entités stockée dans une géodatabase. Le workflow de la géodatabase fichier est un workflow bureautique qui fait appel aux outils de géotraitement mobiles et à Mobile Project Center pour créer un projet et synchroniser les mises à jour sur le terrain avec la géodatabase parent. De même, la géodatabase multi-utilisateurs peut utiliser les outils de géotraitement, ainsi qu'ArcGIS Server pour créer des services mobiles qui pourront ensuite servir à définir un projet dans Mobile Project Center. Lorsqu'ils disposent d'une connexion, les utilisateurs sur le terrain peuvent ainsi télécharger les jeux de données modifiés sur le serveur.

Voici les conditions requises pour les classes d'entités ArcGIS for Windows Mobile (couches opérationnelles) :

• Elles doivent être stockées dans une base de données fichier ou multi-utilisateurs (ArcSDE).
• Les classes d'entités ne peuvent pas porter des noms de champ réservés par le langage SQL.

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 :

• Pour collecter des données - Une couche de collecte de données doit contenir le champ GlobalID. En outre, pour qu'une couche opérationnelle réside dans une géodatabase fichier modifiable, vous devez utiliser l'outil Créer un cache mobile pour générer un cache mobile à partir de la carte contenant la couche. Si la couche réside dans une géodatabase ArcSDE, vous pouvez également utiliser l'outil Créer un cache mobile pour générer un cache mobile ou alors publier la carte dans ArcGIS 10.1 for Server en tant que service mobile (dans ce cas, vous devez inscrire la base de données auprès du serveur).
• Pour fournir des informations de référence en lecture seule - La structure d'une couche en lecture seule ne présente aucune restriction.
• Pour identifier 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 GlobalID. Vous pouvez héberger la couche sur un serveur ArcGIS ou la mettre en cache à l'aide de l'outil Créer un cache mobile.
• Couche de consignation - Cette couche de points doit contenir le champ GlobalID, un champ de date/heure et un champ de texte pour le nom de la machine (ou les informations d'identité si votre projet comporte une couche d'identité). Vous pouvez héberger la couche sur un serveur ArcGIS 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 contenir le champ GlobalID, 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, 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 de géodatabase pris en charge dans les applications ArcGIS for Windows Mobile est défini par les propriétés suivantes :

• 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 valeurs par défaut sont signalées par un astérisque (*). Si aucune valeur par défaut n'est spécifiée, vous êtes invité à saisir une valeur valide. Les domaines par plage indiquent la plage de valeurs valides que vous pouvez saisir pour un attribut numérique.
• Valeurs par défaut - Lorsqu'une valeur par défaut est attribuée pour un champ attributaire, vous n'avez pas besoin de la saisir. 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, vous pouvez entrer la hauteur appropriée. 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 - 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, vous devez utiliser 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 dates s'ils sont définis comme type de données. Vous pouvez définir la date et l'heure actuelles lors de la mise à jour en sélectionnant la valeur appropriée dans le calendrier qui s'affiche dès que vous modifiez le champ attributaire.
• Numéro de téléphone - Si vous utilisez un champ de texte pour stocker des numéros de téléphone et formater correctement votre numéro de téléphone 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 ni 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

Les applications de terrain ArcGIS for Windows Mobile et le SDK exploitent pleinement les données que vous intégrez à votre géodatabase et la façon dont vous affichez le contenu dans ArcMap.

Si vous prévoyez d'utiliser une géodatabase multi-utilisateurs sur le terrain, vous pouvez effectuer 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, vous devez rassembler 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. Vous devez définir 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 de carte mobile pour chacun d'eux. Lorsqu'ils auront effectué la collecte ou la maintenance des données et synchronisé leurs mises à jour avec la géodatabase, il faudra utiliser ArcGIS for Desktop pour réconcilier les modifications de versions avec la version parent du bureau.

Infrastructure de mise à jour du client ArcGIS for Windows Mobile

Contrairement aux autres applications ArcGIS, le concept d'ouverture, de fermeture et de sauvegarde d'une session de mise à jour n'existe pas dans les applications ArcGIS for Windows Mobile. Chaque mise à jour effectuée est stockée dans le cache du service mobile sur le périphérique jusqu'à ce que vous décidiez de synchroniser les 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 alors être synchronisées avec le serveur.

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.