Référence spatiale et géotraitement
La référence spatiale d'un jeu de données géographiques est composée des éléments suivants :
- un système de coordonnées qui est constitué d'une projection cartographique et d'un datum,
- une résolution XY et, facultativement, une résolution et un domaine M et Z,
- des tolérances XY et, facultativement, des tolérances M et Z.
Ces propriétés de référence spatiale peuvent avoir un impact significatif sur les performances et les résultats générés par un outil de géotraitement.
- Lorsqu'un outil de géotraitement crée des données en sortie, une référence spatiale doit être affectée au jeu de données nouvellement créé.
- Lorsqu'un outil de géotraitement traite des entités provenant de plusieurs classes d'entités (par exemple l'outil Intersecter) ou de plusieurs rasters (par exemple l'outil Superposition pondérée), les données doivent être importées dans une référence spatiale commune pour calculer des relations entre les contenus des deux jeux de données.
La référence spatiale du jeu de données en sortie et la référence spatiale dans laquelle se produit le traitement sont une seule et même référence spatiale. Une autre façon de l'exprimer est que les outils traitent toujours les données dans la référence spatiale du jeu de données en sortie.
Quelle est la référence spatiale en sortie par défaut ?
Les outils de géotraitement déterminent la référence spatiale en sortie en s'appuyant sur la logique suivante :
- Si la sortie se trouve dans un jeu de classes d'entités, les propriétés de référence spatiale du jeu de classes d'entités sont utilisées.
- Si la sortie est un jeu de données géographiques autonome (ne se trouvant pas dans un jeu de classes d'entités), les propriétés de référence spatiale sont les mêmes que celles du jeu de données géographiques en entrée.
- Si les données en entrée sont une couche dans un affichage, cette référence spatiale de la source de données de la couche est utilisée.
- Si les données en entrée sont une liste de jeux de données (par exemple, l'outil Intersecter), la référence spatiale du premier jeu de données en entrée est utilisée.
- Si l'outil n'a pas de jeu de données en entrée (par exemple, Créer une classe d'entités, Créer un jeu de classes d'entitéset Créer un catalogue d'images), il est particulièrement important de choisir un système de coordonnées afin que le reste des propriétés de référence spatiale (telles que la résolution et la tolérance XY) soit calculé par l'outil.
Procédure de remplacement des propriétés de la référence spatiale par défaut
Les environnements de géotraitement ci-dessous peuvent être utilisés pour remplacer les propriétés de référence spatiale en sortie par défaut suivantes. Si la sortie se trouve dans un jeu de classes d'entités, le système de coordonnées, ainsi que les propriétés XY et Z (sauf la gestion de Z) sont toujours ceux du jeu de classes d'entités.
- Système de coordonnées
- Tolérance XY
- Tolérance Z
- Résolution XY
- Domaine XY - Ignoré pour la sortie dans une géodatabase ultérieure à la version 9.2
- Valeurs Z en sortie
- Valeur Z en sortie par défaut
- Résolution Z
- Domaine Z
Les environnements suivants peuvent être utilisés, que la sortie soit autonome ou qu'elle se trouve dans un jeu de classes d'entités :
Pour la sortie du fichier en sortie reportez-vous à la rubrique Remarques concernant le géotraitement pour la sortie de fichiers de formes.
Outils à entrées multiples – le système de coordonnées affecte les performances des outils
Les outils de géotraitement qui acceptent plusieurs entrées, tels que les outils de la boîtes à outils Analyse ou de la boîte à outils Spatial Analyst, nécessitent que toutes les entités ou les rasters soient dans un système de coordonnées commun pour calculer les relations spatiales. Prenons l'exemple de l'outil Intersecter, qui calcule l'intersection géométrique de plusieurs classes d'entités. Supposons que cinq classes d'entités soient spécifiées comme données en entrée ; la première possède un système de coordonnées UTM et les autres un système de coordonnées Albers. La première classe d'entités étant en coordonnées UTM, les entités des quatre autres classes d'entités sont projetées d'Albers à UTM par l'outil Intersecter avant qu'il les traite. La projection de ces jeux de données peut réduire considérablement les performances ; il peut être beaucoup plus efficace de projeter une classe d'entités d'UTM à Albers plutôt que quatre d'Albers à l'UTM. Inversement, si la classe d'entités en coordonnées UTM contient de nombreuses entités par rapport au nombre total d'entités des quatre autres classes d'entités, il est plus efficace de projeter les autres classes d'entités d'Albers à UTM.
Pour améliorer les performances dans l'exemple ci-dessus, vous pouvez employer l'une des deux techniques suivantes :
- Définir la variable d'environnement du système de coordonnées en sortie de géotraitement sur le système de coordonnées approprié (Albers dans l'exemple précité). A chaque fois que l'environnement du système de coordonnées en sortie est spécifié, il est recommandé de préciser une transformation géographique appropriée si nécessaire.
- Veillez à ce que la première entrée du jeu de données géographiques dans l'outil contienne le système de coordonnées qui réduira la quantité de données projetées (Albers dans l'exemple précité).
Système de coordonnées pour les services de géotraitement ArcGIS Server
Les applications qui sont des clients d'un service de géotraitement ArcGIS Server peuvent définir le système de coordonnées de traitement. Ceci n'est toutefois pas recommandé et, en réalité, peu de clients définissent le système de coordonnées de traitement, mais il s'agit d'une possibilité. Lorsque le client définit un système de coordonnées de traitement, les outils dans le service de géotraitement projettent d'abord toutes les données sur ce système de coordonnées, ce qui peut réduire nettement les performances du service. Par exemple, le client peut définir le système de coordonnées de traitement sur WGS84 (un système de coordonnées géographiques). En poursuivant avec l'exemple de l'outil Intersecter, les cinq jeux de données sont transformés en WGS84 avant que l'outil Intersecter commence le calcul de l'intersection. Vous pouvez verrouiller le système de coordonnées de traitement pour votre service en définissant explicitement la variable d'environnement du système de coordonnées en sortie dans votre modèle ou votre script avant de le publier.
Evitez les systèmes de coordonnées inconnus
Le traitement des données avec un système de coordonnées approprié permet d'obtenir de meilleures valeurs par défaut pour la tolérance, la résolution et les domaines.
Vous devez éviter de traiter les données avec un système de coordonnées inconnu parce que les tolérances par défaut peuvent ne pas être adaptées pour l'outil. La valeur par défaut de Tolérance XY pour un système de coordonnées inconnu est 0,001 unité. Cette valeur est trop importante si les coordonnées des données sont dans un système de coordonnées géographiques où une unité (degrés décimaux) représente jusqu'à 110 kilomètres sur la surface de la Terre, ce qui signifie que la tolérance utilisée pour le traitement pourrait atteindre 110 mètres.
Pour obtenir de l'aide sur la façon de procéder si les données possèdent un système de coordonnées inconnu, reportez-vous à la rubrique Identification d'un système de coordonnées inconnu.
Le système de coordonnées affecte le résultat de l'outil
La relation spatiale ou topologique partagée par deux géométries dans un système de coordonnées peut changer lorsqu'elle est projetée sur un système de coordonnées différent. Par exemple, l'illustration suivante montre une ligne bleue qui connecte les villes de Jakarta et de Wellington. Selon le système de coordonnées dans lequel les données sont projetées et traitées, la ligne bleue qui relie les deux villes peut intersecter ou non la ville d'Alice Springs. Il est important de choisir un système de coordonnées approprié pour les données.
Définition de l'environnement du système de coordonnées dans ModelBuilder
L'environnement du système de coordonnées en sortie peut être défini pour un processus individuel (un processus est un outil plus ses entrée et données en sortie) ou pour le modèle entier. La définition de l'environnement au niveau du processus affecte uniquement l'exécution du processus individuel. La définition de l'environnement au niveau du modèle affecte tous les processus du modèle.
Pour définir le système de coordonnées au niveau du processus
- Dans ModelBuilder, cliquez avec le bouton droit sur un élément d'outil.
- Cliquez sur Générer une variable > Environnement de départ > Coordonnées en sortie > Système de coordonnées en sortie. Une nouvelle variable nommée Système de coordonnées en sortie est créée et connectée à l'outil.
- Double-cliquez sur Système de coordonnées en sortie et entrez le système de coordonnées approprié, qui est habituellement le système de coordonnées de la plus grande entrée de jeu de données géographiques de l'outil.
Pour définir le système de coordonnées au niveau du modèle
- Dans ModelBuilder, cliquez sur Modèle > Propriétés du modèle. Vous pouvez aussi, dans la fenêtre Catalogue ou ArcToolbox, cliquer avec le bouton droit sur le modèle puis sur Propriétés.
- Cliquez sur l'onglet Environnements.
- Développez Coordonnées en sortie.
- Activez Système de coordonnées en sortie.
- Cliquez sur le bouton Valeurs.
- Dans la boîte de dialogue Paramètres d'environnement, développez Système de coordonnées en sortie.
- Dans la liste Système de coordonnées en sortie, sélectionnez l'option Comme spécifié ci-dessous.
- Cliquez sur le bouton de navigation pour rechercher un système de coordonnées existant ou sélectionnez une variable de modèle dans la liste déroulante.
Pour obtenir un exemple de l'utilisation des systèmes de coordonnées, reportez-vous à la rubrique Exemple de service de géotraitement : découper et expédier. Ce modèle génère un fichier .zip qui contient une géodatabase fichier. Il peut être modifié afin que les jeux de données géographiques de la géodatabase de fichier en sortie aient le système de coordonnées de votre choix.
Pour en savoir plus sur la gestion des environnements dans des modèles