<\/HEAD>
Nous partons pour un voyage au fond de la mer, mais le véritable message ici est la capacité d'ArcGIS Data Interoperability à se connecter au web (ou ailleurs) et à intégrer des données de fonctionnalités et des médias dans une classe d'entités de géodatabase avec des pièces jointes sans avoir à coder. Bon, juste un tout petit peu, mais vous n'avez pas à vous soucier des détails comme un programmeur.<\/P>
<\/P>
Un collègue est venu me demander si ArcGIS Data Interoperability pouvait rassembler les données CSV de position et de temps des missions d'un submersible ainsi que le contenu média associé et tout intégrer dans une géodatabase. En production, toutes les sources de données seront sur le web. Aucun problème. Data Interoperability ne concerne pas seulement les formats et transformations, c'est aussi une question d'intégrations, et de les construire sans coder.<\/P>
<\/P>
<\/P>
<\/P>
Python intervient comme étape finale qui évite beaucoup de travail ETL compliqué. La combinaison d'un outil ETL et d'un peu d'ArcPy est un énorme multiplicateur de productivité pour tous les interopérateurs parmi vous. Explorez l'article après téléchargement pour voir comment les sources CSV et médias sont réunies - très simplement - ci-dessous se trouve tout le 'programme' :<\/P>
<\/P>
<\/P>
<\/P>
ArcGIS Data Interoperability a un excellent 'argument de vente', à savoir que vous pouvez éviter les flux de travail codés et utiliser le paradigme de programmation visuelle de Workbench pour faire passer les données de A à B et sous la forme souhaitée. Je montre souvent à mes collègues comment résoudre efficacement des problèmes d'intégration avec Data Interoperability et c'est toujours agréable de voir qu'ils comprennent que les défis ne doivent pas être relevés avec du code.<\/P>
<\/P>
Le codage bas niveau est ce que nous évitons.<\/STRONG> Les outils de géotraitement ArcGIS sont accessibles en tant que fonctions Python ; utiliser les outils de géotraitement ainsi est simplement une invocation en ligne de commande de ce à quoi vous avez accès dans le volet Géotraitement et la galerie d'outils du ruban Analyse, etc. Si cela est nouveau pour vous, jetez un œil et exécutez d'abord l'outil Get Count<\/STRONG> depuis la boîte à outils système puis utilisez le résultat dans la fenêtre Python.<\/P><\/P>Voici l'expérience avec l'outil :<\/P><\/P>
<\/P>
<\/P><\/P>Maintenant dans le volet Catalogue vue Historique, faites un clic droit sur le résultat et envoyez-le vers la fenêtre Python :<\/P><\/P>
<\/P>
<\/P><\/P>Vous verrez l'expression Python équivalente à l'outil :<\/P><\/P>
<\/P><\/P>Notez que je n'ai écrit aucun code...<\/STRONG><\/P><\/P>Où je veux en venir ? Les concepts d'ArcGIS Data Interoperability diffèrent un peu du géotraitement classique en ce que les paramètres <\EM> d'entrée et sortie ont tendance à être des espaces de travail parents et non des types d'entités ou tables à l'intérieur. Vous écrivez fréquemment dans des géodatabases par exemple, auquel cas le paramètre de sortie de l'outil ETL est la géodatabase<\EM>, pas les classes d'entités ou tables elles-mêmes, bien qu'elles soient configurées dans l'outil ETL.<\/P><\/><\/><\/>Que faire si vous devez faire quelque chose avant, pendant ou après votre processus ETL pour lequel il existe un outil puissant de géotraitement ArcGIS disponible mais qui serait vraiment difficile à faire dans Workbench ?<\/><\/><\/>Vous utilisez des fonctions Python ArcGIS haut niveau pour effectuer ce travail dans Workbench.<\/><\/><\/>Je vais donner un exemple simple et puissant sous peu, mais d'abord quelques conseils Python pour Workbench.<\/><\/><\/>Workbench vous permet de configurer votre environnement Python ; pour éviter tout conflit avec la gestion des paquets Pro, contentez-vous du paramètre par défaut et utilisez ces réglages :<\/><\/><\/>Dans Tools>FME Options>Translation<\/> vérifiez que vous préférez l'environnement Python Pro :<\/><\/><\/>
Dans votre Workbench, vérifiez que votre compatibilité Python utilisera cette préférence.
Maintenant vous savez que l'environnement Python ArcGIS peut être utilisé.
Pour mon cas d'utilisation, je fournirai un exemple réel (ci-joint ci-dessous) où je dois créer et charger des pièces jointes dans une géodatabase. Nous ne pouvons pas faire cela entièrement dans Workbench (sauf par la méthode que je vais vous montrer) car il ne peut pas créer la classe relationnelle des pièces jointes. Vous pourriez faire cela manuellement avant le chargement des données, mais ensuite vous devez toujours transformer les images en données blob, gérer les identifiants liés et autres choses qui donnent mal à la tête, alors utilisons ArcPy. Les étapes manuelles empêchent également la création de nouvelles géodatabases avec l'outil ETL, ce que je souhaite prendre en charge.
L'exemple Workbench écrit une classe d'entités destinée à avoir des pièces jointes, ainsi qu'une table pouvant être utilisée pour les charger. Vous pouvez étudier le traitement, mais l'élément clé à inspecter est le script d'arrêt exécuté après achèvement, voir Tool Parameters>Scripting>Shutdown Python Script.
Voici le script intégré :
Ceci n'est pas beaucoup de code, quelques imports, accès au dictionnaire disponible dans chaque session Workbench pour obtenir les valeurs du chemin de sortie utilisées au moment de l'exécution, puis juste deux lignes appelant des outils de géotraitement comme fonctions pour charger les pièces jointes.
C'est une excellente façon d'intégrer l'environnement Python puissant d'ArcGIS dans les outils ETL. Les personnes attentives remarqueront un paramètre scripté dans l'espace de travail aussi, il n'utilise pas ArcPy donc je ne peux pas prétendre qu'il évite le codage bas niveau, c'était juste une manière flexible de créer un dossier pour télécharger des images au moment de l'exécution. Il existe plusieurs façons d'utiliser Python dans Workbench, mais je m'éloignerais ici du message principal qui est que vous pouvez commencer par la méthode simple et puissante - utilisez le géotraitement ArcGIS là où cela fait gagner du travail. Profitez-en !
