Laissez-moi vous présenter un paragraphe de contexte avant d'aborder les choses amusantes : Dans une vidéo précédente<\/A>, j'ai inclus un exemple de capture d'une contrainte spatiale à partir de la carte ou de la scène active ArcGIS Pro et de son envoi dans un espace de travail ETL. L'exemple portait sur un service WFS ; ceux-ci ont un paramètre de boîte englobante qui peut restreindre les entités récupérées. Les services WFS prennent également en charge des opérateurs spatiaux plus complexes qui peuvent être utilisés avec des opérandes géométriques arbitraires fournis sous forme de fragments GML. Cependant, à moins que vous ne sachiez comment assembler tout le XML requis pour les requêtes WFS, vous serez comme moi et terrifié à l'idée d'essayer. ArcGIS Pro 2.3 lui-même ne prend en charge qu'une contrainte de boîte englobante sur les services WFS.<\/P><\/P>Les contraintes spatiales sont beaucoup plus faciles avec les feature services. Ce blog va vous montrer à quel point c'est simple.<\/P><\/P>Le géotraitement de base prend en charge les feature services comme paramètres d'entrée depuis plusieurs versions maintenant, pourquoi utiliser Spatial ETL avec des feature services ? Eh bien, si votre feature service est destiné à être exporté dans un autre format, ou si vous utilisez certaines transformations indiquant Data Interoperability, ou si votre feature service est très volumineux et que vous ne voulez pas utiliser des sélections pour le sous-ensemble. Je viens d'aider un client qui avait besoin de gérer dynamiquement une contrainte spatiale en plein ETL avec un transformateur FeatureReader (plus d'informations ci-dessous). Il y a beaucoup de cas d'utilisation.<\/P><\/P>Data Interoperability concerne les approches sans code, mais je vais faire une petite digression sur les paramètres de requête REST API des feature services pour que vous compreniez ce qui se passe. Ci-dessous se trouve une capture d'écran de la vue HTML d'un point de terminaison Query du feature service<\/A>. Notez qu'il y a un paramètre Input Geometry<\/STRONG> (fourni en JSON) et que vous pouvez définir son utilisation, dans mon cas c'est un Polygon<\/STRONG> pour lequel je veux uniquement les entités satisfaisant la contrainte Intersects<\/STRONG>.<\/P><\/P><\/P><\/P>Donc, l'astuce pour appliquer des contraintes spatiales aux feature services est simplement de fournir la géométrie !<\/P><\/P>Dans le téléchargement du blog (Pro 2.3+), vous trouverez l'outil exemple utilisé, mais l'approche est très simple, appliquez-la vous-même dans vos propres modèles. Cliquez pour agrandir ce graphique afin de voir la carte que j'ai utilisée, l'ensemble des entités dans la carte et la table des matières ainsi que le modèle exécuté comme outil. L'ensemble des entités pilote automatiquement la géométrie d'analyse.<\/P><\/P><\/P><\/P>L'outil utilisé est le Modèle nommé SpatiallyConstrainedGP<\/STRONG> qui a un paramètre d'entrée de type Feature Set. Au moment de l'exécution, vous fournissez une valeur en choisissant une couche ou une classe d'entités ou en créant une entité manuellement par édition dans la carte.<\/P><\/P><\/P><\/P>SpatiallyConstrainedGP<\/STRONG> encapsule l'outil ETL SpatiallyConstrainedETL <\/?STRONG> comme ceci, il y a un outil modèle Calculate Value<\/?STRONG> entre l'ensemble des entités d'entrée et l'outil ETL:<\/P><\/?P>
<\/P>
Les contraintes spatiales sont beaucoup plus faciles avec les feature services. Ce blog va vous montrer à quel point c'est simple.<\/P>
Le géotraitement de base prend en charge les feature services comme paramètres d'entrée depuis plusieurs versions maintenant, pourquoi utiliser Spatial ETL avec des feature services ? Eh bien, si votre feature service est destiné à être exporté dans un autre format, ou si vous utilisez certaines transformations indiquant Data Interoperability, ou si votre feature service est très volumineux et que vous ne voulez pas utiliser des sélections pour le sous-ensemble. Je viens d'aider un client qui avait besoin de gérer dynamiquement une contrainte spatiale en plein ETL avec un transformateur FeatureReader (plus d'informations ci-dessous). Il y a beaucoup de cas d'utilisation.<\/P>
Data Interoperability concerne les approches sans code, mais je vais faire une petite digression sur les paramètres de requête REST API des feature services pour que vous compreniez ce qui se passe. Ci-dessous se trouve une capture d'écran de la vue HTML d'un
<\/?P>
Tout ce que fait Calculate Value<\/?STRONG>, c'est transformer l'ensemble des entités d'entrée en une chaîne JSON avec un extrait Python:<\/?P><\/?p>
Le JSON est ensuite fourni au paramètre publié de l'outil ETL Input Geometry<\/?STRONG> (rappelez-vous le point de terminaison Query !) et...<\/?p>
...l'outil ETL fait son travail, ne considérant que les entités intersectant mon ensemble d'entités...<\/?p>
..qui consiste à créer un tableau récapitulatif de certains totaux de surface parcellaire par cas d'un attribut :<\/?p>
C'est tout, il suffit de récupérer du JSON depuis la carte lorsque vous devez fournir à un lecteur feature service un paramètre Input Geometry<\/?STRONG>. Si vous utilisez un transformateur FeatureReader pour lire un feature service, le flux de travail est un peu différent, vous devrez convertir le JSON en une véritable entité FME avec un GeometryReplacer<\/?STRONG> (le codage géométrique est Esri JSON<\/?STRONG>) et le fournir comme contrainte initiatrice Spatial Filter<\/?STRONG> du FeatureReader<\/?STRONG>, comme ceci :<\/?p>
Maintenant, vous pouvez appliquer des contraintes spatiales pilotées par la carte à votre ETL !<\/?BODY>
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.