Si la valeur Données en entrée est un dossier, il sera exploré de manière récursive afin d’y rechercher des fichiers KML (.kml) et KMZ (.kmz), des shapefiles (.shp), des classeurs Excel (.xlsx et .xls), des fichiers texte contenant des données tabulaires, (.csv, .txt et .tab), des fichiers GeoJSON (.geojson) et des fichiers GPX (.gpx). Le paramètre Filtre permet de limiter les fichiers qui sont importés des dossiers.
Les rasters, ou superpositions terrestres contenues dans un fichier .kml ou .kmz, sont convertis en un jeu de données mosaïque dans le paramètre Géodatabase cible. Les rasters source référencés par le jeu de données mosaïque sont stockés dans leur format natif dans un sous-dossier nommé d’après le jeu de données mosaïque. Ce sous-dossier se situe au même emplacement que la géodatabase cible. Ces fichiers sont nommés d’après la valeur Géodatabase cible, le suffixe _Rasters leur étant ajouté. Par exemple, si la valeur Géodatabase cible est C:\Data\OperationalData.gdb, un dossier nommé OperationalData_Rasters est créé sous C:\Data.
Si vous importez des fichiers dans une géodatabase d’entreprise, vérifiez que le fichier de connexion à la base de données (.sde) est spécifié sous forme de chemin UNC dans le paramètre Géodatabase cible et que le chemin est accessible par la géodatabase d’entreprise.
Il est possible de spécifier en entrée des fichiers KML et KMZ, versions 2.2 et antérieures de la norme Open Geospatial Consortium KML. Les emplacements des points qui utilisent l’onglet d’adresses (par géocodage) ne sont pas pris en charge. L’emplacement doit être spécifié selon sa latitude et sa longitude dans le fichier KML source.
Le délimiteur standard pour les fichiers texte à données tabulaires dotés des extensions .csv et .txt est une virgule, et pour les fichiers dont l’extension est .tab, il s’agit d’une tabulation. Pour utiliser une table en entrée avec un délimiteur non standard, vous devez spécifier ce dernier à l’aide d’un fichier schema.ini. Pour plus d’informations, reportez-vous à la rubrique Fichier Schema.ini (pilote du fichier texte) dans la documentation Microsoft.
Pour les feuilles de calcul Excel et les fichiers texte à données tabulaires en entrée, seule la géométrie de type point est prise en charge.
La spécification GeoJSON prend en charge plusieurs types de géométrie. Une classe d’entités distincte est créée pour chaque type de géométrie dans le fichier .geojson en entrée selon la convention de dénomination FichierGeoJSONSource_TypeGéométrie. Par exemple, si le fichier .geojson se nomme World Airports.geojson et qu’il contient les types de géométrie point, multi-points, polyligne et polygone, les classes d’entités sont nommées World Airports_Points, World Airports_Multipoint, World Airports_Polylines et World Airports_Polygons.
Les systèmes de coordonnées tiennent compte des éléments suivants lors de l’exécution de cet outil :
- Dans le cas des shapefiles, de fichiers .kml, .kmz, .geojson et .gpx, le système de coordonnées du jeu de données en sortie est le même que celui du jeu de données en entrée. Les spécifications KML et GPX exigent que le système de coordonnées du jeu de données en entrée soit GCS WGS1984.
- En ce qui concerne les classeurs Excel et les fichiers texte à données tabulaires, le système de coordonnées de la sortie est GCS WGS1984.
Si l’une des coordonnées en entrée d’une entité n’est pas valide (coordonnées nulles ou non valides), l’entité correspondante a une géométrie nulle. L’outil Vérifier les géométries permet de rechercher les géométries nulles dans la sortie.
Les coordonnées prises en charge pour les fichiers texte à données tabulaires (.csv, .txt et .tab) ainsi que pour les classeurs Excel sont des latitudes et longitudes en degrés décimaux dans le système de référence de carroyage militaire (MGRS) et au format USNG (United States National Grid). La source est recherchée parmi les colonnes de coordonnées dans l’ordre suivant : latitude et longitude dans des colonnes distinctes, latitude et longitude dans une même colonne, MGRS et enfin USNG.
En ce qui concerne les valeurs de latitude et de longitude dans une colonne unique, la valeur de latitude doit être la première, la longitude étant séparée par un espace, une virgule ou une barre oblique.
Les noms de colonnes suivants sont valides :
- Latitude : latitude, lat, y_coordinate, y_coord et y
- Longitude : longitude, long, lon, x_coordinate, x_coord et x
- Latitude/longitude : latitude_longitude, lat_long, lat_lon, xy_coordinate, xy_coordinates, xy_coord, xy_coords et xy
- Coordonnées MGRS : mgrs, mgrs_coordinate, mgrs_coordinates, mgrs_coord et mgrs_coords
- Coordonnées USNG : usng, usng_coordinate, usng_coordinates, usng_coord et usng_coords
Toutes les feuilles de calcul d’un classeur Excel sont importées.
La symbologie est appliquée aux couches en sortie qui sont ajoutées à la carte en fonction de la symbologie des fichiers de données source comme suit :
Une carte active doit exister dans le projet AllSource au moment de l’exécution de l’outil pour que la symbologie soit préservée. Si l’outil est exécuté en dehors d’un projet AllSource, c’est-à-dire à partir d’un script Python autonome, la symbologie n’est pas conservée.
- Dans le cas des couches en sortie créées à partir de fichiers .kml ou .kmz, la symbologie est extraite à partir du fichier source .kml ou .kmz et est appliquée aux couches en sortie. Il est possible de remplacer cette symbologie en fournissant un fichier de couche (.lyrx ou .lyr) dans le dossier du fichier .kml ou .kmzsource. Le fichier de couche doit avoir le même nom de base que le fichier de données source, auquel est ajouté un trait de soulignement (_), et le même type de géométrie (points, polylignes ou polygones) que la couche à remplacer. Par exemple, si le fichier .kml est nommé World Airports.kml, qu’il contient des entités ponctuelles, linéaires et surfaciques et que vous souhaitez remplacer la symbologie de tous les types de géométrie, les fichiers de couche sont nommés World Airports_Points.lyrx, World Airports_Polylines.lyrx et World Airports_Polygons.lyrx. Les valeurs du type de géométrie respectent la casse. Si un fichier de couche n’existe pas pour un type de géométrie donné, la symbologie du fichier .kml ou .kmz source est appliquée à la couche en sortie.
- Dans le cas de couches en sortie créées à partir de sources autres que des fichiers .kml ou .kmz, la symbologie est appliquée à la couche en sortie s’il existe un fichier de couche (.lyrx ou .lyr) dans le dossier du fichier de données source. Le fichier de couche doit avoir le même nom de base que le fichier de données source, à l’exception des feuilles de calcul Excel et des fichiers .geojson. Dans le cas de feuilles de calcul Excel, le fichier de couche doit porter le même nom de base que le fichier de données source, auquel est ajouté un trait de soulignement (_) et le nom de la feuille de calcul. Par exemple, si le fichier Excel s’appelle World.xlsx et qu’il contient une feuille de calcul nommée Cities (2018), le fichier de couche doit être nommé World_Cities (2018).lyrx ou World_Cities (2018).lyr. Dans le cas de fichiers .geojson, le fichier de couche doit porter le nom de base du fichier de données source, auquel est ajouté un trait de soulignement (_) et le type de géométrie en sortie (points, multi-points, polylignes et polygones). S’il n’existe aucun fichier de couche, un symbole par défaut est appliqué à la couche en sortie.