Dans quelle mesure le langage SQL est-il accessible via les outils ArcGIS?

Cette question semble tellement redondante ...
Quoi qu'il en soit, on m'a demandé d'explorer les utilisations de SQL dans ArcGIS. Nous utilisons une base de données SDE pour tout le stockage côté serveur et la gestion des bases de données / l'édition à grande échelle. Cependant, j'essaie d'approfondir à quel point le SQL intégré est dans les outils d'ArcGIS. Il existe une note dans le Guide de référence des requêtes SQL de l'aide d'ArcGIS 10 qui indique clairement que la syntaxe SQL ne fonctionne pas lors de l'utilisation de l'outil Calculatrice de champ. Je trouve cela très décevant car il semblerait très utile de pouvoir extraire et manipuler des informations directement à partir de la base de données elle-même lors du calcul des valeurs de champ.

Quelles sont les limites et les pièges les plus importants que l'on pourrait rencontrer lors d'une tentative d'utilisation de SQL dans ArcGIS? Quels outils voient les meilleures fonctionnalités lorsqu'ils sont intégrés à SQL?

Si un exemple est nécessaire pour rendre cette question plus claire, j'essaie de suivre le nombre de points d'intérêt qui sont d'un certain type dans une région donnée. Chaque point a un attribut qui décrit son type et sa région. Ma solution actuelle implique une utilisation intensive de curseurs pour le comptage et la récupération de données, mais un supérieur a souligné qu'une simple requête SQL pourrait faire tout cela et plus encore. Malheureusement, il semble que la fonctionnalité ne soit pas présente pour cela.

Ou est-ce?

Si vous souhaitez utiliser Python, jetez un œil à la commande ArcSDESQLExecute . Cela vous permettra d'exécuter du SQL arbitraire mais il doit être connecté via SDE. Si le résultat de la requête est un ensemble de lignes, les attributs seront renvoyés sous forme de liste de listes Python. Sinon, il renverra True si le SQL a été exécuté avec succès ou None dans le cas contraire. Voir aussi: Exécution de SQL à l'aide d'une connexion ArcSDE

Si vous écrivez des ArcObjects personnalisés, vous pouvez exécuter du SQL arbitraire sur un espace de travail SDE à l'aide de la méthode ExecuteSQL . Cette méthode est limitée aux requêtes qui ne renvoient pas de jeux de résultats, telles que INSERT, UPDATE ou certaines procédures stockées.

Si vous travaillez via ArcMap UI, vos options sont un peu plus limitées. La raison pour laquelle vous ne pouvez pas utiliser SQL via Calculer le champ est que l'expression est en fait VBScript et / ou Python. Vous pouvez utiliser VBScript ou Python pour exécuter une expression SQL arbitraire et extraire des valeurs du curseur résultant, mais je ne le recommanderais pas.

Alternativement, vous pouvez utiliser la réponse de Regan et créer un calque de requête. Pour les données en lecture seule, c'est votre meilleure approche. Si vous avez besoin de mettre à jour des données, c'est un peu plus compliqué. Vous devrez créer une couche de requête avec vos "nouvelles" valeurs, effectuer une jointure avec votre table existante, puis utiliser les champs de calcul. Cela pourrait être combiné avec ExecuteSQL pour effectuer des mises à jour complexes, puis afficher les résultats (un peu maladroits).

Votre dernière alternative consiste à exécuter SQL directement sur les tables ArcSDE.

Vous devez vérifier les couches de requête dans ArcMap 10

Selon le SGBDR que vous utilisez, vous pouvez tirer parti des bibliothèques SQL en dehors d'ArcObjects ou d'arcpy, tant que vous ne dépendez pas de la récupération des données d'entité. De nombreuses requêtes dans la base de données SQL Server que j'utilise quotidiennement ne sont pas de nature spatiale, donc j'utiliserai les classes System.Data à l'intérieur de .NET, ou la bibliothèque pymssql Python à l'intérieur des applications Python. Si vous avez besoin d'utiliser des données spatiales, les couches de requête sont votre meilleur choix. La seule mise en garde avec les couches de requête est qu'elles ne fonctionnent qu'avec des données stockées à l'aide de types de données spatiales (pas le type SDEBINARY standard).