La diversité des outils de développement ArcGIS et les exigences du codage d’un service web peuvent rendre les extensions d’objet serveur (SOE) et les intercepteurs d’objet serveur (SOI) intimidants pour les débutants. Cette rubrique examine certaines tâches SIG web courantes pour lesquelles les développeurs SIG ont écrit jusqu’à présent du code personnalisé et présente des méthodes différentes qui ne nécessitent pas de coder une SOE ou un SOI.
Créer des mises en page pour l’impression
De nombreux développeurs ont utilisé du code personnalisé pour accéder à l’objet Layout du service de carte, précisément afin d’intégrer des fonctions d’impression haute qualité dans leurs applications web. Ils utilisaient précédemment ArcObjects pour effectuer un travail de qualité avec les cartes et leurs éléments environnants, générer des documents imprimables grand format, etc.
Une autre possibilité consiste désormais à utiliser le module Python arcpy.mp (pour ArcGIS Pro) afin d’écrire le script de la construction de la mise en page et de l’impression des cartes. Ensuite, vous pouvez présenter le script au moyen d’un service de géotraitement ou d’un outil web. ArcPy vous permet de manipuler les cartes avec une extrême précision : vous pouvez ajouter dynamiquement des couches à la carte, mettre à jour leur symbologie, et plus encore. Vous pouvez également accéder à la mise en page de la carte, en manipulant des éléments tels que le texte et les images.
Le didacticiel suivant explique comment partager des mises en page d’impression personnalisées :
Modifier les symboles et les moteurs de rendu
Par le passé, les développeurs avaient également besoin de code personnalisé pour modifier la symbologie d’une couche particulière dans un service de carte. Ce processus nécessitait souvent d’avoir recours à des services non groupés, ce qui limitait l’évolutivité des applications. Certains développeurs réussissent à créer des applications avec des services groupés, même si le basculement incessant de l’état d’un service pour répondre aux requêtes de différents utilisateurs entraîne souvent de faibles performances et oblige le développeur à maintenir l’intégrité de l’instance de carte elle-même.
Les API web ArcGIS vous permettent de symboliser facilement les entités à l’aide d’une couche d’entités ou de graphiques côté client, dont les propriétés de rendu peuvent être modifiées à tout moment. Voici en quoi cela consiste : la géométrie et les attributs des entités visibles sont tous téléchargés sur le client. Il est donc facile pour ce dernier d’afficher les entités dans n’importe quelle couleur, largeur ou avec n’importe quelle borne de classes définie par le développeur de l’application.
La technique de la couche d’entité est particulièrement efficace pour cartographier thématiquement des entités, interagir avec les entités et les mettre en surbrillance, etc., mais elle l’est moins pour traiter des milliers d’entités ou des entités surfaciques très complexes. Dans ces cas, mieux vaut demander des modifications de symbologie au niveau du service et laisser le service de carte représenter l’image de la carte. Avant, cette opération requérait l’utilisation d’ArcObjects.
Vous pouvez maintenant modifier le contenu et la symbologie d’un service de carte au moment de l’exécution. Vous n’avez plus besoin d’utiliser du code personnalisé détaillé pour changer la symbologie sur vos couches de service de carte. A la place, vous pouvez décider, à la demande, du contenu ou de la symbologie à utiliser dans la carte que vous souhaitez créer.
La définition de la symbologie des couches du service de carte au moment de l’exécution s’effectue via l’inclusion des informations du moteur de rendu dans la requête d’affichage de carte de votre service web, ainsi que des informations standard de visibilité des couches, d’étendue, etc. Les API web ArcGIS comprennent des classes d’utilitaires qui vous permettent de définir facilement le contenu, les moteurs de rendu, les interruptions de classe, la symbologie, etc.
Pour en savoir plus sur la modification du contenu et de la symbologie en temps réel dans un service de carte, reportez-vous à la rubrique À propos des couches dynamiques.
Mise à jour Web
Dans les versions antérieures d’ArcGIS Server, les données devaient être mises à jour sur le web exclusivement via un code personnalisé exploitant les connexions (DCOM) locales. Grâce à l’introduction du service d’entités, il n’est plus nécessaire d’écrire des extensions pour cela.
L’API REST vous permet de mettre à jour les entités de vos services d’entités sur le web. Cette mise à jour est non seulement possible via REST, elle est également pratique à personnaliser du fait que plusieurs méthodes de mise à jour courantes (coupe, troncature, extension, polygones automatiques et remodelage, par exemple) sont exposées par l’implémentation REST du service de géométrie. De plus, la mise à jour versionnée est prise en charge dans les services d’entités.
Héritage :
Dans les versions antérieures à ArcGIS 10.1, vous pouviez utiliser des services non groupés pour effectuer des mises à jour suivant un modèle de transaction longue. Avec le service d’entités, toutes les opérations sont sans état, ce qui signifie que vous ne pouvez pas revenir au niveau de la base de données (bien que vous puissiez le faire avec une logique métier dans votre application). Cela ne vous empêche pas d’implémenter des opérations d’annulation/de rétablissement, comme avec les API web ArcGIS.
Exécution de la logique métier avec le géotraitement
Certaines applications SIG exécutent un ensemble particulier d’outils pour réaliser une logique métier SIG avancée. Ces outils peuvent prévoir le rendement en bois d’une forêt, localiser les sites adaptés à l’implantation d’un restaurant ou estimer l’endroit où un nuage toxique pourrait se répandre. De nombreux développeurs ont utilisé du code personnalisé pour en tenir compte.
Généralement, ces traitements peuvent être exprimés dans ModelBuilder, où vous pouvez « associer » graphiquement des outils. Ces modèles de géotraitement peuvent être proposés sous forme de services web et utilisés à partir de vos applications web. Des avantages indéniables se profilent : l’utilisation d’un service de géotraitement peut vous épargner beaucoup de codage. De même, vous pouvez tirer parti de l’exécution asynchrone de services de géotraitement, qui est difficile à atteindre en rédigeant votre propre code SOE.
Outre la flexibilité de disposer de milliers d’outils prêts à l’emploi que vous pouvez combiner dans ModelBuilder, le géotraitement vous donne la possibilité de développer des outils personnalisés. La méthode la plus simple consiste à créer des scripts Python exécutables seuls ou associés à d’autres outils au sein d’un modèle. L’utilisation de ArcPy pour créer des cartes de haute qualité sur le web, mentionnée plus haut dans cette rubrique, en est une illustration.
Que vous utilisiez Python ou un autre langage, les outils personnalisés ainsi créés présentent l’intérêt d’être réutilisables dans des processus différents puisqu’ils se comportent de la même manière que tout autre outil prêt à l’emploi. De plus, votre code personnalisé peut s’exécuter dans le modèle d’exécution asynchrone des services de géotraitement, ce qui est très pratique pour les traitements de longue durée.
Exécution de calculs géométriques
Bien que les services de géotraitement soient utiles, ils ne sont plus nécessaires pour effectuer des opérations de géométrie.
Les API clientes Esri, telles que ArcGIS Maps SDK for JavaScript et ArcGIS Runtime SDKs, proposent des bibliothèques de géométries locales complètes qui permettent notamment de réaliser des projections et de calculer des distances.
Si vous n’avez pas l’intention d’utiliser ces API clientes, vérifiez si le service de géométrie reposant sur SOAP ou REST offre les méthodes dont vous avez besoin. Un service de géométrie peut effectuer des opérations SIG classiques, telles que la bufférisation, la détermination des relations spatiales et la mesure des longueurs et des surfaces. Faire appel à une série de méthodes dans un service de géométrie et combiner cette opération avec les fonctionnalités de requête des services de carte et la logique côté client peut s’avérer plus simple et plus rapide que l’utilisation d’un service de géotraitement.
Vous avez un commentaire à formuler concernant cette rubrique ?