Il arrive parfois que la diversité des outils de développement ArcGIS et les exigences du codage d’un service web rendent les extensions d’objet serveur et les intercepteurs d’objet serveur (SOE et 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, en précisément afin d’intégrer des fonctions d’impression haute qualité dans leurs applications web. Ils utilisent ArcObjects pour faire un travail de qualité avec les cartes, comme dans ArcMap, et avec leurs éléments environnants, générer des documents imprimables, etc.
Vous pouvez utiliser les modules Python arcpy.mapping (pour ArcMap) ou arcpy.mp (pour ArcGIS Pro) pour é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.
Les didacticiels suivants expliquent comment partager des mises en page d’impression personnalisées :
Changer 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.
Avec les API web ArcGIS, vous pouvez symboliser facilement des entités à l’aide d’une couche d’entités ou de graphiques côté client, dont les propriétés de rendu sont modifiables à 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 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é ultra-ciblé pour changer la symbologie sur vos couches de services de cartes. A la place, vous pouvez décider, à la demande, du contenu ou de la symbologie à utiliser dans la carte que vous souhaitez créer.
Pour définir la symbologie de vos couches dans les services de carte au moment de l’exécution, vous devez indiquer les informations du moteur de rendu dans votre demande de service web pour l’affichage de la carte, ainsi que les informations habituelles 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, entre autres.
Pour en savoir plus sur la modification du contenu et de la symbologie à la volée dans un service de carte, reportez-vous à la rubrique À propos des couches dynamiques.
Mise à jour Web
Dans les versions antérieures de ArcGIS Server, les données devaient être mises à jour sur le web exclusivement par du code personnalisé tirant parti de 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 :
Avant 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 processus 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 ArcObjects.
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 API 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 ?