Résumé
Importe des répertoires de fichiers KML, de fichiers KMZ, de shapefiles, de feuilles de calcul Excel, de fichiers texte à données tabulaires, de fichiers GeoJSON et de fichiers GPX dans des classes d’entités stockées dans une géodatabase unique.
Utilisation
Par défaut, l’emplacement Input Data (Données en entrée) est régulièrement soumis à des recherches de fichiers KML (.kml), de fichiers KMZ (.kmz), de shapefiles (.shp), de classeurs Excel (.xlsx and .xls), de fichiers texte à données tabulaires (.csv, .txt et .tab), de fichiers GeoJSON (.geojson) et de fichiers GPX (.gpx). Le paramètre Filter (Filtre) peut être utilisé pour limiter les fichiers importés.
Les rasters, ou superpositions terrestres contenues dans un fichier KML ou KMZ, sont convertis en un jeu de données mosaïque au sein de la géodatabase Target Geodatabase (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 géodatabase Target Geodatabase (Géodatabase cible), le suffixe _Rasters leur étant ajouté. Par exemple, si la géodatabase Target Geodatabase (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 Target Geodatabase (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é en termes de latitude et de 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 dotés d’une extension .tab, une tabulation. Si vous souhaitez 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, 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 et des 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.
- Dans le cas de classeurs Excel et de fichiers texte aux données tabulaires, le système de coordonnées supposée de l’entrée est GCS WGS1984 et les valeurs des coordonnées de longitude et de latitude sont exprimées en degrés décimaux.
Si l’une des coordonnées de latitude ou de longitude en entrée d’une entité n’est pas valide (valeurs nulles ou non numériques), l’entité correspondante a une géométrie nulle. Il est possible de recourir à l’outil Vérifier les géométries pour vérifier la présence de géométries nulles dans la sortie.
Les fichiers texte à données tabulaires (.csv, .txt et .tab) et les feuilles de calcul Excel doivent comporter une colonne de longitude et de latitude. Les colonnes de longitude valides sont longitude, long, lon, x_coordinate, x_coord et x. Les colonnes de latitude valides sont latitude, lat, y_coordinate, y_coord et y. Si la source a plusieurs colonnes de longitude et de latitude valides, la première colonne valide est utilisée.
Toutes les feuilles de calcul d’un classeur Excel sont importées.
La symbologie est appliquée aux couches en sortie ajoutées à la carte en fonction de la symbologie des fichiers de données source comme suit :
Remarque :
Une carte active doit exister dans la projet ArcGIS Pro au moment de l’exécution de l’outil pour que la symbologie soit conservée. Si l’outil est exécuté en dehors d’un projet ArcGIS Pro, 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 du fichier 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 KMZ source. 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 sonné, 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 se nomme 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.
Syntaxe
arcpy.intelligence.BatchImportData(in_data, target_gdb, {filter}, {include_sub_folders}, {include_groundoverlay})| Paramètre | Explication | Type de données |
in_data [in_data,...] | Répertoires contenant les fichiers de données à convertir en classes d’entités de géodatabase. | Folder |
target_gdb | Géodatabase cible dans laquelle les classes d’entités en sortie sont stockées. | Workspace |
filter (Facultatif) | Filtre pour les données en cours d’ajout à la géodatabase. Les caractères génériques utilisés pour le filtre fonctionnent sur le chemin complet des données en entrée et sont répertoriés ci-dessous :
Voici quelques exemples de filtres :
| String |
include_sub_folders (Facultatif) | Indique si les sous-dossiers sont explorés de manière récursive.
| Boolean |
include_groundoverlay (Facultatif) | Spécifie si une superposition de sol KML ou KMZ (raster, photos aériennes, etc.) est incluse dans la sortie. Soyez prudent si le fichier KMZ désigne un service qui propose des images raster. L'outil essaie de traduire les images raster à toutes les échelles disponibles. Ce processus risque de prendre du temps et d'encombrer le service.
| Boolean |
Sortie dérivée
| Nom | Explication | Type de données |
| out_geodatabase | Géodatabase cible mise à jour. | Espace de travail |
Exemple de code
Le script de fenêtre Python ci-dessous illustre l’utilisation de la fonction BatchImportData en mode immédiat :
import arcpy
arcpy.BatchImportData_intelligence("c:/data/sourcedata", "c:/data/output.gdb", "", "SUBFOLDERS", "NO_GROUNDOVERLAY")Le script Python ci-dessous illustre l’utilisation de la fonction BatchImportData dans un script autonome :
# Name: BatchImportData_Example2.py
# Description: Imports all shapefiles with 'airport' in the file name or file
# path within a directory to feature classes in a single geodatabase.
# Requirements: Standard or Advanced license
# Import system modules
import arcpy
# Set local variables
in_data = ["c:/data/sourcedata"]
target_gdb = r"\\data\operationaldata.sde"
filter = "*airports*.shp"
include_sub_folders = "NO_SUBFOLDERS"
# Execute BatchImportData
arcpy.BatchImportData_intelligence(in_data, target_gdb, filter, include_sub_folders)Environnements
Informations de licence
- Basic: Non
- Standard: Oui
- Advanced: Oui
Rubriques connexes
Vous avez un commentaire à formuler concernant cette rubrique ?