<\/HEAD>"Si vous ne planifiez pas, vous planifiez d'échouer." Ce vieil adage a une large applicabilitélorsque vous voulez perdre 10 livres, 00 10 livres, être choisi pour un poste de leadership, obtenir l'emploi parfait, et ainsi de suite. Donc, comme tout dans la vie, quand il s'agit d'analyse GIS, la planification paie. Pour garantir des résultats fiables, voici le processus éprouvé que nous recommandons :
- Formuler la question.<\/LI>
- Explorer et préparer les données.<\/LI>
- Choisir les méthodes et outils d'analyse.<\/LI>
- Réaliser l'analyse.<\/LI>
- Examiner et affiner les résultats.<\/LI><\/OL>
L'étape 2 est sans doute la plus critique car vos résultats finaux ne sont fiables que dans la mesure où les données de départ le sont. Lisez la suite pour un examen plus approfondi de l'exploration et de la préparation des données pour un projet d'analyse.Explorer les données<\/SPAN><\/STRONG>
La première partie de l'étape 2 découle directement de la question d'analyse. Prenez du temps au début pour identifier toutes les données, y compris les attributs, nécessaires pour répondre à la question. Ne vous retrouvez pas à mi-chemin d'un projet en découvrant qu'il vous manque un jeu de données clé.
Le but d'explorer les données est de comprendre ce que vous pouvez faire valablement avec elles. Vous devriez :Examiner les métadonnées. Notez la résolution spatiale et la précision, le système de coordonnées, quand les données ont été collectées et par qui, les contraintes d'utilisation des données, et d'autres informations importantes.<\/LI>Explorer tous les jeux de données spatiales que vous prévoyez d'utiliser dans ArcMap. Les couches s'alignent-elles correctement ? Certaines couches sont-elles plus généralisées que d'autres ? Certaines couches ont-elles une étendue plus grande (ou plus petite) que nécessaire ?<\/LI>Explorer la table attributaire de chaque couche et noter le nombre d'enregistrements et les attributs. Trier les champs et regarder les statistiques des champs pour comprendre les valeurs. Noter les erreurs évidentes de saisie des données et les incohérences.<\/LI><\/UL>Préparer les données<\/SPAN><\/STRONG>
Préparer les données signifie s'assurer que les jeux de données peuvent être analysés valablement ensemble et réduire autant que possible le temps de traitement. Les tâches de préparation des données incluent souvent la projection des données, la réduction de l'étendue spatiale à la zone d'intérêt, la suppression des attributs inutiles, la création de nouveaux attributs, le nettoyage des valeurs attributaires, et plus encore.
Tirez le meilleur parti des outils de géotraitement ArcGIS. Beaucoup peuvent être exécutés en mode batch et certains ont des options que vous pouvez utiliser pour combiner des tâches de préparation des données. Par exemple, dans l'outil Feature Class to Feature Class tool<\/A>, vous pouvez créer une expression SQL pour importer uniquement les entités situées dans votre zone d'intérêt, vous pouvez exclure les attributs source dont vous n'avez pas besoin, et vous pouvez définir de nouveaux champs attributaires dont vous avez besoin. Avec un seul outil, vous accomplissez trois étapes de préparation.
Vous pouvez également créer un modèle pour automatiser la préparation des données — il suffit de glisser-déposer les outils de géotraitement dont vous avez besoin dans une fenêtre modèle et définir leurs paramètres. Créer un modèle est un excellent moyen de visualiser et ordonner les tâches au fur et à mesure.
Les mêmes données peuvent être utilisées pour plusieurs analyses. Il est bon usage de faire une copie des données originales avant d'apporter des modifications pour préparer un projet spécifique. De cette façon, les données originales sont préservées pour des analyses ultérieures — et vous avez quelque chose vers quoi revenir au cas où.Exemple : Analyser les incidents de piraterie<\/SPAN><\/STRONG>
Regardons un exemple simple pour illustrer l'importance d'explorer et préparer les données. La question d'analyse a été formulée comme suit :Entre 2009 et 2011, quels types de navires ont été les victimes les plus fréquentes de piraterie dans et autour du Golfe d'Aden et de la mer d'Arabie ?<\/LI><\/UL>
L'Agence nationale américaine du renseignement géospatial (NGA) distribue des rapports Anti-Shipping Activity Messages<\/A> (ASAM), qui incluent des localisations et descriptions d'actes hostiles contre navires et marins dans le monde entier. Vous pouvez télécharger les données ASAM au format shapefile depuis le site web NGA.Explorer les données<\/SPAN><\/STRONG>
Après avoir téléchargé le shapefile ASAM, ajoutez-le à ArcMap. Pour le contexte géographique, il est utile d'ajouter une carte de base ; dans ce cas, la Carte topographique mondiale <\/A>d'ArcGIS Online fonctionne bien.
Le graphique cartographique à droite montre l'étendue globale des données ASAM (symbolisées par des points rouges). Une exploration rapide de la table attributaire révèle 6 158 enregistrements ; un attribut stocke un code sous-régional mondial ; et un attribut stocke la date à laquelle chaque incident s'est produit — la plage de dates va du 01/05/1978 au 09/01/2012. 
Pour répondre efficacement à la question d'analyse, vous devez réduire les données aux incidents survenus entre le 01/01/2009 et le 31/12/2011 dans la sous-région 62 (le site NGA liste les codes sous-région). Vous devez aussi effectuer quelques autres préparations pour résoudre certains problèmes avec ces données.Problème 1 : Les données n'ont pas de référence spatiale.<\/SPAN> <\/STRONG>
Lorsque le shapefile ASAM a été ajouté à ArcMap, un message indiquant que les données manquaient une référence spatiale est apparu. Pour les shapefiles, l'information sur la référence spatiale est stockée dans le fichier projection (.PRJ) et il n'est pas rare que ce fichier .PRJ soit manquant, comme ici. Alors comment savoir quel système de coordonnées utiliser ?
Un bon point de départ est la boîte de dialogue Propriétés du calque. Dans l'onglet Source, lorsque vous regardez les coordonnées d'étendue, le nombre de chiffres à gauche des décimales indique qu'il s'agit d'un système géographique. 
Avec les systèmes géographiques, les valeurs d'étendue Gauche et Droite auront entre un et trois chiffres à gauche du point décimal, tandis que celles du Haut et Bas auront entre un ou deux chiffres à gauche du point décimal.Conseil :<\/EM> Vous pouvez apprendre des méthodes pour identifier des systèmes inconnus dans le cours web Travailler avec les systèmes de coordonnées dans ArcGIS<\em>. <\LI> Puisque ces données ont une étendue globale, il est raisonnable d'attribuer le système géographique WGS 1984. Si votre analyse impliquait des mesures précises, vous voudriez aussi attribuer un système projeté adapté à votre zone d'intérêt.Problème 2 : Les données sont plus étendues que nécessaire.<\SPAN>Les données ASAM ont une étendue spatiale plus grande ainsi qu'une étendue temporelle plus longue que nécessaire. Les requêtes SQL résoudront ces problèmes.Pour cette analyse, les tâches initiales de préparation sont :1. Créer une géodatabase fichier pour organiser les données du projet.2. Importer le shapefile ASAM dans la géodatabase fichier.
- N'importer que les entités situées dans la sous-région 62 qui tombent dans l'intervalle du 01/01/2009 au 31/12/2011.<\LI>
3. Attribuer le système WGS 1984 à la classe d'entités dans la géodatabase. Le graphique modèle à droite montre le flux de travail du géotraitement.Une expression SQL a été définie dans la boîte de dialogue Feature Class to Feature Class afin que seuls les incidents répondant aux critères soient importés.
Après avoir exécuté le modèle, vous disposez d'une nouvelle classe d'entités avec 643 entités. Maintenant que ces données sont plus gérables en taille, avant de passer à l'étape 3 du processus d'analyse, vous devez vérifier que toutes ces 643 entités représentent bien des incidents de piraterie survenus pendant la période analysée.Dans les données ASAM, deux champs contiennent des informations sur la date (Reference and DateOfOcc). DateOfOcc stocke mm/jj/aaaa tandis que Reference inclut l'année suivie par un numéro ID unique. Le champ Reference a été utilisé dans l'expression SQL lors du dialogue Feature Class to Feature Class par commodité mais cela signifie qu'il faut maintenant nettoyer ces données. Trier le champ DateOfOcc révèle que quatre enregistrements ont 2009 dans Reference (reflétant l'année où le rapport a été soumis), mais leurs valeurs DateOfOcc indiquent que ces incidents se sont réellement produits durant la dernière semaine de 2008. Ces enregistrements peuvent être supprimés. Il reste donc maintenant 639 enregistrements à analyser.Problème 3 : Les valeurs attributaires sont incohérentes.<\SPAN>Ensuite, vous devez faire sûr que tous les enregistrements sont des incidents de piraterie. Le champ Aggressor stocke cette information. Le tri du champ Aggressor révèle plusieurs valeurs, dont la grande majorité contient une variation de "pirate."
- Astuce : Une méthode visuelle rapide pour comprendre comment les valeurs d'Aggressor varient est d'ouvrir la boîte de dialogue Propriétés de la couche et de symboliser la couche par Valeurs uniques basées sur le champ Aggressor. Chaque valeur unique d'agresseur s'affiche et le champ Count vous indique combien il y en a de chaque.
Après avoir exploré les valeurs d'Aggressor, vous pouvez créer une requête d'attribut pour sélectionner tous les enregistrements qui ont une des variations "pirate" dans le champ Aggressor, puis changer la sélection pour voir combien d'enregistrements ne font pas directement référence à des agresseurs pirates. Dans ce cas, seulement 16 incidents ont des valeurs d'Aggressor qui ne font pas référence aux pirates.Vous devez explorer les descriptions des incidents pour déterminer si l'un de ces 16 était probablement une attaque par des pirates. S'ils n'impliquaient clairement pas d'agresseurs pirates, supprimez les enregistrements. Dans ce cas, les descriptions des incidents n'excluent pas clairement les agresseurs pirates, donc vous choisissez de garder les enregistrements mais de les catégoriser pour tenir compte de l'ambiguïté. Vous utilisez le Calculateur de champs pour changer ces 16 valeurs d'Aggressor en Possible Pirates, et vous nettoyez les enregistrements restants afin qu'ils aient tous une valeur d'Aggressor de Pirates.Problème 4 : La table contient des enregistrements en double. Avec le champ DateOfOcc trié, un regard sur le champ Reference montre quelque chose d'alarmant. Il semble y avoir beaucoup d'enregistrements en double — des enregistrements avec la même valeur Reference et des données identiques dans les autres champs attributaires. Comment cela se peut-il ? Quelque chose a-t-il mal tourné lorsque vous avez converti le shapefile en classe d'entités géodatabase ? C'est le moment de revenir aux données originales et de déterminer si les doublons existaient déjà là. En raison du nombre d'entités dans le shapefile, il est efficace de résumer le champ Reference, ce qui produit une table avec un compte de chaque valeur unique de référence dans le shapefile.Après avoir créé la table récapitulative et trié le champ Count_Reference, vous voyez que beaucoup de numéros Reference ont un doublon. Pour savoir exactement combien, sélectionnez les enregistrements dont la valeur Count_Reference est égale à 2. Il s'avère que 493 numéros Reference ont un doublon dans les données sources avec lesquelles vous avez commencé. Déterminer combien de ces 493 sont dans votre classe d'entités géodatabase nécessite plus de travail.Tout comme vous l'avez fait pour le shapefile, dans la couche Incidents to Analyze, résumez le champ Reference pour produire une table avec un compte des valeurs reference, puis sélectionnez les enregistrements dont la valeur Count_Reference est égale à 2. Il s'avère que 170 enregistrements ont un doublon. Existe-t-il un moyen facile de supprimer 170 enregistrements en double ? Oui, assez facilement. Voici comment :
- Joignez la table récapitulative des valeurs reference à la table Incidents to Analyze.
- Sélectionnez les enregistrements dont la valeur Count_Reference est égale à 2 — comme prévu, il y a 340 enregistrements sélectionnés.
- Démarrez une session d'édition, puis utilisez l'outil Delete Identical pour supprimer les enregistrements sélectionnés qui ont la même valeur Reference qu'un autre enregistrement (notez qu'avant d'exécuter l'outil Delete Identical, vous devez supprimer la jointure de table — les enregistrements sélectionnés restent sélectionnés après la suppression de la jointure).
Résultat final : 469 incidents prêts à être utilisés comme entrée à l'étape 3 du processus d'analyse SIG.Toute cette exploration et préparation des données n'a vraiment nécessité que quelques heures de travail concentré. Bien sûr, les valeurs des victimes des incidents nécessitent probablement aussi un nettoyage — mais nous terminerons l'exemple ici car la ligne frontière entre les étapes 2 et 3 du processus d'analyse SIG n'est pas une clôture solide.Conclusion : Lors de la préparation des données pour l'analyse, vous devez prendre des décisions et vivre avec une certaine incertitude. Vos critères spécifiques d'analyse et votre connaissance du sujet déterminent jusqu'où vous allez dans le nettoyage des données. Pour éviter de créer ou propager des erreurs, explorez soigneusement les données et documentez toute préparation effectuée ainsi que vos raisons. N'oubliez pas qu'un modèle est un outil précieux pour documenter votre flux de travail et aider les autres à mieux comprendre vos résultats d'analyse.Les données que vous utilisez pour un projet d'analyse SIG peuvent ne pas être parfaites et peuvent ne pas correspondre exactement à vos besoins. Mais la planification et la préparation contribuent grandement à garantir que les données génèrent des résultats fiables que vous pouvez partager avec confiance.Vous souhaitez apprendre davantage sur les meilleures pratiques pour l'analyse SIG ? Voici des cours qui peuvent aider.
